Solved

Receiving same SID for two different Builtin groups

Posted on 2009-04-05
8
727 Views
Last Modified: 2013-12-17
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
Comment
Question by:resham
  • 4
  • 4
8 Comments
 
LVL 83

Expert Comment

by:oBdA
ID: 24075026
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
 

Author Comment

by:resham
ID: 24075217
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
 
LVL 83

Accepted Solution

by:
oBdA earned 500 total points
ID: 24075294
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
DevOps Toolchain Recommendations

Read this Gartner Research Note and discover how your IT organization can automate and optimize DevOps processes using a toolchain architecture.

 

Author Comment

by:resham
ID: 24075953
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
 
LVL 83

Expert Comment

by:oBdA
ID: 24076004
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
 

Author Comment

by:resham
ID: 24076575
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
 
LVL 83

Expert Comment

by:oBdA
ID: 24076704
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
 

Author Closing Comment

by:resham
ID: 31566907
Thanks oBdA for all your help.
0

Featured Post

Netscaler Common Configuration How To guides

If you use NetScaler you will want to see these guides. The NetScaler How To Guides show administrators how to get NetScaler up and configured by providing instructions for common scenarios and some not so common ones.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Find out how to use Active Directory data for email signature management in Microsoft Exchange and Office 365.
In this article, I am going to show you how to simulate a multi-site Lab environment on a single Hyper-V host. I use this method successfully in my own lab to simulate three fully routed global AD Sites on a Windows 10 Hyper-V host.
This Micro Tutorial hows how you can integrate  Mac OSX to a Windows Active Directory Domain. Apple has made it easy to allow users to bind their macs to a windows domain with relative ease. The following video show how to bind OSX Mavericks to …
This video shows how to use Hyena, from SystemTools Software, to bulk import 100 user accounts from an external text file. View in 1080p for best video quality.

770 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question