Re: Bad bug in MS ACL API and seems to have been there for years!
- From: "Mike Matheny" <thomasdotmdotmathenya@nasadotgov>
- Date: Tue, 26 Aug 2008 11:21:45 -0500
Nope, ANY group if the user is also a member of it will not duplicate the
ACL for the user from the target domain.
--
Mike
"Roger Abell [MVP]" <mvpnospam@xxxxxxx> wrote in message
news:eV3$G$sBJHA.4816@xxxxxxxxxxxxxxxxxxxxxxx
Does this happen only when the involved group is Administrators ?
If you have it consistently happening only with Administrators that is
perhaps an understandable behavior.
Otherwise it sounds like something is not as expected.
Roger
"Mike Matheny" <thomasdotmdotmathenya@nasadotgov> wrote in message
news:uhcwy87AJHA.3400@xxxxxxxxxxxxxxxxxxxxxxx
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
.
- References:
- Bad bug in MS ACL API and seems to have been there for years!
- From: Mike Matheny
- Bad bug in MS ACL API and seems to have been there for years!
- Prev by Date: Default Smartcard Logon template still visible on web enrollment pages
- Next by Date: Re: Default Smartcard Logon template still visible on web enrollment pages
- Previous by thread: Re: Bad bug in MS ACL API and seems to have been there for years!
- Next by thread: Re: Expired Kerberos TGT, AcquireCredentials/InitializeSecurityContext failure, how to force refresh/renew?
- Index(es):
Relevant Pages
|
