When setting up PTA with SSO the Kerberos decryption keys must be rolled over every 30 days. Unfortunately Microsoft have not yet devised a streamline process to automate, but hoping to deliver within the next 6 months. Till this is made available the following solution has been developed to automatically perform this function.
The problem is best illustrated in the following test environment which has three internal domains configured for seamless single sign-on.
As illustrated below the decryption keys should be rolled over every 30 days to ensure the platform remains secure and operational. If this does not occur the keys will eventually expire !
Proposed Solution
Leveraging the existing AD-Connect Server and gMSA account the Windows Task Scheduler is used to run a custom PowerShell script every 30 days. Although the script must use both the Office365 Global Admin account and on premise PTA_SSO accounts the passwords are encrypted.
As a prerequisite step the service account which will be used to run the PowerShell account must be granted local Admin rights on the AD-Connect Server. Illustrated below the account being leveraged is the gMSA account which is already being used by the AD-Connect service (acmegroup\adc_gmsa).
To allow the service account to be able to run as a scheduled task open the Local Security Policy on the AD-Connect Server and choose Log on as a batch job. As depicted in the below screenshot add the gMSA account trailing with the $ symbol, choose Apply and OK.
On the AD-Connect Server create two new folders (if they don’t already exist) on C:\ one called scripts and the other called temp.
Next login to your Domain Controller for the domain\s which are configured to leverage SSO and create a domain user account. In Active Directory Users and Computers turn on the Advanced Features view if not already enabled by selecting View from the top menu bar.
Create a user account, in this example it has been provisioned into a Service Account OU, ensure this account has a routable UPN suffix. As demonstrated in the following screen capture under the Account options section check both boxes for User cannot change password and Password never expires.
If you have multiple domains create an account in each domain and use the same password, make note of the password as this will be used in a future step.
Next from the Computer OU find the AZUREADSSOACC object ( Right mouse button ) and chose Properties or using the left mouse button double left click the object.
Navigate to the Security tab and add the new PTA_SSO account created previously in the permissions box and only allocate write and Reset Password permissions, it does not require Change Password.
These steps will need to be repeated for each domain if you have a multiple domain configuration.
Script Setup:
Edit the PTASSO_RENWAL.PS1 PowerShell Script using PowerShell ISE. An extract of the sections of script that needs re-configuring is included below.
Step 1.
Uncomment lines 33 and 34 of the script and replace the {password} section with the plain text passwords of the Office365 Global Admin Account and the PTA_SSO reset password account configured in the above steps. The example below demonstrates this change.
PowerShell is using the Windows Data Protection API to encrypt the password from plan text to a secure string and then converts this into a text string. By design only the original user and the original machine where the encryption was performed can use this file. For this reason it is imperative the script is initially run manually through the Task Schedule service account at a later stage.
Step 2.
Edit line 42, 51 and 60 – this should reference the on-premise domains and user account that has write and reset password permission on the AZUREADSSOACC object. If SSO is only configured for a single on-premise domain delete lines 48 to 64 and re-save the file otherwise edit the file as required.
Step 3.
Edit the PTA_SSO_Key_Rollover_Task_Schedule.ps1 PowerShell Script using PowerShell ISE It is assumed the name of the file the task schedule will run has not been changed. If it has you must edit the syntax in Line 3 of the script.
Edit line 7 as the UserID value should be changed to reflect the account being used to run the task. If this is a gMSA account then remember to include the trailing $ symbol as depicted below and the password should remain configured as Password.
Step 4.
Re-save the file and then from an elevated PowerShell Window execute the PTA_SSO_Key_Rollover_Task_Schedule.PS1, this will create the following task schedule all configured and ready to be run.
Step 5.
Run the task manually through the task scheduler, this will create two new encrypted files in the C:\Scripts folder which only the gMSA account can decipher as illustrated below.
Login into the Office365 Tenant and check Azure Active Directory Admin > Azure AD Connect. Select the Seemless single sign-on link.
Notice the status is now green and the key creation date has updated.
If this has not worked check the C:\temp directory for an error log file and troubleshoot accordingly.
Step 6.
Storing passwords in clear text in scripts is a serious security risk, it is imperative to obfuscate these in your code. In this demonstration the passwords are encrypted by initially running the script manually through the scheduled task.
Once this has been performed open the PTASSO_RENWAL.ps1 script. using PowerShell ISE navigate to both lines 33 and 34 and comment out both of these lines using the # symbol at the beginning of the line. Also remove the clear text passwords and re-save the file.
You can actually run this password reset from a regular service account in your AD (but admin in AAD) if you have delegates the right privileges. And in the script I would change it a bit that it automatically generates a password, uses the online script to set it there and reset the password in AAD. No need for any password to be stored in any file.
Great post, thanks!
However, I’d like to point out that SecureString can be easily converted back to plain text, for instance like this:
$a=ConvertTo-SecureString “MyPasswordIsSecret” -AsPlainText -Force | ConvertFrom-SecureString
$b=ConvertTo-SecureString -String $a
$c=New-Object System.Management.Automation.PSCredential(“user”, $b)
$c.GetNetworkCredential().password
Thus, I’d put more effort on protecting the server from unwanted admin access. Admins can do anything, including logging in as any user. However, It is still better to save the passwords as SecureStrings than plain text.