Oops, I deleted AZUREADSSOACC – What now – How to fix

Accidents happen, we are only human and sometimes we accidently delete something that we shouldnt have. In most cases its no big deal, we can restore wlEmoticon-thumbsup.png. When it comes to Active Directory, it actually can be an issue. AD restores can be a nightmare (in my humble oppinion, anyways).

On a quick sidenote, enable AD recycle Bin, it can really save you some time.

Open Active Directory Administrative Center

2019-10-08_10h48_48

2019-10-08_10h50_05

After enabling it, you can’t disable it (but why would you?)

BUT, in this case we “act” like, we havent enabled it wlEmoticon-smile.png

So somebody accidently deleted the AZUREADSSOACC computer account . This is the “virtual” computer account, used with Azure AADConnect when you enable SSO. (You can read more about it in a previous articel HERE.

Normally its placed In the Computers container2019-10-08_11h12_28

But, in this case we deleted it ( And just to prove to you, that I’m not cheating smiley disappointed)

2019-10-08_11h13_55

It’s gonewlEmoticon-sleepysmile.png

 

First you need to log on the computer on which you have AADConnect running.

Right click, and choose run as Admin (If you have UAC enabled, click yes wlEmoticon-smile.png ) on the “Azure AD Connect” icon, placed, must likly on your desktop (Thats default)

2019-10-08_11h16_12

2019-10-08_11h17_39

Click “Configure”

2019-10-08_11h18_35

Choose “Change user sign-in”, and click next. Logon with your Office 365 Global Admin account

2019-10-08_11h19_55

Remove the option for “Enable single sign-on” and click next

2019-10-08_11h21_48

And then, Configure

2019-10-08_11h23_46

Now, if the next screenshot is what you get, you are got to gowlEmoticon-thumbsup.png. If it comes with a warning, saying something like “Single sign-on could not be disabled”, have no fear, it did for me when I did some test the first time. Run the wizard to the end, wait 5-10 min. and try again. You should end up with it being succesfully disabled.

2019-10-08_11h25_12

Status: For now, we have diabled SSO. Now we need to enable it again, because its an awesome feature and we really want it……

Run the Wizard again (As an admin), and make sure you set the tick (or what ever you call it) in “Enable single sign-on”

2019-10-08_11h30_35

Click next – In the “Enter credentials” box, you need to provide your local Domain Admin

2019-10-08_11h32_22

Click OK, and next

2019-10-08_11h33_46

Click “Configure” and let the wizard do its magicwlEmoticon-confusedsmile.png

2019-10-08_11h34_41

Dont be alarmed, if it throws an error, it did for me a couple of times, just hit retry.

2019-10-08_11h38_26

Yay…success… and look, AZUREADSSOACC is back where it belongs in AD wlEmoticon-openmouthedsmile.png2019-10-08_11h39_57

Give it time to run a sync (or force one with PowerShell Start-ADSyncSyncCycle -PolicyType Delta ), but eventually it will sync back up, and work like it did before.

Happy Clouding wlEmoticon-smile.png

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