Sharing folders and clients AD no take changes

Question

I have the following problem. In my company I have installed a DNS server + AD in WS2008 R2. The problem I have is that by sharing a folder for a group when I add or remove users from the group, customers do not make changes until you close the session and start again. For example, you do not close session until a user can access the shared folder but not within the group. I see something strange also is that if I access the IP, the changes are reflected, but if I agree for DNS changes are not reflected, and the DNS resolved correctly. Can somebody help me? Thank you so much!

Answer 1

This is expected behavior. Windows only looks up your group memberships when generating a Kerberos Ticket Granting Ticket. There's a good explanation here, but to quote:

When Alice has successfully authenticated to her DC (this is a DC of the domain where Alice's user account is defined), the DC's KDC constructs a Kerberos Ticket Granting Ticket (TGT). To enable the KDC to populate the TGT's PAC field with Alice's authorization data, the DC completes the following steps:

• In step 1, the DC queries the local AD domain partition to find out Alice's global group memberships. These not only include Alice's global group memberships that were assigned to her user account directly, but also the global group memberships that were assigned to one of the global groups Alice belongs to.
• In step 2, the DC queries the local AD domain partition to find out Alice's universal group memberships. Again, These not only include Alice's universal group memberships that were assigned to her user account directly, but also the universal group memberships that were assigned to one of the universal or global groups Alice belongs to.
• In step 3, the DC queries the local AD domain partition to find out Alice's domain local group memberships. Once more, these not only include Alice's domain local group memberships that were assigned to her user account directly, but also the domain local group memberships that were assigned to one of the domain local, universal, or global groups Alice belongs to.

The KDC then stores the authorization data gathered in these three steps in Alice's TGT and forwards the TGT to Alice's workstation. Alice's workstation will automatically cache the TGT in Alice's local Kerberos ticket cache.

To let Alice access a resource located on a member server and to let Alice transparently authenticate to that member server, the Kerberos logic on Alice's workstation will then use Alice's cached TGT to request to the KDC a service ticket for the resource.

If the service ticket request is valid, the KDC will generate a service ticket. To populate the new service ticket's PAC, the KDC copies the authorization data it finds in the PAC of Alice's TGT. The KDC then sends the service ticket to Alice. Again, Alice's workstation will automatically cache the service ticket in Alice's local Kerberos ticket cache.

(Kerberos stores your group memberships in the Privilege Access Certificate (PAC) field.)

I hope that helps.

Answer 2

When a user logs on, they get a Kerberos ticket. That ticket contains a list of all the groups the user belongs to at that time. If you add them to the group after they've logged on, they need to logoff/logon to get a new ticket with the new group list.

When you access the share by DNS name, that connection is authenticated with Kerberos. When you access the share by IP, NTLM is used to authenticate the connection (not Kerberos). NTLM does not use tickets, and membership is evaluated in a more dynamic manner. However, Kerberos is a an industry standard auth method that is more widely used and offer other advantages that NTLM does not offer.