Jorge's Quest For Knowledge!

About Windows Server, ADDS, ADFS, Azure AD, FIM/MIM & AADSync (Just Like An Addiction, The More You Have, The More You Want To Have!)

(2014-10-24) Enabling IdP Initiated Sign-On In ADFS

Posted by Jorge on 2014-10-24


In ADFS v2.0, ADFS v2.1 and ADFS v3.0 the IdP Initiated Sign On Page can be used by default and you do not need to do anything for it. It just works! However, if you also need to use RelayState, then also have a look at (2014-10-16) Enabling RelayState In ADFS Versions

The URL of the IdP Initiated Sign On Page is: "https://<FQDN Of The Federation Service>/adfs/ls/IdPInitiatedSignOn.aspx"

-

image

Figure 1: The IdP Initiated Sign On Page In ADFS v2.0

-

image

Figure 2: The IdP Initiated Sign On Page In ADFS v3.0

-

image

Figure 3: The IdP Initiated Sign On Page In ADFS v4.0 (BEFORE Enabling It In The ADFS Properties)

-

In the Event Viewer (ADFS Admin Event Log) you will see:

image

Figure 4: Error In The ADFS Admin Event Log About The IdP Initiated Sign On Page

-

Encountered error during federation passive request.

Additional Data

Protocol Name:
 

Relying Party:
 

Exception details:
Microsoft.IdentityServer.Web.IdPInitiatedSignonPageDisabledException: MSIS7012: An error occurred while processing the request. Contact your administrator for details.
   at Microsoft.IdentityServer.Web.Protocols.Saml.IdpInitiatedSignOnRequestSerializer.ReadMessage(WrappedHttpListenerRequest httpRequest)
   at Microsoft.IdentityServer.Web.Protocols.Saml.HttpSamlMessageFactory.CreateMessage(WrappedHttpListenerRequest httpRequest)
   at Microsoft.IdentityServer.Web.Protocols.Saml.SamlContextFactory.CreateProtocolContextFromRequest(WrappedHttpListenerRequest request, ProtocolContext& protocolContext)
   at Microsoft.IdentityServer.Web.Protocols.Saml.SamlProtocolHandler.CreateProtocolContext(WrappedHttpListenerRequest request)
   at Microsoft.IdentityServer.Web.PassiveProtocolListener.GetProtocolHandler(WrappedHttpListenerRequest request, ProtocolContext& protocolContext, PassiveProtocolHandler& protocolHandler)
   at Microsoft.IdentityServer.Web.PassiveProtocolListener.OnGetContext(WrappedHttpListenerContext context)

-

So, in ADFS v4.0 it looks as it by default is disabled! Checking the ADFS properties….

Yep, it is disabled by default in ADFS v4.0!

image

Figure 5: IdP Initiated Sign On Page Configured To Be Disabled In The ADFS Properties (=Default)

-

image

Figure 6: Enabling The IdP Initiated Sign On Page In The ADFS Properties Of ADFS v4.0

-

image

Figure 7: The IdP Initiated Sign On Page In ADFS v4.0 (AFTER Enabling It In The ADFS Properties)

-

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

Posted in Active Directory Federation Services (ADFS), IdP-Initiated | 2 Comments »

(2014-10-20) Configuring A New Identity Store As A Claims Provider In ADFS

Posted by Jorge on 2014-10-20


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 vNext, currently in Technical Preview, 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!

-

At the time of writing, for the passive federation protocols (e.g. SAML, WS-Federation and Oauth) and the active federation protocols (e.g. WS-Trust), ADFS v4.0 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.

I have the following ID Store:

  • Type: ADLDS (LDAP)
  • Server (1): IDSTORE.ADCORP.LAB
  • LDAP Port (1): 5389
  • LDAPS Port (1): 5636
  • Account UserName: SVC_R1_IDSTORE@ADLDSCORP.LAB
  • Account Password: pwd

-

# Import The ADFS PowerShell Module

Import-Module ADFS

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

$idStoreAccountUserName = ‘SVC_R1_IDSTORE@ADLDSCORP.LAB’
$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 IDSTORE.ADCORP.LAB -Port 5636 –SslMode SSL –Credential $idStoreAccountCreds –AuthenticationMethod Basic

# 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)

$mappingUPN = New-AdfsLdapAttributeToClaimMapping –LdapAttribute userPrincipalName –ClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn&quot;
$mappingGivenName = New-AdfsLdapAttributeToClaimMapping –LdapAttribute givenName –ClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname&quot;
$mappingSurname = New-AdfsLdapAttributeToClaimMapping –LdapAttribute sn –ClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname&quot;
$mappingDisplayName = New-AdfsLdapAttributeToClaimMapping –LdapAttribute displayName –ClaimType "http://temp.org/identity/claims/displayName&quot;
$mappingEmployeeID = New-AdfsLdapAttributeToClaimMapping –LdapAttribute employeeID –ClaimType "http://temp.org/identity/claims/employeeID&quot;

# Create The Local Claims Provider Trust  (HRD Through List Of Claims Providers)

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

image

Figure 1a: Creating A Local Claims Provider Based Upon ADLDS In ADFS v4.0 (HRD Will Be Through List Of Claims Providers)

-

REMARK: in this case the yellow error occurs because I did not specify anything for the organizational suffix for this local claims provider

-

# Create The Local Claims Provider Trust (HRD Through UPN Suffix)

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

image

Figure 1b: Creating A Local Claims Provider Based Upon ADLDS In ADFS v4.0 (HRD Will Be Through UPN Suffix)

-

REMARK: in this case the yellow error occurs because I have not enable and also not configured device registration

-

Now let’s try this!

image

Figure 2: Targeting The "Show My Claims App" And Selecting ADFS v4.0 As The Proposed IdP

-

image

Figure 3a: Home Realm Discovery Page In ADFS v4.0 Showing All Configured/Available Identity Providers (Claims Providers)

-

Selecting/clicking "ADLDS-ID-Store", presents the Forms Based Logon Page In ADFS v4.0 (figure 4)

image

Figure 3b1: Home Realm Discovery Page In ADFS v4.0 NOT Showing All Configured/Available Identity Providers (Claims Providers)

-

Selecting/clicking "Other Organization", presents the Home Realm Discovery Page Based Upon UPN Suffixes of organizational accounts

image

Figure 3b2: Home Realm Discovery Page In ADFS v4.0 Based Upon UPN Suffix Of Organizational Accounts

-

image

Figure 4: Forms Based Logon Page To Enter The Credentials Of A User Account In The Configured ID Store

-

image

Figure 5: The List Of Issued Claims To The "Show My Claims" App Based Upon What Was Extracted From The ADLDS ID Store

-

SOME REMARKS: During my tests I also tried to the following setup:

Specifying just 4 attribute-to-claim mappings

$mappingUPN = New-AdfsLdapAttributeToClaimMapping –LdapAttribute userPrincipalName –ClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn&quot;
$mappingGivenName = New-AdfsLdapAttributeToClaimMapping –LdapAttribute givenName –ClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname&quot;
$mappingSurname = New-AdfsLdapAttributeToClaimMapping –LdapAttribute sn –ClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname&quot;
$mappingDisplayName = New-AdfsLdapAttributeToClaimMapping –LdapAttribute displayName –ClaimType "http://temp.org/identity/claims/displayName&quot;
$mappingEmployeeID = New-AdfsLdapAttributeToClaimMapping –LdapAttribute employeeID –ClaimType http://temp.org/identity/claims/employeeID

-

…And then use a file with the content of the Acceptance Transform Rules

File Name: D:\TEMP\ADLDS-ID-Store_AcceptanceTransformRulesFile.txt

Contents:
@RuleName = "Identity Claims – UPN"
c:[Type == "
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn", Issuer == "urn:adlds:idstore"]
=> issue(claim = c);

@RuleName = "Identity Claims – GivenName"
c:[Type == "
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname", Issuer == "urn:adlds:idstore"]
=> issue(claim = c);

@RuleName = "Identity Claims – SurName"
c:[Type == "
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname", Issuer == "urn:adlds:idstore"]
=> issue(claim = c);

@RuleName = "Identity Claims – DisplayName"
c:[Type == "
http://temp.org/identity/claims/displayName", Issuer == "urn:adlds:idstore"]
=> issue(claim = c);

@RuleName = "Identity Claims – EmployeeID"
c:[Type == "
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn", Issuer == "urn:adlds:idstore"]
=> issue(store = "ADLDS ID Store", types = ("
http://temp.org/identity/claims/employeeID"), query = ";employeeID;{0}", param = c.Value);

-

All the claims rules worked, except the last one called "Identity Claims – EmployeeID". The reason for that is that when you specify store = "ADLDS ID Store", ADFS expects to find an attribute store with that name, but for which in this case it is not an attribute but rather an identity store. It is possible to extract identity info from attribute stores when using a local claims provider trust, as long as the attribute store definition exists in ADFS and it actually works!

-

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

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

(2014-10-16) Enabling RelayState In ADFS Versions

Posted by Jorge on 2014-10-16


RelayState is a parameter of the SAML federation protocol that is used to identify the specific target resource the user will access after they are signed in and directed to the relying party’s federation server.

Except for ADFS v1.0 and ADFS v1.1, and starting with ADFS v2.0 (after installing RollUp 2) and higher, the RelayState parameter is supported!

-

Enabling RelayState In ADFS v2.0

REMARK: make sure to have RollUp 2 installed!

  • Navigate to the folder "C:\inetpub\adfs\ls"
  • Open and Edit the file "web.config"
  • Navigate to the section "<microsoft.identityServer.web>"
  • Add the the line/entry: <useRelayStateForIdpInitiatedSignOn enabled="true" />
  • Save the file "web.config"
  • Restart the ADFS service

image

Figure 1: Enabling RelayState In ADFS v2.0

-

Enabling RelayState In ADFS v2.1 (ADFS In W2K12), ADFS v3.0 (ADFS In W2K12R2)

  • Navigate to the folder "C:\Windows\ADFS"
  • Open and Edit the file "Microsoft.IdentityServer.Servicehost.exe.config"
  • Navigate to the section "<microsoft.identityServer.web>"
  • Add the the line/entry: <useRelayStateForIdpInitiatedSignOn enabled="true" />
  • Save the file "Microsoft.IdentityServer.Servicehost.exe.config"
  • Restart the ADFS service

image

Figure 2: Enabling RelayState In ADFS v2.1, ADFS v3.0

-

Enabling RelayState In ADFS vNext

REMARK: Only when the ADFS Farm Level is higher than Win2012R2! (also see: (2014-10-12) Migrating Or Upgrading To A New ADFS Version)

  • Open PowerShell Command Prompt Window
  • Execute: Import-Module ADFS
  • Execute: (Get-AdfsProperties).RelayStateForIdpInitiatedSignOnEnabled
  • Execute: Set-ADFSProperties -EnableRelayStateForIdpInitiatedSignOn $true
  • Execute: (Get-AdfsProperties).RelayStateForIdpInitiatedSignOnEnabled
  • Restart the ADFS service

image

Figure 3: Enabling RelayState In ADFS vNext

-

More information:

-

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

Posted in Active Directory Federation Services (ADFS), IdP-Initiated, RelayState | Leave a Comment »

(2014-10-12) Migrating Or Upgrading To A New ADFS Version

Posted by Jorge on 2014-10-12


Currently at the time of writing the following ADFS versions are available:

  • ADFS v1.0 as a server role in Windows Server 2003 R2
  • ADFS v1.1 as a server role in Windows Server 2008
  • ADFS v1.1 as a server role in Windows Server 2008 R2
  • ADFS v2.0 as a separate download for both Windows Server 2008 and Windows Server 2008 R2
  • ADFS v2.1 as a server role in Windows Server 2012
  • ADFS v3.0 as a server role in Windows Server 2012 R2
  • ADFS v4.0 (?) as a server role in Windows Server vNext

-

With regards to the terms used here I mean the following with:

  • Upgrading: adding an new ADFS STS to an existing ADFS farm. This is only possible if the "old" version can interoperate with the "new" version at farm level
  • Migration: exporting all configuration from the existing ADFS farm and importing it into a new ADFS farm. This is always possible, either manually or (semi-) automated

-

Both ADFS v1.0 and ADFS v1.1 are almost the same, so upgrading from ADFS v1.0 to ADFS v1.1 is possible.

-

When comparing ADFS v1.x with any ADFS version starting from ADFS v2.0 you will understand, they are far from the same/similar. Therefore the only way is to migrate, and you will have to do everything manually.

-

Both ADFS v2.0 and ADFS v2.1 are almost the same, so upgrading from ADFS v2.0 to ADFS v2.1 is possible. While having an existing farm consisting of only ADFS v2.0 STS servers, you can add ADFS v2.1 STS servers to that farm and remove the ADFS v2.0 STS servers. Be sure to check for any custom code that you implemented and see if it still works. One thing is certain and that is you will have to recompile any DLL used by any custom attribute with the correct .NET version.

-

Although ADFS v2.x looks very similar to ADFS v3.0 and ADFS v4.0, under the hood they are quite different. Because of that, it is NOT possible to upgrade from ADFS v2.x to ADFS v3.0 or ADFS v4.0. The only way is to migrate everything. Be sure to check for any custom code that you implemented and see if it still works or if it needs to be implemented differently. One thing is certain and that is you will have to recompile any DLL used by any custom attribute with the correct .NET version.

For more information about this have a look at the info through the following links:

The links above provide information when migrating from ADFS v2.x to ADFS v3.0. That information also applies when migrating from ADFS v2.x to ADFS v4.0. However, you need to take some subtle differences into account.

For example:

  • Enabling RelayState in ADFS v2.0 is done by editing the file "C:\inetpub\adfs\ls\web.config"
  • Enabling RelayState in ADFS v2.1 and ADFS v3.0 is done by editing the file "C:\Windows\ADFS\Microsoft.IdentityServer.Servicehost.exe.config"
  • Enabling RelayState in ADFS v4.0 done by configuring an ADFS property

REMARK: Regarding enabling RelayState in ADFS, see: (2014-10-16) Enabling RelayState In ADFS Versions

What I’m trying to say is that in ADFS v2.x and ADFS v3.0, some configuration needed to take place in configuration files and many of those configuration have moved to become ADFS properties. So when migrating from ADFS v2.x to ADFS v4.0 and you are using the guide above, check if a property in a configuration file in ADFS v2.x has become a property in ADFS v4.0

-

Although ADFS v4.0 contains some interesting enhancements (see: (2014-10-03) ADFS In vNext To Support Other Identity Stores Than AD Only), compared to ADFS v3.0, both ADFS v3.0 and ADFS v4.0 are almost the same, so upgrading from ADFS v3.0 to ADFS v4.0 is possible. While having an existing farm consisting of only ADFS v3.0 STS servers, you can add ADFS v4.0 STS servers to that farm and remove the ADFS v3.0 STS servers. Be sure to check for any custom code that you implemented and see if it still works. One thing is certain and that is you will have to recompile any DLL used by any custom attribute with the correct .NET version. Now when looking at the enhancements in ADFS v4.0 how is it possible to have those and still interoperate between ADFS v3.0 and ADFS v4.0 in the same farm, while ADFS v3.0 does not support those enhancements? That’s where an ADFS farm enters the world of functional levels. Yes, you are reading it right.  ADFS v4.0 introduces the so called Farm Behavior/Level. When mixing ADFS v3.0 and ADFS v4.0 in the same ADFS farm, any ADFS v4.0 STS will tell you the following about the farm.

image

Figure 1: Viewing The Farm Behavior/Level Through An ADFS v4.0 STS When Upgrading From ADFS v3.0 To ADFS v4.0

-

So, how can you change the farm level? Well, first introduce at least one ADFS v4.0 STS server into the existing ADFS farm. When using WID configure the new ADFS v4.0 STS to become the primary farm member. Follow the steps as mentioned in (2014-03-19) Gathering Architectural Details From Your ADFS Infrastructure – WID Primary Computer Or Not. When using SQL, no need to transfer the primary member role as that only exist when using WID. Now introduce as many ADFS v4.0 STS members as needed. Make sure have implemented all certificates with private keys in the certificate store, and all (recompiled) attribute store DLLs on every new ADFS v4.0 STS member. After doing that get rid of the old ADFS v3.0 members.

image

Figure 2: ADFS MMC On An ADFS v4.0 STS Before The Increased Of the Farm Behavior/Level (The Same As The ADFS MMC On An ADFS v3.0 STS)

-

Now at this point in time you can increase the farm behavior/level. To do that, make sure that every ADFS v4.0 STS farm member has Remote Management enabled, which is enabled by default. That can be done on every ADFS v4.0 STS farm member through Server Manager or by executing the following command line: quickconfig winrm

# Import The ADFS PowerShell Module Import-Module ADFS # Get The Current Farm Behavior/Level (Get-ADFSProperties).CurrentFarmBehavior # Define The Admin Credentials For ADFS When Connecting $adfsAdminUserName = '<DOMAIN\ADFSADMINACCOUNT>' $adfsAdminPassword = '<ADFSADMINACCOUNTPASSWORD>' | ConvertTo-SecureString -asPlainText -Force $adfsAdminCreds = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $adfsAdminUserName,$adfsAdminPassword # Increase The Farm Behavior/Level Invoke-AdfsFarmBehaviorLevelRaise -Member <Comma-Separated list of the FQDN of each farm member> -Credential $adfsAdminCreds # Get The New Farm Behavior/Level (Get-ADFSProperties).CurrentFarmBehavior

 

-

image

Figure 3: Increasing The ADFS Farm Level

-

As you can see the Farm Behavior/Level was increased to "Threshold", whatever that may mean!

During the Farm Behavior/Level increase a new database "AdfsConfigurationV2" is created, using the old database "AdfsConfiguration" as input. After the upgrade the old database is not removed. On every farm member the connection string is adjusted to point to the new database.

image

Figure 4: Increasing Farm Behavior/Level Results In New Configuration Database "AdfsConfigurationV2"

-

REMARK: Remember that currently you may have features enabled that can only be enabled after the Farm Behavior/Level increase!

REMARK: I have not tested this, but one thing to keep in mind, AFTER the Farm Behavior/Level when performing an upgrade, is that any new ADFS STS member most likely needs to be configured through PowerShell as you need to specify a custom connection string for SQL.

image

Figure 5: ADFS MMC On An ADFS v4.0 STS After The Increased Of the Farm Behavior/Level (Also Applies When Installing A Brand New ADFS Farm)

-

image

Figure 6: Viewing The Farm Behavior/Level Through An ADFS v4.0 STS When Installing A New Farm

-

Cheers,

Jorge

———————————————————————————————

* This posting is provided "AS IS" with no warranties and confers no rights!

* Always evaluate/test yourself before using/implementing this!

* DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/

———————————————————————————————

############### Jorge’s Quest For Knowledge #############

######### http://JorgeQuestForKnowledge.wordpress.com/ ########

———————————————————————————————

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

(2014-10-08) Setting Up Yammer DirSync

Posted by Jorge on 2014-10-08


If you are using Yammer somehow and you really care about provisioning, but also about deprovisioning, you need to implement some kind of directory synchronization between your on-premises AD and the YAMMER.COM cloud system. Now, the next question is: "how can you do that?".

If you already are using Azure AD/Office 365, you may already be using some directory synchronization tool such as the Directory Synchronization Tool (DirSync), Azure Active Directory Sync Services (ADDSync) or even Forefront Identity Manager (FIM) to provision and deprovision Azure AD/Office 365 accounts that can be used in Exchange Online, Lync Online and Sharepoint Online. So would you be able to use Azure AD/Office 365 accounts in Yammer? Well, no. If you have linked your Yammer tenant to your Azure AD/Office 365 tenant, then every Office 365 account automatically gets a Yammer license and with that Office 365 is able to map existing Office 365 accounts to existing Yammer accounts/ Nothing more, nothing less. So, how can you get directory synchronization between your on-premises AD and Yammer? You will have to implement the Yammer Directory Sync Service (DSync) to provision and deprovision (suspend) accounts into/from Yammer.

So, if you are using Office 365 and Yammer, you need to implement 2 different directory synchronization products, one for Azure AD/Office 365 and one for Yammer. Now keep in mind that when you use DSync to enable directory synchronization, you can see in Yammer (Admin –> User Management –> Directory Integration) you have done so when you see the following:

image

Figure 1: Directory Sync Being Enabled In Yammer

-

When using DSync you can also configure an e-mail invitation for new users when these are added to Yammer through DSync as you can see below.

image

Figure 2: E-mail Invitation

-

Now remember that when you are using Office 365 (Exchange Online) and Yammer at the same time, where a user’s mailbox is in Office 365, make sure to provision the mailbox first before provisioning the Yammer account so that you are certain the Yammer e-mail invitation reaches the user!

-

More info about directory synchronization between your on-premises AD and Azure AD/Office 365 or Yammer can be found through the following links:

-

Now, let’s install Yammer DSync. The Yammer Directory Sync tool should be installed on a Windows Server that is on the internal network, and not in the DMZ network. The Yammer Directory Sync tool requires an outbound connection to YAMMER.COM and an inbound connection from every AD forest for which you need to synchronize identities from. Keeping that in mind, you therefore need to setup a Yammer service account and an AD service account for every connected AD forest. You also need to make sure the required ports are open. See the documentation and blog posts above to get that info.

-

Double-click the latest Yammer DSync MSI. By default the install folder on a x64 server is: "C:\Program Files (x86)\Yammer\Directory Sync\"

image

Figure 3: Yammer Installation Folder

-

Right after the installation finishes you will see the following screen. At the top enter the Yammer service account credentials and configure the proxy settings as needed. Either use a direct outbound connection or use an authenticated or unauthenticated proxied connection. After doing that, the [Login] button becomes available and you should click to validate the Yammer credentials and access to the Yammer network.

image

Figure 4: Yammer Directory Sync Setup – Yammer Settings

-

If you get to the next screen, that means the Yammer service account credentials and the proxy settings are correct. This will allow you to setup the connection to the first AD forest. As a hostname either provide the FQDN of a DC or the FQDN of the AD domain. If you choose the FQDN of a DC, you are fully depended on that single DC. If you choose the FQDN of the AD domain, by default all RWDCs in the AD domain are a source candidate for the Yammer Directory Sync tool. This will not be the case if you have configured branch RWDCs not to register that mnemonic (the host record for the AD domain for non-SRV aware clients) (also see: (2011-09-11) Service (SRV) Locator Records Registered By Windows Domain Controllers). In general only central RWDCs should register that mnemonic (the host record for the AD domain for non-SRV aware clients). For the connection service account, you can either use the so called "service user", which is the user account of the "Yammer Directory Sync v3.0" service (by default "Network Service") or you can use a custom AD service user account. After doing that, the [Login] button becomes available and you should click to validate the AD credentials for that AD domain/forest.

To be able to connect to a DC, you need at least the ports TCP:389 (LDAP) and TCP:3268 (GC) to be opened between the DirSync server and the targeted DC. To make the connection faster, you would also need to open in addition TCP:88 (Kerberos).

image

Figure 5: AD Connection Settings For The First AD Domain/Forest

-

If you get to the next screen, that means the hostname and AD credentials are correct. You will now have the possibility to add connections for other AD domains/forests.

image

Figure 6: One AD Domain/Forest Added – The Possibility To Connect Additional AD Domains/Forests

-

In this case I wanted to add an additional AD domain/forest as you can see below. The same logic applies as when providing connection settings for the first AD domain/forest. After doing that, the [Login] button becomes available and you should click to validate the AD credentials for that AD domain/forest.

image

Figure 7: AD Connection Settings For An Additional AD Domain/Forest

-

If you get to the next screen, that means the hostname and AD credentials are correct. You will now have the possibility to add connections for other AD domains/forests.

image

Figure 8: Two AD Domain/Forest Added – The Possibility To Connect Additional AD Domains/Forests

-

When done of adding AD domains/forest, click the [Validate] button on the left and you will get to the next screen.

image

Figure 9: Starting Validation – Importing Data From The Connected AD Domains/Forests

-

If you would continue by clicking the [Start Validation] button the Yammer Directory Sync tool will import ALL USERS from all configured AD domains/forests. If you want to scope specific OUs only you should stop the Yammer Directory Sync setup by clicking the red cross in the upper right corner. Even if you do not want to scope users at OU level, you must still stop the Yammer Directory Sync setup by clicking the red cross in the upper right corner as otherwise, you might go nuts in the trying to start synchronization in a later stage. Therefore, now stop the Yammer Directory Sync setup.

-

The Yammer Directory Sync configuration by default is stored in the folder "C:\ProgramData\Yammer\DirSync". You can also find that out yourself by right-clicking the Yammer icon in the tray area and selecting "About".

image

Figure 10: Accessing The Yammer Advanced Configuration

-

Now click on the [Advanced Configuration] button.

image

Figure 11: Accessing The Yammer Advanced Configuration

-

This will open the folder "C:\ProgramData\Yammer\DirSync" where the Yammer Directory Sync configuration is stored, including log files. The file "globalsettings.config.json" holds the complete Yammer Directory Sync configuration.

For the ADCORP.LAB AD domain/forest I just specified the source OU

image

Figure 12: Specifying A Source OU For The ADCORP.LAB AD Domain/Forest

-

For the PARTNER.LAN AD domain/forest I just specified the source OU

image

Figure 13: Specifying A Source OU For The PARTNER.LAN AD Domain/Forest

-

If you need to modify the filter, or specify additional OUs, check the Yammer Directory Sync Advanced Configuration Guide first.

-

Now in the file "globalsettings.config.json" search for (without the quotes) "EmailNotificationSettings" . By default you will find the following.

image

Figure 14: Default E-mail Notification Settings

-

As you can see the default "FromAddress" may not match the from address you want/need to use. If your e-mail system only accepts authentication from accounts with valid mailboxes, you cannot use the default "FromAddress". To be able to send mails/notification you need to change the "FromAddress". Now change it to a value that will be accepted by your e-mail system and save the file "globalsettings.config.json".

You can also find that out yourself by right-clicking the Yammer icon in the tray area and selecting "Open".

image

Figure 15: Re-opening The Yammer Directory Sync Setup

-

When everything is correct you will right away to the validation page.

image

Figure 16: Starting Validation – Importing Data From The Connected AD Domains/Forests

-

Click the [Start Validation] button and you will see something similar too:

image

Figure 17: Validation Result Of The Yammer Directory Sync Tool

-

When the validation is done you can click the [Sync] button on the left and you will get to the next screen. The following e-mail settings are used when the Yammer Directory Sync tool encounters issues.

image

Figure 18: Configuring The E-mail Settings

-

In the server field enter the SMTP server of your e-mail system. If you are using Office 365, then enter "smtp.office365.com".

In the port field enter the SMTP port of your e-mail system. If you are using Office 365, then enter "587".

If your e-mail system requires SSL, then check it.

Enter the credentials (username and password) of the account to connect to the e-mail system.

Enter the e-mail address of one or more recipients eligible to receive test notifications.

As a final test, click the [Send Test Email] button.

If everything is OK, then you will the following:

image

Figure 19: Successful Configuration Of The E-mail Settings

-

Now click the [Apply] button and you will see something similar to:

image

Figure 20: Enabling The Yammer Directory Sync

-

Finish it by clicking the [Enable Sync] button and you will something similar to:

image

Figure 21: Finished Configuration Of The Yammer Directory Sync Tool

-

Close the window by clicking the red cross in the upper right corner. You’re done!

-

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

Posted in DirSync, Yammer | Leave a Comment »

(2014-10-05) Presenting @ Experts Live 2014

Posted by Jorge on 2014-10-05


I’m going to present a session (in Dutch) about certificates in ADFS @ the Experts Live 2014 Conference on November 18th. The conference agenda can be found through the following link: http://www.expertslive.nl/index.php/programma/

-

DUTCH:

Sessie Titel: ADFS en Certificaten – Het is meer dan techniek alleen!

Sessie Abstract: Een ADFS infrastructuur is zeer afhankelijk van certificaten. De stabiliteit van een dergelijke infrastructuur staat of valt dus met de werking van de benodigde certificaten. Bij het ontsluiten van applicaties lokaal of in de cloud, is ADFS vaak niet het doel zelf, maar juist een middel om een ander hoger doel te bereiken. Wanneer de certificaten in ADFS niet de juiste aandacht krijgen, gaat het mogelijk na 1 of 2 jaar na de implementatie van ADFS behoorlijk mis. Bent u er op voorbereid om vooral de impact zo laag mogelijk te houden? In deze sessie zullen we alle ins en out tevoorschijn halen v.w.b. certificaten in ADFS.

-

ENGLISH:

Session Title: ADFS and Certificates – It is more than technology only!

Session Abstract: An ADFS infrastructure is very dependent on the use of certificates. The stability of such an infrastructure stands or falls with the operation of the required certificates. When connecting applications locally or in the cloud , ADFS itself is often not the goal itself, but rather a mean to achieve a higher goal. When the certificates in ADFS do not get the right attention, it is possible that after 1 or 2 years after the implementation of ADFS things go quite wrong. Are you prepared to keep the impact as low as possible? In this session , we’ll talk about all the ins and outs with regards to certificates in ADFS.

-

Cheers,

Jorge

———————————————————————————————

* This posting is provided "AS IS" with no warranties and confers no rights!

* Always evaluate/test yourself before using/implementing this!

* DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/

———————————————————————————————

############### Jorge’s Quest For Knowledge #############

######### http://JorgeQuestForKnowledge.wordpress.com/ ########

———————————————————————————————

Posted in Conferences | Leave a Comment »

(2014-10-03) ADFS In vNext To Support Other Identity Stores Than AD Only

Posted by Jorge on 2014-10-03


Taken from: http://technet.microsoft.com/en-US/library/hh831502.aspx#BKMK_preview

-

For the Windows Server Technical Preview, the AD FS server role includes the same functionality and feature set that is available in Windows Server 2012 and Windows Server 2012 R2. It also includes new features that enable you to configure AD FS to authenticate users stored in non-AD directories, such as X.500 compliant Lightweight Directory Access Protocol (LDAP) directories and SQL databases. In many organizations, identity management solutions consist of a combination of Active Directory, AD LDS and third-party LDAP directories, as well as SQL databases. With the AD FS support of the non-AD identity stores, you can benefit from the entire enterprise-ready AD FS feature set regardless of where your user identities are stored

-

YES!, YES!, YES!, YES!, YES!, YES!, YES!, YES!, YES!, YES!. F-I-N-A-L-L-Y !!!

-

For more information, see Configure AD FS to authenticate users stored in LDAP directories.

-

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

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

(2014-10-01) TroubleShooting Federation/SSO To Windows Azure AD And Office 365

Posted by Jorge on 2014-10-01


When setting up DirSync And Federation between your on-premise AD and Windows Azure AD to support identity sync and SSO, the most important attribute to make sure everything works are the immutableID and the userPrincipalName.

-

Paul Williams from msresource.net has written a great number of blog posts about this, touching all kinds of related stuff. See the following blog posts:

-

With regards to the implementation I used the string version of the objectGUID (AD) as the immutableID (sourceAnchor in AAD)) and the UPN as the userPrincipalName (AAD). I achieved that by leveraging FIM with the AAD connector. Because of that I also had to implement slighty different claims rules in ADFS for Azure AD/Office 365. The rules in my ADFS v2.0 looked like:

@RuleName = "Identity Claims – objectGUID (Base64) To objectGUID (String)"
c:[Type == "
http://temp.org/identity/claims/adObjectGuidBase64org"]
=> add(store = "String Processing Store", types = ("http://temp.org/identity/claims/adObjectGuidString"), query = "fromBase64GuidtoStringGuid", param = c.Value);

@RuleName = "Identity Claims – upn To UPN"
c:[Type == "
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"]
=> issue(Type = "http://schemas.xmlsoap.org/claims/UPN", Value = c.Value);

@RuleName = "Identity Claims – objectGUID (String) To ImmutableID"
c:[Type == "
http://temp.org/identity/claims/adObjectGuidString"]
=> issue(Type = "http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType);

@RuleName = "Identity Claims – ImmutableID To Name ID"
c:[Type == "
http://schemas.xmlsoap.org/claims/UPN"]
=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Value = c.Value, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified");

-

I swear everything was working, until some day I started to get the following errors:

….when navigating to: https://outlook.office365.com/owa/

image

Figure 1: Error When Using Federated Logon And Navigating To Office 365 Portal

-

….when navigating to: https://manage.windowsazure.com/default.aspx

image

Figure 2: Error When Using Federated Logon And Navigating To Azure AD Management Portal

-

….when navigating to: https://portal.office.com/

image

Figure 3: Error When Using Federated Logon And Navigating To Office 365 Management Portal

-

By giving the correlation ID to someone at Microsoft that is able to check it in the system logs, they most likely will be able to tell you what would be wrong. In this case unfortunately I as not able to do that. The logs on my system did not given me any clue!

As I have another ADFS v3.0 system in my environment, I therefore decided to configure that ADFS instance with all default values for DirSync and federation. After configuring all this, I was able to access Azure AD and Office 365 through federated logon on my ADFS v3.0 box, but still not on my ADFS v2.0.

-

After comparing the federation trusts between  ADFS v2.0 and Azure AD, and between ADFS v3.0 and Azure AD I saw the following difference:

image

Figure 4: Signature Hash Algorithm On The RP Trust On ADFS v3.0 For Azure AD/Office 365 (Default Config) – WORKING

-

image

Figure 5: Signature Hash Algorithm On The RP Trust On ADFS v2.0 For Azure AD/Office 365 (Custom Config) – NOT WORKING

-

For whatever reason, in the past I had changed the signature hash algorithm on the RP Trust On ADFS v2.0 For Azure AD/Office 365 AND I had forgotten about it. It took me some time to find this one, but by just changing the signature hash algorithm on the RP Trust On ADFS v2.0 For Azure AD/Office 365 from SHA-256 to SHA-1, everything started to work again! Yiiihhaaaaaa!

-

PS: this has NOTHING to do between the usage of ADFS v2.0 and ADFS v3.0. This was a configuration mistaken I made when playing around in the test/demo environment

-

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

Posted in Active Directory Federation Services (ADFS), Azure AD Sync, DirSync, DirSync, Federation Trusts, Office 365, SSO, Transform Rules, Windows Azure Active Directory | Leave a Comment »

(2014-09-29) Default Claims Rules In ADFS To Support SSO Through Federation With Azure AD/Office 365

Posted by Jorge on 2014-09-29


Just for reference I posting the default claims rules in ADFS to support SSO through federation with Azure AD/Office 365.

@RuleName = "Identity Claims – Windows Account Name To UPN, ImmitableID"
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"]
=> issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/claims/UPN","http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"), query = "samAccountName={0};userPrincipalName,objectGUID;{1}", param = regexreplace(c.Value, "(?<domain>[^\\]+)\\(?<user>.+)", "${user}"), param = c.Value);

@RuleName = "Identity Claims – ImmitableID To Name ID"
c:[Type == "http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"]
=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Value = c.Value, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified");

-

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

Posted in Active Directory Federation Services (ADFS), Azure AD / Office 365, Transform Rules | Leave a Comment »

 
%d bloggers like this: