Securing and restricting access to Office 365 with custom AD FS claimrules

We’ve been working hard with one of our clients to secure access to Office 365 workloads such as Exchange Online. In this specific article we will share our experience how to restrict access to Exchange Online to specific networks and for specific protocols.

This client was using MobileIron for securing mobile devices and wanted to integrate this MDM solution with Office 365.

The tricky part of securing access to Exchange Online with MobileIron is the fact that MobileIron Sentry servers require dedicated IP adresses to Exchange. As you can imagine, the always changing Office 365 Cloud – with all it’s IP Addresses – will make it hard to follow this requirement. Thus we had to use a different technology, outside of MobileIron for restricting access to Office 365.

We chose to implement custom claimrules in AD FS, the enviroment we built this solution for on was an AD FS 2016 farm. In this new version of AD FS there are several changes on how to create custom claim rule, by default AD FS 2016 uses Access Control Policies and with these policies it was not possible to create such custom claim rules. So before we begin, we will start with explaining how torevert back to making use of the old school way of creating claim rules

  1. Log on the one of your AD FS servers
  2. Fire up PowerShell and run these commands
    1. $ADFSRpt = Get-AdfsRelyingPartyTrust -Name “Microsoft Office 365 Identity Platform”
    2. Set-AdfsRelyingPartyTrust -TargetRelyingParty $ADFSRpt -AccessControlPolicyName $null
    3. Set-AdfsRelyingPartyTrust -TargetRelyingParty $ADFSRpt -IssuanceAuthorizationRules $null
    4. Set-AdfsRelyingPartyTrust -TargetRelyingParty $ADFSRpt -IssuanceAuthorizationRules ‘@RuleName = “TEMP RULE” exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy”%5D) => issue(Type = “http://schemas.microsoft.com/authorization/claims/deny”,Value = “true”);’
  3. Open the AD FS Management Console
  4. Navigate to “Relying Party Trusts” and select the Office 365 relying party trust.
  5. Click on “Edit Access Control Policy” in the right menu to find the old menu for configuring “Issuance Authorization Rules”
  6. Remove the “TEMP RULE’ but DO NOT close the window
    Issuance AuthorizationRules

Now here the cool part comes, which is actually restricting specific traffic and protocols to specific networks, for instance SMTP or EWS traffic.

Restricting ActiveSync Protocol

  1. Add new rule
  2. Insert the following custom claim
  3. This claim contains the dedicated IP Adress from the MobileIron Sentry server from which we do accept ActiveSync traffic to Office 365. All other IP adressess are denied.

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-client-application”, Value == “Microsoft.Exchange.ActiveSync”])
&& NOT exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip”, Value =~ “\b82\.125\.45\.23\b”])
=> issue(Type = “http://schemas.microsoft.com/authorization/claims/deny”, Value = “true”);

Restricting IMAP Protocol

  1. Add new rule
  2. Insert the following custom claim
  3. This claim contains the dedicated IP Adress from the MobileIron Sentry server from which we do accept IMAP traffic to Office 365. All other IP adressess are denied.

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-client-application”, Value == “Microsoft.Exchange.Imap”])
&& NOT exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip”, Value =~ “\b82\.125\.45\.23\b”])
=> issue(Type = “http://schemas.microsoft.com/authorization/claims/deny”, Value = “true”);

Restricting SMTP Protocol

  1. Add new rule
  2. Insert the following custom claim
  3. This claim contains the dedicated IP Adress from the MobileIron Sentry server from which we do accept SMTP traffic to Office 365. All other IP adressess are denied.

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-client-application”, Value == “Microsoft.Exchange.SMTP”])
&& NOT exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip”, Value =~ “\b82\.125\.45\.23\b”])
=> issue(Type = “http://schemas.microsoft.com/authorization/claims/deny”, Value = “true”);

Restricting POP Protocol

  1. Add new rule
  2. Insert the following custom claim
  3. This claim contains the dedicated IP Adress from the MobileIron Sentry server from which we do accept POP traffic to Office 365. All other IP adressess are denied.

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-client-application”, Value == “Microsoft.Exchange.Pop”])
&& NOT exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip”, Value =~ “\b82\.125\.45\.23\b”])
=> issue(Type = “http://schemas.microsoft.com/authorization/claims/deny”, Value = “true”);

Restricting EWS Protocol

  1. Add new rule
  2. Insert the following custom claim
  3. This claim contains the public IP Adress range from the on-premises network from which we do accept EWS traffic to Office 365. All other IP adressess are denied. For this claimrule we also require the hybrid Exchange servers to send EWS traffic to Office 365 for delivering rich-coexistence functionality to all users. This example allows traffic from the range of 82.125.45.1 – 82.125.45.14.

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-client-application”, Value == “Microsoft.Exchange.SMTP”])
&& NOT exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip”, Value =~ “\b82\.125\.45\.([1-9]|1[0-4])\b”])
=> issue(Type = “http://schemas.microsoft.com/authorization/claims/deny”, Value = “true”);

Now the current rule configuration should look like this:

Issuance AuthorizationRules2

The last rule to be added is a standard rule “Permit Access to All Users” and be sure this rule is at the bottom of the list with the “Permit” action.

Now all desired Exchange protocols are restricted to anywhere besides the MobileIron Sentry server or either the on-premises network range for some EWS traffic to support free/busy and other hybrid traffic to Exchange on-premises. However the new Outlook for iOS and Android app doesn’t use these traditional Exchange protocols. This new nifty app uses the Graph API for fetching e-mail and other resources.

To restrict access from unknown clients to Exchang Online with the use of the Outlook for iOS or Android app we chose to make use of Conditional Access for Azure Active Directory. And restrict access from any other networks then the public IP address from the Sentry server. To make use of this feature an Azure Active Directory Premium P1 license is required though!

A last fun fact to end this blogpost with is the fact that the documentation provided by Microsoft on TechNet is incorrect. The technet documentation on Limiting Access to Office 365 Services Based on the Location of the Client lists an incorrect HTTP Header for Imap traffic Microsoft.Exchange.PopImap. After a lot of searching and troubleshooting with Microsoft our eye fell on a little detail in the ADFS trace logs which caused the initial claimrule for Imap to fail. We found out that HTTP Headers for Imap traffic use the value Microsoft.Exchange.Imap and not Microsoft.Exchange.PopImap as described in the article!! Below here you can find the event registered in the AD FS Trace Logs from a IMAP client:

Following request context headers present:

X-MS-Client-Application: Microsoft.Exchange.Imap
X-MS-Client-User-Agent: –
client-request-id: 6338b8c2-c283-4c93-2c00-0080000000c6
X-MS-Endpoint-Absolute-Path: /adfs/services/trust/2005/usernamemixed
X-MS-Forwarded-Client-IP: xxx.xxx.xxx.xxx, xxx.xxx.xxx.xxx
X-MS-Proxy: WAP
X-MS-ADFS-Proxy-Client-IP: xxx.xxx.xxx.xxx

Big shout-out to my fellow friend and teammember Kevin Raap for working together on the claimrules, and finding out the flaw in Microsoft Technet documentation.

Configuring a multi-tenant federation with AD FS in a multi forest scenario with PowerShell

For weeks we have been working with Microsoft Premier Support and several product teams within Microsoft on a multi-forest to multi-tenant federation solution for Office 365 at two Dutch municipalites. There was some unclarity concerning supportabilty for our desired architecture at Microsoft, but as Microsoft calls it… this architecture qualifies for supportabilty. The fun part is, this scenario doesn’t require the provisioning of AD objects by hand, and allows you to use AADConnect to do this for you!

Now as the topology shows, we have two accounting forests where the AADConnect servers and Active Directory users reside. Each municipality has its own forest (forest B and forest C) and a configured a two-way full trust (forest-wide) to the resource forest (forest A). The Active Directory Federation Services (AD FS) farm resides in the resource forest (forest A).

Now the business requirement is having a single but high available AD FS farm in a resource forest, delivering an easy way of administering Identity Management for the long term. While at the same time delivering single sign-on functionality to all users working with Office 365 for each respected municipality.

Now the hard part here is the second federation to Office 365. The first federation configurated between the Microsoft Federation Gateway and your on-premises AD FS farm is pretty straight forward. And here is how it’s done:

  1. Log in to one of the AD FS Servers with an Domain Administrator account.
  2. You need to install the modules that are required for Office 365,
    1. Microsoft Online Service Sign-in Assistant for IT Professionals RTW
    2. Windows Azure Active Directory Module for Windows PowerShell (64-bit version
  3. Setup a Remote PowerShell connection to your tenant with an account having Global Administrator rights with this script;
    1. Import-Module MSOnline
      $O365Cred = Get-Credential
      $O365Session = New-PSSession –ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -Credential $O365Cred -Authentication Basic -AllowRedirection
      Import-PSSession $O365Session
      Connect-MsolService –Credential $O365Cred

Once connected to the first tenant in Office 365 on the AD FS server run this cmd-let, be sure to use the -SupportMultipleDomains $true parameter.

Convert-MsolDomainToFederated -DomainName contoso.com -SupportMultipleDomain $true

The –SupportMultipleDomain parameter is needed since this is required for the multi-tenant configuration to work. This paramater makes sure that the federation is built with the correct IssuerUri set to https://contoso.com/adfs/services/trust/ instead of the Federation Service namespace (generally sts.domain.com) when not using this parameter. This is a vital requirement later on. To double-check this you can check the Claim Rules in AD FS management, the third rule should containt this claim:

c:[Type == “http://schemas.xmlsoap.org/claims/UPN“] => issue(Type = “http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid“, Value = regexreplace(c.Value, “^((.*)([.|@]))?(?<domain>[^.]*[.].*)$”, “http://${domain}/adfs/services/trust/“));

Now this was the first municipality for which contoso.com is the federated domain. You can download the script at the bottom of this blog.

Wait for a minute -or five- untill the federation kicks in and let’s carry on implementing the second federation…the real fun part!

First of all we need to export the token-signing certificate from the AD FS farm by PowerShell:

$tokenRefs=Get-AdfsCertificate -CertificateType Token-Signing
$tokenBytes=$certRefs[0].Certificate.Export([System.Security.Cryptography.X509Certificates.X509ContentType]::Cert)
[System.IO.File]::WriteAllBytes(“c:\temp\tokensigning.cer”, $certBytes)

Next we can establish a new Remote PowerShell session to the second tenant with the script shared in step one of this post. After that we configure the second federation with this PowerShell script.

$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(“C:\temp\tokensigning.cer”)
$certData = [system.convert]::tobase64string($cert.rawdata)
$dom=”fabrikam.com”
$url=”https://adfs.ResourceForestFDQN.com/adfs/ls/&#8221;
$uri=”http://fabrikam.com/adfs/services/trust/&#8221;
$ura=”https://adfs.ResourceForestFDQN.com/adfs/services/trust/2005/usernamemixed&#8221;
$logouturl=”https://adfs.ResourceForestFDQN.com/adfs/ls/&#8221;
$metadata=”https://adfs.ResourceForestFDQN.com/adfs/services/trust/mex&#8221;
#command to enable SSO
Set-MsolDomainAuthentication -DomainName $dom -Authentication Federated -ActiveLogOnUri $ura -PassiveLogOnUri $url -MetadataExchangeUri $metadata -SigningCertificate $certData -IssuerUri $uri -LogOffUri $logouturl -PreferredAuthenticationProtocol WsFed

Now the most beautiful part of this second implementation is that it only configures endpoints on the Microsoft Federation Gateway, and doesn’t touch our on-premises configuration. The magic third claim we talked about earlier is all we need for it to work!

Once configured, the configuration of both tenants can be validated using the ‘Get-MsolDomainFederationSettings’ cmdlet. The only difference when comparing the tenant configuration should be the ‘FederationBrandName’ and the ‘IssuerUri’ values.

Download the PowerShell scripts right here!

 

 

 

Office 365 Hybrid Configuration Wizard for Exchange 2010 free/busy bug

Recently we used the new Office 365 Hybrid Configuration Wizard for Exchange 2010.

The Office 365 Hybrid Configuration wizard has been updated to support Exchange 2010. This new wizard comes with the following advantages:

  • An updated user experience that simplifies the hybrid configuration process
  • The error handling experience allows for simple remediation of issues, meaning you can actually read and understand the error
  • Fixes for HCW can happen quickly and are no longer tied to the on-premises product release cycle
  • Inefficient code that caused the HCW to take hours to run has been completely reworked and now you should be in and out in minutes

The on-premises Exchange 2010 environment was updated to the latest SP and CU and had one multi-role hybrid server. For the new Office 365 HCW please read this article published by the Exchange product team.

The HCW ran smoothly without big issues and completed succesfully. However when testing the created functionality we noticed free/busy didn’t work from on-prem users to cloud users. The free/busy worked like a charm vice-versa.

When troubleshooting further we ran the following two PowerShell cmd-lets to test the created OrganizationFederation on the on-premises Exchange Organization.

Get-FederationInformation -DomainName contoso.mail.onmicrosoft.com

Test-OrganizationRelationship -Identity “On-premises to O365 – 9a4a2b73-ebb9-4925-91ec-3b4dae60
6805” -UserIdentity clouduser@contoso.com 

Both cmd-lets resulted in this generic error message:

WARNING: An unexpected error has occurred and a Watson dump is being generated:

After running the Test-OrganizationRelationship cmd-let with the -Verbose parameter we noticed all steps and iterations done and exactly where the cmd-let failed. The cmd-let failed on the EWS call to our tenant at this step:

Test-OrganizationRelationship : Calling the Microsoft Exchange Autodiscover service for the remote federation information.

Further down the pipeline we noticed this explicit error message which contained valuable troubleshooting information.

Test-OrganizationRelationship : The Microsoft Exchange Autodiscover service failed to be called at ‘https://autodiscover.outlook.com/autodiscover/autodiscover.svc&#8217; because the following error occurred:
Exception:
Microsoft.Exchange.SoapWebClient.GetFederationInformationException: Discovery for domain contoso.mail.onmicrosoft.com failed. —>
System.Net.WebException: Unable to connect to the remote server —> System.Net.Sockets.SocketException: No connection
could be made because the target machine actively refused it 132.245.226.24:443
at System.Net.Sockets.Socket.DoConnect(EndPoint endPointSnapshot, SocketAddress socketAddress)
at System.Net.ServicePoint.ConnectSocketInternal(Boolean connectFailure, Socket s4, Socket s6, Socket& socket,
IPAddress& address, ConnectSocketState state, IAsyncResult asyncResult, Int32 timeout, Exception& exception)
— End of inner exception stack trace —

After comparing the current OrganizationRelationship (see image below)  with other clients hybrid configurations we noticed a difference on the TargetAutodiscoverEpr memberobject of the OrganizationRelationship object.

26-4-2016 10-48-56.png

At the OrganizationRelationship which was created by the new Office 365 Hybrid Configuration Wizard for Exchange 2010 the TargetAutodiscoverEpr was configured at the https://autodiscover.outlook.com/autodiscover/autodiscover.svc/WSSecurity namespace. At the other clients environment we used the built-in HCW from the Exchange 2010 EMC. And the namespace of the TargetAutodiscoverEpr was different. It had https://autodiscover-s.outlook.com/autodiscover/autodiscover.svc/WSSecurity configured and worked like a charm.

Now when we found the dissimilarity in both configurations we contacted Microsoft. We told Microsoft Suppoort that we used the brand-new Office 365 Hybrid Configuration Wizard for Exchange 2010 and showed them the other clients environment. Microsoft proposed to change the namespace on the environment to https://autodiscover-s.outlook.com/autodiscover/autodiscover.svc/WSSecurity and test free/busy calls. After changing the value to the correct namespace the free/busy availability information worked!

Microsoft is further investigating this behaviour but to me it looks a lot like a bug in the new Office 365 HCW for Exchange 2010 environments. So please be aware for this behaviour when running the newly published HCW on Exchange 2010 environments…

Cheers!

Using the SimpleDisplayName attribute for Exchange and Exchange Online in Office 365 with PowerShell

So I came across a scenario where a organization doesn’t use the DisplayName field for external mailflow and has this disabled on their Remote Domain. In this scenario messages will use the SMTP address.

This setting is enabled by default and Exchange Server will use the DisplayName field for external mailflow. Now imagine the scenario you want your users to use a different and somewhat more catchy name for external parties and suppliers. A nice additional attribute can be used for this, which is the SimpleDisplayName attribute. By populating this object with for instance “John Doe – Microsoft Corporation” you will use this information for external parties, and keep using the already in-place DisplayName attribute for internal mailfow and these changes wont affect your Global Address List.

Now to enable Exchange Server, or Exchange Online to use start using the SimpleDisplayName object this needs to be enabled on your Remote Domain. This can be done via a simple PowerShell one-liner.

Set-RemoteDomain -Identity Default -UseSimpleDisplayName $true

Now once this is done Exchange will stop using the populated DisplayName field, and it will use the empty SimpleDisplayName field on userobjects. While being empty and not populated Exchange will use the SMTP Address for external mailflow, so next step will be populating all the empty fields  with the new desired values.

To accomplish this I use this handy PowerShell script which uses the FirstName and LastName attribute and adds a catchy company name behind it.

$users = Get-User -ResultSize Unlimited
foreach ($user in $users) {

$name=$user.DisplayName

$SDN=[string]::Concat($user.FirstName.Trim(), ” “, $user.LastName.Trim(), ” – Microsoft Corporation”)

Set-User $user.Identity -SimpleDisplayName $SDN

}

Intune device enrollment AD FS sign-in error “An error occurred. Contact your administrator for more information.”

Recently a client of mine added Windows Intune to their existing Office 365 subscription. The enablement of Intune requires users to install the Company Portal App on their mobile device which enrolls their device to your Office 365 organization.

In the process of enrolling a device it asks to login to Office 365. When a user tries to login with a federated Identity useraccount the login session will be redirected to your local AD FS sign-in page. However, when this is done from a mobile device it throws an error.

“An error occurred. Contact your administrator for more information.”

4-2-2016 14-17-03

Now once you have a look on the AD FS Admin eventviewer logging which can be found under the Applications and Services tree in the eventviewer MMC snap-in.

There you will find the error listed below:

Encountered error during federation passive request.

Additional Data

Protocol Name:
wsfed

Relying Party:
urn:federation:MicrosoftOnline

Exception details:
Microsoft.IdentityServer.Service.Policy.PolicyServer.Engine.InvalidAuthenticationTypePolicyException: MSIS7102: Requested Authentication Method is not supported on the STS.
at Microsoft.IdentityServer.Web.Authentication.GlobalAuthenticationPolicyEvaluator.EvaluatePolicy(IList`1 mappedRequestedAuthMethods, AccessLocation location, ProtocolContext context, HashSet`1 authMethodsInToken, Boolean& validAuthMethodsInToken)
at Microsoft.IdentityServer.Web.Authentication.AuthenticationPolicyEvaluator.RetrieveFirstStageAuthenticationDomain(Boolean& validAuthMethodsInToken)
at Microsoft.IdentityServer.Web.Authentication.AuthenticationPolicyEvaluator.EvaluatePolicy(Boolean& isLastStage, AuthenticationStage& currentStage, Boolean& strongAuthRequried)
at Microsoft.IdentityServer.Web.PassiveProtocolListener.GetAuthMethodsFromAuthPolicyRules(PassiveProtocolHandler protocolHandler, ProtocolContext protocolContext)
at Microsoft.IdentityServer.Web.PassiveProtocolListener.GetAuthenticationMethods(PassiveProtocolHandler protocolHandler, ProtocolContext protocolContext)
at Microsoft.IdentityServer.Web.PassiveProtocolListener.OnGetContext(WrappedHttpListenerContext context)

Solution:

  1. Logon to AD FS server(s).
  2. Open the AD FS Management Console
  3. On the right hand side right click on the Authentication Policies folder
  4. Choose “Edit Global Primary Authentication…”
  5. In this menu you should check (enable) Forms Authentication on both Intranet and Extranet.

 

After enabling forms authentication on both sides the AD FS requests sent from mobile devices will be succesfully authenticated by the AD FS secure token service.

How to force a manual DirSync to Office 365 with AADConnect

Since the introduction of the renewed version of DirSync – called AADConnect nowadays – we have noticed great new functionalities. Depending upon the version that you are using to replicate Active Directory objects from on-premises Active Directory Domain Services to Office 365 Windows Azure Active Directory there are different commands that you will need to use.

Since June 2015 we have the release of AADConnect. As time of writing this blog the current version we’re on is 1.0.9125.0. Because the tool is under heavy development check out version history ocasionally on this website.

The default installation folder of AADConnect is C:\Program Files\Microsoft Azure AD Sync\Bin and this is where you can initiate a full or delta sync to Office 365.

deltasync_aadconnect

  1. Open PowerShell with administrative priviliges.
  2. Change the directory to folder containing the tool with the cmd-let cd “C:\Program Files\Microsoft Azure AD Sync\Bin” 
  3. To initiate a Full Syc to Office 365 run the cmd-let .\DirectorySyncClientCmd.exe initial staging 
  4. For a incremental or delta sync the cmd-let .\DirectorySyncClientCmd.exe delta 

Now be patient for 5 minutes for the new and edited objects to show up on the Office 365 portal. Depending on the amount of objects in ADDS and assigned server resources this action can take up to 15 minutes.

Import distribution groups to Office 365: Exchange Online with PowerShell

Today we faced an issue where a client needed to migrate their GroupWise distribution groups to Office 365. Since there is no easy way doing this we developed a PowerShell script to automate this proces. Well, actually it are two scripts.

The scripts are divided in one, creating the distribution groups and part two is adding the members to the newly created groups. First we have to gather the input for creating the distribution groups in Office 365. For this I only used the required attributes for creating a distribution group.

$import = Import-Csv -Path “C:\temp\Create-DG.csv” -Delimiter “;”
foreach ($item in $import) {
New-DistributionGroup -Name $item.Name -DisplayName $item.DisplayName -PrimarySmtpAddress $item.PrimairyEmailAddress -Type $item.Type
Export-Csv -Path “C:\temp\New-DistributionGroup_LogFile_$(get-date -Format ddMMyyyy).csv”
}

Once the distribution groups are created we can head on adding the members to them using the PowerShell script below.

$import = Import-Csv -Path “C:\temp\Add-DGMembers.csv” -Delimiter “;”
foreach ($item in $import) {
Add-DistributionGroupMember -Identity $item.GroupName -Member $item.UPN -Verbose
Out-File -FilePath “C:\temp\Add-DGMembers_LogFile_$(get-date -Format ddMMyyyy).log”
}

As we can see both the scripts import a .csv file containing the content. The .csv files and the PowerShell scripts can be downloaded below.

DOWNLOAD HERE

Please note that the distribution groups can be either created on-premises in Active Directory and then synced to Windows Azure Active Directory (Office 365) or either directly created in Office 365 with the help of remote PowerShell. Based on your infrastructure and migration scenario it can differ which is the best way to go. Functionally there will be no difference for Exchange Online. However in some hybrid scenarios it can be best to create the distribution groups on-premises and sync them to Office 36 with the help of Azure Active Directory Sync (DirSync).

First post!

Welcome at my blog. On this site you will find technical articles and solutions about various Microsoft products such as:

  • Office 365
  • Exchange Online
  • SharePoint
  • Microsoft SQL Server
  • ADFS and DirSync

Please stay tuned for new blogs to be released very soon!

Blog at WordPress.com.

Up ↑