Update on Microsoft Azure Data Center Locations


Updated 12-oct-2015
Microsoft has now a quality website about the current datacenter regions https://azure.microsoft.com/en-us/regions

In 2012 I’ve posted a blog post with a map of the Azure Datacenter Locations at that moment. A lot of changes has taken place since that time!

In this post an updated map, thanks to William Zack (Microsoft). With new datacenters in Brazil and Japan, and planned datacenters in Australia.

2014-09-15_21h45_08

 

Azure Active Directory Sync Tool reaches General Availability


If you are planning for

– Multi-forest implementation of Office 365
– Multi-forest / multi exchange organization hybrid
– Resource and accounts forest

You can now start directly with this new “version” of DirSync.

There is only one item which can be found in DirSync and AAD Sync has not, it is password hash sync. All other, and a lot more features are there!

Download Azure Active Directory Sync Tool here: http://go.microsoft.com/fwlink/?LinkID=511690
Documentation can be found here: http://go.microsoft.com/fwlink/?LinkID=393942

Preauthenticate Office 365 (SharePoint and Exchange) for Internal Users


Using ADFS for Single Sign On does not leverage a full Single Sign On Experience for the users. People will often see the Office 365 and need to fill in their email/upn, before Single Sign On will happen.

Thanks to a very nice OneDrive CodePlex project (http://office365drivemap.codeplex.com/), which you should visit too, I was able to write the following PowerShell script which you can use to preauthenticate Office 365 when you use ADFS.

Run the following powershell script after login (see http://msdn.microsoft.com/en-us/library/jj130675.aspx to configure the script to run after login)


$domain = "contoso.com"; # your Federated domain
$ie = new-object -com InternetExplorer.Application
$ie.navigate("https://login.microsoftonline.com/login.srf")
$ie.visible = $true #Uncomment this for debugging

# Wait for the page to finish loading
do {sleep 1} until (-not ($ie.Busy))
# We have to click the remember me checkbox before logging in, we also have to have IE be automated for this to work
try {
  $ie.document.GetElementById("_link").click()
  do {sleep 1} until (-not ($ie.Busy))
} catch {$null}

try {
  $ie.document.GetElementById("cred_userid_inputtext").value = "dummy@"+$domain
  $ie.document.GetElementById("cred_keep_me_signed_in_checkbox").click()
  do {sleep 1} until (-not ($ie.Busy))
  $ie.document.GetElementById("cred_sign_in_button").click()
  do {sleep 1} until (-not ($ie.Busy))
}catch {$null}

sleep -seconds 15 # give plenty of time to redirect
$ie.Quit()

For exchange it is quite easy to create a auto-login just with some DNS modification. You just need to create a CNAME to outlook.com.

e.g. webmail.contoso.com => outlook.com

How To Integrate Microsoft Azure Active Directory to Authenticate SharePoint 2013 for External Users


A few days ago I was designing a new Extranet solution for one of our clients.

The customer had the following requirements for the extranet with regard to authentication of external users.

– Manage external users and groups is an easy to use interface

– Users can manage their passwords themselves

– 2-factor authentication

– No access to other resources

Our first idea was to implement external access using ADFS with the federated parties, although it will work great for other extranet scenario’s, it did not met all of our requirements.

The second idea was to use Azure with WAAD (Windows Azure Active Directory) and ACS (Access Control Services) to met our goals. The WAAD would provide identities for our environment, supports multifactor authentication and users can reset their passwords themselves!

Get Started

So lets gets started with our Proof-of-Concept! The first hit on google regarding this scenario is a great blog post from Steve Pescka (http://blogs.technet.com/b/speschka/archive/2013/05/10/integrating-sharepoint-2013-with-azure-active-directory-part-1-configuration.aspx). He wrote several blog items about this topics which was really supporting the configuration.

Prerequisities

– Azure account (https://account.windowsazure.com/signup?offer=ms-azr-0044p to sign up)

– SharePoint 2013 Environment

Create Azure Active Directory

– Login to https://manage.windowsazure.com

– Go to Active Directory

– Press Add

– If you want to use an existing Azure Active Directory (like the one you use for Office 365), choose for Existing Directory. You will be asked to re-signin with an global administrator of the Office 365 tenant, after this process the Azure Active Directory is connected to you Azure account.

– For a new directory, fill in your directory details, if you want to use a custom domain you can add this afterwards.

– The Directory is ready to use. To use the features, password reset and groups you also need to Enable Active Directory Premium

– Click on Add a user

– Fill in the wizard and choose the role “Global Administrator”

– Download the Windows Azure Active Directory Shell
http://technet.microsoft.com/en-us/library/jj151815.aspx#bkmk_installmodule

Create ACS Service in Azure

If you have already setup a ACS namespace you can skip this step.

– Go to https://manage.windowsazure.com

– Press New, and add a new Access Control namespace

– Fill in a name and region and proceed

– Your ACS namespace will now be created

Configure Identity Provider in ACS

Configure the WAAD as an identity provider in ACS

– Go to https://manage.windowsazure.com

– Go to Active Directory

– Go to Access Control Namespaces and select your newly created namespace

– Go to Manage

– Go to Trust relationshops > Identity Providers

– Click on Add Identity Provider

– Choose a WS Federation provider

– Fill in a Descriptive Name and use https://accounts.accesscontrol.windows.net/<waad-name>/FederationMetadata/2007-06/FederationMetadata.xml as WS metadata URL. Provide your own WAAD or use a more general approach to allow multiple WAAD’s to sign in to your SharePoint 2013 environment using the federation url https://login.windows.net/common/FederationMetadata/2007-06/FederationMetadata.xml

Configure Relying Party Trust in ACS

Now we need to configure the on-premises SharePoint 2013 environment as the relying party

– Go to relying party applications

– Click on Add, choose to enter settings manually.

– Fill in a realm, in this example urn:sharepoint:acs, but it can be any realm (and take note of this, we need this later on)

– Select Token form SAML 1.1. (unfortunately SharePoint 2013 (and 2010) do not support SAML 2.0)

– Select the identity provider selected earlier

– Press Save

Configure Group Rules

Now we need to generate and configure the claim translation from the WAAD claim to an workable claim for SharePoint 2013.

– Go to Group Rules

– Click on Add, fill in a Group name “AAD Rules” and click Save

– Click on Generate

– Select the IdP created earlier and click Generate

– Select the Output claim UPN

– Set the input claim type to http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name instead of upn, because this input claim is empty. The name claim will contain the upn.

– Set the output claim type to http://schemas.microsoft.com/ws/2008/05/identity/claims/upn , which will be accepted by the STS of SharePoint.

– Click on Save

Enabled Application for WAAD to authenticate

– Execute the following Powershell

<code>

$replyUrl = New-MsolServicePrincipalAddresses –Address “https://<youracs>.accesscontrol.windows.net/v2/wsfederation”

New-MsolServicePrincipal –ServicePrincipalNames @(“https://<youracs>.accesscontrol.windows.net/”) -DisplayName “Joran Markx Tenant” -Addresses $replyUrl

</code>

Configure SharePoint to use ACS

– Go to Development -> Application integration

– Copy and paste the WS-Federation Metadata into the internet browser

– Copy and paste the base64 code in EntityDescriptor>RoleDescriptor>KeyDescriptor>..>X509Certificate to a notepad and save as .cer file (Certificate)

– Open the certificate to check if it is working great! If it does not, please check if you copied the whole X509Certificate and the file is saved with ANSII.

– Copy the .cer to the SharePoint 2013 Server

Create and configure STS in SharePoint

Now we need to create a new Trusted Root Authority and configure the Trusted Identity Token Issues.

– Open the SharePoint Management Shell (as Administrator)

<code>
$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(“c:aadcert.cer”)

New-SPTrustedRootAuthority -Name “ACS Token Signing Certificate” -Certificate $cert

$map = New-SPClaimTypeMapping -IncomingClaimType “http://schemas.microsoft.com/ws/2008/05/identity/claims/upn” -IncomingClaimTypeDisplayName “UPN” -SameAsIncoming

$map2 = New-SPClaimTypeMapping -IncomingClaimType “http://schemas.microsoft.com/ws/2008/06/identity/claims/role” -IncomingClaimTypeDisplayName “Role” -SameAsIncoming

$map3 = New-SPClaimTypeMapping -IncomingClaimType “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress” -IncomingClaimTypeDisplayName “EmailAddress” -SameAsIncoming

$map4 = New-SPClaimTypeMapping -IncomingClaimType “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname” -IncomingClaimTypeDisplayName “GivenName” -SameAsIncoming

$map5 = New-SPClaimTypeMapping -IncomingClaimType “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname” -IncomingClaimTypeDisplayName “SurName” -SameAsIncoming

$map6 = New-SPClaimTypeMapping -IncomingClaimType “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/jobtitle” -IncomingClaimTypeDisplayName “JobTitle” -SameAsIncoming

$map7 = New-SPClaimTypeMapping -IncomingClaimType “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/office” -IncomingClaimTypeDisplayName “Office” -SameAsIncoming

$realm = “urn:sharepoint:acs”

$ap = New-SPTrustedIdentityTokenIssuer -Name “AAD” -Description “ACS” -realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map,$map2,$map3,$map4,$map5,$map6,$map7 -SignInUrl “https://litware.accesscontrol.windows.net:443/v2/wsfederation” -IdentifierClaim http://schemas.microsoft.com/ws/2008/05/identity/claims/upn
</code>

– Create or configure a webapplication in SharePoint with Claims Authentication and select the new TrustedIdentityToken Issuer

– Authorize add at least one user from the WAAD to the a site in the webapplication

– You’re ready to go!

Test the solution

– Fire up a browser and go to your SharePoint site

– Select AAD, you will not get this screen if you disable Windows Authentication (and have only one authentication provider)

– Then select one of the IdP in ACS, you will not see this screen if you only have one IdP configured.

– You will now get the Azure Active Directory Login screen

– After entering your username and password, you will be redirected to SharePoint 2013 and will be logged in!

Known issues

– People picker will not find people in the directory
http://blogs.technet.com/b/speschka/archive/2013/05/12/integrating-sharepoint-2013-with-azure-active-directory-part-2-the-custom-claims-provider.aspx