Feb 02 2018 12:44 AM - edited Feb 02 2018 01:02 AM
I have a question around Azure Active Directory Seamless Single Sign-On.
So we want to use the Azure Seamless Single Sign-On but we have a forest and each business is in an organisation unit then each organisation unit is connected to their own office 365 tenant for each business via Azure AD Connect. Would we be able to use Azure Active Directory Seamless Single Sign-On for all the businesses that have separate tenants ?
Feb 02 2018 04:20 AM
I don't see any limitation for your scenario:
https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-sso
You could face problems when you sync 30 or more AD forests, which is not your case:
Just follow the procedure for each tenant:
Feb 02 2018 05:22 AM
Feb 02 2018 05:29 AM
You're right, so you had the answer.
Is it not possible to unify tenants in one single tenant with multiple verified domains?
Feb 02 2018 05:48 AM
Solutionsorry... then I guess your only option is trying multiple federated tenants, but I'm not sure it's supported
Oct 07 2019 11:35 PM
@Will Mellor, this is actually possible, but not supported due to how the Azure AD Connect works. Technically, SSO is using Kerberos. This means that both the "server" account in AD and the "service" (Azure AD) must share the secret (see this doc).
When enabling SSO, Azure AD connect creates a computer account in AD (AZUREADSSOACC), service principalname (https://autologon.microsoftazuread-sso.com), and configures SSO in Azure AD. During this process, it creates a random password for AZUREADSSOACC and tells this to Azure AD.
So, if you could set the password for each tenant to be the same, this would work. With Microsoft tools, this is not possible. However, this feature will be introduced in the next version of my AADInternals PowerShell module after being presented and announced in T2'19 infosec conference.
Oct 08 2019 01:41 AM
@Nestori SyynimaaThank you will keep a look out
Feb 20 2020 11:57 PM - edited Feb 21 2020 12:05 AM
Here are the steps how to set the SSO password using AADInternals toolkit.
First step is to install and import the AADInternals PowerShell Module.
Install-Module AADInternals
Import-Module AADInternals
After successful import, the text "AADInternals v0.2.8 by @NestoriSyynimaa" should appear.
Next step is to acquire an OAuth access token for pass-through authentication (PTA) which is using same tokens than DesktopSSO (=internal technical name for Seamless SSO). The following command prompts for credentials (must be Global Admin) and stores it to a variable.
$pt=Get-AADIntAccessTokenForPTA
Now, assuming that the Seamless SSO is enabled, you can list the current settings using the following command.
Get-AADIntDesktopSSO -AccessToken $pt
The output should be similar to below, depending on how many domains is registered.
Domains : company.com
Enabled : True
ErrorMessage :
Exists : True
IsSuccessful : True
Now, the password for a specific domain can be set using the following command
Set-AADIntDesktopSSO -AccessToken $pt -DomainName "company.com" -Password "MyVerySecretPassword"
As the password must be same in cloud and on-prem, the command prompts whether the on-prem computer account should also be set. If you answer "yes" the command tries to set password using following commands.
$computer = Get-ADComputer "AZUREADSSOACC"
Set-ADAccountPassword -Identity $computer.DistinguishedName -NewPassword (ConvertTo-SecureString -AsPlainText "MyVerySecretPassword" -Force)
If you do not have required rights to on-prem AD or Set-ADAccountPassword cmdlet is not available, you should answer "no" and do it manually. Also, the Kerberos Key Distribution Center must be restarted in Domain Controller for the changes to take effect.
After the password for cloud is successfully set you should get the following output:
IsSuccessful ErrorMessage
------------ ------------
True
In the case of multiple tenants, the password needs to be set to each tenant for the specific domains the tenant is using.
However, everyone should be aware that if the password (i.e. "MyVerySecretPassword") is known, you can login as any user of the tenant using user's sid:
# Generate kerberos ticket
$kt=New-AADIntKerberosTicket -SidString "S-1-5-xx-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx-xxx" -Password "MyVerySecretPassword"
# Get access token using the ticket, for example to Exchange Online
$at=Get-AADIntAccessTokenForEXO -KerberosTicket $kt -Domain "company.com"
# Send an email message
Send-AADIntOutlookMessage -AccessToken $at -Recipient "someone@company.com" -Subject "Message" -Message "<h1>Message</h1>"
Luckily, you cannot bypass MFA using this technique. More info at http://o365blog.com/post/kerberos/
Mar 03 2020 01:30 AM
Anyone allready implemented this somewhere? Is there any statement from Microsoft allowing this in a production environment? @Nestori Syynimaa
Mar 03 2020 01:44 AM - edited Mar 03 2020 01:45 AM
@Harold Baele Their is no reply from Microsoft's Azure Team on this at all. They have not said anything on this style of AD setup for Seamless Single Sign-On.
It is really frustrating and disappointing that Microsoft has not sorted this, I want to remove us from a 3rd Party Identity provider and move into Azure to provide Identity as our 3rd Party lacks features. But we cannot move as we have a requirement for Seamless Single Sign-On which is not possible with this style of AD. We would also buy Azure premium licensing if Microsoft can make this Seamless Single Sign-On in this AD style.
Mar 03 2020 01:55 AM
Sure this is frustrating. Also because having separation within a single tenant with this like Administrative Units is also still in preview - and currently nowhere near the answser... @Will Mellor
Apr 30 2020 05:13 PM - edited Apr 30 2020 11:57 PM
This is fantastic @Nestori Syynimaa. I have a few questions regarding this:
1. Microsoft recommends cycling the Kerberos decryption key every 30 days using the Update-AzureADSSOForest command, where does this solution fit into that?
2. Do we complete the cycling task for each Office 365 tenant or can we not do it because it will break something?
3. I haven't been able to confirm, is the Kerberos decryption key the same as the computer account password?
4. Should we be regularly changing the computer account password using your solution?
5. When installing AD Connect for additional tenants, I assume we don't need to tick the Enable single sign-on tickbox in the install wizard so that it doesn't fail to create the computer account later in the process? Or do we need to delete the computer account and have it recreate when configuring for each tenant then use your process to set the password up for all tenants again?
Sep 19 2020 05:41 PM
@Michael_Szabo @Nestori Syynimaa would love to know the answers too!
Feb 02 2018 05:48 AM
Solutionsorry... then I guess your only option is trying multiple federated tenants, but I'm not sure it's supported