Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 746
  • Last Modified:

Receiving same SID for two different Builtin groups

Hello,
I want to search all the local & domain groups and let user select them to add to our application.
For local groups I am searching on 'WINNT\LocalMachineName' root DirectoryEntry and for global groups I am searching on domain root using LDAP.
Everything else works fine except for BuiltIn groups.

When I search 'Administrators' groups, I get below two entries along with others:
LocalMachineName\Administrators
DomainName\Administrators

First one is my machine (2k3 server) builtin group and second one is DC machine's builtin group

My problem is I am getting same SID for both the groups. Why is it happening??
For getting local group entry I am using following code:
==============
string path = string.Format("WinNT://{0}", domain);
DirectoryEntry entry = new DirectoryEntry(path);
foreach (DirectoryEntry dirChildEntry in entry.Children)
{
string entryName = dirChildEntry.Name;
NTAccount acct = new NTAccount(entryName);
SecurityIdentifier sid = (SecurityIdentifier)acct.Translate(typeof(SecurityIdentifier));
}
==============

And for getting Global entry, I am using following code:
==============
string path = string.Format("LDAP://DC={0},DC=com", domain);
DirectoryEntry entry = new DirectoryEntry(path);

string filter = string.Format("(|(| (& (objectCategory=group)(sAMAccountName={0}) ) (& (objectCategory=group)(displayName={0}) ) (& (objectCategory=group)(cn={0}) ) )(| (& (objectCategory=person)(objectClass=user)(sAMAccountName={0}) ) (& (objectCategory=person)(objectClass=user)(givenName={0}) ) (& (objectCategory=person)(objectClass=user)(sn={0}) ) (& (objectCategory=person)(objectClass=user)(displayName={0}) )))", searchString);

mySearcher.Filter = filter;
SearchResultCollection results = mySearcher.FindAll();

foreach (SearchResult result in results)
{  
    object resName = result.Properties["Name"][0];
    object resAccount = result.Properties["sAMAccountName"][0];
    object resSID = result.Properties["objectSid"][0];
    SecurityIdentifier sid = new SecurityIdentifier((byte[])resSID, 0)
}
==============
Basically if we iterate members of global group, we can see members of DC group then why is this happening?? To make sure, we even changed names of built in groups on local machine and DC machine. We get the different names for both results but SID is same.

While searching on domain, we are using DC administrator's credentials so that there should not be any access issues.

I am stuck here so any help would be greatly appriciated.
0
resham
Asked:
resham
  • 4
  • 4
1 Solution
 
oBdACommented:
You're getting S-1-5-32-544 for both? That's perfectly normal, because the built-in group "Administrators" on a DC is the actual local group "Administrators", and the "Administrators" group is a well-known SID. It's the same on all machines.
Well-known security identifiers in Windows operating systems
http://support.microsoft.com/kb/243330
0
 
reshamAuthor Commented:
Thanks oBdA for ypur reply.

Just to make sure, we changed name of 'Administrators' group on local machine and on DC machine, then changed names appeared on respective accounts. Plus members are different (global) on DC machine's Administrators group than the local machine's Administrators group.

I know both are builtin groups but they belong to different machines and they have different (NT) accounts then shouldnt they have different SIDs?

Thanks & Regards,
Reshma
0
 
oBdACommented:
Again: the group "Administrators" (whether renamed or not; renaming does not change the SID) has the same well-known SID of S-1-5-32-544 on *all* NT based installations. This is a *local* group, it has no relation to the domain. The membership has nothing to do with the group's SID.
Quote from the article above:
"[...] Well-known SIDs are a group of SIDs that identify generic users or generic groups. Their values remain constant across all operating systems.
[...]
SID: S-1-5-32-544
Name: Administrators
Description: A built-in group. After the initial installation of the operating system, the only member of the group is the Administrator account. When a computer joins a domain, the Domain Admins group is added to the Administrators group. When a server becomes a domain controller, the Enterprise Admins group also is added to the Administrators group."
0
Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
reshamAuthor Commented:
Hi oBdA,

Thanks for explanation. I got it that irrespective of the machines, SID will be same for Builtin administrators group.

Now my requirement is, I want to treat these two groups seperate. When user will select any group for the policy defined in my application, then that policy should be applicable to its members. To establish the link between policy and selected users/groups, we use (our parent product's framework) SIDs. As SID being same for both the groups, link gets added for BUILTIN\Administrators group all the time and it points to local builtin group.

So is there any solution for this? Can u suggest me some pointers to think?

I appreciate your help a lot.

Thanks & Regards,
Reshma
0
 
oBdACommented:
There is no solution for that. A local group is exactly that: a local group that is not accessible from other machines; its scope is exclusively local.
If you're querying for the group "Administrators" (or a group with the SID S-1-5-32-544), you will only ever be able to pick the *local* group, not one on another machine.
0
 
reshamAuthor Commented:
Okay but still remains one question:

Why does my LDAP search returns BUILTIN groups of domain controller machine then?? If I cannot access them or treat them as a seperate entity and they are LOCAL to DC then why do I see them?

I dont see these groups of any other (non DC) machine in my search.

Thanks for being patient and answering all my queries.

Regards,
Reshma
0
 
oBdACommented:
Because you need a possibility to manage these groups on a DC as well, and the "normal" local management tools on a DC are only accessible if the DC is booted in DSRM mode. But just because you see them in ADUC/LDAP doesn't mean you can anything (useful) with them on a member server.
0
 
reshamAuthor Commented:
Thanks oBdA for all your help.
0

Featured Post

What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

  • 4
  • 4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now