JStump Posted December 25, 2012 Author Report Share Posted December 25, 2012 (edited) is all the fail happening from only one machine? gpresult /r (i think), see if the security group membership(s) look right.you said some users work but new ones don't. maybe try 'no work user' on 'working user's' machine.if it's only one machine, using the fqdn of the server might work, if so an ipconfing /flushdns might/should fix.Multiple machines, I have 2 vms and 2 physical machines I have been testing on. I am able to map and access drives on any problem machine by doing the "Connect as another user" option and using my actual admin account.Yes, existing users and groups work, I can get to the drive with my actual admin account since it is a part of a group who had existing permission on the share, but I just tested adding my test admin account to the ITadmins group and still a no go. Its possible when my account was created it was just a copy of an existing admins account which could be why my account works but this test admin does not.EDIT: I just confirmed my last thought, will need to dig deeper into what permissions are set for myself, and existing users on the share drive since it appears copying my own profile results in view abilities while creating a new user in the exact same group does not allow me to view the files on the share. Edited December 25, 2012 by JStump Quote Link to comment Share on other sites More sharing options...
Tonik Posted December 25, 2012 Report Share Posted December 25, 2012 EDIT: I just confirmed my last thought, will need to dig deeper into what permissions are set for myself, and existing users on the share drive since it appears copying my own profile results in view abilities while creating a new user in the exact same group does not allow me to view the files on the share.Sounds like you are giving permissions to accounts rather than groups? When you copy an account that has permissions on a share the new account does not get those permissions....if you give a group permissions on a share and you copy an account that is a member of that group then the new account will have permissions.If that is the case, never give an account permissions to a share, use groups and add the accounts to the group membership. Quote Link to comment Share on other sites More sharing options...
JStump Posted December 25, 2012 Author Report Share Posted December 25, 2012 Sounds like you are giving permissions to accounts rather than groups? When you copy an account that has permissions on a share the new account does not get those permissions....if you give a group permissions on a share and you copy an account that is a member of that group then the new account will have permissions.If that is the case, never give an account permissions to a share, use groups and add the accounts to the group membership.But the thing is, I am creating a new user and placing them in the ITadmins group, the ONLY group on the share, everyone else is a single user. This new user however does not have access, BUT if I copy a member of the same group, the new user then has the correct permissions but is also automatically a member of 15 or so groups as a result of the copy. Removing this new user from the ITadmins group after the copy however does not remove their permissions and I can still access the drive with this account after taking them out of ITadmins. Quote Link to comment Share on other sites More sharing options...
Tonik Posted December 25, 2012 Report Share Posted December 25, 2012 Then another group has perms on the share. ... That is why accounts that are not members of itadmins keep permission.Did you recently add itadmins to this share? Did you add it just to the folder and not propagate it down to the files? What about the share perms vs the ntfs perms? They both have to be right. You said this is in Cleveland, that is where I am. This is what I do, and I am very good if you want a hand. How about a screen shot of the ntfs perms and share perms. Bet we can spot it from there.Perms are cumulative. Ntfs....most permisive apply except deny trumps.Share perms....the same.Then you put the result of the two beside each other....most restrictive applies. Quote Link to comment Share on other sites More sharing options...
Cheech Posted December 25, 2012 Report Share Posted December 25, 2012 Stump, I hope you get this worked out. This is why I'm so fucking happy I switched to network instead of staying with server administration. Blosser and Tonik are smart guys, they'll get you sorted out. Quote Link to comment Share on other sites More sharing options...
RVTPilot Posted December 25, 2012 Report Share Posted December 25, 2012 Then another group has perms on the share. ... That is why accounts that are not members of itadmins keep permission.Did you recently add itadmins to this share? Did you add it just to the folder and not propagate it down to the files? What about the share perms vs the ntfs perms? They both have to be right. You said this is in Cleveland, that is where I am. This is what I do, and I am very good if you want a hand. How about a screen shot of the ntfs perms and share perms. Bet we can spot it from there.Perms are cumulative. Ntfs....most permisive apply except deny trumps.Share perms....the same.Then you put the result of the two beside each other....most restrictive applies.This is what my thoughts were. NTFS perms and folder security are not equal. Were it a larger network I would think it could also be FW, depending on what box the share was on relative to the net segment the user node is. Quote Link to comment Share on other sites More sharing options...
Tonik Posted December 25, 2012 Report Share Posted December 25, 2012 This is what my thoughts were. NTFS perms and folder security are not equal. Were it a larger network I would think it could also be FW, depending on what box the share was on relative to the net segment the user node is.He mentioned it maps the share, so I am with you. Firewall, vlan acl's are probably not in play here. Quote Link to comment Share on other sites More sharing options...
JStump Posted December 25, 2012 Author Report Share Posted December 25, 2012 Thanks guys for the help! I figured it out. The issue was a combination of cumulative permissions and cached credentials on my test machines. Started testing by choosing the "Map with different credentials" every time so I knew exactly who was being used to map the drive. Also, I may not have been waiting long enough for the DC to replicate new AD settings to the second DC which was giving conflicting user rights when playing with Active Directory then immediately testing.Again, thanks for all the help guys! Quote Link to comment Share on other sites More sharing options...
Cheech Posted December 25, 2012 Report Share Posted December 25, 2012 Thanks guys for the help! I figured it out. The issue was a combination of cumulative permissions and cached credentials on my test machines. Started testing by choosing the "Map with different credentials" every time so I knew exactly who was being used to map the drive. Also, I may not have been waiting long enough for the DC to replicate new AD settings to the second DC which was giving conflicting user rights when playing with Active Directory then immediately testing.Again, thanks for all the help guys!Ah. You can use ADSS to force replication to the secondary DC, then check the event log to make sure the sync took. Glad you got it worked out. Quote Link to comment Share on other sites More sharing options...
Tonik Posted December 25, 2012 Report Share Posted December 25, 2012 Also disable then enable the account. AD has a few events that force a near instantaneous replication between DCs and that is the easiest. Doubt cached credentials was a problem unless you were on vpn or didn't relog after membership changes. And if a DC is available cached is not used. Fyi group membership checking is done when you first connect to a share. Not again until you disconnect. From a command prompt whoami /groups will remove any doubt what groups you are currently in. Quote Link to comment Share on other sites More sharing options...
Cheech Posted December 26, 2012 Report Share Posted December 26, 2012 Also disable then enable the account. AD has a few events that force a near instantaneous replication between DCs and that is the easiest. Doubt cached credentials was a problem unless you were on vpn or didn't relog after membership changes. And if a DC is available cached is not used. Fyi group membership checking is done when you first connect to a share. Not again until you disconnect. From a command prompt whoami /groups will remove any doubt what groups you are currently in.Didn't know about the disable/enable account trick, I'll have to file that away.You can clear out the cached credentials on mapped network drives by putting in "net use [drive letter/UNC/IP share path] /delete" Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.