RE: RE: [ActiveDir] SID Deleted users remains in NTS permission.
Even tools that would help with this sort of thing just in the AD would be welcomed. As far as I know, there's no GUI for finding out all the places just in AD where a particular security principal is asserted. I'd like to be able to find any (non-inherited) ACE that refers directly to a user account so that I can look to see why they aren't using a group. Even with tools like DSACLS, it's not clear which object you actually need to touch. Wook From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Sunday, January 07, 2007 9:27 AM To: ActiveDir@mail.activedir.org Subject: RE: RE: [ActiveDir] SID Deleted users remains in NTS permission. 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
RE: RE: [ActiveDir] SID Deleted users remains in NTS permission.
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
RE: RE: [ActiveDir] SID Deleted users remains in NTS permission.
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
RE: RE: [ActiveDir] SID Deleted users remains in NTS permission.
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
[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
RE: [ActiveDir] SID Deleted users remains in NTS permission.
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 - 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
RE: [ActiveDir] SID Deleted users remains in NTS permission.
and to remove those orphaned SIDs you could use SUBINACL (make sure you download the lastest version from the MS site) Met vriendelijke groeten / Kind regards, Ing. Jorge de Almeida Pinto Senior Infrastructure Consultant MVP Windows Server - Directory Services LogicaCMG Nederland B.V. (BU RTINC Eindhoven) ( Tel : +31-(0)40-29.57.777 ( Mobile : +31-(0)6-26.26.62.80 * E-mail : see sender address From: [EMAIL PROTECTED] on behalf of Akomolafe, Deji Sent: Thu 2007-01-04 10:53 To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] SID Deleted users remains in NTS permission. 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 - 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 This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. winmail.dat
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 - 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
Re: RE: [ActiveDir] SID Deleted users remains in NTS permission.
The ACEs in the ACL on the file server are maintained by the LSA on that server. ACLs on member servers are nothing to do with AD really. AD is used to verify the SIDs in the ACLs when necessary, but it's the local LSA that's doing the authorisation (based on the information in one's security token which AD participates in generating). Managing the ACLs is the client's job, not the DCs job. I don't see this changing in the future. It would be far to complex and expensive to have the DCs manage this kind of stuff. The whole MSFT client-server design is based on the client systems doing most of the leg work. Clients always use servers. Servers don't use clients. --Paul - Original Message - From: Yann To: ActiveDir@mail.activedir.org Sent: Thursday, January 04, 2007 10:35 AM 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 - 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
RE: RE : RE: [ActiveDir] SID Deleted users remains in NTS permission.
The issue is that there is no automated service in AD/Windows that reconciles the SIDs in AD with those used to ACL the file system; and AD ACLs are separate and disconnected from the OS ACLs. Imagine deleting a group or user that had permissions on hundreds of computers around your network the OS on each box would have to *know* that the user or group was deleted then scan itself for obsolete SIDs or alternativly some service on the DC could contact each server to scan it for obsolete SIDs. As Deji correctly pointed out this is another example of why you should use groups to do your permissioning... it is also one of the reasons why many administrators choose to disable user accounts rather than just delete them when they become obsolete. Bob From: [EMAIL PROTECTED] on behalf of Yann Sent: Thu 1/4/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 - 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
RE : RE: RE : RE: [ActiveDir] SID Deleted users remains in NTS permission.
Ok, interesting thing you point out. So in the case of restoring the group deleted, there will also no automated service that reconcilies the sid in AD with those used to ACL the file system ? Today, I discovered something i thought i master... :) Thanks all for clarification to this subject. Robert Bobel [EMAIL PROTECTED] a écrit : The issue is that there is no automated service in AD/Windows that reconciles the SIDs in AD with those used to ACL the file system; and AD ACLs are separate and disconnected from the OS ACLs. Imagine deleting a group or user that had permissions on hundreds of computers around your network the OS on each box would have to *know* that the user or group was deleted then scan itself for obsolete SIDs or alternativly some service on the DC could contact each server to scan it for obsolete SIDs. As Deji correctly pointed out this is another example of why you should use groups to do your permissioning... it is also one of the reasons why many administrators choose to disable user accounts rather than just delete them when they become obsolete. Bob - From: [EMAIL PROTECTED] on behalf of Yann Sent: Thu 1/4/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 - 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 __ 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
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 x-excid://3277/uri:http://www.akomolafe.com www.akomolafe.com - we know IT -5.75, -3.23 Do you now realize that Today is the Tomorrow
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 it's 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
Re: RE: [ActiveDir] SID Deleted users remains in NTS permission.
Because it's not managed by the DS. The SID as you refer to it is actually an ACE. The ACE is an item that makes up the DACL which makes up the ACL. This is managed locally by the member server. Windows itself. The LSA. It's far too expensive and problematic with the current design for this to auto-manage itself. Re-read Joe's post. The DS doesn't know or care where a security principal is referenced as an ACE in an ACL. And the computer in question shouldn't really auto-prune the ACEs based on a rule or two... --Paul - Original Message - From: Haritwal, Dhiraj To: ActiveDir@mail.activedir.org Sent: Thursday, January 04, 2007 3:18 PM 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 it's 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
RE : RE: RE: [ActiveDir] SID Deleted users remains in NTS permission.
Hi, After rereading posts, it now makes sense to me that the ACEs are managed by the local LSA, and not by AD LSA So now if i consider that a group or user is deleted from AD and that object is set on an AD object ACLs (not share or ntfs permission), that object will be definitively disappear with no sid remaining from the ACLs, because the update is done by the local LSA (DC) where the deletion occurs, that is to say AD itself... Yann joe [EMAIL PROTECTED] a écrit : 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
Re: RE: RE: [ActiveDir] SID Deleted users remains in NTS permission.
No. Not quite. No cleanup happens whatsoever. Even when the ACEs are in the AD they aren't cleaned up. The LSA was mentioned to try and highlight the expense and difficulty of such a cleanup operation. The fact of the matter is that regardless of the securable object, it's ACE is managed locally and no cross-checking is done against a DC and a DC certainly doesn't look for stale ACEs when an object is deleted. Hope this clarifies the point. --Paul - Original Message - From: Yann To: ActiveDir@mail.activedir.org Sent: Thursday, January 04, 2007 3:54 PM Subject: RE : RE: RE: [ActiveDir] SID Deleted users remains in NTS permission. Hi, After rereading posts, it now makes sense to me that the ACEs are managed by the local LSA, and not by AD LSA So now if i consider that a group or user is deleted from AD and that object is set on an AD object ACLs (not share or ntfs permission), that object will be definitively disappear with no sid remaining from the ACLs, because the update is done by the local LSA (DC) where the deletion occurs, that is to say AD itself... Yann joe [EMAIL PROTECTED] a écrit : 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
RE : Re: RE: RE: [ActiveDir] SID Deleted users remains in NTS permission.
Yes, definitively ;o) Thanks again ! Cheers, Yann Paul Williams [EMAIL PROTECTED] a écrit : No. Not quite. No cleanup happens whatsoever. Even when the ACEs are in the AD they aren't cleaned up. The LSA was mentioned to try and highlight the expense and difficulty of such a cleanup operation. The fact of the matter is that regardless of the securable object, it's ACE is managed locally and no cross-checking is done against a DC and a DC certainly doesn't look for stale ACEs when an object is deleted. Hope this clarifies the point. --Paul - Original Message - From: Yann To: ActiveDir@mail.activedir.org Sent: Thursday, January 04, 2007 3:54 PM Subject: RE : RE: RE: [ActiveDir] SID Deleted users remains in NTS permission. Hi, After rereading posts, it now makes sense to me that the ACEs are managed by the local LSA, and not by AD LSA So now if i consider that a group or user is deleted from AD and that object is set on an AD object ACLs (not share or ntfs permission), that object will be definitively disappear with no sid remaining from the ACLs, because the update is done by the local LSA (DC) where the deletion occurs, that is to say AD itself... Yann joe [EMAIL PROTECTED] a écrit : 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
RE: RE: [ActiveDir] SID Deleted users remains in NTS permission.
I should point out that you can get dangling SIDs even when the relevant user or group is still in the AD. The scenario involves SID History and the migration of security principals from one domain to another. Suppose a security principal, say user X with SID X is migrated from domain A to domain B. (Let's keep everything in the same forest to make it interesting.) The new object, user Y, in domain B will now have a new SID Y and SID X will be placed in the SID History attribute of the object. The resources back in domain A that user X had permissions to directly will still have ACEs that refer to SID X. Windows uses the SID history to allow user Y to have access back to the resource in domain A. Kind of like having dual citizenship. At some point after user X is migrated, the AD administrators decide that user formerly known as user X has had enough time on the fence (or have found that the user is experiencing token bloat but that's a topic for another message) and cleans out SID X from the SID History for user Y. Unless something is done to touch all the objects in domain A that might refer to SID X and replace it with SID Y, user Y will lose access to those resources and ACEs that refer to SID X will remain in the ACLs for those resources. This is the case for anywhere that SID X is referenced even though the user formerly known as X (i.e. user Y) is still in the AD. The difficulty of hunting down all the references to SID X is further complicated if there are any group policies that refer to SID X or if there are any domains that trusted domain A that could then make reference to SID X in an ACL somewhere. And let's not forget that there may also be references to SID X inside a variety of data stores such as but not limited to SQL, Exchange mailboxes, etc. And just because a SID doesn't back-translate, it doesn't mean that the object is really gone. Itcould just mean that the domain that is responsible for the translation is temporarily unavailable, so it's best to double check that the SID is really defunct before purging any references to it. Wook From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Williams Sent: Thursday, January 04, 2007 7:29 AM To: ActiveDir@mail.activedir.org Subject: Re: RE: [ActiveDir] SID Deleted users remains in NTS permission. Because it's not managed by the DS. The SID as you refer to it is actually an ACE. The ACE is an item that makes up the DACL which makes up the ACL. This is managed locally by the member server. Windows itself. The LSA. It's far too expensive and problematic with the current design for this to auto-manage itself. Re-read Joe's post. The DS doesn't know or care where a security principal is referenced as an ACE in an ACL. And the computer in question shouldn't really auto-prune the ACEs based on a rule or two... --Paul - Original Message - From: Haritwal, Dhirajmailto:[EMAIL PROTECTED] To: ActiveDir@mail.activedir.orgmailto:ActiveDir@mail.activedir.org Sent: Thursday, January 04, 2007 3:18 PM 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 it's 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
RE: RE: [ActiveDir] SID Deleted users remains in NTS permission.
You can also get dangling SIDs when the server housing the resource is not able to contact a corresponding DC for various reasons. One common reason is WAN outage, another is DNS hiccup. In any case, you are looking at the permission on a resource on a file server in a remote office, and you are seeing SIDs instead of normal names because the file server is unable to normalize the SIDs to names at that particular time. The accounts themselves are not deleted in AD, the file server just couldn't reach a DC to get the info. When connectivity/name resolution is restored, the SIDs appear normal as they should. Now, we certainly don't want the file server to go uh-oh, I can't resolve these wacky names, so they must be bad. Let me delete them during that outage, do we? Sincerely, _ (, / | /) /) /) /---| (/_ __ ___// _ // _ ) /|_/(__(_) // (_(_)(/_(_(_/(__(/_ (_/ /) (/ Microsoft MVP - Directory Services 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: Lee, Wook Sent: Thu 1/4/2007 10:39 AM To: ActiveDir@mail.activedir.org Subject: RE: RE: [ActiveDir] SID Deleted users remains in NTS permission. I should point out that you can get dangling SIDs even when the relevant user or group is still in the AD. The scenario involves SID History and the migration of security principals from one domain to another. Suppose a security principal, say user X with SID X is migrated from domain A to domain B. (Let's keep everything in the same forest to make it interesting.) The new object, user Y, in domain B will now have a new SID Y and SID X will be placed in the SID History attribute of the object. The resources back in domain A that user X had permissions to directly will still have ACEs that refer to SID X. Windows uses the SID history to allow user Y to have access back to the resource in domain A. Kind of like having dual citizenship. At some point after user X is migrated, the AD administrators decide that user formerly known as user X has had enough time on the fence (or have found that the user is experiencing token bloat but that's a topic for another message) and cleans out SID X from the SID History for user Y. Unless something is done to touch all the objects in domain A that might refer to SID X and replace it with SID Y, user Y will lose access to those resources and ACEs that refer to SID X will remain in the ACLs for those resources. This is the case for anywhere that SID X is referenced even though the user formerly known as X (i.e. user Y) is still in the AD. The difficulty of hunting down all the references to SID X is further complicated if there are any group policies that refer to SID X or if there are any domains that trusted domain A that could then make reference to SID X in an ACL somewhere. And let's not forget that there may also be references to SID X inside a variety of data stores such as but not limited to SQL, Exchange mailboxes, etc. And just because a SID doesn't back-translate, it doesn't mean that the object is really gone. Itcould just mean that the domain that is responsible for the translation is temporarily unavailable, so it's best to double check that the SID is really defunct before purging any references to it. Wook From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Williams Sent: Thursday, January 04, 2007 7:29 AM To: ActiveDir@mail.activedir.org Subject: Re: RE: [ActiveDir] SID Deleted users remains in NTS permission. Because it's not managed by the DS. The SID as you refer to it is actually an ACE. The ACE is an item that makes up the DACL which makes up the ACL. This is managed locally by the member server. Windows itself. The LSA. It's far too expensive and problematic with the current design for this to auto-manage itself. Re-read Joe's post. The DS doesn't know or care where a security principal is referenced as an ACE in an ACL. And the computer in question shouldn't really auto-prune the ACEs based on a rule or two... --Paul - Original Message - From: Haritwal, Dhiraj To: ActiveDir@mail.activedir.org Sent: Thursday, January 04, 2007 3:18 PM 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 it's not getting deleted automatically. Dhiraj Haritwal From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent
