Month: January 2014

ADFS CAP & Limiting Mail Client Access – Thunderbird/IMAP Mishap

Posted on

For you Exchange Online / ADFS Administrators who have to support your older IMAP clients, you may have had to wrangle with your ADFS deployment, specific the Client Access Policy (CAP) settings, which limit which users/devices can use the ADFS Services.

Many times ADFS is deployed internally, so users MUST be on the corporate network in order to access the server. The default ADFS Token Issuance rule states that any authenticated user can use the server/ADFS service, however there is the ability to define Client Access Policies (CAP) which have a more granular approach, on who/what/where these users must be or conform before they are allowed access.

There are many sites and articles on how the use the ADFS CAP rules, one of particular note is the Client Access Policy Builder, created by a Microsoft person, which is a graphical UI that helps in defining these conditions and requirements for accessing ADFS.  If you are looking to create and use an ADFS CAP setting, you should definitely review all available material BEFORE turning on this feature, as I found, it can be tricky:

ADFS Client Access Policy Builder

Sample ADFS CAP Entry

Rule to allow Autodiscover, ActiveSync and POPIMAP Access when coming through ADFS-Proxy, which covers Exchange Online.

exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy”%5D)
exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path”, Value == “/adfs/services/trust/2005/usernamemixed”])
&& NOT exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application”, Value == “Microsoft.Exchange.ActiveSync”])
&& NOT exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application”, Value == “Microsoft.Exchange.Autodiscover”])
&& NOT exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application”, Value == “Microsoft.Exchange.POPIMAP”])
&& exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip&#8221;, Value =~ “”<NEED any Internal and EXO and O365 IP Addresses HERE>”])
=> issue(Type = “http://schemas.microsoft.com/authorization/claims/deny&#8221;, Value = “true”);

When defining the CAP you will find that you can define different applications, connections, etc.  I found that while allowing Microsoft.Exchange.Autodiscover and Microsoft.Exchange.ActiveSync, I did NOT define Microsoft.Exchange.POPIMAP, which stopped my Thunderbird IMAP clients from obtaining authorization and authentication.  As a result Thunderbird seemingly connects into an Exchange Online MBX, however their LIST request for the different folders errors with Bad or Invalid Data.  As a result the issue appears to be a Protocol/EXO services issue, when in fact ADFS is failing to allow the user to authenticate.

SO if you are going to use ADFS CAP AND you are defining entries for Microsoft.Exchange.ActiveSync and other items and you will be using POPIMAP, then you must also enter the Microsoft.Exchange.POPIMAP entry as well, otherwise the IMAP client will fail during connectivity but show that is has authenticated without issue….very strange.

 

 

What Happens to SkyDrive Pro Sites When Removing an SPO License

Posted on Updated on

SPO

For those SharePoint Online Admins who are responsible for licensing and site cleanup, this post is for you.  A great write-up on this can be found here, however for brevity’s sake, the important information is listed below:

Source: http://blogs.msdn.com/b/kaevans/archive/2012/06/25/top-recommendations-for-managing-the-my-site-cleanup-timer-job.aspx

Note – While the above references SharePoint 2010, using the MySites Moniker for people’s personal SharePoint sites, SharePoint Online 2013 references SkyDrive Pro as the new name for this feature.  While the above reference is to SharePoint 2010, the SkyDrive Pro/MySite “clean-up” process is still used in SharePoint 2013.

The My Site Cleanup Job is responsible for deleting user profiles and My Sites of those users.  This includes the following activities:

  1. Remove user profiles that are queued for deletion.
  2. If those users have a My Site, assign the  user’s manager as the SPSite.SecondaryContact.  Email the manager letting them know that the user’s My Site will be deleted in 14 days.
  3. 11 days after the first notification, email the manager again letting them know that the My Site will be deleted in 3 days.
  4. After a total of 14 days, delete the MySite.