Mapped drive is not accessible. Access is Denied.

We had an issue yesterday where we were unable to change an Exchange 2010 Distribution List from being Global to Universal.  I found an article online, that had me run this command in powershell:

dsquery group -limit 0 | dsmod group -c -q -scope u

This seems to have let us make that change.

However, I have a new problem now, that never happened prior to this change.  Several employees are members of a security group, which is also a member of another security group.  This does not seemed to be recognized in the case of drive mappings anymore, and users get access denied when attempting to connect to mapped drives.

For example:

Employee John Smith is a member of security Group A.

Group A is a member of DriveMap group.

John Smith cannot access the drive map as a member of Group A.

When John Smith is added as a member of DriveMap group directly, it works.

Again, this has been working fine for all this time, up until we had the issue with changing global to universal distribution lists. I'd rather not go through several hundred employees and add them to the DriveMap group manually, when it should apply the way we have groups broken down.

Thanks.
LVL 1
fireguy1125Asked:
Who is Participating?
 
fireguy1125Connect With a Mentor Author Commented:
I believe this may have something to do with the global and universal settings of the groups.  I am also noticing now that the GROUP A group and others are no longer members of the MAPDRIVES group, so I'm guessing that command did something that caused the removal of the GROUP A, GROUP B, etc... groups from the MAPDRIVES group.
0
 
armchair_scouseCommented:
This may not be the cause, but what you are describing is similar to the symptoms of problems with Kerberos netowrk authentication, in that Kerberos has a ticket/file per user, of a certain size, that holds a list of the AD groups to which a user is allowed to belong.  If the user is added to too many groups, or groups are added to other groups, the Kerberos file just cuts off the list of AD groups as far as the file size can hold, meaning anything that didn't make it into the file isn't recorded, and it might mean that resources that a user was previously able to access are no longer accessible.

If it is the case, then I understand the Kerberos ticket/file size can be adjusted, alternatively if the AD group names are rather long and flowery, adjusting the length of the names can help, or simply removing users from groups that they just don't need.

Apologies if this is a red herring/doesn't apply to your situation, but the symptoms sounded a little simliar to experiences we've had here, so thought I'd suggest it just in case.
0
 
fireguy1125Author Commented:
No other solution found, but issue resolved by adding users back to individual groups
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.