Domain Profiles Borked - Can't Grant Admin Rights - HELP!!!

[=?ISO-8859-1?Q?Caine_H=F6rr?=]

THE BACK STORY:
Yesterday (1/23/2006) our company experienced a power outage that
ultimately brought our network down in a not so graceful manner. Don't
ask why the UPS system failed as we don't have an answer to that
question either.

We are running a FreeBSD system with an installation of SMB configured
as an NT 4.0 domain.

Once power was restored and the system was brought back up, we realized
some users could not log onto the network (NT domain) as their accounts
had become corrupted due to a non-graceful shutdown of a UNIX (variant)
system.

THE CORE PROBLEM:
The individuals that suffered a corrupted domain account are now
experiencing a strange desktop (local) issue.

Once we restored their domain access and they logged into their Windows
XP Professional SP/2 machine, they noticed the following problems:

* Their profile.DOMAIN was no longer being used - XP created a new
profile.DOMAIN.0000
* Their desktop profile has reverted back to a stock XP configuration
* Their files seem to have disappeared
* They could no longer access email via Outlook 2003
* They no longer have Admin Privileges to their machines (ie:
inability to configure Outlook, install programs, etc.)

I logged in as the Administrator for each machine and checked the
status of their account. Sure enough, local Admin rights were given to
each domain user. But when the user was actually logged in, they did
not have Admin privleages.

Now, if I log in with a different user who has never logged into the
afflicted machine and give them local Admin rights, everything is as it
should be.

Furthermore, to rule out the domain server, I had the afflicted user
log into a different machine and gave them local admin rights and
everything worked flawlessly.

WHAT CAN BE DONE:
So my question is this... Giving the domain user Admin rights to the
local machine seems to have no affect, even after I remove the domain
user from the local machine, delete the profile.DOMAIN or
profile.DOMAIN.0000 directory under C:\Documents & Settings\

I have scanned the Windows registry and everything points to the
correct file paths and the AdminUser flag is set to true.

Has anybody seen this before? Is there any way to counter the problem
without reformatting/reinstalling Windows?

Thanks in advance.

If you could forward your reply to me email address as well, it would
be grealty appreciated.
--
Caine Horr
Systems Administrator
(e-mail address removed)

GroundWork Open Source Solutions
http://www.itgroundwork.com

 

[Adam Leinss]

[posted and mailed]


[snip]

Has anybody seen this before? Is there any way to counter the
problem without reformatting/reinstalling Windows?

Check out this URL: http://tinyurl.com/bnqaa. Basically, you can place
Regmon/Filemon in the background using PSEXEC and it watch what the
system is looking when the user logs in. You can then parse the log it
creates.

The other thing you could do is delete and re-create the user account
on the DC. This would assign a new SID to the user account and Windows
would see it as being a totally brand new account. Then you could copy
over their old profile and adjust the permissions accordingly.

Also note that the user registry itself has permissions on it. For
fun, you might want to load their old profile (NTUSER.DAT) as a hive in
regedit, and then give the Users group FC of the hive. Then copy that
profile over to their new profile directory and see if it takes it.

Adam

 

[j.sestrich]

THE BACK STORY:
Yesterday (1/23/2006) our company experienced a power outage that
ultimately brought our network down in a not so graceful manner. Don't
ask why the UPS system failed as we don't have an answer to that
question either.

We are running a FreeBSD system with an installation of SMB configured
as an NT 4.0 domain.

Once power was restored and the system was brought back up, we realized
some users could not log onto the network (NT domain) as their accounts
had become corrupted due to a non-graceful shutdown of a UNIX (variant)
system.

THE CORE PROBLEM:
The individuals that suffered a corrupted domain account are now
experiencing a strange desktop (local) issue.

Once we restored their domain access and they logged into their Windows
XP Professional SP/2 machine, they noticed the following problems:

* Their profile.DOMAIN was no longer being used - XP created a new
profile.DOMAIN.0000
* Their desktop profile has reverted back to a stock XP configuration
* Their files seem to have disappeared
* They could no longer access email via Outlook 2003
* They no longer have Admin Privileges to their machines (ie:
inability to configure Outlook, install programs, etc.)

I logged in as the Administrator for each machine and checked the
status of their account. Sure enough, local Admin rights were given to
each domain user. But when the user was actually logged in, they did
not have Admin privleages.

Now, if I log in with a different user who has never logged into the
afflicted machine and give them local Admin rights, everything is as it
should be.

Furthermore, to rule out the domain server, I had the afflicted user
log into a different machine and gave them local admin rights and
everything worked flawlessly.

WHAT CAN BE DONE:
So my question is this... Giving the domain user Admin rights to the
local machine seems to have no affect, even after I remove the domain
user from the local machine, delete the profile.DOMAIN or
profile.DOMAIN.0000 directory under C:\Documents & Settings\

I have scanned the Windows registry and everything points to the
correct file paths and the AdminUser flag is set to true.

Has anybody seen this before? Is there any way to counter the problem
without reformatting/reinstalling Windows?

Thanks in advance.

If you could forward your reply to me email address as well, it would
be grealty appreciated.
--
Caine Horr
Systems Administrator
(e-mail address removed)

GroundWork Open Source Solutions
http://www.itgroundwork.com

Basically, the SID of your users is no longer the same as it was. The
actual username on an account is really just a label to make it easier
to refer to the account, kind of like a DNS name to an IP address. The
rights are applied to the SID of the account, and that's how Windows
refers to it.

So even though in Local Users and Groups you've applied admin rights to
joeuser, you've actually applied them to <sid-of-joeuser>. If you then
delete the account "joeuser" from the domain, and create a new account,
also called joeuser, that account will not have any of the security
privileges of the old joeuser account because it has a new SID.

So Local Users and Groups is not comparing joeuser to joeuser, but

Once we restored their domain access and they logged into their Windows
XP Professional SP/2 machine, they noticed the following problems:

* Their profile.DOMAIN was no longer being used - XP created a new
profile.DOMAIN.0000

This is because a profile with that username already exists, so Windows
created a new profile with the new account, using a standard naming
convention. To avoid this, rename the original profile before logging
the user back in.

* Their desktop profile has reverted back to a stock XP configuration

This is a new account to Windows, with a new profile, default settings
apply

* Their files seem to have disappeared

You mean locally? They are in the old profile folder. On the network,
any files associated with the old SID won't be accessible by the new
sid.

* They could no longer access email via Outlook 2003

see above Old sid/new sid = old account/new account.

* They no longer have Admin Privileges to their machines (ie:
inability to configure Outlook, install programs, etc.) I logged in as the Administrator for each machine and checked the status of their account. Sure enough, local Admin rights were given to
each domain user. But when the user was actually logged in, they did
not have Admin privleages.

Local admin on old sid != local admin on new sid. I don't understand
though, you say if you delete the original account from local admin
group, and then re-add it, it still doesn't work? Maybe you need to
delete the original profile as well, but I wouldn't think so. Maybe
delete the account from local admin, reboot and then try to re-add?
Not sure about this one.

Now, if I log in with a different user who has never logged into the
afflicted machine and give them local Admin rights, everything is as it
should be.

Exactly. The problem isn't with the system, it's with the accounts.

Furthermore, to rule out the domain server, I had the afflicted user
log into a different machine and gave them local admin rights and
everything worked flawlessly.

Exactly. The different system has no knowledge of the old SID, and
happily granted rights on the new sid.

Unfortunately, this is probably going to be messy, reapplying security
settings to all your accounts. I don't really have a firm enough grasp
of your specific situation to offer a suggestion, but hopefully, I've
explained what's happening well enough for you to figure it out?