Configuring SAML with ADFS

Configuring SAML with ADFS

Step 1:

Open the ADFS management application

Step 2:

Right-click Relying Party trust and choose Add Relying Party Trust. The Add Relying Party Trust Wizard opens.

Step 3:
Choose Claims Aware and click Start

Step 4:

Choose Enter data about the relying party manually and click Next.

Step 5:
Provide a display name, add notes if any, and click next.

Note: Skip the configure certificate option and click next.

Step 6:
In the configure URL tab, Enable support for the SAML 2.0 Web SSO protocol and enter the assertion consumer URL from the application, and click next.


Step 7:

In the Relying Party Trust identifier, enter the Entity ID of Service Desk Plus and click Add.

Click Next.

Step 8:
Under "Choose Access Control Policy Tab", select Permit Everyone and click next.

Step 9:
Skip the Ready to Add Trust by clicking next and under the Finish tab, click close.

Step 10:

Upon closing the tab, click the edit claim issuance policy.


Step 11:

Add the Rule name and save the rule shown in the below image.


Step 12:
Upon clicking the created relying party trust and click the properties.
The properties window will open.

Step 13:
In the Signature tab, add the certificate file downloaded from Service Desk Plus by clicking Add.


Step 14:

Under the Advanced tab, choose the Algorithm used in ServiceDesk Plus.

Click Apply.

Step 15:
To download IDP certificate---> Go to Services > Certificates and click the Token-signing certificate.

Under the Details tab, click Copy to File. The Certificate Export Wizard opens.




  • Choose DER encoded binary X.509 (.CER) and click Next.




  • Enter the location to save the file and provide the file name at the end of the URL.

  • Click Next. You must upload this certificate in ServiceDesk Plus application to complete the integration.

Login and Log out URL for ADFS:
Login URL: https://yourdomainname/adfs/ls  
Logout URL: https://yourdomainname/adfs/ls?SingleSignOut=SingleSignOut. 


How to Add Additional Attributes in ADFS:

Unlike other IDPs, ADFS has a notably different way of sending claims. ADFS provides a few default claims (that are not sent, but just available for transformation or usage) and among which here are some notable ones:

  • upn (

  • implicitupn (

  • name (SDP-CART\conan)

  • windowsaccountname (SDP-CART\conan)

  • insidecorporatenetwork (true)

  • userip (

So, we can edit the "Claim Issuance Policy" and define a set of rules to transform any of the default claims or send additional claims from "Attribute Stores" like "Active Directory" or from a database.

Until now, we have been using the "Transform an Incoming Claim" rule to send the already available "Windows account name" claim's value (SDP-CART\conan) as the "Name ID" with "Transient" NameID format.

However to send additional claims, we can add either of the following rules to send the required properties.

  • "Send LDAP Attributes as Claims"

  • "Custom Rule"   


Send LDAP Attributes as claims:

ADFS already provides a set of "claim descriptions" in the URI format for a few common attributes (can be viewed from AD FS > Service > Claim Descriptions).  If we take a look at "UPN" field below, the value under "Claim Type" will be sent as the "claim name" and this is the value that needs to be mapped in SDP.

For every other attribute that they need, the users are expected to add new claim descriptions (either in URI format or normal string, say "seating_location" or "" for seating location). These descriptions can then be used in "Send LDAP Attributes as Claims" to send values from AD.

However, this forces the user to create separate claim descriptions for all the additional attributes they require (that does not exist in the default set provided by ADFS), which that may find hard.

However, "Send LDAP Attributes as Claims" also allows us to type the AD attribute name directly in the left side (like "physicalDeliveryOfficeName") and any arbitrary claim name (like "site" or "") on the right, without having to define them under claim descriptions. Using this, we can easily send basic claims as well as claims for the UDFs.

Note: If their ADFS admin wants to maintain the standards and wishes to create claims for all attributes, they can certainly do that (either in URI format or as a normal string) and they can just update the claim description's "claim type" value in SDP.

 Limitations of Send LDAP Attributes: 

  • As we know, we choose AD property on the left and we can type any "string" or type in a name of a "claim description" on the right. Also if we type a string, the string value will be the claim name, and if we type the name of a claim description, then the claim description's "claim type" (see image above) value will be sent as the claim name.

  • So, If we want to send the upn of the user with the claim name as "UPN", we would type "UPN" on the right ride. However, since ADFS already has a claim description with the name "UPN", it will point to this claim description instead of our expected string (called "UPN"), and  eventually, the user's upn value will be sent with claim name as "", instead of the expected string, "UPN".

  • So we cannot use the claim names that are already defined in claim descriptions as "string".

Moreover, if we want to send a constant value (a string literal) for all the users; Say, if we want to send "SDP-TEAM" as the value for "domain", this is not possible with "Send LDAP Attributes".

Custom Rule:

We have one more option to send the claims by using a custom rule. Using an already available claim (windowsaccountname) we can write a rule to query/fetch  an AD attribute given in the "query" and send it's value with claim name as given in "type". The following rule sends the AD attribute "givenName" as "FirstName"; "sn" (surname) attribute as "LastName", etc.

c:[Type == ""]

=> issue(store = "Active Directory", types = ("FirstName", "LastName", "DisplayName", "PhoneNumber", "MobileNumber", "EmailAddress", "EmployeeID", "JobTitle", "DepartmentName", "LoginName"), query = ";givenName,sn,displayName,telephoneNumber,mobile,mail,employeeID,title,department,sAMAccountName;{0}", param = c.Value);


We can provide the above custom rule to the customers for mapping the default fields, and if they have additional fields, they can either create a new custom rule for it or they can use the same rule and add the claim name in "types" and the corresponding AD attribute in the "query" portion. Moreover, custom rules also allow us to send a constant value as a claim like below (in a new rule):

=> issue(Type = "domain", Value = "SDP-CART");


Although custom rules do not provide any UI support, we may say that custom rules should be easier to setup than "Send LDAP Attributes" since this is quite straightforward and does not deal with "claim descriptions".

Note: As mentioned earlier, the customer may still define claim descriptions for all properties and use them in send LDAP Attributes too.
                  New to ADManager Plus?

                    New to ADSelfService Plus?

                      • Related Articles

                      • Configuring SAML with Azure (New)

                        Step 1: Open the Azure Portal--->Enterprise Applications. Step 2: Select the created Enterprise Application and get started with Set up Single Sign-On. Step 3: Edit the basic SAML Configuration. Step 4: Copy the Entity ID from SDPMSP and place the ...
                      • Unable to configure SAML using OneLogin -Uploaded Certificate is Invalid

                        Upon configuring SAML, if you come across the below errors: Uploaded Certificate is Invalid (Happens with .PEM cert generated in OneLogin) failed to update IdP details. Check logs for details Verify the below trace in the Logs: ...
                      • How to configure SAML with Azure AD (Old KB)

                        This guide will help us configure SAML for users who want to use Azure AD as their IdP and also give you insights on a few issues that you might run into while configuring SAML in an Azure Environment. In an ideal environment, customers will have an ...
                      • SAML FAQ's

                        Please find the list of frequently asked queries in SAML 1. I have enabled SAML but still could not find a way to log in using SAML Since the application has multi-tenant feature there are certain security added to the SAML login. In a SAML ...
                      • Page crashed exception thrown while downloading metadata.xml in the SAML configuration page.

                        Applicable only from build10523 Unable to download Metadata.xml from the SAML configuration page? Workaround-1: Please access the following URL to download metadata.xml https://localhost:8523/servlet/SamlMetaServlet?id=<id> Get the id from the ...