Bad bug in MS ACL API and seems to have been there for years!
- From: "Mike Matheny" <thomasdotmdotmathenya@nasadotgov>
- Date: Thu, 21 Aug 2008 13:53:25 -0500
OK - we are migrating our domain, and to make it as seamless as possible, I
wanted to double ACL the files and folders (duplicate the file/folder
permissions from domain A with equivalent permissions from domain B - that
way we could migrate the users on OUR schedule).
So, to make this easier, we purchased a program from ScriptLogic named
Security Explorer. It has MANY features that make managing permissions
easier, such as it doesn't choke on long pathnames when adding permissions
to existing permissions, like cacls.exe does. It also has a neat feature
called Clone, where it will automatically match up accounts from either the
same or different domains (if the account/group names are the same, it does
an automatic match - if not, you can specify a mapping file to map different
account names). (BTW - best $400 we have ever spent on 3rd party tools -
just the ability to add permissions down extremely long pathnames makes it
worth it's weight in gold!)
Well, after running this tool in the clone mode (Several times to gather
data about what is going on) we discovered a strange bug - if a folder has a
user with permissions, and there is also a group with permissions, and the
user is a member of that group, it DOES NOT duplicate the user from the
other domain, it just duplicates the group. Problem comes in when the group
has less permissions than the user!
Now, I bet you are wondering what this has to do with MS. Well, here is the
tie. We had opened a support case on this behavior with Script Logic. We
came in on a weekend, and had 4 TB of data to re-ACL, so we started looking
at other tools. That's when we came across the subinacl.exe tool and the
command line, /migratetodomain., which takes a source and target domain as
parameters, and it clones the permissions from Domain A with Domain B - now,
there is no mapping of different account names with this tool, it looks for
identical account/group names in the target domain. That's when we noticed
the EXACT SAME BEHAVIOR!
Also, this week we are using a tool by NetIQ named Domain Migration
Administrator. We are using it to migrate our workstations to the other
domain. What it does is add a new entry in the ProfileList in the registry
for the account on the target domain, and point that to the existing profile
folder, so all is the same. It is then supposed to re-ACL the profile
folder, adding the user account from the other domain. Well, guess what -
the local Administrators group by default has full access to all Profile
folders, and because the users are local admins, and in the Administrators
group, it DID NOT re-ACL the profile folder with permissions from the user
account in the target domain. Only reason they can log on is that they are
local admins, which has full control to the profile folder - if I remove
local admin rights, they get the Unable to load profile error, and it
creates a temp profile for them.
Seems all 3 tools use a common API by Microsoft - I can't believe this bug
has not been noticed or reported before. In the first place, why is the API
resolving all the users membership to see if they are a member of the group
that has access, then skipping adding them to the permissions - this is
WRONG LOGIC and a waste of CPU cycles!
It is easy to duplicate, and 100% reproducible.
How do I go about opening a bug report with MS on this issue? Also, if
others are able to reproduce it, please post the results so I can be sure of
my testing.
--
Mike
.
- Follow-Ups:
- Re: Bad bug in MS ACL API and seems to have been there for years!
- From: Paul Adare - MVP
- Re: Bad bug in MS ACL API and seems to have been there for years!
- Prev by Date: Re: FQDN for self-signed certificate
- Next by Date: Re: FQDN for self-signed certificate
- Previous by thread: FQDN for self-signed certificate
- Next by thread: Re: Bad bug in MS ACL API and seems to have been there for years!
- Index(es):
Relevant Pages
|
