Security events with un-resolvable SID's
Hi,I am seeing some strange behavior with the security event log on domain controllers. I am wondering if anyone can verifiy if it is expected, if I have a configuration issue or hepl me verifiy domain trusts.I have a forest root domain (domain A) with two child domains (domain B,C) configured, afaik, properly. All normal communication and authentication seems to occur without error.Whenever an event that contains information about a user from a different domain occurs on a domain controller the SID in the event is un-resolvable. We noticed this because we recieve errors in our log gathering device whenever a user from domain A or B was added to a universal group in domain C.The event generated on domain C looks like this:660Security Enabled Universal Group Member AddedMember Name: DN of user.Member ID: S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx-0Target Account Name: Universal Group NameTarget Domain: Domain CTaret Account ID: Domain C\Universal Group NameCaller User Name: user that made changeCaller Domain: domain of user that made changeAlways the RID for the SID is zero (0). It does not resolve to a user name using any tools that I have. Using the right SID for a user in domain A or B resolves fine from any domain controller on C so it seems the SID being recorded in the log is invalid.Can anyone shed some light on this? I have been googling for days on what this means and found lots of issues regarding the inablity to resolve a SID across domain trusts, but nothing about an invalid SID in the event log.Thanks,-Jay
March 3rd, 2008 7:10pm
I have not tried to nail this down before, so here are my ideas... It would make sense to me that this would be the case. Your local domain isn't going to have any way of information about the users from other domains (outside of the global catalog anyway) and the event logs are generated at a domain level. Some things that you could try (they might make a replication storm, so I would try it in a lab first) are: 1. In both the target and the source domains, go into the AD schema snap-in and, ifit isnt already, setthe "objectSID" attribute to Replicate to the Global Catalog, Index the attribute in AD, and Index the attribute for Containerized searches. 2. Enable the caching of Universal Groups: http://technet2.microsoft.com/windowsserver/en/library/08f11546-a6ed-4045-9d60-20a5fc1db11b1033.mspx?mfr=true Let me know what you find,
March 3rd, 2008 7:41pm
Thanks for the quick reply.I allready checked to make sure that the objectSid atrrib. was in the GC. It is.I did come across the caching article a few days ago but ruled it out. Do you think it could resolve the issue? I don't have a lab setup yet so I was trying to get a definitive without having to troubleshoot on the prod. domains.Thanks,-J
March 3rd, 2008 7:49pm
Step #1 - set up a lab I think that the annoynace of the event logs are going to be a far distant second to the havoc that could arise from lack of lab... In the short term, you could use Virtual PC even, and run two or three virtual machines. Long term, you are definately going to want to have a lab running on servers. Caching the infomrationprovides a copy of universal group information on all of your DCs, eliminating the need for a Global Catalog during Universal Group lookups. This reduces network chatter and increases logon times, so I think that you might want to consider doing this on its own merits - it may also fix this problem which would be an additional benefit. Indexing the attribute for containerized searches will increase the size of your AD database and will initially slow things down a bit, but if your DCshavespare CPU and IO cyclesand you have a smaller environment, you could be reasonably sure that this wouldn't provide too harsh of a consequence - but that recommendation is based on testing in labs that reflect your environment The definitive way to solve this problem is to use a product like MOM or SCOM and while monitoring events, when seeing an event like this, have a scripted, automated response to perform an LDAP query to resolve the user's SID based on the DN. It is an extra step, but you should be using a monitoring product anyway (best practices), so it shouldn't be all that much extra work.
March 3rd, 2008 8:11pm
Hi, I performed a test on my side and I could reproduce this issue. The following is the test result: 1. The unsolved SID is only displayed when you modify the universal group membership by adding or removing accounts and groups that are not in the local domain. 2. The 'domain_id' is just the Local Domain ID instead of the ID of the domain that the membership resides. 3. The Event ID 660 is a success audit event that indicate the membership operation is successful. So I think this should be expected in the Windows Server 2003 Active Directory. Hope this helps.
March 5th, 2008 1:12pm
Just a hunch but you may want to check whether your DC holding the Infrastructure Master FSMO role is also a Global Catalog server. An Infrastructure Master should not be a GC (unless all the DCs in the forest are GCs as well). Salvador Manaois III MCSE MCITP CEH http://badzmanaois.spaces.live.com/blog
March 18th, 2008 6:55pm