Configure Single Sign-On for Microsoft ADFS¶

Before configuring ADFS¶

Register your Windows Server as a member of the existing domain.
Log in to the ADFS server as a domain administrator.
Ensure that the ADFS server has a valid certificate meant for it (ADFS).

Step 1: Install the ADFS role¶

Open Server Manager >> Manage >> Add Roles and Features.
On the Before You Begin page, click Next.
On the Select Installation Type page, select role-based or feature-based installation, and then click Next.
On the Select Destination Server page, click Select a Server from the Server Pool and click Next.
On the Select Server Roles page, select Active Directory Federation Services and click Next.
On the confirmation page, click Install. The wizard displays the installation progress.
Wait until the installation gets completed.

Step 2: Configure the Federation Server¶

Once the ADFS role is installed, click Configure the federation service on this server link.
On the Welcome page, select Create the first federation server in a federation server farm and click Next.
On the Connect to Active Directory Domain Services page, specify an account with domain administrator rights for the Active Directory domain that this system is connected to, and then click Next.
On the Specify Service Properties page, enter the following details before clicking Next:
- Select the SSL certificate. The Federation Service Name will be automatically populated.
- Enter a display name for Federation Service Display Name.
On the Specify Service Account page, select Use an existing domain user account or Group Managed Service Account and click Next.
On the Specify Configuration Database page, select Create a database on this server using Windows Internal Database and click Next.
On the Pre-requisite Checks page, verify if all prerequisite checks have been successfully completed and then click Configure.
Review the results and check whether the configuration has been completed successfully on the Results page.

Step 3: Configure ADFS to integrate with Securden¶

Open Server Manager >> Tools >> ADFS Management.
Expand to Relying Party Trusts and click Add Relying Party Trust.
On the Add Relying Party Trusts wizard, click Start.
Launch Securden web interface (https://:5454/), navigate to Admin >> Integrations >> SAML SSO and download the metadata file - securden_metadata.xml.
Go back to Add Relying Party Trusts wizard. Under Select Data Source, select Import data about the relying party from a file. Browse and select the securden_metadata.xml, which you downloaded from Securden and click Next.
In the Specify Display Name field, enter Securden and then click Next.
Choose I don't want to configure multifactor authentication settings for this relying party trust at this time and then click Next.
Choose Permit all users to access this relying party.
Go through the subsequent pages by clicking Next until you reach the Finish screen.
Choose to open the Edit Claim Rules dialog before clicking Finish. This will launch the Edit Claim Rules window.
On the Issuance Transform Rules tab, click Add Rule.
Under Select Rule Template, set Transform an incoming claim as the rule template and click Next.
Choose Windows account name in Incoming Claim Type and Name ID in Outgoing Claim Type and then click Finish. Apply the claim rules in Issuance Transform Rules tab.
Navigate to Endpoints >> MetaData Group. Select the entry with type Federation MetaData.
Open a web browser and access the following URL path as in the entry
```
https://ADFS-Server-Name/URL-Path 
```
Example: (https://SEC-2K12.SECURDEN.LOCAL/FederationMetaData/2007-06/FederationMetaData.xml)
Launch Securden web client. Navigate to Admin >> Integrations >> SAML SSO. Enable SAML SSO and then upload the federation metadata.

Troubleshooting Tips:¶

Issue - I have integrated with a SAML-compatible federal identity management solution but got an invalid user response when SSO feature was used. How to resolve this issue?

Steps to follow:

The username format could be the cause of this issue. For authentication, we validate the value against the Username in Securden.

When you import users from AD, Securden maintains the username as DomainName\username. (When you add users locally instead of importing from AD, it will be just the username alone).

So, on the SSO configuration page, if you change the Custom Rule for Securden Login as below, the issue might be resolved:

stringAppend('DOMAINNAME\', loginname)

Example: stringAppend('SECURDENDEV\', loginname)

In addition, there might be an email mismatch with username.

If an email is received from SSO, the domain name has to be trimmed from the value:

stringAppend('DOMAINNAME\', substringBefore(loginname, '@'))

For extracting username from email:

substringBefore(loginname, '@')

If the issue doesn't resolve after the steps above, you may write to support@securden.com.