Back in February, I posted a question on the Geneva forum about Adjusting token lifetimes at the Web Application Proxy (WAP) for external access:
Does the Web Application Proxy or AD FS have any separate controls for adjusting token lifetimes to a different value via WAP than directly at AD FS? I can see there’s a session cookie for EdgeAccessCookie that WAP issues but this seems to be entirely undocumented at present. I’ve poked around in C:\Windows\ADFS\Config\microsoft.identityServer.proxyservice.exe.config (also undocumented as far as I can tell) but I’m not finding anything there either. We used to have some of these controls (sort of) with TMG/UAG. Are they totally gone now? With the AD FS Proxy this was less of an issue because it was only publishing AD FS but this is something that I’d hope to be able to control with a Reverse Proxy. Any ideas?
I didn’t get any replies, but after carrying out some tests of my own, I noticed the EdgeAccessCookie, and found a bit of information on TechNet:
After the user is authenticated, the AD FS server issues a security token, the ‘edge token’, containing the following information and redirects the HTTPS request back to the Web Application Proxy server:
- The resource identifier that the user attempted to access.
- The user’s identity as a user principal name (UPN).
- The expiry of the access grant approval; that is, the user is granted access for a limited period of time, after which they are required to authenticate again.
- Signature of the information in the edge token.
Web Application Proxy receives the redirected HTTPS request from the AD FS server with the edge token and validates and uses the token as follows:
- Validates that the edge token signature is from the federation service that is configured in the Web Application Proxy configuration.
- Validates that the token was issued for the correct application.
- Validates that the token has not expired.
- Uses the user identity when required; for example to obtain a Kerberos ticket if the backend server is configured to use Integrated Windows authentication.
If the edge token is valid, Web Application Proxy forwards the HTTPS request to the published web application using either HTTP or HTTPS.
This quickly became one of those things where there was insufficient documentation and limited project time, so I had to put this inquiry on hold. Then in July, I posted a question on the Application Proxy blog (a great resource), to see if this is something that they planned to document. The response that I got from Ian Parramore was unexpected and pleasing:
Continue reading “Coordinating AD FS 2012 R2 token lifetimes to reduce logon prompts, enforce revocation and limit session duration over public networks”
When helping our clients with Office 365 deployments, we sometimes find that DirSync has been associated with a trial tenant that is about to expire and/or was originally created with a provisional name, or similar. In any case, a public DNS name can only be verified once in Office 365, which associates that namespace with the Office 365 and Azure AD tenancies. So if we want to move DirSync (which is also a prerequisite for ADFS) to a new tenancy, then we need to back it out from the first tenant and re-associate it with the second. Unfortunately, that process isn’t exceptionally quick, but there are some manual steps that you can carry out in order to accelerate the change. As we do this more often, our list of things to check is growing, so this list may change, but this is where we’re at today. Please feel free to comment if you feel we’re overlooking anything.
Continue reading “Moving an Office 365 DirSync/ADFS domain from one Azure AD tenant to another”
Earlier this week, I had the misfortune of generating an error I’d never seen before when building a new SharePoint Server 2010 farm. The error first emerged when the SharePoint installation process landed me at the Farm Configuration Wizard page. I wouldn’t have been running it (not advisable ever, really), but it’s the first page that loads after the Product Configuration Wizard completes, so my first Central Administration page was this error:
The page cannot be displayed because your server’s current configuration does not support it. To perform this task, use the command line operations in Stsadm.exe.
How odd, given the emphasis on PowerShell in SharePoint 2010! After a bit of head scratching and examining application and ULS logs, I navigated to the Central Admin home page and everything appeared to be fine, but then when I got around to creating a new Site Collection a bit later, I got the same error, even though I was able to create web/service applications. I had the same error when logged on as farm admin, farm admin + local admin rights, farm admin + SQL SysAdmin and farm admin + domain admin rights, so I was pretty sure it wasn’t a permission issue (and I should note my temporary fiddlery here is only really suitable for non-production environments). This error also occurred on some other Site Collection-specific pages.
Continue reading “Active Directory Account Creation Mode in SharePoint 2010”
As promised in my SharePoint 2010 SEO Analysis with the IIS SEO Toolkit post, while the IIS.NET SEO Toolkit does an excellent job of generating an initial sitemap and providing a nice GUI for ad hoc updates, it does not offer any obvious scheduling mechanism to ensure that your sitemap stays current with the changing content in your CMS. Thankfully, my colleague Glyn Clough whipped up some PowerShell to produce a full sitemap for your web application based on Jie Li’s initial script, which was scoped at the root web. Running this as a Windows scheduled task will get you a very up-to-date sitemap for all sites in your web application with very little on-going maintenance. Nice one Glyn!
You may notice that the Usage and Health Data Collection Proxy is Stopped after deploying it in your environment. This is not just a matter of starting the service like it is with some Service Applications. In this case the SA proxy itself appears to be stopped.
Unfortunately I’ve found a problem with our development build, or rather, with SharePoint 2010. You may notice that the Usage and Health Data Collection Proxy is Stopped after deploying it in your environment. This is not just a matter of starting the service like it is with some Service Applications. In this case the SA proxy itself appears to be stopped. It appears that this is a known problem when provisioning this Service Application via the GUI. In fact, ours was created automatically as part of the Search Service Application creation process. At any rate, it doesn’t work in its current state in our environments, so it won’t actually collect any data.
To fix this just requires a couple of lines of PowerShell, courtesy of this article (to which I’ve added some clarification here).
Continue reading “Fixing the Usage and Health Data Collection Service Application Proxy”