Problems caused by ADMT

Database Search

If you can't find the information using the categories below, post a question over in our WinBatch Tech Support Forum.

TechHome

WinBatch

Networks - Servers

Microsoft Client

wNT

Services

Can't find the information you are looking for here? Then leave a message over on our WinBatch Tech Support Forum.

Problems caused by ADMT

Question:

I'm using the following code to delete all the users in the 'Debugger Users' group on a Windows 2000 machine. There are 2 orphaned SIDs in there (left over from an ADMT conversion a while back). I'm trying to delete users by SID instead of name (due to the ADMT conversion... this is the same type of error I ran into a while back). The code below will delete "Real" users just fine, but errors when it tries to delete the orphaned users.
* wntMemberList does return the SID pack probably (verified by use the 'pause' command to display the results)
* The Deletion error I get is "Error 542: Invalid user/group name"
here's the code:
;Clean up Debugger Users Group If wntGroupInfo("", "Debugger Users", @LOCALGROUP, -1) ;if Group Exist people=wntMemberList("","Debugger Users",@LOCALGROUP,4,0) NumPeople = ItemCount(People, @TAB) For i = 1 To NumPeople CurrentPerson = ItemExtract(i, People, @TAB) Pause("Current Person", CurrentPerson) ; ErrorMode(@Off) wntMemberDel("", "Debugger Users", CurrentPerson, @LOCALGROUP, 2) ; ErrorMode(@Cancel) Next EndIf
Note: I can delete them manually.

Answer:

I remember the problem you were dealing with before. Is the ADMT agent still installed? I seem to recall that the crux of the issue was that the agent was mucking around with the conversions between account names & SID values.

In this case, are you saying that you can successfully delete group members [via their SID values] for accounts that currently exist, but this same task fails when performed for accounts that were migrated and no longer exist?

I'm wondering if group memberships were handled differently than NTFS permissions. The reason I question this is that converting NTFS permissions would involve an exhaustive search & replace operation throughout all of the NTFS permissions on all computers in a domain, while group membership changes are limited to only being done within the SAM [Security Accounts Manager] database. Maybe the SID values in the groups were converted to be the new SID values.

Can you enable DebugTrace() in your code and post the results here or email them to me?

User Reply:

I sent you a copy of the debug log. I did have two SID that wouldn't remove, but now there is only one (I removed the other one manually for another test). The remaining SID still doesn't remove, however I the script doesn't crash any more. It must have been the other SID causing the script to crash.

Answer:

What's the other SID value that the account associated with the SID "S-1-5-21-1109269927-665796172-1543857936-5853" maps to as a result of ADMT having worked its mojo? Remember, when an account got migrated, the account name stayed the same but the SID changed. The ADMT agent & tools have been playing a shell game w/respect to changing the actual SID value & account names that get returned by the lookup operations that convert between SID values and account names.

I see that wntMemberDel() returned zero, which means that the specified account/SID wasn't a member of the group to begin with. I think that ADMT is showing you one SID, but actually has a different one as member of the group.

User Reply:

What would be the problem command to take a SID and resolve it to a username? I'm trying:
ResolvedName = wntUserGetDat("", CurrentPerson, "name", 1) Pause("Resolved Name", ResolvedName)
But get errors saying "Invalid User Name"

Answer:

wntAcctInfo() is your friend.

User Reply:

It resolves to a name in the current domain (IE: NewDomain\Jdoe)
In computer manager, when I look at the members of 'debugger users' The persons name is listed like this:
NewDomain\Jdoe (OldDomain\Jdoe)
(NewDomain being the new domain name, and OldDomain being the Old Domain name)

Answer:

And so we go round & around in circles again. I'm beginning to think that I should scrape up $1M, buy myself a blackmarket nuke and simply drop it on the blackhearted trolls who invented ADMT. Would everybody within 100 miles of Redmond, WA, as well as anybody 1000 miles down-wind or affected by the flow of ground water from that area, please evacuate to a safer locale.

ADMT is causing some significant problems here because it's mucking around with the results that get returned by the low-level security functions that are involved in manipulating SID values, account names, conversions between them and whether old or new SID values are being returned by various functions that report on group membership, NTFS permissions, etc.... This, in turn, is making it very difficult for the NT extender to do its job properly because, in effect, it's being lied to by the O.S.

Here's something you didn't know about how wntMemberDel() works vs. how the wntAccess*() functions work:

The wntMemberDel() function actually operates on user names & group names. If you pass in a SID string, it has to be converted to an account name before it can be properly processed by the underlying Win32 API functions that manipulate local & domain group memberships [yes, there are 2 separate functions - one for local, one for domain].

The wntAccess*() functions operate purely on SID values, and all account names passed in to them must be converted to SID values before any permissions can be manipulated or reported upon.

Given these differences in behavior, try the following:

Take the SID value that was reported back as an "oprhaned" SID that's a member of your local group. Convert it to an account name, which you've shown will be in the new domain. Map that account name back to its old domain & account name. Then take the old domain & account name and pass that in to wntMemberDel() and I think it will work properly.

User Reply:

Hmmm.. now things are going to get difficult. When we converted to the new domain via ADMT, we also changed all our logon names to a new standard.

Do you know of any way to have the OS tell me what the old username was? Oh.. also, ADMT was used on at least 2 different domains during a merger. Know of any way to have the OS tell me what the old domain was?

Answer:

Of course you did.... that's quite necessary most of the time when you combine multiple domains that have been acquired over time and which were implemented using different naming standards. Once you consolidate things in a new domain, it's nice to have *ONE* naming standard. Nobody can fault you for doing that.

Surely ADMT produced some sort of report somewhere and stored it in a file showing the mappings of the names, right?

Like I said, ADMT & its agent software are forcing the O.S. to lie to us about some very fundamental things like account names & SID values at various times when we ask for them. It's not surprising that the NT extender has takend a psychotic-break as a result of this. Does the name "HAL 9000" have any meaning for you? Be glad the NT extender isn't in control of life-support systems at your facility, as ADMT may have just pushed it over the edge.

In this one case, though, do you actually know the old account name so that you can just feed that value to wntMemberDel() in order to test out the theory?

User Reply:

Jumping thru the hoops and ultimately feeding wntMemberDel() the old domains's username worked.
So, I take it that that's no easy way to tell Windows to "Return the SID value of listed users and DON'T lie to me!"? heh...

In the GUI it had the user listed as "NewDomain\Jdoe (OldDomain\JDoe)" any idea how it new the 'OldDomain\Jdoe' part? I don't know if it'd be possible to have wntUserDel key off whatever that field is.

Answer:

Check & Mate! I claim Victory!

At least my theory was sound and the sanity check didn't bounce at the reality bank.

So, I take it that that's no easy way to tell Windows to "Return the SID value of listed users and DON'T lie to me!"?

Not that I'm aware of at this time. I'm used Windows lying to me, though, so I tend to treat the return values of all Win32 API functions with a certain amount of scepticism.

That's the part that ADMT inserted... it has introduced additional code that is being executed that ties together the old SID/account-name and new SID/account-name.

As to how such a mapping is achieved, I'm not entirely certain. There's obviously something out there that's doing it, the question is how to tap into it and make use of it. If I can cook up some sort of DllCall() example that would do the trick, I'll post it here. At least now I have some idea of how to construct some Google Groups searches to further research the subject.

Article ID:   W17064

File Created: 2007:07:03:14:28:02

Last Updated: 2007:07:03:14:28:02