Partager via

How to setup a federation with Automatic Data Processing, Inc (ADP) using ADFS 2.0

  • Article

Hey all, Rob Greene here again. We have been getting calls recently on how to use ADFS 2.0 to federate with ADP, so today I explain how.

Disclaimer: If you have problems with connecting to ADP, your first call should be to them. If after talking with ADP you need further assistance you then open a case with Microsoft Support. The AskDS blog cannot troubleshoot connectivity between ADP and ADFS; it requires data and access to your network. This post is a friendly attempt to save you from contacting the support lines as your first option.

Note: The information given is from working with customers setting up a federated trust with ADP and as of this writing it is accurate. This post is not going to discuss how to install ADFS 2.0 or discuss any design decisions around ADFS. If you need this type of information, please visit here.

You need two certificates from a Public Certification Authority (not your internal CA).

  • Use with the Service Communications Certificate
  • Use for Token-Signing Certificate

You could use one certificate for both purposes; however, the best practice is to use two different certificates, in case one of them is compromised. Once you get the certificates issued, you can review the following WIKI content on the steps that are required so that AD FS 2.0 uses these new certificates.

The next step is to contact ADP. They need the public certificate for your Token-Signing certificate. Follow the below steps to export the public certificate on the ADFS Server:

  1. Click on the "Start" button, the select "Run".
  2. Type:  "MMC".
  3. Click on the menu options:  "File" then select "Add/Remove Snap-in...".
  4. Select "Certificates" then click the "Add" button.
  5. The Certificate Snap-in Wizard starts. 
  6. Select "Computer account" and click the "Next" button.
  7. Select "Local computer:  (the computer this console is running on)" then click the "Finish" button.
  8. Click the "OK" button.
  9. Expand Console Root\Certificates (Local Computer)\Personal\Certificates.
  10. Select the certificate in question.
  11. Right click on it, and select "All Tasks", and then click on "Export".
  12. Click the Next button.
  13. Select “No, do not export the private key” and click the Next button.
  14. Select “Base-64 encoded x.509(.CER)” and click the Next button.
  15. Type in a file path and name then click the Next button.
  16. Click the Finish button.
  17. In the dialog box “The export was successful.” click the OK button.

Configuring Relying Party Trust information:

ADP uses RelayState information to direct users to their different applications but ADFS 2.0 does not support that protocol binding. Let ADP know that you are using ADFS, and they will modify some settings on their end to get things working.

Now let’s get to the actual configuration steps.

  1. Open AD FS 2.0 Management snapin.

  2. Navigate to: AD FS 2.0\Trust Relationships\Relying Party Trusts

  3. Right click on the “Relying Party Trusts” container and select “Add Relying Party Trust”

  4. The “Add Relying Part Trust” wizard starts, click the Start button.

  5. Since ADP does not provide metadata information, you will need to select “Enter data about the relying party manually”, and click the Next button.

  6. For Display name, you can type what you would like here. For example: ADP Trust

  7. Click the Next button.

  8. Select “AD FS 2.0 profile” and click the Next button.

  9. The Relying Party Trust configuration to ADP does not require a Token Encryption certificate (although I hear that they will give you one if you ask.).

  10. Click the Next button.

  11. Check “Enable support for SAML 2.0 Web SSO protocol”

  12. For the Relying party SAML 2.0 SSO service URL you will type in the Service Provider (SP) URLs. Currently this is: https://fed-stag.adp.com/affwebservices/public/saml2assertionconsumer (when testing) or https://fed.adp.com/affwebservices/public/saml2assertionconsumer (when production).

    image

  13. Click the Next button.

  14. In the Relying party trust identifier the ADP SAML endpoint needs to be typed in here. When looking at the ADP Federation Integration Guide.pdf (provided by ADP) this refers to the Audience Attribute, currently this is: https://fed.adp.com

    image

  15. Click the Add button.

  16. Click the Next button.

  17. Select “Permit all users to access this relying party” and click the Next button.

  18. You can review the configuration on this screen. Once you are satisfied with the information click the Next button.

  19. Click the Close button.

You should now see a dialog box to add Claim rules to the “ADP Trust” relying party that we just configured. There are two claims that need configuration before sending to ADP: PersonImmutableID, and NameID. The next steps show you how to configure them. Please keep in mind that with any federation configuration, case sensitivity is critical. Please make sure to use the matching case when configuring the claim names.

Configuring PersonImmutableID claim:

  1. In the ADP Trust Claim rules click the Add button.

  2. Select “Send LDAP attributes as Claims” and click the Next button.

  3. The Claim rule name can be anything. We will type in: Send EmployeeID as PersonImmutableID

  4. For the “Attribute store” drop down and select “Active Directory”.

  5. In “LDAP Attribute” section, drop down and select “Employee-ID”.

  6. In “Outgoing Claim Type” section type in: PersonImmutableID

    image

  7. Click the Finish button.

Configuring NameID claim:

  1. In the ADP Trust Claim rules click the Add button.

  2. Select “Send LDAP attributes as Claims” and click the Next button.

  3. The Claim rule name can be anything. We will type in: Send UPN as NameID

  4. For the “Attribute store” drop down and select “Active Directory”.

  5. In “LDAP Attribute” section, drop down and select “User-Principal-Name”.

  6. In “Outgoing Claim Type” section, drop down and select “Name ID”.

    image

  7. Click the Finish button.

  8. Click the OK button on the Claim rule configuration for ADP Trust.

Since we have configured this as a SAML assertion we can use the LoginToRP feature with the IDPIntitiatedSignon page to get the users signed into ADFS and then redirect them to ADP. Here is an example of this assuming that the ADFS server name is adfs.fabrikam.com. The URL would be:

https://adfs.fabrikam.com/adfs/ls/IDPInitiatedSignon.aspx?LoginToRP=https://fed.adp.com

Now you are ready to begin testing connectivity with ADP. I hope this blog helps making federating with ADP a lot easier.

Rob “Fuzzy” Greene