Jorge's Quest For Knowledge!

All About Identity And Security On-Premises And In The Cloud – It's Just Like An Addiction, The More You Have, The More You Want To Have!

(2018-11-01) Transform Rules In ADFS – Send E-Mail Address Value For E-mail, Otherwise Send UPN Value For E-Mail

Posted by Jorge on 2018-11-01


A few days ago I got the following question:

  • Some accounts have a mailbox, some do not;
  • For accounts that do have a mailbox I need to send the e-mail address value as the claim value in the e-mail address claim type;
  • For accounts that do not have a mailbox I need to send the upn value as the claim value in the e-mail address claim type;

How can I achieve that through the claims rule language in ADFS?

It is not that difficult. See below for an example as the answer to the question above:

RULENAME1: User Identity Claims – Windows Account Name
COMMENT1: if the windows account name claim exists and has a value send it through

c:[Type == "
http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"]
=> issue(claim = c);

RULENAME2: User Identity Claims – upn
COMMENT2: if the UPN claim exists and has a value send it through

c:[Type == "
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"]
=> issue(claim = c);

RULENAME3: User Identity Claims – E-Mail Address
COMMENT3: get mail from AD and put it in claim

c:[Type == "
http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"]
=> issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"), query = ";mail;{0}", param = c.Value);

RULENAME4: System Claims – Check E-Mail Address Existence
COMMENT4: check if the mail address claim exist or not

NOT EXISTS([Type == "
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"])
=> add(Type = "http://temp.org/system/claims/eMailAddressExistance", Value = "False");

RULENAME5: User Identity Claims – upn To E-Mail Address (When E-Mail Address DOES NOT Exist)
COMMENT5: send the UPN value into mail address claim if no mail claim address exists

c1:[Type == "
http://temp.org/system/claims/eMailAddressExistance", Value == "False"] &&
c2:[Type == "
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"]
=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress", Value = c2.Value);

Make sure to test this first in a TEST environment!

Cheers,
Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
####################
http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

Advertisements

Posted in Active Directory Federation Services (ADFS), Claims, Claims Rule Language | Leave a Comment »

(2018-10-26) Running The Azure AD Password Protection Summary Report May Generate An Error

Posted by Jorge on 2018-10-26


When on one of the Azure AD Password Protection Proxy servers, you can generate an Azure AD Password Protection Summary report through one of the following commands:

Targeting a specific DC:

Get-AzureADPasswordProtectionSummaryReport -DomainController <RWDC FQDN>

Targeting all DCs in a specific AD Domain:

Get-AzureADPasswordProtectionSummaryReport -Domain <AD DOMAIN FQDN>

Targeting all DCs in a specific AD Forest:

Get-AzureADPasswordProtectionSummaryReport -Forest <AD FOREST FQDN>

Targeting all DCs in the local AD Forest:

Get-AzureADPasswordProtectionSummaryReport

So, whatever your targeted scope is, if all DCs have have the Azure AD Password Protection DC Agent installed, they will also have the corresponding event logs, which are:

Get-WinEvent -ListLog * | ?{$_.LogName -like "*AzureADPasswordProtection*"}

image

Figure 1: All The Azure AD Password Protection DC Agent Event Logs On An RWDC

….and for completeness on the Azure AD Password Protection Proxy servers

Get-WinEvent -ListLog * | ?{$_.LogName -like "*AzureADPasswordProtection*"}

image

Figure 2: All The Azure AD Password Protection Proxy Event Logs On The Proxy Servers

However, if you see errors similar to the one below…

image

Figure 2: Error When Generating The Azure AD Password Protection Summary Report Against Targeted DCs

…then the targeted event logs are missing. And of the events logs are missing, then the Azure AD Password Protection DC Agent is most likely not installed on the RWDC.

Solution? Install the Azure AD Password Protection DC Agent on the RWDC that throws the error.

Please be aware that querying for DCs that have the Service Connection Point (SCP) registered in AD, may not be accurate. Why? If you installed the Azure AD Password Protection DC Agent and then uninstall it, for whatever reason, the SCP for that RWDC is not cleaned during the uninstall. Also be aware that if you force removed any DC and did not clean up its metadata, you will be trying to reach an RWDC that does not exist anymore when running the summary report.

Although more intense, the most accurate way is checking for any of the following:

  • If the Azure AD Password Protection DC Agent is installed (against every RWDC –> Get-WmiObject -Class win32_product -Filter "Name like ‘Azure AD Password Protection DC Agent’")
  • If the Azure AD Password Protection DC Agent service is installed (against every RWDC –> Get-Service AzureADPasswordProtectionDCAgent)
  • If the Azure AD Password Protection DC Agent is installed (against every RWDC –> Get-WinEvent -ListLog * | ?{$_.LogName -like "*AzureADPasswordProtection*"})

Cheers,
Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
####################
http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

Posted in Azure AD Password Protection, Windows Azure Active Directory | Leave a Comment »

(2018-10-25) When Installing The Azure AD Password Protection DC Agent Generates An Error

Posted by Jorge on 2018-10-25


If you are installing the Azure AD Password Protection DC Agent on an RWDC and you receive the following error….

image

Figure 1: An Error The Azure AD Password Protection DC Agent Setup Wizard Ended Prematurely

….execute the AADPwdProtection\AzureADPasswordProtectionDCAgent.msi with the following options

MSIEXEC /i AzureADPasswordProtectionDCAgent.msi /log AzureADPasswordProtectionDCAgent.log

After it errors again, open the log file and search for the word ERROR. When you do, you will most likely find why it errors. If it has the same cause as I had, you will see something similar to the following:

Dumping MSI properties of interest:
  ‘INSTALLDIR’ = ‘C:\Program Files\Azure AD Password Protection DC Agent\’
  ‘Installed’ = ”
  ‘INSTALLLEVEL’ = ‘1’
  ‘ProductCode’ = ‘{67E66797-A45C-4C3C-B481-554F9F427227}’
  ‘ProductID’ = ”
  ‘ProductName’ = ‘Azure AD Password Protection DC Agent’
  ‘ProductState’ = ‘-1’
  ‘ProductVersion’ = ‘1.2.10.0’
  ‘ProgramFiles64Folder’ = ‘C:\Program Files\’
  ‘Remove’ = ”
  ‘UPGRADINGPRODUCTCODE’ = ”
  ‘BPL_NONUPGRADEABLEAPPFOUND’ = ”
  ‘BPL_STATEMIGRATIONFOLDER’ = ”
Done with MSI property dump
CheckForNonUpgradeableApps – opened Uninstall key with 9 subkeys
CheckForNonUpgradeableApps – a nonupgradeable app was found ‘Azure AD Password Protection DC Agent’ – ‘1.1.10.3’
CustomAction BPL_CheckForNonUpgradeableApps returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
Action ended 16:30:01: BPL_CheckForNonUpgradeableApps. Return value 3.
Action ended 16:30:01: INSTALL. Return value 3.


In plain English this means you are trying to install a newer version on top of an version that cannot be upgraded. Check the versions. The old version here was installed by means months ago when I participated in the public preview. Today I wanted to install the officially released version and had forgotten the old version was still installed.

The solution here? Uninstall the old version first and install the newer version. After both the uninstall and the install a reboot of the RWDC is required.

To determine if a version is already installed and if yes to uninstall it, execute the following commands:

WMIC PRODUCT GET NAME | FIND /I "Azure AD Password Protection DC Agent"

WMIC PRODUCT WHERE NAME="Azure AD Password Protection DC Agent" CALL UNINSTALL

….and if you are a PowerShell junky, you can also use the following for the uninstall

$product = Get-WmiObject -Class win32_product -Filter "Name like ‘Azure AD Password Protection DC Agent’"

$product

$product.Uninstall() # WARNING: Reboot is immediate, no mercy and no questions asked!!!

After the uninstall and reboot, install the newest AzureADPasswordProtectionDCAgent.msi available from Microsoft

Cheers,
Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
####################
http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

Posted in Azure AD Password Protection, Windows Azure Active Directory | Leave a Comment »

(2018-10-24) Setting/Fixing The Correct Permissions On Your ADFS Certificates And/Or On The Certificate Sharing Container

Posted by Jorge on 2018-10-24


Are the permissions on any of the private keys of your certificates in use by ADFS and/or the certificate sharing container screwed up? If YES, then you can use the PowerShell code below to fix those permissions for the account the ADFS Service is running under. Make sure to test this is a test environment first!

### Function To Permission Private Key Of Custom/Non-ADFS Managed Certificates
Function permissionPrivateKey($certificate,$certType,$svcAccount) {
    $ace = $svcAccount,"Read,Synchronize","Allow"
    $machineKeysLocation = $ENV:ALLUSERSPROFILE + "\Microsoft\Crypto\RSA\MachineKeys\"
    $CertKeyFile = $certificate.PrivateKey.CspKeyContainerInfo.UniqueKeyContainerName
    $CertKeyFileFullPath = $MachineKeysLocation + $CertKeyFile
    $CertKeyFileACL = Get-Acl $CertKeyFileFullPath
    Write-Host "+++ RESULT +++" -ForeGroundColor Magenta
    $certSubject = $null
    $certSubject = $certificate.Subject
    Write-Host "Certificate Type……..: $certType" -ForegroundColor Yellow
    Write-Host "Certificate Subject…..: $certSubject" -ForegroundColor Yellow
    Write-Host ""
    Write-Host "Private Key Permissions (BEFORE)" -ForegroundColor Yellow
    $CertKeyFileACL.Access | FT @{n='[Account]’;e={$_.IdentityReference}},@{n='[Control]’;e={$_.AccessControlType}},@{n='[Permissions]’;e={$_.FileSystemRights}}
    $accessRule = New-Object System.Security.AccessControl.FileSystemAccessRule $ace
    $CertKeyFileACL.SetAccessRule($accessRule)
    $CertKeyFileACL | Set-Acl $CertKeyFileFullPath
    $CertKeyFileACL = $null
    $CertKeyFileACL = Get-Acl $CertKeyFileFullPath
     Write-Host ""
    Write-Host "Private Key Permissions (AFTER)" -ForegroundColor Yellow
    $CertKeyFileACL.Access | FT @{n='[Account]’;e={$_.IdentityReference}},@{n='[Control]’;e={$_.AccessControlType}},@{n='[Permissions]’;e={$_.FileSystemRights}}
}
   
### Determining Current ADFS Service Account
$adfsService = Get-WmiObject win32_service -filter "name=’ADFSSRV’"
$currentADFSServiceAccount = $adfsService.StartName

### Determining Database Type Being Used
$adfsSTS = Get-WmiObject -namespace root/ADFS -class SecurityTokenService
$configDBConnectionString = $adfsSTS.ConfigurationDatabaseConnectionString
If ($configDBConnectionString.contains("\\.\pipe\")) {
    Write-Host ""
    Write-Host "Windows Internal Database Is Being Used" -ForegroundColor Yellow
     $dbType = "WID"
    $roleADFSServer = (Get-AdfsSyncProperties).Role
    If ($roleADFSServer -eq "SecondaryComputer") {
         Write-Host ""
        Write-Host "Running On Secondary ADFS Server" -ForegroundColor Yellow
        Function portConnectionCheck($fqdnServer,$port,$timeOut) {
            $tcpPortSocket = $null
            $portConnect = $null
            $tcpPortWait = $null
            $tcpPortSocket = New-Object System.Net.Sockets.TcpClient
            $portConnect = $tcpPortSocket.BeginConnect($fqdnServer,$port,$null,$null)
            $tcpPortWait = $portConnect.AsyncWaitHandle.WaitOne($timeOut,$false)
            If(!$tcpPortWait) {
                $tcpPortSocket.Close()
                 Return "ERROR"
            } Else {
                $ErrorActionPreference = "SilentlyContinue"
                $tcpPortSocket.EndConnect($portConnect) | Out-Null
                If (!$?) {
                    Return "ERROR"
                } Else {
                    Return "SUCCESS"
                }
                 $tcpPortSocket.Close()
                $ErrorActionPreference = "Continue"
            }
        }
        $primaryADFSServer = (Get-AdfsSyncProperties).PrimaryComputerName
        $adfsWIDIsSecondary = $true
    } Else {
        Write-Host "Running On Primary ADFS Server" -ForegroundColor Yellow
        $adfsWIDIsSecondary = $false
    }
} Else {
    Write-Host "SQL Server Is Being Used" -ForegroundColor Yellow
    $dbType = "SQL"
}

### Getting ADFS Properties And Certificates
If ($dbType -eq "WID") {
    If ($adfsWIDIsSecondary) {
        $ports = 5985,443,80 # WinRM For Remote PowerShell, ADFS HTTPS, ADFS HTTP
        $connectionCheckOK = $true
        $ports | %{
            $port = $null
            $port = $_
            $connectionResult = $null
            $connectionResult = portConnectionCheck $primaryADFSServer $port 500
            If ($connectionResult -eq "ERROR") {
                $connectionCheckOK = $false
            }
        }
        If ($connectionCheckOK) {
            $primaryADFSServerSession = New-PSSession -ComputerName $primaryADFSServer
            $fedSvcConfig = Invoke-Command -Session $primaryADFSServerSession -ScriptBlock {
                $fedSvcProperties = Get-AdfsProperties
                $fedSvcCertificates = Get-AdfsCertificate
                Return $fedSvcProperties,$fedSvcCertificates
            }
            Remove-PSSession $primaryADFSServerSession
            $fedSvcProps = $fedSvcConfig[0]
            $fedSvcCerts = $fedSvcConfig[1]
        } Else {
             Write-Host ""
            Write-Host "The Primary ADFS Server IS NOT Reachable" -ForegroundColor Red
            Write-Host "Aborting…" -ForegroundColor Red
            Write-Host ""
            EXIT
        }
    } Else {
        $fedSvcProps = Get-AdfsProperties
        $fedSvcCerts = Get-AdfsCertificate
     }
}
If ($dbType -eq "SQL") {
    $fedSvcProps = Get-AdfsProperties
    $fedSvcCerts = Get-AdfsCertificate
}

### Checking If Certificate Sharing Container Has Been Configured
If ($fedSvcProps.CertificateSharingContainer) {
    Write-Host ""
    Write-Host "Certificate Sharing Container IS Configured" -ForegroundColor Yellow
    $certSharingContainerConfigured = $true
    $certSharingContainerState = "Configured"
    $certSharingContainerDN = ($fedSvcProps.CertificateSharingContainer).ToString()
} Else {
     Write-Host ""
    Write-Host "Certificate Sharing Container IS NOT Configured" -ForegroundColor Yellow
    $certSharingContainerConfigured = $false
    $certSharingContainerState = "NOT Configured"
    $certSharingContainerDN = "N.A."
}

### Checking If Custom Certificates Are Being Used Or ADFS Managed Self-Signed Certificates For Token Signing/Encryption
If ($fedSvcProps.AutoCertificateRollover -eq $false) {
    Write-Host ""
    Write-Host "ADFS Managed Self-Signed Certs ARE NOT Being Used" -ForegroundColor Yellow
    $adfsManagedCerts = $false
    $certManagement = "NON-ADFS Managed"
} ElseIf ($fedSvcProps.AutoCertificateRollover -eq $true) {
    Write-Host ""
    Write-Host "ADFS Managed Self-Signed Certs ARE Being Used" -ForegroundColor Yellow
    $adfsManagedCerts = $true
    $certManagement = "ADFS Managed"
}

### Displaying All The Info Gathered
Invoke-Command -ScriptBlock {
    Write-Host ""
    Write-Host "Database Type………………………: $dbType" -ForegroundColor Yellow
    Write-Host ""
    Write-Host "Certificate Sharing Container State…..: $certSharingContainerState" -ForegroundColor Yellow
    Write-Host ""
    Write-Host "Certificate Sharing Container DN……..: $certSharingContainerDN" -ForegroundColor Yellow
    Write-Host ""
     Write-Host "Certificate Management………………: $certManagement" -ForegroundColor Yellow
    Write-Host ""
    Write-Host "Current Service Account……………..: $currentADFSServiceAccount" -ForegroundColor Yellow
    Write-Host ""
    Write-Host "Token-Signing Certificate(s)…" -ForegroundColor Yellow
    $fedSvcTokenSigningCert = $fedSvcCerts | ?{$_.CertificateType -eq "Token-Signing"}
    $fedSvcTokenSigningCert | FT Thumbprint,@{n=’Subject’;e={$_.Certificate.Subject}},@{n=’Not Before’;e={$_.Certificate.NotBefore}},@{n=’Not After’;e={$_.Certificate.NotAfter}}
    Write-Host "Token-Encryption Certificate(s)…" -ForegroundColor Yellow
    $fedSvcTokenEncryptCert = $fedSvcCerts | ?{$_.CertificateType -eq "Token-Decrypting"}
    $fedSvcTokenEncryptCert | FT Thumbprint,@{n=’Subject’;e={$_.Certificate.Subject}},@{n=’Not Before’;e={$_.Certificate.NotBefore}},@{n=’Not After’;e={$_.Certificate.NotAfter}}
    Write-Host "Service Communications / SSL Certificate…" -ForegroundColor Yellow
    $fedSvcSvcCommCert = $fedSvcCerts | ?{$_.CertificateType -eq "Service-Communications"}
    $fedSvcSvcCommCert | FT Thumbprint,@{n=’Subject’;e={$_.Certificate.Subject}},@{n=’Not Before’;e={$_.Certificate.NotBefore}},@{n=’Not After’;e={$_.Certificate.NotAfter}}
}

### Setting Permissions On Private Key Of Custom Token Certificates
If (!$adfsManagedCerts) {
    Write-Host ""
    Write-Host "Permissioning Custom Token Certificates" -ForegroundColor Yellow
    $certStoreLocation = "Cert:\LocalMachine\My"
    $fedSvcCerts | ?{$_.CertificateType -ne "Service-Communications"} | %{
        $certificateType = $null
        $certificateType = $_.CertificateType
        $certificateThumbprint = $null
        $certificateThumbprint = $_.Thumbprint
        $certificateInStore = $null
        $certificateInStore = Get-ChildItem $($certStoreLocation + "\" + $certificateThumbprint) -ErrorAction SilentlyContinue
        If ($certificateInStore -And $certificateInStore.HasPrivateKey) {
            permissionPrivateKey $certificateInStore $certificateType $currentADFSServiceAccount
        } Else {
             Write-Host ""
            Write-Host "The Certificate With Thumbprint ‘$certificateThumbprint’ ($certificateType) Does Not Exist" -ForegroundColor Red
            Write-Host "Or" -ForegroundColor Red
            Write-Host "The Certificate With Thumbprint ‘$certificateThumbprint’ ($certificateType) Does Not Have A Private Key" -ForegroundColor Red
            Write-Host ""
        }
    }
}

### Setting Permissions On Private Key Of SSL/Service-Communication Certificate
$fedSvcCerts | ?{$_.CertificateType -eq "Service-Communications"} | %{
    $certificateType = $null
    $certificateType = $_.CertificateType
    $certificateThumbprint = $null
    $certificateThumbprint = $_.Thumbprint
     $certificateInStore = $null
    $certificateInStore = Get-ChildItem $($certStoreLocation + "\" + $certificateThumbprint) -ErrorAction SilentlyContinue
    If ($certificateInStore -And $certificateInStore.HasPrivateKey) {
        permissionPrivateKey $certificateInStore $certificateType $currentADFSServiceAccount
    } Else {
        Write-Host ""
        Write-Host "The Certificate With Thumbprint ‘$certificateThumbprint’ ($certificateType) Does Not Exist" -ForegroundColor Red
        Write-Host "Or" -ForegroundColor Red
        Write-Host "The Certificate With Thumbprint ‘$certificateThumbprint’ ($certificateType) Does Not Have A Private Key" -ForegroundColor Red
        Write-Host ""
    }
}

### If Configured Setting Permissions On Certificate Sharing Container
### WARNING: ADDS PowerShell Module Required!!! – Will Be Installed!
If ($certSharingContainerConfigured) {
    Write-Host ""
    Write-Host "Certificate Sharing Container Is Configured Used" -ForegroundColor Yellow

    # Install RSAT PowerShell Tools And Load Module
    Install-WindowsFeature RSAT-AD-Tools -IncludeAllSubFeature
     Import-Module ActiveDirectory

    # Get The Certificate Sharing Container DN, Its ACL And Present The Results Of That
    $dnPathCertSharingContainer = ($fedSvcProps.CertificateSharingContainer).ToString()
    $dnPathCertSharingContainerPath = $(Join-Path "AD:\" $dnPathCertSharingContainer)
    Write-Host ""
    Write-Host "Certificate Sharing Container Permissions (BEFORE)" -ForegroundColor Yellow
    $aclCertSharingContainer = Get-Acl $dnPathCertSharingContainerPath
    $aclCertSharingContainer.Access | FT @{n='[Account]’;e={$_.IdentityReference}},@{n='[Control]’;e={$_.AccessControlType}},@{n='[Permissions]’;e={$_.ActiveDirectoryRights}}
   
    # Object Class And Inheritance Scope
    $schemaIDGUIDScopedObject = [guid]"00000000-0000-0000-0000-000000000000"
    $inheritanceScope = "All"

    # Security Principal To Assign Permissions To
    $securityPrincipalAccount = $currentADFSServiceAccount
    $securityPrincipalObject = New-Object System.Security.Principal.NTAccount($securityPrincipalAccount)

    # Define ACE
    $rightsCollection = [System.DirectoryServices.ActiveDirectoryRights]::"CreateChild","Self","WriteProperty","DeleteTree","GenericRead","WriteOwner"
    $aclType = [System.Security.AccessControl.AccessControlType]::"Allow"
    $aceDefinition = $securityPrincipalObject,$rightsCollection,$aclType,$schemaIDGUIDScopedObject,$inheritanceScope
    $accessRule = New-Object System.DirectoryServices.ActiveDirectoryAccessRule($aceDefinition)   

    # Set The New Access Rule
    $aclCertSharingContainer.AddAccessRule($accessRule)
    $aclCertSharingContainer | Set-Acl $dnPathCertSharingContainerPath

    # Get The Certificate Sharing Container ACL And Present The Results Of That
    Write-Host ""
    Write-Host "Certificate Sharing Container Permissions (AFTER)" -ForegroundColor Yellow
    $aclCertSharingContainer = Get-Acl $dnPathCertSharingContainerPath
    $aclCertSharingContainer.Access | FT @{n='[Account]’;e={$_.IdentityReference}},@{n='[Control]’;e={$_.AccessControlType}},@{n='[Permissions]’;e={$_.ActiveDirectoryRights}}
    $aclCertSharingContainer.Access | ?{$_.IdentityReference -eq $securityPrincipalAccount} | FT @{n='[Account]’;e={$_.IdentityReference}},@{n='[Control]’;e={$_.AccessControlType}},@{n='[Permissions]’;e={$_.ActiveDirectoryRights}}
    $aclCertSharingContainer.Access | ?{$_.IdentityReference -eq $securityPrincipalAccount}
}

Cheers,
Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
####################
http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

Posted in Active Directory Federation Services (ADFS), Certificates, PowerShell | Leave a Comment »

(2018-10-23) How Do You Know Your ADFS Server Is Lacking Permissions On Its Certificates?

Posted by Jorge on 2018-10-23


Even through the ADFS Service starts and everything “appears” to be right, NOTHING works! In the ADFS Admin Event Log you may see the following event

image

Figure 1: An Error In The ADFS Admin Event Log Referencing The Lack Of Permissions On The Private Key

There was an error in enabling endpoints of Federation Service. Fix configuration errors using PowerShell cmdlets and restart the Federation Service.

Additional Data
Exception details:
System.ArgumentNullException: Value cannot be null.
Parameter name: certificate
    at System.IdentityModel.Tokens.X509SecurityToken..ctor(X509Certificate2 certificate, String id, Boolean clone, Boolean disposable)
    at Microsoft.IdentityServer.Service.Configuration.MSISSecurityTokenServiceConfiguration.Create(Boolean forSaml, Boolean forPassive)
    at Microsoft.IdentityServer.Service.Policy.PolicyServer.Service.ProxyPolicyServiceHost.ConfigureWIF()
    at Microsoft.IdentityServer.Service.SecurityTokenService.MSISConfigurableServiceHost.Configure()
    at Microsoft.IdentityServer.Service.Policy.PolicyServer.Service.ProxyPolicyServiceHost.Create()
    at Microsoft.IdentityServer.ServiceHost.STSService.StartProxyPolicyStoreService(ServiceHostManager serviceHostManager)
    at Microsoft.IdentityServer.ServiceHost.STSService.OnStartInternal(Boolean requestAdditionalTime)

The solution? Fix the permissions on the private keys and restart the ADFS Service on every ADFS server where the permissions were fixed

When the ADFS Service is finished starting your should ALWAYS see the following informational events (may be slightly different depending on the version of Windows):

  • Event ID 397 (WinHTTP Settings)
  • Event ID 349 (Administration Service)
  • Event ID 251 (For Every Attribute Store)
  • Event ID 278 (SAML Artifact)
  • Event ID 106 (For Every Authentication Provider (Multiple Times))
  • Event ID 100 (Federation Service Started Successfully)
  • Event ID 298 (Windows Hello For Business)
  • Event ID 399 (Certificate Archiving)
  • Event ID 386 (Certificate Expiration)
  • ….And Last But Not Least

image

Figure 2: ADFS Mentioning Everything Is Correct Regarding The ADFS Certificates

AD FS detected that all the service certificates have appropriate access given to the AD FS service account.

Cheers,
Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
####################
http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

Posted in Active Directory Federation Services (ADFS), Certificates | Leave a Comment »

(2018-10-22) Cloning Windows 10 Or Windows Server 2016 May Break Hybrid Azure AD Domain Join

Posted by Jorge on 2018-10-22


When cloning Windows computers you are basically copying everything from some source computer to one or more target computers. One of the benefits is the speed in deployment and the time you same to have to configure stuff every single time. Are there downsides? Yes, there are, at least if you do not take some risk mitigating measures. One of those is the SID of the local computer. Every time you deploy a cloned version of Windows you MUST execute SYSPREP to make the clone gets its own unique SID. If you don’t at the beginning and along the way things may appear to be correct. However, at some point in time you may find yourself with a huge headache trying to understand why something does not work or shows weird behavior.

Recently I found another downside of cloning, that in the end can be mitigated with some post-deployment actions.

For more info about Hybrid Azure AD Domain Join (HAADJ) please also have a look at

I was trying to Hybrid Azure AD Domain Join (HAADJ) a AD domain joined Windows Server 2016 by logging on and waiting for the scheduled task to kick in and checking the correct Event Logs, and later on under the context of “NT AUTHORITY\SYSTEM” by running DSREGCMD.EXE /DEBUG. When running that last command I kept seeing the following error at the end:

DsrDeviceAutoJoinFederated failed with -2146893802
wmain: failed with error code 0x80090016.

After some troubleshooting I discovered that Windows was a cloned deployment. One of the thing that is also cloned is the key material. The key material is in the folder “C:\ProgramData\Microsoft\Crypto\Keys” to “C:\ProgramData\Microsoft\Crypto\Keys”. The solution therefore is to get rid of the old key material and start fresh from the beginning. You can do that by running the following PowerShell commands:

# Rename The “Keys” Folder To “KeysOLD”

Rename-Item -Path "C:\ProgramData\Microsoft\Crypto\Keys" -NewName "KeysOLD"

# Create A New “Keys” Folder

New-Item -Path "C:\ProgramData\Microsoft\Crypto\Keys" -ItemType Directory

# Copy The ACL From The “KeysOLD” Folder To The New “Keys” Folder

Get-Acl -Path "C:\ProgramData\Microsoft\Crypto\KeysOLD" | Set-Acl -Path "C:\ProgramData\Microsoft\Crypto\Keys"

Now retry HAADJ by rebooting the Windows computers and logging on, or executing DSREGCMD.EXE /DEBUG under the context of  “NT AUTHORITY\SYSTEM”. It should work now!

REMARK: If you did not know it yet, you can get into the context of “NT AUTHORITY\SYSTEM” by using PSEXEC and running the following command: PSEXEC –i –s CMD.EXE

Cheers,
Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
####################
http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

Posted in Azure AD Join, Windows Azure Active Directory, Windows Client, Windows Server | 3 Comments »

(2018-10-21) Grant, Revoke Or Get DCOM Permissions Using PowerShell

Posted by Jorge on 2018-10-21


Have you ever needed to script granting or revoking DCOM Permissins, or maybe just retrieving DCOM Permissions? If the answer is “Yes”, then look no further! It is a pitty there is no native PowerShell way to manage stuff like this. But, it is a good thing there are MVPs like Tony who has created a PowerShell module that does some interesting things around DCOM Permissions on Windows systems. All credits for this PowerShell module of course go to Tony as he build and owns it.

The PowerShell Module to manage DCOM Permissions can be downloaded from here.

Benefits:

  • No dependency on external files
  • Can change permissions on DCOM objects where Administrator doesn’t have access
  • Does not remove callback permissions (Using the Component Services GUI often does)
  • Doesn’t write temporary files during operation
  • Pure PowerShell implementation
  • Fully documented and self contained
  • No code hidden in DLL files or other compiled libraries; fully transparent

Requirements:

  • PowerShell 4.0
  • Elevated administrative rights on local computer
  • Tested on Windows 10, Server 2012 R2, Server 2016

Available Cmdlets:

  • Get-DCOMPermission
  • Grant-DCOMPermission
  • Revoke-DCOMPermission 

Cheers,
Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
####################
http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

Posted in Windows Client, Windows Server | Leave a Comment »

(2018-10-20) Grant, Revoke Or Query For User Rights (Privileges) Using PowerShell

Posted by Jorge on 2018-10-20


Have you ever needed to script granting or revoking user rights, or maybe just querying for user rights? If the answer is “Yes”, most likely you have had to use NTRIGHTS from the good old Windows Server 2003 Resource Kit or do some funky magic around SECEDIT. It is a pitty there is no native PowerShell way to manage stuff like this. But, it is a good thing there are MVPs like Tony who has created a PowerShell module that does some interesting things around user rights locally and remotely on Windows systems. All credits for this PowerShell module of course go to Tony as he build and owns it.

The PowerShell Module to manage user rights can be downloaded from here.

Benefits:

  • No dependency on external files
  • Can modify any user right; is not limited to "Logon as a Service"
  • Can add/remove rights from the current process token
  • Doesn’t write temporary files during operation
  • Fully pipeline-able
  • Pure PowerShell implementation
  • Supports changing user rights on remote machines
  • Fully documented and self contained
  • No code hidden in DLL files or other compiled libraries; fully transparent

Requirements:

  • PowerShell 3.0
  • Administrative rights on target computer, or elevation on local computer
  • Tested on Windows 10, Server 2012 R2, Server 2016, Server Core 1709

Available Cmdlets:

  • Grant-UserRight
  • Revoke-UserRight
  • Get-UserRightsGrantedToAccount
  • Get-AccountsWithUserRight
  • Grant-TokenPrivilege
  • Revoke-TokenPrivilege

 

Cheers,
Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
####################
http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

Posted in User Rights, User Rights, Windows Client, Windows Server | Leave a Comment »

(2018-10-11) Configuring A New Identity Store As A Local Claims Provider In ADFS

Posted by Jorge on 2018-10-11


In ADFS v1.0 and ADFS v1.1 it was possible to use both AD and ADLDS/ADAM as an identity store. One of the very common scenarios is to use the AD identity store for internal users and use the ADLDS/ADAM identity store for external users (e.g. partners, customers, vendors, etc.). After ADFS v1.x Microsoft released ADFS v2.0 (separate download for W2K8 and W2K8R2), ADFS v2.1 in W2K12 and ADFS v3.0 in W2K12R2. All the ADFS versions starting with ADFS v2.0 and higher only supported AD as the identity store and nothing else. That could be one of the reasons why some companies remained using ADFS v1.1 and did not move one.

If you would like to support a similar scenario, where you would like to have a separate identity store for externals, you would need to:

  1. Configure a separate AD with its own ADFS infrastructure and configure federation between (also see: (2013-09-24) AD User Accounts For Which The ADFS STS Can Generate Security Tokens)
    OR
  2. Use Azure AD to store those identities and configure federation

The biggest advantage of using [2] instead of [1] is that you do not need a complete new infrastructure just to support externals. The basic Azure AD features are free, but as soon as you need something special from the Azure AD Premium list, you need to pay licensing.

With the release of the Windows Server 2016, a third option has become available as already mentioned in the blog post (2014-10-03) ADFS In vNext To Support Other Identity Stores Than AD Only. YES! YES! YES! Finally!

For the passive federation protocols (e.g. SAML, WS-Federation and Oauth) and the active federation protocols (e.g. WS-Trust), ADFS v4.0 (ADFS in Windows Server 2016) and higher will support the following identity stores:

  • Identity Stores As Claim Providers:◦Active Directory (Trusted AD forests)
  • Identity Stores As Local Claim Providers:◦Active Directory (NON-Trusted AD forests)
    • ADLDS/ADAM
    • Apache DS
    • IBM Tivoli DS
    • Novell DS
    • Open LDAP
    • Open DJ
    • Open DS
    • Radiant Logic Virtual DS
    • Sun ONE v6, v7, v11

The local claims providers can only be configured through PowerShell and authentication through ADFS against those local claims providers can only be done by using forms-based authentication. One last thing to note is that you can only configure local claims providers when the Farm Behavior/Level is higher than Win2012R2. Also see: (2014-10-12) Migrating Or Upgrading To A New ADFS Version.

For more information also see:

I have the following Identity (ID) Store:

  • Type: ADLDS (LDAP)
  • Node Server (1): R1FSRWDC1.IAMTEC.NET
    • LDAP Port: 5389
    • LDAPS Port: 5636
  • Node Server (2): R1FSRWDC2.IAMTEC.NET
    • LDAP Port: 5389
    • LDAPS Port: 5636
  • Account UserName For ADFS To Access data In The IDStore: SVC_R1_LDAPQuery@CORP

# Define The Credentials For ADFS To Use When Connecting To The ID Store

$idStoreAccountUserName = ‘SVC_R1_LDAPQuery@CORP’

$idStoreAccountPassword = ‘pwd’ | ConvertTo-SecureString -asPlainText -Force

$idStoreAccountCreds = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $idStoreAccountUserName,$idStoreAccountPassword

# Define All The Server Instances Hosting The Identity Store

$idStoreInstance1 = New-AdfsLdapServerConnection -HostName R1FSRWDC1.IAMTEC.NET -Port 5389 -SslMode None -Credential $idStoreAccountCreds -AuthenticationMethod Basic

$idStoreInstance2 = New-AdfsLdapServerConnection -HostName R1FSRWDC2.IAMTEC.NET -Port 5389 -SslMode None -Credential $idStoreAccountCreds -AuthenticationMethod Basic

PS: If you have a load balanced ADLDS farm than you would only need to define one connection instance as the load balancer would figure out which node to use. For more information about load balancing ADLDS please see: https://www.itprotoday.com/management-mobility/load-balance-ad-lds-microsoft-nlb-6-steps. If you do not have a load balanced ADLDS farm you need to define all connection instances so that ADFS can figure out which one to use. In the connection above I’m using the custom LDAP port (5389) configured by me. I did this as I was too lazy for this post to get an SSL certificate for LDAPS. For production systems I do suggest you use LDAPS!. For more information please see: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc725767(v=ws.10)

# Define All The Attribute-To-ClaimType Mappings For Which You Want ADFS To Automatically Retrieve From The ID Store

# (These are the attributes and their values, if any, automatically retrieved from the ID store and stored in claims, whether or not these are issued later on in a security token)

$mappingGivenName = New-AdfsLdapAttributeToClaimMapping -LdapAttribute givenName -ClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname"

$mappingSurname = New-AdfsLdapAttributeToClaimMapping -LdapAttribute sn -ClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname"

$mappingDisplayName = New-AdfsLdapAttributeToClaimMapping -LdapAttribute displayName -ClaimType "http://temp.org/identity/claims/displayName"

$mappingEmployeeID = New-AdfsLdapAttributeToClaimMapping -LdapAttribute employeeID -ClaimType "http://temp.org/identity/claims/employeeID"

$mappingDescription = New-AdfsLdapAttributeToClaimMapping -LdapAttribute description -ClaimType "http://temp.org/identity/claims/description"

# Create The Local Claims Provider Trust To Appear In The HRD Screen Through A List Of Claims Providers

Add-AdfsLocalClaimsProviderTrust -Name "External ID Store" -Identifier "urn:adlds:external:idstore" -Type Ldap -LdapServerConnection @($idStoreInstance1,$idStoreInstance2) -UserObjectClass user -UserContainer "OU=People,O=CORP" -LdapAuthenticationMethod Basic -AnchorClaimLdapAttribute userPrincipalName -AnchorClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn" -LdapAttributeToClaimMapping @($mappingGivenName, $mappingSurname, $mappingDisplayName, $mappingEmployeeID, $mappingDescription) -Enabled $true -AcceptanceTransformRules "@RuleName = `"Issue All Mapped Claims`"`nc:[] => issue(claim = c);"

OR

# Create The Local Claims Provider Trust To Appear In The HRD Screen Through UPN Suffix

Add-AdfsLocalClaimsProviderTrust -Name "External ID Store" -Identifier "urn:adlds:external:idstore" -Type Ldap -LdapServerConnection @($idStoreInstance1,$idStoreInstance2) -UserObjectClass user -UserContainer "OU=People,O=CORP" -LdapAuthenticationMethod Basic -AnchorClaimLdapAttribute userPrincipalName -AnchorClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn" -LdapAttributeToClaimMapping @($mappingGivenName, $mappingSurname, $mappingDisplayName, $mappingEmployeeID, $mappingDescription) -Enabled $true -AcceptanceTransformRules "@RuleName = `"Issue All Mapped Claims`"`nc:[] => issue(claim = c);"

Now when running either of the “Add-AdfsLocalClaimsProviderTrust” CMDlets you may see the following error at the end. It is really vague and does not tell you anything about what is really wrong. At first I thought something was wrong with the database.

image

Figure 1: Creating The Local Claims Provider Trust Fails With An Error

When things go wrong, the first thing I look at is the event log of the specific application/system. In this case it was the ADFS Admin Event Log. It did not say anything about this error. Knowing that I thought it would took me hours to figure this out. Au contraire!. Looking at the ADFS Debug Event Log, I saw the following message. It was referencing the Certificate Sharing Container.

image

Figure 2: Error Message In The ADFS Debug Event Log

An error occurred while trying to add an object:
Message: MSIS0013: Encrypted property ‘AccountStoreData’ cannot be set when a certificate sharing container is not configured in AD FS properties.

It was a weird error, because my ADFS farm is NOT using automatic certificate rollover and therefore it does not need the Certificate Sharing Container. You can see in the figure below that is the case. My farm is using CA issued certificates for the Token Signing Certificate and the Token Encryption Certificate.

image

Figure 3: Certificate Rollover NOT Being Enabled And The Certificate Sharing Container Not Being Configured

The Certificate Sharing Container is related to ADFS using ADFS Managed Self-Signed Certificates for the Token Signing Certificate and the Token Encryption Certificate. When the “AutoCertificateRollover” is set to TRUE, the “CertificateSharingContainer” property MUST specify the DN of the Certificate Sharing Container in AD. The ADFS servers and the Certificate Sharing Container must be in the same AD domain. When the “AutoCertificateRollover” is set to FALSE, the “CertificateSharingContainer” property CAN have a DN specified but in that case it is not being and can be removed if needed (but only when you are not going to use it in the future!).

Well, because the error was mentioning the Certificate Sharing Container and I did not have a Certificate Sharing Container, I decided to create one. When doing so you need to specify the service account in use by ADFS. I did that by reading the account from the ADFS service. Please be aware that by configuring the Certificate Sharing Container in ADFS, it will also be created in AD. Because of that you need to have Domain Admin equivalent permissions to be able to successfully do this!

$adfsService = Get-WmiObject win32_service -filter "name=’ADFSSRV’"
$adfsServiceAccount = $adfsService.StartName
Set-AdfsCertSharingContainer -ServiceAccount $adfsServiceAccount

image

Figure 4: Configuring The Certificate Sharing Container For ADFS

Now looking at the ADFS properties you can see the Certificate Sharing Container is configured in ADFS.

image

Figure 5: The Certificate Sharing Container Being Configured For ADFS

Before the configuration in ADFS you can see AD did not have a Certificate Sharing Container.

image

Figure 6: The AD Domain The ADFS Servers Are In With NO Certificate Sharing Container

After the configuration in ADFS you can see AD now does have a Certificate Sharing Container.

image

Figure 7: The AD Domain The ADFS Servers Are In With Certificate Sharing Container

Now when running either of the “Add-AdfsLocalClaimsProviderTrust” CMDlets above succeeds!

image

Figure 8: Creating The Local Claims Provider Trust Now Succeeds

Below you can see the properties of the Local Claims Provider trust that was created.

image

Figure 9: The Configuration Of The Local Claims Provider Trust That Was Just Created

And now you also see the local Claims Provider Trust is displayed and therefore available in the HRD page in ADFS.

image

Figure 10: The HRD Page In ADFS Showing The Newly Created Local Claims Provider Trust

Choosing the IdP “External ID Store” and logging on with an account from the ADLDS based ID Store through Forms Based Authentication, show amongst others the claims as displayed in the figure below.

image

Figure 11: My Show My Claims Application Displaying The Claims That Were Retrieved From The ID Store Based Upon ADLDS

You can see the values for the following claims that were configured above:

Cheers,
Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
####################
http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

Posted in Active Directory Federation Services (ADFS), Active Directory Lightweight Directory Services (ADLDS), Identity Stores | 2 Comments »

(2018-10-09) Changing AD CP Trust Display Name And Order In ADFS 2016 Farm Level And Higher

Posted by Jorge on 2018-10-09


You are currently running ADFS 2012 R2 and you are planning on upgrading (yes, you can upgrade!) to ADFS 2016. Your Home Realm Discovery (HRD) page is looking similar to the one in figure 1, meaning that the AD CP trust is listed at the top and that it inherits the Display Name of the federation service. So far so good , right?

image

Figure 1: A Home Realm Discovery Web Page In ADFS 2012 R2 Or ADFS 2016 When At ADFS 2012 R2 Farm Level

After adding ADFS 2016 servers and removing the ADFS 2012 R2 servers, it is time to increase the farm level to the highest farm level possible.

You “throw the switch” and suddenly your HRD page looks similar to the one as displayed in figure 2. Damn!

image

Figure 2: A Home Realm Discovery Web Page In ADFS 2016 When At, At Least ADFS 2016 Farm Level

From a user perspective, that can be quite some impact as user to not expect “their default selection” to have moved to the bottom. Worse yet, the users might not even recognize it because the trust display name does not inherit the display name of the federation service anymore. It just shows as “Active Directory”, which is a technical name. You might think in changing the display name of the “Active Directory” CP trust to match whatever you need. Let me save you the trouble of trying that, because, it is not allowed to change much including the display name.

So, one simple change (farm level increase) results in an unfortunate functional impact for users.

What can you do about this? The solution to this problem is to implement some extra javascript code in the ONLOAD.JS.

To make sure your current web theme is not broken while making this change, make sure to first create a new web theme and implement the changes in that new web theme. So let’s get started!

Retrieve the name of your CURRENT web theme

Get-AdfsWebConfig

In the property called “ActiveThemeName” you will find the name of the current theme that is active and in use by everyone.

Make a copy of that theme and give the copy a new name:

New-AdfsWebTheme -Name <New WebTheme Name> -SourceName <Current Active WebTheme Name>

Export the new web theme to be able to edit it:

MD <Path To Export The Theme To>

Export-AdfsWebTheme -Name <New WebTheme Name> -DirectoryPath <Path To Export The Theme To>

Open the ONLOAD.JS file

NOTEPAD "<Path To Export The Theme To>\script\onload.js"

Edit the ONLOAD.JS file by adding a piece of javascript code at the end of it. It will put the AD CP trust at the top again and it will rename it to the display name of your choosing. It has been tested with the following browsers: IE, Edge, Chrome, Firefox, Safari.
REMARK: Make sure to follow guidelines as available in
https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/advanced-customization-of-ad-fs-sign-in-pages

The javascript code is available at: https://github.com/microsoft/adfsWebCustomization/tree/master/communityCustomizations/RenameAndReorderADCPTrust

Save the ONLOAD.JS file

Import the new ONLOAD.JS into the new web theme

Set-AdfsWebTheme -TargetName <New WebTheme Name> -AdditionalFileResource @{Uri=’/adfs/portal/script/onload.js’;path="<Path To Export The Theme To>\script\onload.js"}

Now it is time to activate the new web theme and check it has been activated

Set-AdfsWebConfig -ActiveThemeName <New WebTheme Name>

Get-AdfsWebConfig

Now make sure to clear your cookies, and navigate to an application connected to ADFS for which more than one CP trust is allowed to use. In that case, assuming you have cleared your cookies, the HRD page should appear and it should again be similar to what you see in figure 1.

If you need to revert back to your previous current web theme, you new to activate it as such and check it has been activated

Set-AdfsWebConfig -ActiveThemeName <Current Active WebTheme Name>

Get-AdfsWebConfig

PS: make sure to test this first in a test environment!

Cheers,
Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
####################
http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

Posted in Active Directory Federation Services (ADFS), Configuration, Federation Trusts, Home Realm Discovery (HRD), Migration, onload.js | Leave a Comment »

 
%d bloggers like this: