Printable View
While setting up audits, I noticed an unknown user listed in a folders ACL named, "unknown user" followed by a long string of digits. Does anyone know what this is? I was first thinking it could be an old account that I deleted, but wasn't sure. Wouldn't all associations with an old account disappear after the account is deleted out of my OU? Is this still the SID that is now unassociated with a user name?
I've had this happen to me before. The SID didn't resolve to a user name.
There are utilities like sid2user that will tell you which user account a sid belongs to.
http://www.ntbugtraq.com/default.aspx?pid=55&did=6
User account that was deleted...
We had layoffs temp and permenant recently and I noticed this with the deleted accounts.
the string of numbers is the SID of the account
MLF
Ok, it was what I expected. After looking through my notes, I keep notes on all changes I make, I noticed I deleted a user a few weeks back that had access to that folder explicitly. I remember to remove her from Global Security Group before deleting her account, but just figured her SID would be removed from ACLs at the folder level. Come to think of it, I probably didnt' even have to delete her from the group, because AD should have done that automatically. After seeing this happen, maybe it's a good thing.
Thanks for the help
Never add directly an user to a ACL :) Allways use groups. You will avoid this kind of thing.
Its a "best pratice".
I created network drives for users that only gave them; the system and me access. In this scenario, would you use groups? I get what you mean though, I'm trying to use groups whenever possible.
if "you" means "administrator" account, no...otherwise, yes.Quote:
Originally posted here by warriorfan808
I created network drives for users that only gave them; the system and me access. In this scenario, would you use groups? I get what you mean though, I'm trying to use groups whenever possible.
So you add each user to their own group for their "home" drive?Quote:
I use groups for shared resources (common shares, printers, etc.) but for their "home" drive, I've always used "user" "system" and the group "domain admins"
IMO- Creating a dedicated group for each user is not necessary. It may prevent problems like the one above, but after the user is gone... the permissions on the users "home" folder will change and the folder will either be deleted or archived or it's contents moved to another employee.
The purpose of groups is to combine users into logical group so you can manage like users together and not have to make changes to each individual user account. If there is only going to one user assigned to each of those groups... it defeats the purpose of a "group".
We use groups for Job Title... So the Admin Assistant who has rights across numerous drives, folders etc. has a group called Adimin Assistant and the rights are set for that group to the assets they need and added to groups they need to be added to. Then we create the user and add the user to the group. When the user leaves they are removed from the group thus all their rights are removed. When they are replaced the new user is created and added to the Admin Assistant group. They automatically get rights to all the assets the previous Admin Assistant had.
Beats the hell out of having to log where you granted who rights to and manage the change of personnel.
No, because there is no home drives here. Nobody is allowed to have a personal / home space on file servers; only departamental folders are allowed.Quote:
So you add each user to their own group for their "home" drive?]
But even i create a folder on network that only one user will access (e.g. a folder that Data Base admin will store his documentation) i create a group and put this user in a group.
A lot of O.S. simply dont clear direct connections (users to ACL). O windows, its hard to get access because the sid structure. In others, account name is stored directly on ACL. If you reuse / recreate the account, the user will get access on resources.
When you use groups to acl instead accounts to acl, you just avoid a unecessary risk at your installation. When you clear the user, most O.S. just remove the account from all groups. Its silly create a group for just one user? Maybe.
A lot of "best pratices" sounds silly when you get a specific need. But IMHO, if you follow best pratices even if you think its just an overhead, you will be happy at the end of day. The only exception is when the best pratice will reduce the security on specific case. In that case, i skip the best pratice recommendation.
I use groups for users...as stated..
It makes it easier to manage.
We have a database program, users need access to the db files, and also several other folders with various rights to install and run the program. Consists of many folders and hidden shares.
By adding and removing from the group...makes it easy to grant access once the groups permissions are set up....instead of indivually assigning rights per user
For home files...no just user, system and admins
BTW...any one know how to hide mapped drives...w2k and\or xp :what:
MLF
You mean hide mapped drives as in hidden share? You "hide" a share by appending a $ to the share when you create it. When you map it, simply add the $ to the share name.Quote:
Originally posted here by morganlefay
BTW...any one know how to hide mapped drives...w2k and\or xp :what:
net use x: \\server\share$
x "drive" will be assigned to \\server\share$
if you simply do a
net use \\server\share$
The drive is mapped, but not assigned to any specific "drive" letter.
Or do you mean once a drive is mapped, you don't want the user to be able to see it in windows explorer, net use, etc.?
It appears that you can hide mapped drives via group policy too.
http://www.sd61.bc.ca/windows2000/HideDrives.htm
I have hidden shares...which need to be mapped...and I do not want the users to even see them..poke around...you know how the little buggers are...
"ummmm.... whats this......" :rolleyes:
I also need the drive letter...although would be nice if I didnt but it is an older app...and really doesnt respond well to unc paths.....also the outside reporting app uses the drive letter for the data path..I didnt write the reports so not sure if that can be modified
The problem is all users started dumping all kinds of crap into it....even though each department has its own shared directory for this kind of thing...I finally cleaned up.
...I just dont want them to see it
anyway thanks for the link....will look into it
MLF
morganlefay: Thats what I figured... sometimes you just have to verify the obvious.
You can play with that if you want... however, it looks a bit confusing. Don't ask me why they're adding "hexidecimal values" in base 10! See step 4 in that link... It would seem to me if you're going to have hexidecimal values, they should be added in hex?
Maybe the "author" was confused... as it doesn't appear that of those values are hexidecimal.
At lease, none of them have any letters... lol
Thanks again....
Sorry to hijack the thread Warrior... :eek:
MLF