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
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, J
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. Yan
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 : 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