SBS4.5 User SID Problem after Remove & Re-Add?

[Mike Behrenbrinker]

Very strange 'user' problem - I've got an SBS4.5 system that I'm
troubleshooting, that may have had a user removed and then re-added
improperly... In any case, I removed everything that I could find related to
that user and then went through the entire 'add new user' process like you
would for a normal first-time add... Everything seemed to go fine (including
Exchange) until you try to access old shares that the user had had rights to
previously - It appears that the system recognizes that the user 'name' is
the same, but that the SID is different(?) and will not give access to the
share - I'm getting the following message, "Access to the specified device,
path, or file is denied" no matter what I do (including making the user an
Administrator and giving them full rights to the system!) - I have to use
the same original user name, and cannot change the user name to something
differently (permanently) because of the company's standard naming
convention (Lastname) - ANY IDEAS?!?

Thanks in advance,

Mike

[Steve Foster]

You have to go through the share/ntfs permissions, removing the old SID
(which wll shouw up as "Account Deleted") and adding the new user.

Steve Foster

"Mike Behrenbrinker" <nospam...@ach.net> wrote in message
news:uA3jYRmLBHA.1316@tkmsftngp07...

[Andy Kinnard]

As a more permanent and elegant solution to this kind of problem, I use a
lot of Domain Global and Domain Local Groups on SBS. It's not a very "SBS"
solution, but it sure works a whole lot better (if User Man. for Doms. and
the Security tab in Explorer don't put you off). "Add a user" does a
nightmarish job of assigning permissions anyway (and generates error if you
do anything but the default and expected). If your users should all have
(about) the same permissions, just use the snot out of Domain Local Users
group to give permissions to data folders and the like. For restricted or
more open permissions for a small group, just add them to a
descriptively-named Domain Global group, nest the Global group a
descriptively-named Local group and give appropriate permissions to that
Local group. User Accounts go in the global groups, Globals go in Locals
(you can't nest a global in a global), and Locals get the Permissions [MS
calls it AGLP, see it?]; if you remember that rule of thumb, you can't screw
it up, and it's a whole lot easier to go back over permissions later on and
make sense out of them (b/c of the descriptive names). I use the word
"Domain" to begin the names of Global groups (like MS default groups) and
give the corresponding Local group the same name (except for the "Domain"
word) and use names descriptive of the activity that requires different
permissions. I have groups on my SBS like "Domain OWA Users", "OWA users"
[local group], "Domain Unlimited Inet Users", "Unlimited Inet Users",
"Domain Partners" [the owners], and "Partners". See what I mean? That way
you just put new or replacement user accounts in the correct global groups
(they're automatically placed in the "Domain Users" group which is a member
of the local "Users" group) for the functions they need and forget about it.
You can use scanning tools to look for permissions that belong to
unidentified SIDS if the leftover permissions for non-existant accounts
bother you (it's good to clean them up); I believe Shavlik's scanner (free,
inet based) does this.

Like I said, this isn't very "SBS" (so I might catch some heat from
introducing this very "NT" way of managing users and permitts), but it's
just so much nicer.

Andy
"Steve Foster" <steve....@picamar.co.uk> wrote in message
news:eQQt#PnLBHA.508@tkmsftngp02...