(2017-09-15) Azure AD Connect v1.1.614.0 Has Been Released

Integrating your on-premises directories with Azure AD makes your users more productive by providing a common identity for accessing both cloud and on-premises resources. With this integration users and organizations can take advantage of the following:

• Organizations can provide users with a common hybrid identity across on-premises or cloud-based services leveraging Windows Server Active Directory and then connecting to Azure Active Directory.
• Administrators can provide conditional access based on application resource, device and user identity, network location and multifactor authentication.
• Users can leverage their common identity through accounts in Azure AD to Office 365, Intune, SaaS apps and third-party applications.
• Developers can build applications that leverage the common identity model, integrating applications into Active Directory on-premises or Azure for cloud-based applications

Azure AD Connect makes this integration easy and simplifies the management of your on-premises and cloud identity infrastructure.

–

Download "Microsoft Azure Active Directory Connect"

–

Azure AD Connect: Version Release History

1.1.614.0

Released: 2017 September

–

Prerequisites for Azure AD Connect

–

More information about Azure AD Connect

–

IMPORTANT: There are schema and sync rule changes introduced in this build. Azure AD Connect Synchronization Service will trigger Full Import and Full Sync steps after upgrade. Details of the changes are described below.

–

Fixed issues:

Azure AD Connect

• Fixed an issue that prevented Azure AD Connect from updating the claims rules in on-premises ADFS while enabling the msDS-ConsistencyGuid as Source Anchor feature. The issue occurs if you try to enable the feature for an existing Azure AD Connect deployment that has ADFS configured as the sign-in method. The issue occurs because the wizard does not prompt for ADFS credentials before trying to update the claims rules in ADFS.
• Fixed an issue that caused Azure AD Connect to fail installation if the on-premises AD forest has NTLM disabled. The issue is due to Azure AD Connect wizard not providing fully qualified credentials when creating the security contexts required for Kerberos authentication. This causes Kerberos authentication to fail and Azure AD Connect wizard to fall back to using NTLM.

–

Azure AD Connect sync

• Fixed an issue where new synchronization rule cannot be created if the Tag attribute isn’t populated.
• Fixed an issue that caused Azure AD Connect to connect to on-premises AD for Password Synchronization using NTLM, even though Kerberos is available. This issue occurs if the on-premises AD topology has one or more domain controllers that was restored from a backup.
• Fixed an issue that caused full synchronization steps to occur unnecessarily after upgrade. In general, running full synchronization steps is required after upgrade if there are changes to out-of-box synchronization rules. The issue was due to an error in the change detection logic that incorrectly detected a change when encountering synchronization rule expression with newline characters. Newline characters are inserted into sync rule expression to improve readability.
• Fixed an issue that can cause the Azure AD Connect server to not work correctly after Automatic Upgrade. This issue affects Azure AD Connect servers with version 1.1.443.0 (or earlier). For details about the issue, refer to article Azure AD Connect is not working correctly after an automatic upgrade.
• Fixed an issue that can cause Automatic Upgrade to be retried every 5 minutes when errors are encountered. With the fix, Automatic Upgrade retries with exponential back-off when errors are encountered.
• Fixed an issue where password synchronization event 611 is incorrectly shown in Windows Application Event logs as informational instead of error. Event 611 is generated whenever password synchronization encounters an issue.
• Fixed an issue in the Azure AD Connect wizard that allows Group writeback feature to be enabled without selecting an OU required for Group writeback.

–

AD FS Management

• The Initialize-ADSyncNGCKeysWriteBack cmdlet in the AD prep powershell module was incorrectly ACL’ing the device registration container and would therefore only inherit existing permissions. This was updated so that the sync service account has the correct permissions

–

Seamless Single Sign-On

• Fixed an issue that caused Azure AD Connect wizard to return an error if you try to enable Seamless Single Sign-On. The error message is “Configuration of Microsoft Azure AD Connect Authentication Agent failed.” This issue affects existing customers who had manually upgraded the preview version of the Authentication Agents for Pass-through Authentication based on the steps described in this article.

–

Known issues:

Azure AD Connect sync

• There is a known issue with Azure AD Connect Upgrade that is affecting customers who have enabled Seamless Single Sign-On. After Azure AD Connect is upgraded, the feature appears as disabled in the wizard, even though the feature remains enabled. A fix for this issue will be provided in future release. Customers who are concerned about this display issue can manually fix it by enabling Seamless Single Sign-On in the wizard.

–

New features/Improvements:

Azure AD Connect sync

• Added a Troubleshoot task to Azure AD Connect wizard under Additional Tasks. Customers can leverage this task to troubleshoot issues related to password synchronization and collect general diagnostics. In the future, the Troubleshoot task will be extended to include other directory synchronization-related issues.
• Azure AD Connect now supports a new installation mode called Use Existing Database. This installation mode allows customers to install Azure AD Connect that specifies an existing ADSync database. For more information about this feature, refer to article Use an existing database.
• For improved security, Azure AD Connect now defaults to using TLS1.2 to connect to Azure AD for directory synchronization. Previously, the default was TLS1.0.
• When Azure AD Connect Password Synchronization Agent starts up, it tries to connect to Azure AD well-known endpoint for password synchronization. Upon successful connection, it is redirected to a region-specific endpoint. Previously, the Password Synchronization Agent caches the region-specific endpoint until it is restarted. Now, the agent clears the cache and retries with the well-known endpoint if it encounters connection issue with the region-specific endpoint. This change ensures that password synchronization can failover to a different region-specific endpoint when the cached region-specific endpoint is no longer available.
• To synchronize changes from an on-premises AD forest, an AD DS account is required. You can either (i) create the AD DS account yourself and provide its credential to Azure AD Connect, or (ii) provide an Enterprise Admin credentials and let Azure AD Connect create the AD DS account for you. Previously, (i) is the default option in the Azure AD Connect wizard. Now, (ii) is the default option.

–

AD FS Management

• The AAD Connect Verify ADFS Login task was updated so that it verifies logins against Microsoft Online and not just token retrieval from ADFS.
• When setting up a new ADFS farm using AAD Connect, the page asking for ADFS credentials was moved so that it now occurs before the user is asked to provide ADFS and WAP servers. This allows AAD Connect to check that the account specified has the correct permissions.
• During AAD Connect upgrade, we will no longer fail an upgrade if the ADFS AAD Trust fails to update. If that happens, the user will be shown an appropriate warning message and should proceed to reset the trust via the AAD Connect additional task

–

Azure AD Connect Health

• Added support for Microsoft Azure Government Cloud and Microsoft Cloud Germany.

–

I ran the MSI and upgraded from the previous version without any issues!

–

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

(2017-09-11) Registering The Azure AD Connect Health Agent Through A Proxy

If you need to register your Azure AD Connect Health Agent for ADFS, Sync or ADDS through a proxy, you need to first configure the proxy server and port for Azure AD Connect Health.

You have the following options:

• Read the current proxy settings for AAD Connect Health –> Get-AzureAdConnectHealthProxySettings
• Import from Internet Explorer (if confgured) –> Set-AzureAdConnectHealthProxySettings -ImportFromInternetSettings
• Import from WinHTTP (if configured) –> Set-AzureAdConnectHealthProxySettings -ImportFromWinHttp
• Specify Proxy addresses manually –> Set-AzureAdConnectHealthProxySettings -HttpsProxyAddress <fqdn>:<port>
• Clear existing proxy configuration –> Set-AzureAdConnectHealthProxySettings -NoProxy

–

Now let’s assume you have used one of the options to configure the proxy settings. After that you can use the following PowerShell commands to register the Azure AD Connect Health Agent

$azureADUserName = "<replace this with a native or federated account that has the global admin role and is NOT MFA enabled/enforced>"

$azureADPassword = ‘<replace this with the password>’

$azureADSecurePassword = ConvertTo-SecureString $azureADPassword -AsPlainText –Force

$azureADCreds = New-Object System.Management.Automation.PSCredential $azureADUserName, $azureADSecurePassword

REMARK: specifying the credentials through PowerShell may be required if the server installing Azure AD Connect Health does not support cookies and/or javascript.

REMARK: Of course you can also use –> $azureADCreds = Get-Credential

–

For Azure AD Connect Health for ADFS –> Register-AzureADConnectHealthADFSAgent -Credential $azureADCreds

For Azure AD Connect Health for ADDS –> Register-AzureADConnectHealthADDSAgent-Credential $azureADCreds

For Azure AD Connect Health for Sync –> Register-AzureADConnectHealthSyncAgent-Credential $azureADCreds –AttributeFiltering [$false | $true] -StagingMode [$false | $true]

–

If the registration is succesful, you should see something similar to te following

Figure 1: Successful Registration Of Azure AD Connect Health (In This Case For ADFS)

–

However, you may see the following error:

Figure 2: Unsuccessful Registration Of Azure AD Connect Health (In This Case For ADFS) With The Error: “user_realm_discovery_failed: User Realm Discovery Failed”

–

Always when receiving an error, open the specified log file to see/understand what went wrong.

–

In this case opening the file I saw the following:

–

2017-08-25 07:20:39.295 ProductName: Azure AD Connect Health AD FS Agent, FileVersion: 3.0.68.0, Current UTC Time: 2017-08-25 07:20:39Z

2017-08-25 07:20:39.295 AHealthServiceUri (ARM): https://management.azure.com/providers/Microsoft.ADHybridHealthService/

2017-08-25 07:20:39.31 AdHybridHealthServiceUri: https://s1.adhybridhealth.azure.com/

2017-08-25 07:20:39.326 AHealthServiceUri (ARM): https://management.azure.com/providers/Microsoft.ADHybridHealthService/

2017-08-25 07:20:39.326 AdHybridHealthServiceUri: https://s1.adhybridhealth.azure.com/

2017-08-25 07:20:39.373 User Context outbound connections to https://management.azure.com/providers/Microsoft.ADHybridHealthService/ will use proxy address https://management.azure.com/providers/Microsoft.ADHybridHealthService/ (if equal, no proxy is used)

2017-08-25 07:20:39.373 Service Context: Outbound connections to https://management.azure.com/providers/Microsoft.ADHybridHealthService/ will use proxy address http://proxy.iamtec.nl:3128/ (if equal, no proxy is used)

2017-08-25 07:20:39.373 UploadLogFileFromDisk: arguments LogFileLocation=C:\Users\XXX\AppData\Local\Temp\3\AdHealthAdfsAgentConfiguration.2017-08-25_09-20-39.log;ProductName=Azure AD Connect Health AD FS Agent;ProductVersion=3.0.68.0;MachineName=SERVER;ServiceUri=https://s1.adhybridhealth.azure.com/;Result=started;type=registration,activityId=432fd061-6219-498a-8a98-bf68d90a5431

2017-08-25 07:20:39.389 UploadLogFileFromDisk: TenantId: unknown

2017-08-25 07:20:39.389 UploadLogFileFromDisk: MachineId: unknown

2017-08-25 07:20:39.389 UploadLogFileFromDisk: reading file contents of C:\Users\XXX\AppData\Local\Temp\3\AdHealthAdfsAgentConfiguration.2017-08-25_09-20-39.log

2017-08-25 07:20:39.389 UploadLogFileFromDisk: log length: 1842

2017-08-25 07:20:39.389 UploadFile: start, url: https://s1.adhybridhealth.azure.com/providers/Microsoft.ADHybridHealthService/diagnostics/logs/installer/product/Azure-AD-Connect-Health-AD-FS-Agent/version/3.0.68.0/machine/SERVER?result=started&type=registration

powershell.exe Information: 0 : AdHealthWebproxy settings: HttpsProxyAddress: http://proxy.iamtec.nl:3128/, initialization status: Succeeded; Registry value did not exist; Value was not a string, No Initialization Exception

2017-08-25 07:20:40.451 UploadFile: upload successful

2017-08-25 07:20:40.451 UploadLogFileFromDisk: response: Http response code: OK

"log successfully uploaded"

2017-08-25 07:20:40.451 AHealthServiceApiVersion: 2014-01-01

2017-08-25 07:20:40.451 –> https://management.core.windows.net/

powershell.exe Information: 0 : 8/25/2017 7:20:40 AM:  – AdHealthAgentConfigurationUtility: ADAL .NET with assembly version ‘2.24.0.0’, file version ‘2.24.30411.1323’ and informational version ‘4482033c814db2fd31423c79b5027d0b5dfb7a6d’ is running…

powershell.exe Information: 0 : 8/25/2017 7:20:40 AM: 432eb23e-19c6-4c97-9bc2-ca4f7138fb3e – AcquireTokenNonInteractiveHandler: === Token Acquisition started:

                Authority: https://login.windows.net/common/

                Resource: https://management.core.windows.net/

                ClientId: cf6d7e68-f018-4e0a-a7b3-126e053fb88d

                CacheType: Microsoft.IdentityModel.Clients.ActiveDirectory.TokenCache (0 items)

                Authentication Target: User

powershell.exe Information: 0 : 8/25/2017 7:20:40 AM: 432eb23e-19c6-4c97-9bc2-ca4f7138fb3e – <RunAsync>d__0: No matching token was found in the cache

powershell.exe Information: 0 : 8/25/2017 7:20:40 AM: 432eb23e-19c6-4c97-9bc2-ca4f7138fb3e – AsyncMethodBuilderCore: Sending user realm discovery request to ‘https://login.windows.net/common/UserRealm/jorge@iamtec.nl?api-version=1.0&#8217;

powershell.exe Error: 0 : 8/25/2017 7:21:10 AM: 432eb23e-19c6-4c97-9bc2-ca4f7138fb3e – AsyncMethodBuilderCore: Microsoft.IdentityModel.Clients.ActiveDirectory.AdalServiceException: user_realm_discovery_failed: User realm discovery failed —> System.Net.WebException: The operation has timed out

   at System.Net.HttpWebRequest.GetResponse()

   at Microsoft.IdentityModel.Clients.ActiveDirectory.HttpWebRequestWrapper.<GetResponseSyncOrAsync>d__2.MoveNext()

— End of stack trace from previous location where exception was thrown —

   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)

   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)

   at Microsoft.IdentityModel.Clients.ActiveDirectory.UserRealmDiscoveryResponse.<CreateByDiscoveryAsync>d__0.MoveNext()

   — End of inner exception stack trace —

   at Microsoft.IdentityModel.Clients.ActiveDirectory.UserRealmDiscoveryResponse.<CreateByDiscoveryAsync>d__0.MoveNext()

— End of stack trace from previous location where exception was thrown —

   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)

   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)

   at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()

   at Microsoft.IdentityModel.Clients.ActiveDirectory.AcquireTokenNonInteractiveHandler.<PreTokenRequest>d__4.MoveNext()

— End of stack trace from previous location where exception was thrown —

   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)

   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)

   at Microsoft.IdentityModel.Clients.ActiveDirectory.AcquireTokenHandlerBase.<RunAsync>d__0.MoveNext()

                ErrorCode: user_realm_discovery_failed

                StatusCode: 0

2017-08-25 07:21:10.645 Microsoft.IdentityModel.Clients.ActiveDirectory.AdalServiceException: user_realm_discovery_failed: User realm discovery failed —> System.Net.WebException: The operation has timed out

   at System.Net.HttpWebRequest.GetResponse()

   at Microsoft.IdentityModel.Clients.ActiveDirectory.HttpWebRequestWrapper.<GetResponseSyncOrAsync>d__2.MoveNext()

— End of stack trace from previous location where exception was thrown —

   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)

   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)

   at Microsoft.IdentityModel.Clients.ActiveDirectory.UserRealmDiscoveryResponse.<CreateByDiscoveryAsync>d__0.MoveNext()

   — End of inner exception stack trace —

   at Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationContext.RunAsyncTask[T](Task`1 task)

   at Microsoft.Identity.Health.Common.Clients.PowerShell.ConfigurationModule.AdHealthAgentConfigurationUtility.ObtainAadAccessTokenWithExistingCredential(PSCredential psCredential)

   at Microsoft.Identity.Health.Common.Clients.PowerShell.ConfigurationModule.RegisterADHealthAgent.ProcessRecord()

                ErrorCode: user_realm_discovery_failed

                StatusCode: 0

2017-08-25 07:21:10.66 UploadLogFileFromDisk: arguments LogFileLocation=C:\Users\XXX\AppData\Local\Temp\3\AdHealthAdfsAgentConfiguration.2017-08-25_09-20-39.log;ProductName=Azure AD Connect Health AD FS Agent;ProductVersion=3.0.68.0;MachineName=SERVER;ServiceUri=https://s1.adhybridhealth.azure.com/;Result=failed;type=registration,activityId=432fd061-6219-498a-9b98-bf68d90a5431

2017-08-25 07:21:10.66 UploadLogFileFromDisk: TenantId: unknown

2017-08-25 07:21:10.66 UploadLogFileFromDisk: MachineId: unknown

2017-08-25 07:21:10.66 UploadLogFileFromDisk: reading file contents of C:\Users\XXX\AppData\Local\Temp\3\AdHealthAdfsAgentConfiguration.2017-08-25_09-20-39.log

2017-08-25 07:21:10.66 UploadLogFileFromDisk: log length: 7608

2017-08-25 07:21:10.66 UploadFile: start, url: https://s1.adhybridhealth.azure.com/providers/Microsoft.ADHybridHealthService/diagnostics/logs/installer/product/Azure-AD-Connect-Health-AD-FS-Agent/version/3.0.68.0/machine/SERVER?result=failed&type=registration

2017-08-25 07:21:11.082 UploadFile: upload successful

2017-08-25 07:21:11.082 UploadLogFileFromDisk: response: Http response code: OK

"log successfully uploaded"

–

The green lines above list what/where things go wrong. In this case user realm discovery is failing. However, the yellow lines are giving you a hint why things are going wrong.

–

Looking at the second yellow line you see the service context is using the proxy server configured for Azure AD Connect Health. However, the first yellow line tells you the user context context is not using any proxy server at all. Because of that it is failing the realm discovery

–

The solution for this is to configure the user context with a proxy server and port. That is done by configuring the proxy settings in Internet Explorer with the same values

Figure 3: Configuring The User Context With Proxy Settings

–

After doing this, retry registration.

–

If it still fails check the log file again. You might see the following:

–

powershell.exe Information: 0 : 9/11/2017 11:54:12 AM: 68215d80-864f-43af-9b6a-8f3f41f276af – <RunAsync>d__0: No matching token was found in the cache

powershell.exe Information: 0 : 9/11/2017 11:54:12 AM: 68215d80-864f-43af-9b6a-8f3f41f276af – AsyncMethodBuilderCore: Sending user realm discovery request to ‘https://login.windows.net/common/UserRealm/jorge@iamtec.nl?api-version=1.0&#8217;

powershell.exe Error: 0 : 9/11/2017 11:54:12 AM: 68215d80-864f-43af-9b6a-8f3f41f276af – AsyncMethodBuilderCore: Microsoft.IdentityModel.Clients.ActiveDirectory.AdalServiceException: user_realm_discovery_failed: User realm discovery failed —> System.Net.WebException: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. —> System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure.

   at System.Net.Security.SslState.StartSendAuthResetSignal(ProtocolToken message, AsyncProtocolRequest asyncRequest, Exception exception)

   at System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest)

   at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)

   at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)

   at System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest)

   at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)

at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)

   at System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest)

   at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)

   at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)

   at System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest)

   at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)

   at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)

–

In this case, your proxy server is terminating SSL traffic for inspection. If you have not imported the root certificate of the certificate being used by the proxy server into the “Trusted Root Certificate Authority” store, you will see an error like this. Import the root certificate of the certificate being used by the proxy server into the “Trusted Root Certificate Authority” store to fix this.

–

Hope this helps you!

–

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/ ###################
————————————————————————————————————————————————————-

(2017-09-07) Claims Rules Set For Your AAD/O365 RP Trust To Support User And Device Authentication

On the page “How to configure hybrid Azure Active Directory joined devices” Microsoft explains how to setup Domain Join ++, currently a.k.a. Hybrid AAD Join. This post is about, hopefully giving additional, clarification on how to setup the claims rules in ADFS. All the scenarios listed below work, it just on your scenario. Feel free to leave any comments if unclear. The import of the rules below should replace your current rules for the AAD RP Trust, and where applicable add rules to your AD CP trust. A final note, is that these rule sets are based upon Microsoft’s rule in the previous article.

Make sure to test this first in your test environment!

You may also want to have a look at the following blog post:

(2016-12-16) Automatic Azure AD Join With ADFS v3.0 And Higher And Conditional Access – What You Really Need In Detail

–

[OPTION 1]

The following works if you have claims rules in place on the AD CP trust that output the following claim types. This is true if you are using the default claim rule set in ADFSv3/ADFSv4:

• http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid
• http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname

–

Assumptions here:

• You have one ADFS environment servicing all the federated domains in AAD
• The federation identifier being used on your federated domains in AAD is default
• The primary group was not changed for any user or any computer
• The objectGUID is the attribute being used for the Immutable ID for users
• The objectGUID is the attribute being used for the Immutable ID for computers
• On-premises UPN is also the UPN used in AAD
• Whether or not you have multiple federated domains, the config below for the IssuerID for users works as long as the UPN of the user matches one of the federated domains in AAD
• You will replace FEDERATED-DOMAIN with one of the federated domains in AAD. It does not matter which one
• You will replace NAME-OF-AAD/O365-RP-TRUST with the actual name of the RP trust for AAD/O365

–

Remarks:

• Leave a comment if you have any deviation of the assumptions above

–

Thoughts here:

• It is making multiple LDAP calls to AD, and is therefore not that optimized. It works though!
• Still using groupsid claim type

–

Link to claims rules below: https://www.dropbox.com/s/vgzvnwhku2adp39/AzureAD-RP-Trust-Issuance-Rules1.txt

–

$aadRPTrustIssuanceRules = @"

@RuleName = "Issue UPN And ImmutableID (Domain User Only)"

c1:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid&quot;, Value =~ "-513$", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] &&

c2:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"%5D

=> issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/claims/UPN&quot;, "http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID&quot;), query = ";userPrincipalName,objectGUID;{0}", param = c2.Value);

@RuleName = "Issue IssuerID (Domain User Only)"

c:[Type == "http://schemas.xmlsoap.org/claims/UPN"%5D

=> issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid&quot;, Value = regexreplace(c.Value, ".+@(?<domain>.+)", http://${domain}/adfs/services/trust/));

@RuleName = "Issue ImmutableID (Domain Joined Computer Only)"

c1:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid&quot;, Value =~ "-515$", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] &&

c2:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname&quot;, Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"]

=> issue(store = "Active Directory", types = ("http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID&quot;), query = ";objectguid;{0}", param = c2.Value);

@RuleName = "Issue Account Type (Domain Joined Computer Only)"

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid&quot;, Value =~ "-515$", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"]

=> issue(Type = "http://schemas.microsoft.com/ws/2012/01/accounttype&quot;, Value = "DJ");

@RuleName = "Issue ObjectGUID (Domain Joined Computer Only)"

c1:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid&quot;, Value =~ "-515$", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] &&

c2:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname&quot;, Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"]

=> issue(store = "Active Directory", types = ("http://schemas.microsoft.com/identity/claims/onpremobjectguid&quot;), query = ";objectguid;{0}", param = c2.Value);

@RuleName = "Issue ObjectSID (Domain Joined Computer Only)"

c1:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid&quot;, Value =~ "-515$", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] &&

c2:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid&quot;, Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"]

=> issue(claim = c2);

@RuleName = "Issue IssuerID (Domain Joined Computer Only)"

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid&quot;, Value =~ "-515$", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"]

=> issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid&quot;, Value = http://FEDERATED-DOMAIN/adfs/services/trust/);

@RuleName = "Issue NameID (Domain User and Domain Joined Computer)"

c:[Type == "http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"%5D

=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier&quot;, Value = c.Value, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"%5D = "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified");

@RuleName = "Issue AuthN Methods References (Domain User and Domain Joined Computer)"

c:[Type == "http://schemas.microsoft.com/claims/authnmethodsreferences"%5D

=> issue(claim = c);

"@

Set-AdfsRelyingPartyTrust -TargetName "NAME-OF-AAD/O365-RP-TRUST" -IssuanceTransformRules $aadRPTrustIssuanceRules

–

[OPTION 2]

The following works if you have claims rules in place on the AD CP trust that output the following claim types. This is true if you are using the default claim rule set in ADFSv3/ADFSv4:

• http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid
• http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname
• http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn

–

Assumptions here:

• You have one ADFS environment servicing all the federated domains in AAD
• The federation identifier being used on your federated domains in AAD is default
• The primary group was not changed for any user or any computer
• The objectGUID is the attribute being used for the Immutable ID for users
• The objectGUID is the attribute being used for the Immutable ID for computers
• On-premises UPN is also the UPN used in AAD
• Whether or not you have multiple federated domains, the config below for the IssuerID for users works as long as the UPN of the user matches one of the federated domains in AAD
• You will replace FEDERATED-DOMAIN with one of the federated domains in AAD. It does not matter which one
• You will replace NAME-OF-AAD/O365-RP-TRUST with the actual name of the RP trust for AAD/O365

–

Remarks:

• Leave a comment if you have any deviation of the assumptions above

–

Thoughts here:

• Although a few LDAP calls less, it is still making LDAP calls to AD. It works though!
• Still using groupsid claim type

–

Link to claims rules below: https://www.dropbox.com/s/udn1rudm5bgv7jq/AzureAD-RP-Trust-Issuance-Rules2.txt

–

$aadRPTrustIssuanceRules = @"

@RuleName = "Issue UPN (Domain User Only)"

c1:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid&quot;, Value =~ "-513$", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] &&

c2:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"%5D

=> issue(Type = "http://schemas.xmlsoap.org/claims/UPN&quot;, Issuer = c2.Issuer, OriginalIssuer = c2.OriginalIssuer, Value = c2.Value, ValueType = c2.ValueType);

@RuleName = "Issue IssuerID (Domain User Only)"

c:[Type == "http://schemas.xmlsoap.org/claims/UPN"%5D

=> issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid&quot;, Value = regexreplace(c.Value, ".+@(?<domain>.+)", http://${domain}/adfs/services/trust/));

@RuleName = "Issue Account Type (Domain Joined Computer Only)"

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid&quot;, Value =~ "-515$", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"]

=> issue(Type = "http://schemas.microsoft.com/ws/2012/01/accounttype&quot;, Value = "DJ");

@RuleName = "Issue ObjectGUID (Domain Joined Computer Only)"

c1:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid&quot;, Value =~ "-515$", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] &&

c2:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname&quot;, Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"]

=> issue(store = "Active Directory", types = ("http://schemas.microsoft.com/identity/claims/onpremobjectguid&quot;), query = ";objectguid;{0}", param = c2.Value);

@RuleName = "Issue ObjectSID (Domain Joined Computer Only)"

c1:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid&quot;, Value =~ "-515$", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] &&

c2:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid&quot;, Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"]

=> issue(claim = c2);

@RuleName = "Issue IssuerID (Domain Joined Computer Only)"

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid&quot;, Value =~ "-515$", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"]

=> issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid&quot;, Value = http://FEDERATED-DOMAIN/adfs/services/trust/);

@RuleName = "ImmutableID (Domain User And Domain Joined Computer)"

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"%5D

=> issue(store = "Active Directory", types = ("http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID&quot;), query = ";objectGUID;{0}", param = c.Value);

@RuleName = "Issue NameID (Domain User and Domain Joined Computer)"

c:[Type == "http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"%5D

=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier&quot;, Value = c.Value, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"%5D = "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified");

@RuleName = "Issue AuthN Methods References (Domain User and Domain Joined Computer)"

c:[Type == "http://schemas.microsoft.com/claims/authnmethodsreferences"%5D

=> issue(claim = c);

"@

Set-AdfsRelyingPartyTrust -TargetName "NAME-OF-AAD/O365-RP-TRUST" -IssuanceTransformRules $aadRPTrustIssuanceRules

–

[OPTION 3]

The following works if you have claims rules in place on the AD CP trust that output the following claim types. This is true if you are using the default claim rule set in ADFSv3/ADFSv4:

• http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid
• http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname
• http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn
• http://temp.org/identity/claims/objectGUID

–

For the last claim type you would need the following claim rule on the AD CP trust if you are not already extracting additional data from AD

–

$additionalADCPTrustRule = @"
@RuleTemplate = "LdapClaims"
@RuleName = "Extract Extra Data From AD"
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname&quot;, Issuer == "AD AUTHORITY"]
  => issue(store = "Active Directory", types = ("http://temp.org/identity/claims/objectGUID&quot;), query = ";objectguid;{0}", param = c.Value);
"@

$existingADCPtrustAcceptRuleSet = (Get-AdfsClaimsProviderTrust -Name "Active Directory").AcceptanceTransformRules

$newADCPtrustAcceptRuleSet = $existingADCPtrustAcceptRuleSet + $additionalADCPTrustRule

Set-AdfsClaimsProviderTrust -TargetName "Active Directory" -AcceptanceTransformRules $newADCPtrustAcceptRuleSet

–

If you are already extracting additional data from AD, you need to add the claim type and attribute to that existing extraction

–

Assumptions here:

• You have one ADFS environment servicing all the federated domains in AAD
• The federation identifier being used on your federated domains in AAD is default
• The primary group was not changed for any user or any computer
• The objectGUID is the attribute being used for the Immutable ID for users
• The objectGUID is the attribute being used for the Immutable ID for computers
• On-premises UPN is also the UPN used in AAD
• Whether or not you have multiple federated domains, the config below for the IssuerID for users works as long as the UPN of the user matches one of the federated domains in AAD
• You will replace FEDERATED-DOMAIN with one of the federated domains in AAD. It does not matter which one
• You will replace NAME-OF-AAD/O365-RP-TRUST with the actual name of the RP trust for AAD/O365

–

Remarks:

• Leave a comment if you have any deviation of the assumptions above

–

Thoughts here:

• No LDAP calls!
• Still using groupsid claim type

–

Link to claims rules below: https://www.dropbox.com/s/8cicjpyusapsarj/AzureAD-RP-Trust-Issuance-Rules3.txt

–

$aadRPTrustIssuanceRules = @"

@RuleName = "Issue UPN (Domain User Only)"

c1:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid&quot;, Value =~ "-513$", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] &&

c2:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"%5D

=> issue(Type = "http://schemas.xmlsoap.org/claims/UPN&quot;, Issuer = c2.Issuer, OriginalIssuer = c2.OriginalIssuer, Value = c2.Value, ValueType = c2.ValueType);

@RuleName = "Issue IssuerID (Domain User Only)"

c:[Type == "http://schemas.xmlsoap.org/claims/UPN"%5D

=> issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid&quot;, Value = regexreplace(c.Value, ".+@(?<domain>.+)", http://${domain}/adfs/services/trust/));

@RuleName = "Issue Account Type (Domain Joined Computer Only)"

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid&quot;, Value =~ "-515$", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"]

=> issue(Type = "http://schemas.microsoft.com/ws/2012/01/accounttype&quot;, Value = "DJ");

@RuleName = "Issue ObjectGUID (Domain Joined Computer Only)"

c1:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid&quot;, Value =~ "-515$", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] &&

c2:[Type == "http://temp.org/identity/claims/objectGUID"%5D

=> issue(Type = "http://schemas.microsoft.com/identity/claims/onpremobjectguid&quot;, Issuer = c2.Issuer, OriginalIssuer = c2.OriginalIssuer, Value = c2.Value, ValueType = c2.ValueType);

@RuleName = "Issue ObjectSID (Domain Joined Computer Only)"

c1:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid&quot;, Value =~ "-515$", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] &&

c2:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid&quot;, Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"]

=> issue(claim = c2);

@RuleName = "Issue IssuerID (Domain Joined Computer Only)"

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid&quot;, Value =~ "-515$", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"]

=> issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid&quot;, Value = http://FEDERATED-DOMAIN/adfs/services/trust/);

@RuleName = "ImmutableID (Domain User And Domain Joined Computer)"

c:[Type == "http://temp.org/identity/claims/objectGUID"%5D

=> issue(Type = "http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID&quot;, Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType);

@RuleName = "Issue NameID (Domain User and Domain Joined Computer)"

c:[Type == "http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"%5D

=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier&quot;, Value = c.Value, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"%5D = "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified");

@RuleName = "Issue AuthN Methods References (Domain User and Domain Joined Computer)"

c:[Type == "http://schemas.microsoft.com/claims/authnmethodsreferences"%5D

=> issue(claim = c);

"@

Set-AdfsRelyingPartyTrust -TargetName "NAME-OF-AAD/O365-RP-TRUST" -IssuanceTransformRules $aadRPTrustIssuanceRules

–

[OPTION 4]

The following works if you have claims rules in place on the AD CP trust that output the following claim types.  This is true if you are using the default claim rule set in ADFSv3/ADFSv4 for the first 2 claim types, but not for the last 2 claim types. My main reason for not using groupsid is that the amount of values can be so huge it may not fit on a cookie and the browser chokes. Because of that, when not using the groupsid claim type, you need to design a better model to extract group data from AD and use authorization based claims types from that data. If you are not using the groupsid claim type you can also not identify the difference between a user and a computer. That’s why you can then specifically extract the primaryGroupID.:

• http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname
• http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn
• http://temp.org/identity/claims/objectGUID
• http://temp.org/identity/claims/primaryGroupID

–

For the last 2 claim types you would need the following claim rule on the AD CP trust if you are not already extracting additional data from AD

–

$additionalADCPTrustRule = @"
@RuleTemplate = "LdapClaims"
@RuleName = "Extract Extra Data From AD"
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname&quot;, Issuer == "AD AUTHORITY"]
  => issue(store = "Active Directory", types = ("http://temp.org/identity/claims/objectGUID&quot;,"http://temp.org/identity/claims/primaryGroupID&quot;), query = ";objectguid,primaryGroupID;{0}", param = c.Value);
"@

$existingADCPtrustAcceptRuleSet = (Get-AdfsClaimsProviderTrust -Name "Active Directory").AcceptanceTransformRules

$newADCPtrustAcceptRuleSet = $existingADCPtrustAcceptRuleSet + $additionalADCPTrustRule

Set-AdfsClaimsProviderTrust -TargetName "Active Directory" -AcceptanceTransformRules $newADCPtrustAcceptRuleSet

–

If you are already extracting additional data from AD, you need to add the claim type and attribute to that existing extraction

–

Assumptions here:

• You have one ADFS environment servicing all the federated domains in AAD
• The federation identifier being used on your federated domains in AAD is default
• The primary group was not changed for any user or any computer
• The objectGUID is the attribute being used for the Immutable ID for users
• The objectGUID is the attribute being used for the Immutable ID for computers
• On-premises UPN is also the UPN used in AAD
• Whether or not you have multiple federated domains, the config below for the IssuerID for users works as long as the UPN of the user matches one of the federated domains in AAD
• You will replace FEDERATED-DOMAIN with one of the federated domains in AAD. It does not matter which one
• You will replace NAME-OF-AAD/O365-RP-TRUST with the actual name of the RP trust for AAD/O365

–

Remarks:

• Leave a comment if you have any deviation of the assumptions above

–

Thoughts here:

• No LDAP calls!
• No groupsid claim type!

–

Link to claims rules below: https://www.dropbox.com/s/6nbwuuxl677wb3p/AzureAD-RP-Trust-Issuance-Rules4.txt

–

$aadRPTrustIssuanceRules = @"

@RuleName = "Issue UPN (Domain User Only)"

c1:[Type == "http://temp.org/identity/claims/primaryGroupID&quot;, Value =~ "^513$"] &&

c2:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"%5D

=> issue(Type = "http://schemas.xmlsoap.org/claims/UPN&quot;, Issuer = c2.Issuer, OriginalIssuer = c2.OriginalIssuer, Value = c2.Value, ValueType = c2.ValueType);

@RuleName = "Issue IssuerID (Domain User Only)"

c:[Type == "http://schemas.xmlsoap.org/claims/UPN"%5D

=> issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid&quot;, Value = regexreplace(c.Value, ".+@(?<domain>.+)", http://${domain}/adfs/services/trust/));

@RuleName = "Issue Account Type (Domain Joined Computer Only)"

c:[Type == "http://temp.org/identity/claims/primaryGroupID&quot;, Value =~ "^515$"]

=> issue(Type = "http://schemas.microsoft.com/ws/2012/01/accounttype&quot;, Value = "DJ");

@RuleName = "Issue ObjectGUID (Domain Joined Computer Only)"

c1:[Type == "http://temp.org/identity/claims/primaryGroupID&quot;, Value =~ "^515$"] &&

c2:[Type == "http://temp.org/identity/claims/objectGUID"%5D

=> issue(Type = "http://schemas.microsoft.com/identity/claims/onpremobjectguid&quot;, Issuer = c2.Issuer, OriginalIssuer = c2.OriginalIssuer, Value = c2.Value, ValueType = c2.ValueType);

@RuleName = "Issue ObjectSID (Domain Joined Computer Only)"

c1:[Type == "http://temp.org/identity/claims/primaryGroupID&quot;, Value =~ "^515$"] &&

c2:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid&quot;, Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"]

=> issue(claim = c2);

@RuleName = "Issue IssuerID (Domain Joined Computer Only)"

c:[Type == "http://temp.org/identity/claims/primaryGroupID&quot;, Value =~ "^515$"]

=> issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid&quot;, Value = http://FEDERATED-DOMAIN/adfs/services/trust/);

@RuleName = "ImmutableID (Domain User And Domain Joined Computer)"

c:[Type == "http://temp.org/identity/claims/objectGUID"%5D

=> issue(Type = "http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID&quot;, Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType);

@RuleName = "Issue NameID (Domain User and Domain Joined Computer)"

c:[Type == "http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"%5D

=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier&quot;, Value = c.Value, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"%5D = "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified");

@RuleName = "Issue AuthN Methods References (Domain User and Domain Joined Computer)"

c:[Type == "http://schemas.microsoft.com/claims/authnmethodsreferences"%5D

=> issue(claim = c);

"@

Set-AdfsRelyingPartyTrust -TargetName "NAME-OF-AAD/O365-RP-TRUST" -IssuanceTransformRules $aadRPTrustIssuanceRules

–

Hopefully this blog post gives you the information you need to understand what is needed

–

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/ ###################
————————————————————————————————————————————————————-

(2017-08-14) Azure AD Connect v1.1.561.0 Has Been Released

Integrating your on-premises directories with Azure AD makes your users more productive by providing a common identity for accessing both cloud and on-premises resources. With this integration users and organizations can take advantage of the following:

• Organizations can provide users with a common hybrid identity across on-premises or cloud-based services leveraging Windows Server Active Directory and then connecting to Azure Active Directory.
• Administrators can provide conditional access based on application resource, device and user identity, network location and multifactor authentication.
• Users can leverage their common identity through accounts in Azure AD to Office 365, Intune, SaaS apps and third-party applications.
• Developers can build applications that leverage the common identity model, integrating applications into Active Directory on-premises or Azure for cloud-based applications

Azure AD Connect makes this integration easy and simplifies the management of your on-premises and cloud identity infrastructure.

–

Download "Microsoft Azure Active Directory Connect"

–

Azure AD Connect: Version Release History

1.1.561.0

Released: 2017 July

–

Prerequisites for Azure AD Connect

–

More information about Azure AD Connect

–

IMPORTANT: There are schema and sync rule changes introduced in this build. Azure AD Connect Synchronization Service will trigger Full Import and Full Sync steps after upgrade. Details of the changes are described below.

–

Fixed issues:

Azure AD Connect sync

• Fixed an issue that caused the out-of-box synchronization rule “Out to AD – User ImmutableId” to be removed:
• The issue occurs when Azure AD Connect is upgraded, or when the task option Update Synchronization Configuration in the Azure AD Connect wizard is used to update Azure AD Connect synchronization configuration.
• This synchronization rule is applicable to customers who have enabled the msDS-ConsistencyGuid as Source Anchor feature. This feature was introduced in version 1.1.524.0 and after. When the synchronization rule is removed, Azure AD Connect can no longer populate on-premises AD ms-DS-ConsistencyGuid attribute with the ObjectGuid attribute value. It does not prevent new users from being provisioned into Azure AD.
• The fix ensures that the synchronization rule will no longer be removed during upgrade, or during configuration change, as long as the feature is enabled. For existing customers who have been affected by this issue, the fix also ensures that the synchronization rule is added back after upgrading to this version of Azure AD Connect.
• Fixed an issue that causes out-of-box synchronization rules to have precedence value that is less than 100:
• In general, precedence values 0 – 99 are reserved for custom synchronization rules. During upgrade, the precedence values for out-of-box synchronization rules are updated to accommodate sync rule changes. Due to this issue, out-of-box synchronization rules may be assigned precedence value that is less than 100.
• The fix prevents the issue from occurring during upgrade. However, it does not restore the precedence values for existing customers who have been affected by the issue. A separate fix will be provided in the future to help with the restoration.
• Fixed an issue where the Domain and OU Filtering screen in the Azure AD Connect wizard is showing Sync all domains and OUs option as selected, even though OU-based filtering is enabled. Also explained here, including solution: (2017-06-28) Azure AD Connect Wizard Chooses To Sync All Instead Of Already Selected OUs/Domains
• Fixed an issue that caused the Configure Directory Partitions screen in the Synchronization Service Manager to return an error if the Refresh button is clicked. The error message is “An error was encountered while refreshing domains: Unable to cast object of type ‘System.Collections.ArrayList’ to type ‘Microsoft.DirectoryServices.MetadirectoryServices.UI.PropertySheetBase.MaPropertyPages.PartitionObject.” The error occurs when new AD domain has been added to an existing AD forest and you are trying to update Azure AD Connect using the Refresh button.

–

New features/Improvements:

Azure AD Connect sync

• Automatic Upgrade feature has been expanded to support customers with the following configurations:
• You have enabled the device writeback feature.
• You have enabled the group writeback feature.
• The installation is not an Express settings or a DirSync upgrade.
• You have more than 100,000 objects in the metaverse.
• You are connecting to more than one forest. Express setup only connects to one forest.
• The AD Connector account is not the default MSOL_ account anymore.
• The server is set to be in staging mode.
• You have enabled the user writeback feature.

–

I ran the MSI and upgraded from the previous version without any issues!

–

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/ ###################
————————————————————————————————————————————————————-

(2017-07-05) Azure AD Connect v1.1.557.0 Has Been Released

Integrating your on-premises directories with Azure AD makes your users more productive by providing a common identity for accessing both cloud and on-premises resources. With this integration users and organizations can take advantage of the following:

• Organizations can provide users with a common hybrid identity across on-premises or cloud-based services leveraging Windows Server Active Directory and then connecting to Azure Active Directory.
• Administrators can provide conditional access based on application resource, device and user identity, network location and multifactor authentication.
• Users can leverage their common identity through accounts in Azure AD to Office 365, Intune, SaaS apps and third-party applications.
• Developers can build applications that leverage the common identity model, integrating applications into Active Directory on-premises or Azure for cloud-based applications

Azure AD Connect makes this integration easy and simplifies the management of your on-premises and cloud identity infrastructure.

–

Download "Microsoft Azure Active Directory Connect"

–

Azure AD Connect: Version Release History

1.1.557.0

Released: 2017 July

–

Prerequisites for Azure AD Connect

–

More information about Azure AD Connect

–

IMPORTANT: There are schema and sync rule changes introduced in this build. Azure AD Connect Synchronization Service will trigger Full Import and Full Sync steps after upgrade. Details of the changes are described below.

–

Fixed issues:

Azure AD Connect sync

• Fixed an issue with the Initialize-ADSyncDomainJoinedComputerSync cmdlet that caused the verified domain configured on the existing service connection point object to be changed even if it is still a valid domain. This issue occurs when your Azure AD tenant has more than one verified domains that can be used for configuring the service connection point.

–

Known issues:

Azure AD Connect sync:

• There is an issue that affects customers who are using OU-based filtering with Azure AD Connect sync. When you navigate to the Domain and OU Filtering page in the Azure AD Connect wizard, the following behavior is expected:
• If OU-based filtering is enabled, the Sync selected domains and OUs option is selected.
  Otherwise, the Sync all domains and OUs option is selected.
• The issue that arises is that the Sync all domains and OUs option is always selected when you run the Wizard. This occurs even if OU-based filtering was previously configured. Before saving any AAD Connect configuration changes, make sure the Sync selected domains and OUs option is selected and confirm that all OUs that need to synchronize are enabled again. Otherwise, OU-based filtering will be disabled.
• Also explained here, including solution: (2017-06-28) Azure AD Connect Wizard Chooses To Sync All Instead Of Already Selected OUs/Domains

–

New features/Improvements:

Azure AD Connect sync

• Password writeback is now available for preview with Microsoft Azure Government cloud and Microsoft Cloud Germany. For more information about Azure AD Connect support for the different service instances, refer to article Azure AD Connect: Special considerations for instances.
• The Initialize-ADSyncDomainJoinedComputerSync cmdlet now has a new optional parameter named AzureADDomain. This parameter lets you specify which verified domain to be used for configuring the service connection point.

–

I ran the MSI and upgraded from the previous version without any issues!

–

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/ ###################
————————————————————————————————————————————————————-

(2017-06-28) Azure AD Connect Wizard Chooses To Sync All Instead Of Already Selected OUs/Domains

After upgrading to the latest version of AAD Connect, at the time of writing that was v1.1.553.0 as described here, I ran the AAD Connect wizard to enable an option that I wanted to try.

While going through the wizard I noticed that the wizard by default chose the option “Sync All Domains An OUs” instead of the option “Sync Selected Domains And OUs”. In my opinion it should have selected the last option as THAT was what I had configured previously including the selected domains and OUs.

Figure 1: AAD Connect Wizard Selecting The Option “Sync All Domains And OUs”

–

So, how do you solve this? Just reselect the option “Sync Selected Domains And OUs” and all your previous selected domains and OUs that you selected previously are reselected again

Figure 2: Fixing The Default Selection Of The AAD Connect Wizard With The Selection Of The Option “Sync Selected Domains And OUs”

–

Prior to version v1.1.524.0 you had to use the Synchronization Service Manager if you did not want to have OUs in the root of the domain to be automatically selected for sync. With v1.1.524.0 and later you can also use the AAD Connect wizard to not have OUs in the root of the domain to be automatically selected. This corresponds to the following issue fixed in v1.1.524.0:

To configure OU filtering, you can either use the Azure AD Connect wizard or the Synchronization Service Manager. Previously, if you use the Azure AD Connect wizard to configure OU filtering, new OUs created afterwards are included for directory synchronization. If you do not want new OUs to be included, you must configure OU filtering using the Synchronization Service Manager. Now, you can achieve the same behavior using Azure AD Connect wizard.

So if with the introduction with version v1.1.524.0 you also unselected the domains as shown below and now you run the wizard and see the domains being selected again, you will need to fix this yourself. The fix is quite easy. Do not selected any of the domains, just expand and re-collapse each of the domains. You will see the checkmark will disappear

Figure 3: Fixing The Default Selection Of The AAD Connect Wizard Of Each AD Domain Being Checked With The Unchecking Of Each AD Domain

–

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/ ###################
————————————————————————————————————————————————————-

(2017-06-28) AAD Connect Versions Prior To v1.1.553.0 Have A Vulnerability That May Affect You

Executive Summary

Microsoft is releasing this security advisory to inform customers that a new version of Azure Active Directory (AD) Connect is available that addresses an Important security vulnerability.

The update addresses a vulnerability that could allow elevation of privilege if Azure AD Connect Password writeback is misconfigured during enablement. An attacker who successfully exploited this vulnerability could reset passwords and gain unauthorized access to arbitrary on-premises AD privileged user accounts.

The issue is addressed in the latest version (1.1.553.0) of Azure AD Connect by not allowing arbitrary password reset to on-premises AD privileged user accounts.

–

Advisory Details

Password writeback is a component of Azure AD Connect. It allows users to configure Azure AD to write passwords back to their on-premises Active Directory. It provides a convenient cloud-based way for users to reset their on-premises passwords wherever they are. For information about password writeback, refer to Password writeback overview.

To enable Password writeback, Azure AD Connect must be granted Reset Password permission over the on-premises AD user accounts. When setting up the permission, an on-premises AD Administrator may have inadvertently granted Azure AD Connect with Reset Password permission over on-premises AD privileged accounts (including Enterprise and Domain Administrator accounts). For information about AD privileged user accounts, refer to Protected Accounts and Groups in Active Directory.

This configuration is not recommended because it allows a malicious Azure AD Administrator to reset the password of an arbitrary on-premises AD user privileged account to a known password value using Password writeback. This in turn allows the malicious Azure AD Administrator to gain privileged access to the customer’s on-premises AD.

See CVE-2017-8613 – Azure AD Connect Elevation of Privilege Vulnerability

–

More Information:

• Microsoft Security Advisory 4033453 – Vulnerability in Azure AD Connect Could Allow Elevation of Privilege

–

If this affects you, update to the newest version of AAD Connect ASAP!

–

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/ ###################
————————————————————————————————————————————————————-

(2017-06-28) Azure AD Connect v1.1.553.0 Has Been Released

Integrating your on-premises directories with Azure AD makes your users more productive by providing a common identity for accessing both cloud and on-premises resources. With this integration users and organizations can take advantage of the following:

• Organizations can provide users with a common hybrid identity across on-premises or cloud-based services leveraging Windows Server Active Directory and then connecting to Azure Active Directory.
• Administrators can provide conditional access based on application resource, device and user identity, network location and multifactor authentication.
• Users can leverage their common identity through accounts in Azure AD to Office 365, Intune, SaaS apps and third-party applications.
• Developers can build applications that leverage the common identity model, integrating applications into Active Directory on-premises or Azure for cloud-based applications

Azure AD Connect makes this integration easy and simplifies the management of your on-premises and cloud identity infrastructure.

–

Download "Microsoft Azure Active Directory Connect"

–

Azure AD Connect: Version Release History

1.1.553.0

Released: 2017 June

–

Prerequisites for Azure AD Connect

–

More information about Azure AD Connect

–

IMPORTANT: There are schema and sync rule changes introduced in this build. Azure AD Connect Synchronization Service will trigger Full Import and Full Sync steps after upgrade. Details of the changes are described below.

–

Fixed issues:

Azure AD Connect sync

• Fixed an issue with Password writeback that allows an Azure AD Administrator to reset the password of an on-premises AD privileged user account. The issue occurs when Azure AD Connect is granted the Reset Password permission over the privileged account. The issue is addressed in this version of Azure AD Connect by not allowing an Azure AD Administrator to reset the password of an arbitrary on-premises AD privileged user account unless the administrator is the owner of that account. For more information, refer to Security Advisory 4033453.
• Fixed an issue related to the msDS-ConsistencyGuid as Source Anchor feature where Azure AD Connect does not writeback to on-premises AD msDS-ConsistencyGuid attribute. The issue occurs when there are multiple on-premises AD forests added to Azure AD Connect and the User identities exist across multiple directories option is selected. When such configuration is used, the resultant synchronization rules do not populate the sourceAnchorBinary attribute in the Metaverse. The sourceAnchorBinary attribute is used as the source attribute for msDS-ConsistencyGuid attribute. As a result, writeback to the ms-DSConsistencyGuid attribute does not occur. To fix the issue, following sync rules have been updated to ensure that the sourceAnchorBinary attribute in the Metaverse is always populated
• In from AD – InetOrgPerson AccountEnabled.xml
• In from AD – InetOrgPerson Common.xml
• In from AD – User AccountEnabled.xml
• In from AD – User Common.xml
• In from AD – User Join SOAInAAD.xm
• Previously, even if the msDS-ConsistencyGuid as Source Anchor feature isn’t enabled, the “Out to AD – User ImmutableId” synchronization rule is still added to Azure AD Connect. The effect is benign and does not cause writeback of msDS-ConsistencyGuid attribute to occur. To avoid confusion, logic has been added to ensure that the sync rule is only added when the feature is enabled
• Fixed an issue that caused password hash synchronization to fail with error event 611. This issue occurs after one or more domain controllers have been removed from on-premises AD. At the end of each password synchronization cycle, the synchronization cookie issued by on-premises AD contains Invocation IDs of the removed domain controllers with USN (Update Sequence Number) value of 0. The Password Synchronization Manager is unable to persist synchronization cookie containing USN value of 0 and fails with error event 611. During the next synchronization cycle, the Password Synchronization Manager reuses the last persisted synchronization cookie that does not contain USN value of 0. This causes the same password changes to be resynchronized. With this fix, the Password Synchronization Manager persists the synchronization cookie correctly
• Previously, even if Automatic Upgrade has been disabled using the Set-ADSyncAutoUpgrade cmdlet, the Automatic Upgrade process continues to check for upgrade periodically, and relies on the downloaded installer to honor disablement. With this fix, the Automatic Upgrade process no longer checks for upgrade periodically. The fix is automatically applied when upgrade installer for this Azure AD Connect version is executed once.

–

AD FS management

• Following URLs are new WS-Federation endpoints introduced by Azure AD to improve resiliency against authentication outage and will be added to on-premises AD FS replying party trust configuration:
• https://ests.login.microsoftonline.com/login.srf
• https://stamp2.login.microsoftonline.com/login.srf
• https://ccs.login.microsoftonline.com/login.srf
• https://ccs-sdf.login.microsoftonline.com/login.srf
• Fixed an issue that caused AD FS to generate incorrect claim value for IssuerID. The issue occurs if there are multiple verified domains in the Azure AD tenant and the domain suffix of the userPrincipalName attribute used to generate the IssuerID claim is at least 3-levels deep (for example, johndoe@us.contoso.com). The issue is resolved by updating the regex used by the claim rules.

–

Known issues:

Azure AD Connect sync:

• There is an issue that affects customers who are using OU-based filtering with Azure AD Connect sync. When you navigate to the Domain and OU Filtering page in the Azure AD Connect wizard, the following behavior is expected:
• If OU-based filtering is enabled, the Sync selected domains and OUs option is selected.
  Otherwise, the Sync all domains and OUs option is selected.
• The issue that arises is that the Sync all domains and OUs option is always selected when you run the Wizard. This occurs even if OU-based filtering was previously configured. Before saving any AAD Connect configuration changes, make sure the Sync selected domains and OUs option is selected and confirm that all OUs that need to synchronize are enabled again. Otherwise, OU-based filtering will be disabled.
• Also explained here, including solution: (2017-06-28) Azure AD Connect Wizard Chooses To Sync All Instead Of Already Selected OUs/Domains

–

New features/Improvements:

Azure AD Connect sync

• Previously, the msDS-ConsistencyGuid as Source Anchor feature was available to new deployments only. Now, it is available to existing deployments. More specifically
• To access the feature, start the Azure AD Connect wizard and choose the Update Source Anchor option.
• This option is only visible to existing deployments that are using objectGuid as sourceAnchor attribute.
• When configuring the option, the wizard validates the state of the msDS-ConsistencyGuid attribute in your on-premises Active Directory. If the attribute isn’t configured on any user object in the directory, the wizard uses the msDS-ConsistencyGuid as the sourceAnchor attribute. If the attribute is configured on one or more user objects in the directory, the wizard concludes the attribute is being used by other applications and is not suitable as sourceAnchor attribute and does not permit the Source Anchor change to proceed. If you are certain that the attribute isn’t used by existing applications, you need to contact Support for information on how to suppress the error.
• Specific to userCertificate attribute on Device objects, Azure AD Connect now looks for certificates values required for Connecting domain-joined devices to Azure AD for Windows 10 experience and filters out the rest before synchronizing to Azure AD. To enable this behavior, the out-of-box sync rule “Out to AAD – Device Join SOAInAD” has been updated.
• Azure AD Connect now supports writeback of Exchange Online cloudPublicDelegates attribute to on-premises AD publicDelegates attribute. This enables the scenario where an Exchange Online mailbox can be granted SendOnBehalfTo rights to users with on-premises Exchange mailbox. To support this feature, a new out-of-box sync rule “Out to AD – User Exchange Hybrid PublicDelegates writeback” has been added. This sync rule is only added to Azure AD Connect when Exchange Hybrid feature is enabled.
• Azure AD Connect now supports synchronizing the altRecipient attribute from Azure AD. To support this change, following out-of-box sync rules have been updated to include the required attribute flow:
• In from AD – User Exchange
• Out to AAD – User ExchangeOnline
• The cloudSOAExchMailbox attribute in the Metaverse indicates whether a given user has Exchange Online mailbox or not. Its definition has been updated to include additional Exchange Online RecipientDisplayTypes as such Equipment and Conference Room mailboxes. To enable this change, the definition of the cloudSOAExchMailbox attribute, which is found under out-of-box sync rule “In from AAD – User Exchange Hybrid”, has been updated
• from:

CBool(IIF(IsNullOrEmpty([cloudMSExchRecipientDisplayType]),NULL,BitAnd([cloudMSExchRecipientDisplayType],&amp;HFF) = 0))

• to:

CBool(
  IIF(IsPresent([cloudMSExchRecipientDisplayType]),(
    IIF([cloudMSExchRecipientDisplayType]=0,True,(
      IIF([cloudMSExchRecipientDisplayType]=2,True,(
        IIF([cloudMSExchRecipientDisplayType]=7,True,(
          IIF([cloudMSExchRecipientDisplayType]=8,True,(
            IIF([cloudMSExchRecipientDisplayType]=10,True,(
              IIF([cloudMSExchRecipientDisplayType]=16,True,(
                IIF([cloudMSExchRecipientDisplayType]=17,True,(
                  IIF([cloudMSExchRecipientDisplayType]=18,True,(
                     IIF([cloudMSExchRecipientDisplayType]=1073741824,True,(
                        IF([cloudMSExchRecipientDisplayType]=1073741840,True,False)))))))))))))))))))),False))

• Added the following set of X509Certificate2-compatible functions for creating synchronization rule expressions to handle certificate values in the userCertificate attribute:
• CertSubject, CertIssuer, CertKeyAlgorithm, CertSubjectNameDN, CertIssuerOid, CertNameInfo, CertSubjectNameOid, CertIssuerDN, IsCert, CertFriendlyName, CertThumbprint, CertExtensionOids, CertFormat, CertNotAfter, CertPublicKeyOid, CertSerialNumber, CertNotBefore, CertPublicKeyParametersOid, CertVersion, CertSignatureAlgorithmOid, Select, CertKeyAlgorithmParams, CertHashString, Where, With
• Following schema changes have been introduced to allow customers to create custom synchronization rules to flow sAMAccountName, domainNetBios, and domainFQDN for Group objects, as well as distinguishedName for User objects:
• Following attributes have been added to MV schema:
• Group: AccountName
• Group: domainNetBios
• Group: domainFQDN
• Person: distinguishedName
• Following attributes have been added to Azure AD Connector schema:
• Group: OnPremisesSamAccountName
• Group: NetBiosName
• Group: DnsDomainName
• User: OnPremisesDistinguishedName
• The ADSyncDomainJoinedComputerSync cmdlet script now has a new optional parameter named AzureEnvironment. The parameter is used to specify which region the corresponding Azure Active Directory tenant is hosted in. Valid values include:
• AzureCloud (default)
• AzureChinaCloud
• AzureGermanyCloud
• USGovernment
• Updated Sync Rule Editor to use Join (instead of Provision) as the default value of link type during sync rule creation.

–

ADFS Management

• Previously, the ADFS Certificate Management feature provided by Azure AD Connect can only be used with ADFS farms managed through Azure AD Connect. Now, you can use the feature with ADFS farms that are not managed using Azure AD Connect.

–

I ran the MSI and upgraded from the previous version without any issues!

–

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/ ###################
————————————————————————————————————————————————————-

(2017-06-23) Adding A Link To The SSPR Page In The ADFS FBA Page

When users use Windows Integrated Authentication against ADFS through their Windows desktop/laptop the users are authenticated based upon the credentials they used to logon with onto that Windows desktop.laptop. If those users needed to reset their password or unlock their account, a link would need to be provided within the logon screen to point to the SSPR page or users would need to use some kind of kiosk PC.

However, when hitting the Forms Based Authentication page within ADFS, it would be nice if you could display a link on that same page if users needed to reset their password or unlock their account when for example on a mobile device. Something similar to the following:

 

Figure 1: A Link To The SSPR Page On The FBA Page

–

If you want to do this, you can use the following steps

[Step 1]

Clone the current active ADFS web theme to a new ADFS web theme

First determine the current web theme

Get-ADFSWebConfig

Clone the current active web theme to a new web theme

New-AdfsWebTheme -Name <New Web Theme Name> -SourceName <Active Web Theme Name>

–

[Step 2]

Export the cloned web theme to a folder on the file system

Export-AdfsWebTheme -Name <New Web Theme Name> -DirectoryPath <Some Folder On The File System>

–

[Step 3]

Edit the file “onload.js” in the folder “<Some Folder On The File System>\Script” and add the following piece of code to the end of the file to show the link to the SSPR page in AAD on the FBA page (NOTE: you can use any other SSPR page if you want, such as the FIM/MIM SSPR page)

// Add link for password reset, if we find the forms authentication element in the page
var formsAuthArea = document.getElementById("formsAuthenticationArea");
if (formsAuthArea) {
    //Create the hyperlink
    var pwdResetLink = document.createElement(‘a’);
    var linkText = document.createTextNode("Click Here For Password Reset Or Account Unlock");
    pwdResetLink.appendChild(linkText);
    pwdResetLink.title = "Click Here For Password Reset Or Account Unlock";
    pwdResetLink.href = "";’>";’>https://passwordreset.microsoftonline.com/?whr=<Your Domain In AAD>";
    pwdResetLink.target = "_blank";
    document.body.appendChild(pwdResetLink);

    //append to the authArea
    var authNArea = document.getElementById("authArea");
    authNArea.appendChild(pwdResetLink);
}

–

[Step 4]

Import the new edited “onload.js” file

Set-AdfsWebTheme -TargetName <New Web Theme Name> -AdditionalFileResource @{Uri=’/adfs/portal/script/onload.js’;path="<Some Folder On The File System>\script\onload.js"}

–

[Step 5]

Activate the new web theme

Set-AdfsWebConfig -ActiveThemeName <New Web Theme Name>

–

Now access an application and make sure to use the FBA page. The FBA page is used when coming from a mobile device on an external network or when not using WIA

–

–

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/ ###################
————————————————————————————————————————————————————-

(2017-06-19) Azure AD Connect Health For Sync To The Rescue

I was playing around with some Azure AD (AAD) features and I required a new synched account in AAD. So I picked one of my existing accounts in the on-premises AD and added the user account to the groups that allowed it to sync to Azure AD, assign it a license for O365, assign a license for EMS and allow it to use SSPR. Instead of waiting for the next sync cycle I decided to force a delta sync within AAD Connect. So far so good. While AAD Connect was synching I decided to prepare some other things.

To my surprise I saw the following error in AAD Connect

Figure 1: Error In AAD Connect About “AttributeValueMustBeUnique”

–

Clicking on [Detail] I saw the following details regarding the error

Figure 2: Error Details In AAD Connect About “AttributeValueMustBeUnique”

–

ERROR = AttributeValueMustBeUnique
Unable to update this object because the following attributes associated with this object have values that may already be associated with another object in your local directory services: [ProxyAddresses SMTP:John.Doe@XXXXX;]. Correct or remove the duplicate values in your local directory. Please refer to http://support.microsoft.com/kb/2647098 for more information on identifying objects with duplicate attribute values.
Tracking Id: xxxxxxxxxxxxxxxxxxxxxxxxxx
ExtraErrorDetails:
[{"Key":"ObjectId","Value":["xxxxxxxxxxxxxxxxxxxxxxxxx"]},{"Key":"ObjectIdInConflict","Value":["yyyyyyyyyyyyyyyyyyyyyy"]},{"Key":"AttributeConflictName","Value":["ProxyAddresses"]},{"Key":"AttributeConflictValues","Value":["SMTP:John.Doe@XXXXX"]}]

–

This is basically saying there is another object in AAD with the same value of "SMTP:John.Doe@XXXXX" in the proxyAddresses attribute

–

Now that was weird because the object with UPN ‘John.Doe@XXXXX’ was never synched to AAD as a user. To be sure I checked if there already was a user with the same UPN and/or proxyAddresses. As I expected there was none. I also knew for sure there was no conflicting object in the on-premises AD. Nevertheless I checked it with ADFIND (instead of PowerShell because hadn’t used for quite some time!). And again as expected there was none! So what the heck is going on!?

–

First I will tell you what was wrong and why, and after that I will guide you through troubleshooting

–

At this point in time I’m always using AAD Connect to sync stuff from AD to AAD. I also have a MIM Infrastructure using the AAD connector that also syncs stuff from AD to AAD and more specifically users, groups and contacts. However I had not used that for quite some time. What I had forgotten was that in the past I synched my mailbox enabled user accounts to AAD (Office 365) as contacts. So almost all on-premises users exist as contacts in AAD.

–

Definition of the issue:

• Somewhere in the past, MIM synched user ‘John.Doe@XXXXX’ as contact to AAD
• Now I wanted to sync user ‘John.Doe@XXXXX’ as user to AAD using AAD Connect

–

The error in figure 2 is misleading as it is telling me to check my on-premises AD to resolve the conflict, but there is NO conflict in my on-premises AD!

Just to be sure I used:

• ADFIND/PowerShell to query for any object with the same UPN value or the same proxyAddress value – Only 1 object was returned which was expected
• IDFIX to check for conflicts – No conflicts found for this object in the on-premises AD – This was expected
• Directory Synchronization Troubleshooter to check for conflicts – No conflicts found for this object in the on-premises AD – This was expected

–

Now it was time to check AAD. It had to be in AAD somewhere, but what was causing it!? I was looking at all troubleshooting capabilities.

–

I found the following blog posts that ONLY focus on user accounts in AAD

• How to fix Attribute Value Must Be Unique “AttributeValueMustBeUnique” error message when trying to sync an object from on-premises Active Directory to Office 365
• Duplicate or invalid attributes prevent directory synchronization in Office 365

–

Looking at the error in figure 2:

• “ObjectId” contains the objectID of the object I was trying to sync to AAD
• “ObjectIdInConflict” contains the objectID of the object already in AAD with which the conflict was being caused

Therefore I needed to query AAD using the objectID in “ObjectIdInConflict”. I decided to use the CMDlets in the MSONLINE module

To look for users in AAD with that same objectID, I executed:

Get-MsolUser -ObjectId <objectid value in “ObjectIdInConflict”>

No result

–

To look for groups in AAD with that same objectID, I executed:

Get-MsolGroup -ObjectId <objectid value in “ObjectIdInConflict”>

No result

–

I suddenly remembered about my MIM infrastructure and what it was synching, so I decided to also execute:

Get-MsolContact -ObjectId <objectid value in “ObjectIdInConflict”>

Bingo! One object was returned! Yeah!

–

Now I do not have many objects. Howeverm if you do have many object, this might take quite some time as unfortunately the MSONLINE module does not have a CMDlet like ‘Get-MsolObject’. However, the AzureAD module does have such a CMDlet that allows you to search across object types, being:

Get-AzureADObjectByObjectId -ObjectIds <objectid value in “ObjectIdInConflict”>

Again, Bingo! One object was returned! Yeah!

–

I also received the following e-mail telling me about the conflict. To be honest, the mail is not really helpful from an informational perspective. It is however from a warning perspective. With the latter I mean it triggers me to go look in Azure AD Connect Health, which will tell me what is wrong and why.

Figure 3: Mail From AAD Telling Me About the Conflict Error

–

Another option for troubleshooting this is Azure AD Connect Health for Sync. Trust me when I say that Azure AD Connect Health tells what is wrong and why. It showed me the sync error including all the specifics around the error in one view. Really really helpful! Let’s have a look at this!

Go to the Azure AD Portal (https://portal.azure.com/) and then go to the Azure AD Connect Health blade. In my case I have Azure AD Connect Health for Sync, ADFS and AD. So should you!. Make it easy on yourself!

Although Azure AD Connect Sync tile so as healthy, to its left, does tell you there is a sync error. Click on that tile.

Figure 4: Azure AD Connect Health In The Azure AD Portal

–

A new window opens with all the sync errors by type. In this case it is about the “Duplicate Attribute” issue. I clicked on that tile

Figure 5: Azure AD Connect Health For Sync With Errors By Type

–

A new window opens with all the sync errors about “Duplicate Attributes”. In my case I had and saw an error about a duplicate value in the proxyAddresses attribute. I clicked on the listed object.

Figure 6: Azure AD Connect Health For Sync With A “Duplicate Attribute” Error For An Object

–

A new window opens with all the details about the “Duplicate Attribute” conflict and the objects involved. At the bottom you can see the conflicting attribute and the conflicting value. Now I know I have to get rid of the contact object to make it possible for the user account in AD to get a corresponding user account in AAD.

Figure 7: Azure AD Connect Health For Sync With “Duplicate Attribute” Error Details

–

BINGO!!!

–

Now my suggestion for this is:

• Make sure to get Azure AD Connect Health up and running
• As soon as you see an error in AAD Connect (figure 1 and 2) or receive the e-mail (figure 3) about it, make sure to read it carefully. At this point in time I would say to go right away to the Azure AD Connect Health blade in the Azure AD Portal and check there what could be wrong. It is very likely it will tell you what is wrong and why!

–

Additional information:

• Identity synchronization and duplicate attribute resiliency
• Troubleshooting Errors during synchronization

–

–

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/ ###################
————————————————————————————————————————————————————-