Scenarios with Alerts and more than one Active Directory Forest when using NTLM for a WebApp


SharePoint 2010 works together with Active Directory and for a lot of possible reasons you might have a Resource Forest and a User Forest. To be able to give access to a user or group from another Forest/Domain you need a Forest Trust. Furthermore also for possible security reason you can use one-way trusts only. But due to the design of the Active Directory and possible security scenarios when a user should find other users or a system process on a machine living in the resource forest has to find users and group memberships; we might run into logical limitations.

We found that the following scenario works only 24 hours in regards of sending an Alert to a user who wants to be informed when someone changed a document in a DocLib, as one example.

User Accounts from DOM-User are members in the Security Group (SG) “DOM-RES\AllFromUserDom Local SG”. Permissions are set inside the SharePoint Site Collections by using this SG only.

 

Problem

Why this works for 24 hours only?
We are storing User-Token in a SQL table and some services will check that token before asking again a Domain Controller. To be not unsecure after some time the default timeout of that token is 24 hours.

If you need to change the timeout of User-Tokens use: “stsadm.exe –o setproperty –pn token-timeout –pv 60” In this case 60 means 60 minutes. For more information please check the documentation for STSADM.

In a chronological order what happens:
The user logged in on his/her workstation.
Start Internet Explorer and navigate to a particular Site on the SharePoint Server.
That time the SharePoint Server has the account-information and the hash of the password. With that information the SharePoint Server is able to ask the Resource DC and will get the User-Token.

Resource DC get the request for a particular user:
That user is from the other domain and because of the Trust to the other Forest the DC can ask the other DC to get from them such a User-Token.
DC DOM-Res will ask the DC DOM-User and gets a token.
DC DOM-Resource has also own information because there is a local security group “DOM-RES\AllFromUserDom Local SG” and that user is a member of that SG. The final User-Token contains now both “parts”.
SharePoint gets the “big” token from DC DOM-Resource.

Within the 24 hours:
OWSTIMER works on the job to send Alert Emails.
That job will have to also security trim so that a user gets Alert Emails where this particular user still has access to.
For performance the job will check the User-Token in the SQL table and the token is still valid and the Email will be sent.

So far so good and after 24 hours?
Again OWSTIMER works on the Alerts job.
Now the User-Token in the SQL table is not more valid and the job has to ask on the possible ways ( incl.Windows APS’s ) to update that User-Token. But now we do not have the password hash and it is not possible to ask in the same way SharePoint asks when a user logged-in interactively.
We need a PeoplePicker configuration so that all SharePoint services are able to ask the DC-User when looking for a user who comes from the DOM-User.
Based on the user information where he/she comes from the job will ask the DC DOM-User to get a User-Token.
It is no problem for the DC DOM-User to build a User-Token but that token cannot contain information of the local security group in DOM-Resource; because there is a One-Way Trust.

Next time the user logged-in interactively it works again for 24 hours.

How looks now a configuration that works longer than 24 hours?

We could create a very long List with a lot of alternative solutions; some of them would work and others not. But few I want to mention here:

Give permissions inside a Site Collection directly to a user.
Give permissions inside a Site Collection through a SharePoint-Group and the user is a member of that group.
….

Based on the scenario above I would like to share two other solutions for you.

The Two-Way Trust Solution:

ReproDiagram-Alert-Security-Trimmed-Solution-11

 

And one more needed AD membership configuration which is out of the box configured in the way you can see here. Check on DC DOM-User that the build-in group “Pre-Windows 2000 Compatible Access” contains the “Authenticated Users”. Screenshot made on a Windows 2008R2 machine. Translate doso.com to DOM-User.

clip_image001 Screen

 

Start here with the problematic part:

So far so good and after 24 hours?
Again OWSTIMER works on the Alerts job.
Now the User-Token in the SQL table is not more valid and the job has to ask on the possible ways ( incl.Windows APS’s ) to update that User-Token. But now we do not have the password hash and it is not possible to ask in the same way SharePoint asks when a user logged-in interactively.
We need a PeoplePicker configuration so that all SharePoint services are able to ask the DC-User when looking for a user who comes from the DOM-User.
Based on the user information where he/she comes from the job will ask the DC DOM-User to get a User-Token.
The DC DOM-User is now able with the two-way trust to ask the DC DOM-Res and gets also a part of the “final-token” from that foreign Forest/Domain. Our job running inside OWSTIMER gets now the User-Token from DC DOM-User which contains all the needed information.

 

The One-Way Trust Solution:

The main difference is that all user accounts and SG’s where a user can be a member of are living in the DOM-User and NOT in the DOM-Res.

Solution-two

 

What is the difference now in regards how the User-Token really contains all the needed information?

During the interactively login of a user the DC DOM-Res has to ask the DC DOM-User to build a User-Token. With that One-Way Trust there is no problem to get that information.

When the Alert Job inside OWSTIMER has to update the User-Token there is also no problem because we will ask the DC DOM-User and in that domain are all information stored we would need to build the real good User-Token.

Remark:

These scenarios are based on SharePoint Web applications configured to work with NTLM. Using Kerberos or Claims are resulting in different stories. Everything has to do with security and we know from the real life that as much as we have security in place results in more and more uncomfortable ways to reach an own goal.

I tested these scenarios in a test environment so I can say that these are working as explained above. We are able to create very complex scenarios and we also would need a lot of experienced people to build secure environments so please do not hesitate and create Your Own test environment and test everything what comes into your mind; please do not forget to document your results like a scientist.

Comments (1)

  1. ACH1LLES says:

    Thanks for the write up. This has been a pain point for enterprise clients with the one-way trust topologies that you have described.  Glad to see someone from Microsoft finally acknowledge it publicly.  Personally I think this expired token affects more than just Alerts, but haven't been able to prove it 100%.

Skip to main content