Testing AD FS for Office 365 without Directory Synchronization

Artikel
02/22/2017

Let's say you're in one of the following scenarios:

You need to set up AD FS for a shared hosting environment and won't have any identities synchronized from the forest where AD FS will be deployed and want to verify that the AD FS infrastructure is working.
You need to stage AD FS before you're ready to connect to Office 365 and want to verify that the AD FS infrastructure is working.

In either is you need to get an identity in the cloud that can be linked back to an on-premises identity. It's actually way easier than it sounds.

Confirm a domain in a tenant

In order to configure federation, you must have a verified domain in a tenant. So, do that.

Add the UPN suffix for the tenant domain to your AD forest

Again, if you've been working with Office 365 for a while, this should come as no surprise. If you haven't done this before:

Launch Active Directory Domains and Trusts.
At the top node (Active Directory Domains and Trusts), right-click and select Properties.
Type the new domain suffix for the domain that you will be testing this AD FS infrastructure against, and click Add.
Click OK to close the UPN suffixes dialog box.

Federate your domain

This is a pretty straightforward process. You'll need a global admin ID in your Office 365 tenant and to have installed the Azure Active Directory PowerShell cmdlets on your AD FS primary farm server.

Log into the primary AD FS Farm server.
Launch Elevated PowerShell prompt.

 $cred = Get-Credential <enter department Global Admin in the form of admin@tenant.onmicrosoft.com>

```
 Connect-MSOLService -Credential $cred
```
If you didn’t log into the primary farm server, update the AD FS context:
```
 Set-MSOLADFSContext -Computer <primary AD FS farm server>
```

Federate the domain (I always use he -SupportMultipleDomain switch)

 Convert-MsolDomain -DomainName <dept namespace> -SupportMultipleDomain

Create a fake synchronized object

This is the moment we've all been waiting for.

Create an identity in the AD FS Active Directory forest (in my case, I named the user testfederation) using the UPN suffix. I'm creative that way.
Launch the Azure AD PowerShell and connect to Office 365.
Import the ActiveDirectory module.
Convert the user's objectGUID to the base64 value that will be used in Office 365 using this snazzy one-liner:
```
 $ImmutableID = [system.convert]::ToBase64String((get-aduser testfederation).objectGuid.ToByteArray())
```

Create a new user in the federated namespace:

 New-MsolUser -UserPrincipalName testfederation@verifieddomain.com -DisplayName "Test Federation" -FirstName "Test" -LastName "Federation" -ImmutableID $ImmutableID

Test logging in with the federated ID to Office 365.

It's not solving world peace, but it's a good step.

Comments

Anonymous
February 23, 2017
always relevant, seems were working veryprojects sometimes:)cool trickThanks
- Anonymous
  February 23, 2017
  So it would seem. At least, we all have to jump through similar hoops in our daily consulting, deployment, and administration lives. :-)

Freigeben über