Seamless Sign On, Kerberos roll over–Wait what??

UPDATE: So happy to see that Microsoft has heard our prayers. They are working on a solution to automate the rollover in Azure. Read more about it HERE.

 

So, you’ve installed Seamless Sign On, and its been running awesome, by chance you logon to your Azure tenant, just nosy browsing around, improving your Azure skills, and suddenly you find this……. Kerberos Roll Over, wait what? erhm… What?….. Confused smile

image

First of, when I saw this, I thought it was a joke, but after thinking it over, it made sense….in a weird kind of way.

First of, when you install AADConnect and enable Seamless Sign On and Single Sign On, you get an extra auto generated Computer object in your AD called AZUAREADSSOACC.

image

This is the object in charge of handling / generating the shared Kerberos key needed between local AD and Azure AD. (best leave that one alone Smile with tongue out)

Since this is a “dead, virtual” object, it is not able to create new keys automatically, so for at best practice, MS recommends to do a manual “Roll-Over” every 30 days. I will explain how to do this in a short while, first of, cast your vote HERE, for the feature of AADConnect to do automatic Roll-Overs….Awesome, Thanks.

First of, connect your Powershell ISE to your Tenant.

(You got to know that one by now Smile)

Next you run these simple Cmdlets. (NOTE: These Cmdlets and the text is copied from the official MS documentation. Explanations where great, so no need to convert them )

(I’m really sorry, but for some reason i didn’t get the steps in, where you have to import the powershell script AzureADSSO.psd1. This script has the CMDlets you need.)

You have to run this from the server, where you run AADConnect. So, dive down to the install dir, and import this

cd “C:\Program Files\Microsoft Azure Active Directory Connect”

Import-Module .\AzureADSSO.psd1

New-AzureADSSOAuthenticationContext

#This command should give you a popup to enter your tenant’s Global Administrator credentials.


Get-AzureADSSOStatus | fl


#This command provides you the list of AD forests (look at the “Domains” list) on which this feature has been enabled.

#Step 2. Update the Kerberos decryption key on each AD forest that it was set it up on

$O365Cred
= Get-Credential

# When prompted, enter the Domain Administrator credentials for the intended AD forest
.

Update-AzureADSSOForest
-OnPremCredentials $O365Cred

#This command updates the Kerberos decryption key for the AZUREADSSOACC computer account in this specific AD forest and
 updates it in Azure AD.

#Repeat the preceding steps for each AD forest that you’ve set up the feature on

And you’re done…. AADConnect welcomes you back in 30 days Smile. Seriously, save it in a .psd1 file, for easy running, next time.

THATS why I use PowerShell ISE for everything (and the fact that my memory is really bad Open-mouthed smile)

I’ve seen some bloggers doing articles where they save Global Tenant admin’s and corresponding passwords in text files, encrypted, not encrypted and so on, in an attempt to automate this. Needles to say, this is a MAJOR SECURITY RISK, and cannot be recommended. Better yet, go cast your vote, so that MS puts this feature inside AADConnect.

Until next time, happy cloud computing Smile

Seamless Sign On and High Availability

In my previous articles I’ve written about Seamless Sign On, and for good reason. It’s an absolutely awesome feature Surprised smile. For small and midsize companies wanting to go “up” the Cloud road, not having Exchange, SharePoint and so on, with the high cost, tons of expensive maintenance in their Onprem environment.

Office 365 is, in my humble opinion, the only way to go. But what about the users. Well AADConnect is a must, if you have your own AD. So you have 4 options for authentication…

– User sync but Cloud only password

– Password synchronization

– ADFS Single Sign On

– Seamless Sign On

User sync but Cloud only password

Not really an option in my book. We want to make it easy for the users and not giving them 2 sets of credentials to worry about. (gives us less time to enjoy a good cup of coffee Winking smile)

Password synchronization

Could be a possibility, but why would you force your users to login twice?

ADFS Single Sign On

Absolutely, IF you want to maintain 2 ADFS server, 2 WAP servers and you AADConnect server. ADFS is an awesome feature. But it leaves a fairly large footprint in your infrastructure, especially if you want high availability. Maybe not the best solution for the smaller to midsize company’s.

Seamless Sign On

YESSSS…. You guessed it…. Seamless Sign On to the rescue. First of, I’ve never had an AADConnect service break down, its very stable (Big thanks to the guys at Microsoft Thumbs up). Second, if the server you’ve installed AADConnect on crashes, well users won’t be able to logon. But why bother getting stressed about it? Just make it High Available Winking smile. With the newer versions, you have the option to install AADConnect Authentication Agent.

So, here we go Fingers crossed

First of, a little about my test setup. I have 2 Domain Controllers and one File server. AADConnect is installed on DC01 (I won’t go into the installation process of AADConnect), and I want to install the AADConnect Authentication agent on my File Server.

Logon on to your O365 tenant, and go straight to the Azure Portal –> Go to “Azure Active Directory” –> then to “Azure AD Connect”

image

Click on “agents” (please disregard the warning sign and the 3’rd agent, it was for testing purpose, and it takes a while for Azure to realize, its not there anymore, and I was so excited to write this article, that I didn’t have the patience to wait for it to go away.)

image

At the top left, you have a Download option, this is the agent install file. (I’ve cheated, and already installed it on the File server… Shh…)

image

It’s a Next –> next, finish installation, so no need to document that.

After a short wait, the second “agent” will popup in your view. Now, your Seamless sign on setup as HA…. And yes, it really is that easy.

In my setup I have 2 DC’s, so if the AADConnect DC crashes, the Authentication agent on the File server, still has authentication against the second DC.

The “downside” to this, is you’ll need at least 2 Domain Controllers, for this to work, but with multi-role servers today, I don’t see this as any issue.

Hope you enjoyed, this little write-up. Feel free to comment Winking smile

Seamless Sign On – How to and why

Seamless Sign On, what is it and why would you want to use it

Well, good questions. Seamless Sign On is a fairly new feature in Azure ADConnect, that allows users to have that “Single Sign On” experience, you get from using ADFS, but without the huge infrastructure. I can’t really see a lot of large companies using this feature, but for smaller / midsize businesses it makes a lot more sense. Why? Make it as easy for your users as possible, they would only need to remember 1 password, and you, as and admin, are in control of your users ID’s and passwords, from within your local AD (which in return will give you more time to enjoy your coffee)

So, lets get to it and start looking at the configuration. It doesn’t matter if you already have Azure ADConnect installed, or its a new installation. Its the same settings for both scenarios.

First of, start the AADConnect wizard. If you install AADConnect for the first time, the below is what you need to configure.

image

If you already have AADConnect running, this is what you need to configure.

image

On a side note, I would always recommend using OU filtering, so that you only synchronize what you need, and not all objects from AD. It will only look messy and confusing.

image

After configuration is done, you need a little more work on the client side. You need to set up GPO’s to allow Azure to receive the Kerberos tickets for Authentication before it works. So you need your browser to trust some sites.

Internet Explorer

For IE users (the few left smiley lol), you need to add some URL’s to the local intranet zone. Preferably done by GPO. These are the 2 addresses you need to add:

https://autologon.microsoftazuread-sso.com
https://aadg.windows.net.nsatc.net

Chrome

For Chrome users, there is a little more work, but it pays of. First of, download the Google ADMX files and add them to your AD, so that you are able to configure Chrome with GPO’s. Afterwards go to the Google Extension store. Search for “Windows 10 accounts”

clip_image002

Right click on the the logo and copy the link address.

clip_image004

Paste it to notepad

image

Copy the “app id”, from the last dash, to the questionmark, and paste it on a new line. Now you need to format the address for the Chrome GPO.

Separate the 32 character ID, with the default Google store address ;https://clients2.google.com/service/update2/crx, so that it looks like this

ppnbnpeolgkicgegkbkbjmhlideopiji;https://clients2.google.com/service/update2/crx

Find the correct Computer GPO setting for Chrome extensions

clip_image006

Open up “Configure the list of force-installed apps and extensions

Enable –> show, and paste the above ID address we created a few seconds ago

clip_image008

Save the GPO and link it to the OU where your computers are located, and you’re in business.

Once the GPO is “active” on clients (if it doesn’t happen run gpupdate /force, might require a restart) you will see the little Windows logo on the right topside of Chromeimage

Try and click on it smiley surprise, or just go to https://portal.office.com.

I have not tested it with other browsers. Edge browser isn’t supported, go figuresmiley disappointed

Pros and cons

I my opinion this as an awesome feature. Some of the smaller customers that I have helped, would definitely have benefited from this, instead of an ADFS infrastructure, but that’s just me smiley sunglasses. I will list my view on pros and cons here.

Pros

  • Users, need only to remember their AD password, and get easy access to your Office 365 tenant
  • Easy configuration, no need for expensive certificates, or a larger infrastructure as with ADFS
  • If browsers are configured correctly, the Seamless Sign On is as close to the Single Sign On, as you can get
  • The AADConnect / service is really stable. I have yet to see it crashing, or break down
  • Low footprint in your infrastructure. With installation on Domain Controllers being supported, or maybe your file server / application server, you don’t need dedicated HW / VM to run add extra costs

 

Cons

  • If the service is down, users can’t login. It’s possible to make the solution High available, but for that you will need one more local server to install an agent on
  • hmm… not sure I can find any more cons, but if i do, I’ll be sure to update smiley lol

 

Have fun, and enjoy.