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