Oh great, like the water needed to be any muddier... Thanks Lee, I hadn't seen this yet. I will have to look into it. Something that makes Exchange even more "special". Have I complained recently on how much I dislike the Exchange permissioning model. ;o)
-- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lee Flight Sent: Monday, January 08, 2007 8:35 AM To: ActiveDir@mail.activedir.org Subject: RE: RE: [ActiveDir] SID Deleted users remains in NTS permission. One example that I would highlight that can muddy the water in attempting tracking of resolvable SIDs is that the SID might be from an Authority that does not resolve by a native windows mechanism/api e.g. an SD that contains a SID from the SECURITY_RESOURCE_MANAGER_AUTHORITY (S-1-9-etc). I had not seen an example of this until a few months ago when I noticed such SID appearing in DSACLS output in an Exchange 2007 deployment[1]. Lee Flight [1] See Table 3 in http://technet.microsoft.com/en-us/library/315d9c42-1ab4-4ef4-9292-12cdcb9c9 8cf.aspx On Sun, 7 Jan 2007, joe wrote: > Because as mentioned in my post, this is a very difficult and complex task > given the current security infrastructure. There is nothing maintaining > backlinks into where specific SIDs are used for ACLing. Even so, as Wook and > Deji and I all mentioned, there are times where something could have a SID > in an ACL and be perfectly valid but some sort of burb or in progress issue > causes the SID to be temporarily unavailable. This kind of thing happens > pretty regularly and people don't tend to catch it because MSFT, > intelligently, didn't go through and scrub the ACLs when this occurred. If > they did, people would be posting all of the time how some group or user or > other security principal lost access to something or in the case of DENY > ACEs all of a sudden had access to something. It is a very fine line between > being helpful and being destructive. > > In order to implement this so it was effective and efficient I would > visualize something that would have to track ALL uses of SIDs (not just file > system or AD) with a backlink table and would somehow get notifications when > a security principal was truly deleted and it was intended to be so and > wouldn't be coming back (i.e. someone didn't pull a whoops). The first is > extremely involved but likely possible from a technical standpoint though it > would cause bloat somewhere where that info is stored. The second is near > impossible, IMO, because it involves people not screwing up and I don't > expect to see that day happen. > > A couple of other items to think about, you have more than ACes that have > the SIDs in a security descriptor, you also have the owner and the group. > You don't just want to zap the old value out, you want something there, what > do you put there? Administrators? LocalSystem? What? Now what if you want to > go clean all those up and reassign them to someone else? You are in the same > place you were when you had the old missing user/group object. > > I have posted this before (slightly different because then it included DNs), > but here is a portion of the list list of objects that can have SIDs > embedded: > > 1. Windows Security Descriptors - this includes any kernel securable objects > that can accept a security descriptor as well as many other objects that > have "customized" ACL-like definitions like the customSD for event logs. A > partial list of the "official" securable objects off the top of my head: > > O Active Directory Objects > O SAM Objects (users and groups on member machines) > O File System Objects (files/directories) > O Threads/Processes > O Synchronization objects (mutexes, events, semaphores, timers) > O Job Objects > O Network shares > O Printers > O Services > O As of 2003 SP1 the Service Control Manager itself > O Registry keys > O Windows Desktops and Windows Stations > O Access tokens > O File Mapping objects > O Pipes (named or anonymous) > > Basically anything that allows you to pass in a SECURITY_ATTRIBUTES > structure when creating the object plus more.... > > 2. Microsoft supplied Windows based applications. This includes things like > ADAM, SQL Server, Exchange, SharePoint, etc etc etc ad nauseum. > > 3. Third party applications that run on Windows and were written "properly" > to take advantage of Windows security. This list could be long and wide, > there are hundreds of thousands of Windows applications out there. > > 4. Third party applications that run on Windows and were written incorrectly > to take advantage of Windows security. These apps don't use Windows security > descriptors, they use custom security structures that are based on Windows > Security Descriptors or are completely different but rely on SIDs. An > example here would be how the event log security stuff was implemented in K3 > which uses a basic Windows Security Descriptor SDDL format type that isn't > quite "standard". > > 5. Ditto #4 but running on non-Windows platforms. > > 6. Applications that use the groups for something other than security but > still use the SID for identification purposed to avoid rename issues. For > instance an IM app that uses groups for contact lists or an email app using > groups for mail distribution. > > Numbers 3-6 are exceptionally hard to trace because in all but limited > cases, it is pretty much guaranteed no well known well used interface is > available to enumerate this info. You are completely dependent on how well > you understand your environment and how well you know the underpinnings of > what is running in that environment. > > 7. Any attribute in AD or ADAM or in fact any directory that takes a SID. As > an example here, in an Exchange/LCS enabled R2 Forest there are roughly 20 > SID attributes, hundreds of string types wihch could have SIDs in string > format, etc. > > 8. Cross forest uses which are represented through FSPs in the foreign > forests. > > 9. Privileges/Rights (in GPOs or security policy files) > > > Again, the flexibility of the security model is what makes it very powerful > and also difficult to work with. For folks who are policy/standards > challenged, it is a great way for them to get into a very messy situation. > Anyone who thinks that ad hoc is the best way to run their technology stuff, > well they are in for some challenges. Certainly it can be done properly, but > it requires discipline. Unfortunately in many of the ad hoc just get it done > do whatever it takes environments I have been in, discipline is not a common > trait. It isn't a problem until cleanup or reporting/auditing becomes an > issue or things are just such a trainwreck that the system isn't performant > > As an example of that trainwreck.... One company I was in had a very strict > policy about how security was to be applied to project shares... One day > (actually I can say I had this story times about 100 for that one company) > the folks in a Chicago plant are complaining because AD has been getting > slower and slower over the months and now it is unbearably slow. Of course I > knew more about how well AD was running than the person complaining because > it was my job to know and very few folks knew we monitoring things very > closely because most of them didn't themselves but as many of you know, the > AD admins are usually the admins that have to figure out everyone else's > issues or the issues don't get figured out and people just whine. I dug into > it and sure enough, the very well published and documented standards weren't > being followed at all and they had literally hundreds of unresolvable SIDs > on the root folder of the file share and once you dived down into the > subfolders you found thousands of unresolvable SIDs which of course > propogated to hundreds of folders and tens of thousands of files. Had they > followed the standard there would have been maximum of about 5 fully > resolveable SIDs on the top level folder and the direct subfolders would > have had an additional 2-3 SIDs that almost certainly were always > resolveable... This obviously was impacting the speed at which the ACLs > could be displayed when someone needed to look but it also impacted the > access to the objects because Windows was forced to wade through all of that > garbage to verify access when anyone did anything with the folders or files. > > > Could something be written third party of via scripts to clean these kinds > of things up, yes. If you intend to do so make sure the utility has belt, > suspenders, super glue, rubber bands and anything else you can think of to > doublecheck and validate and verify before changing anything because it > could be a nightmare for someone. Also it should be able to completely undo > what it did quite quickly because again, lots of security problems could > come up. Both in lack of access and for those folks who were silly with Deny > ACEs people getting access that they shouldn't. The main thing is that the > only folks who need SIDs to be resolvable to names are people, Windows > doesn't resolve a SID to a name to figue out if someone has access to > something, SIDs are compared, not names. > > joe > > > -- > O'Reilly Active Directory Third Edition - > http://www.joeware.net/win/ad3e.htm > > > > > _____ > > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Haritwal, Dhiraj > Sent: Thursday, January 04, 2007 10:18 AM > To: ActiveDir@mail.activedir.org > Subject: RE: RE: [ActiveDir] SID Deleted users remains in NTS permission. > > > > But still the actual discussion is pending. If someone is having a single > folder which is mapped to a single user. So in that case how we can use > groups & suppose tomorrow this user left the organization & his account got > deleted, SID will come on to the permission of that folder. If I am not > wrong the actual discussion was why SID is coming after deleted an account. > Why its not getting deleted automatically. > > > > > > Dhiraj Haritwal > > > > > > _____ > > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of joe > Sent: Thursday, January 04, 2007 7:18 PM > To: ActiveDir@mail.activedir.org > Subject: RE: RE: [ActiveDir] SID Deleted users remains in NTS permission. > > > > Not sure why this suprises you. The ACLs are not maintained by AD nor the > SAM where the user accounts exist which means you either get to poll or put > some form of notification system in process. Consider also the case of > trusted security principals, systems don't get a notification when a trusted > system deletes a security principal. > > > > Here are just a couple of the bad things that could happen if the machines > were responsible for cleaning up those SIDs > > > > 1. Overhead. Do you know the sheer number of Security Descriptors that are > on any given system? You are just thinking of file Security Descriptors but > there are Security Descriptors on many many different securable objects. I > have published the list of items I at least know about to this list on a > couple of occasions and the different types of objects alone is double > digits let alone the actual instants of those objects. Consider a file > system with hundreds of thousands or millions of Security Descriptors with > really long ACL chains. You could have a scavenger thread running 24x7 in > idle mode (you wouldn't want it higher as it would eat up CPU and that would > be a different complaint) just constantly walking the ACLs and verifying > them. > > > > 2. Mistakes. Since we don't have a change notification capability for > deleted security principals, and quite honestly you wouldn't (could you > imagine 300,000 machines registering with every domain in your forest for > change notifications of security principal changes) so that leaves polling > and lets say you have a tempory network glitch that makes a SID unresolvable > to a friendly name... Do you then just start stripping the SIDs from the > ACLs because a name can't be resolved once, twice, three times? What about > when an account gets undeleted or restored because it was accidently deleted > for an hour? > > > > I can think of even more bad things but don't have the time to write about > them. If you want to, think through how you would build an application to do > what you are suggesting. It is always a good thought exercise before being > surprised at what MSFT has done. Keep in mind they are a collection of > really bright programmers that often have to work in committee, they aren't > necessarily miracle workers. > > > > Could this be done? Maybe. I think could visualize mechanisms to possibly > help here but would really have to think it through even more than I have > and I have thought a lot about things like this... But it would take serious > rework with how security is implemented on Windows and I would be quite > fearful of the scaling capabilities. The Windows security system is > difficult to work with and can be quite a pain but it is extremely flexible > and powerful at the same time. I have started and stopped several times to > write all inclusive security tracking tools, it is a big big deal and if > done wrong will really make someone have a bad day. > > > > As someone else mentioned, use groups. Don't use users. When you go to > delete a group, make it a point to clean up where that group has been used. > If you don't know where it has been used, that is a process issue and one of > the reasons why I am not a fan of universal and global groups because the > scope of use is huge. Alternately write your own tools to scan all of the > various ACLs looking for unresolvable SIDs and clean them up, but I would be > shy on how agressive you are with the cleanup. You can easily screw yourself > up. > > > > joe > > > > -- > > O'Reilly Active Directory Third Edition - > http://www.joeware.net/win/ad3e.htm > > > > > > > > _____ > > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Yann > Sent: Thursday, January 04, 2007 5:35 AM > To: ActiveDir@mail.activedir.org > Subject: RE : RE: [ActiveDir] SID Deleted users remains in NTS permission. > > Thanks for replying. > > > > You say that it is normal that the sid still remains in file & directory > ACLs after the deletion of the corresponding group ?? > > > > I always thought that sids *HAVE TO* disapear dynamically on all existing > ACLs set on file server. > > I'm a bit surprise that the system (AD<->file server) leave this dirty sid > and that there is no synchronisation that updates the "link" between the AD > object and the ACE.... > > > > What is the reason ? could this behavior be altering ? > > > > I'd like sid disappears after deletion of the corresponding group in AD in > order to not have this dirty SIDs... > > > > Thanks. > > > > Yann > > > > "Akomolafe, Deji" <[EMAIL PROTECTED]> a écrit : > > It's "normal". You should be permissioning your resources with groups > instead of directly with user accounts. Groups tend to last longer, so you > don't have to deal with the horrible SIDs. > > > > > Sincerely, > _____ > (, / | /) /) /) > /---| (/_ ______ ___// _ // _ > ) / |_/(__(_) // (_(_)(/_(_(_/(__(/_ > (_/ /) > (/ > Microsoft MVP - Directory Services > www.akomolafe.com <x-excid://32770000/uri:http:/www.akomolafe.com> - we > know IT > -5.75, -3.23 > Do you now realize that Today is the Tomorrow you were worried about > Yesterday? -anon > > > > > _____ > > > From: Yann > Sent: Thu 1/4/2007 1:52 AM > To: ActiveDir@mail.activedir.org > Subject: [ActiveDir] SID Deleted users remains in NTS permission. > > Hello all & Happy new year ! :) > > > > AD 2k3 sp1 in FFL mode. > > > > When i delete a user or group from AD, and these objects have permissions on > ntfs permissions, i usually see their sids remaining in those file & > directory ACLs. > > > > Is this normal ? If not,what could be the reason(s) & how to investigate > this issue ? > > > > Thanks, > > > > Yann > > > > > > __________________________________________________ > Do You Yahoo!? > En finir avec le spam? Yahoo! Mail vous offre la meilleure protection > possible contre les messages non sollicités > http://mail.yahoo.fr Yahoo! Mail > > > > __________________________________________________ > Do You Yahoo!? > En finir avec le spam? Yahoo! Mail vous offre la meilleure protection > possible contre les messages non sollicités > http://mail.yahoo.fr Yahoo! Mail > > _____ > > > This email is confidential and intended only for the use of the individual > or entity named above and may contain information that is privileged. If you > are not the intended recipient, you are notified that any dissemination, > distribution or copying of this email is strictly prohibited. If you have > received this email in error, please notify us immediately by return email > or telephone and destroy the original message. - This mail is sent via Sony > Asia Pacific Mail Gateway. > _____ > > Lee Flight __________________________________________________________ Lee Flight ([EMAIL PROTECTED]) Tel: +44 (0)116 252 2257 Network Support Section, Computer Centre, University of Leicester Leicester LE1 7RH, United Kingdom List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ma/default.aspx
