locked
simpleSAMLphp and ADFS 2.0 RRS feed

  • Question

  • Hello,

    I'm trying to set up an ADFS connection between two ADFS servers (separate forests) to Moodle through SAML. The current setup is as follows:

    SAML Installation (v1.14.0) > ADFS1 (Server 2008 R2 ADFS 2.0) > ADFS2 (Server 2008 R2 ADFS 2.0)

    I'm able to successfully log into SAML with AD creds from the forest on ADFS1 but not any creds from the forest on ADFS2. I have ADFS2 set up as a Claims Provider on ADFS1, and ADFS1 is set as a Relying Part Trust on ADFS2. The claim rules match between them. For some reason it seems as if SAML is not seeing ADFS2 at all, I checked the event logs on ADFS2 and I'm not seeing any authentication events from the account I'm testing with.

    Our goal is to pass ADFS authentication through a central ADFS server (Acting as a Relying Trust) to SAML.

    My question is where or not this setup is even possible with SAML, and if not what would be the best practice in this scenario?

    Best,
    Adam

    Wednesday, March 30, 2016 3:20 PM

All replies

  • In your case, your SAML doesn't need to know about ADFS2.

    What do you mean by it does not seem to see ADFS2? What are the claims expected by your SAML app?


    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Wednesday, March 30, 2016 3:28 PM
  • Hi Pierre,

    Apologies - by not seeing ADFS2 I was referring to the SAML app not authenticating credentials from the domain forest being federated from ADFS2. When using the Federation Auth Test in SAML the page just refreshes on the log-in prompt. If we try authenticating with invalid credentials from the domain on ADFS1 it will throw an error in the event log on that server, but there are no errors in the event logs of ADFS2.

    Our SAML app is using an LDAP attribute claim for the following fields:

    • User-Principle-Name > UPN
    • SAM-Account-Name > uid
    • E-Mail-Addresses > mail
    • Given-Name > givenName
    • Surname > sn

    It's also using a Transform rule to change UPN claims to Name ID with a Transient ID format. Other than that I'm passing through all claims for mail, Given Name, Surname, and UPN (This may be redundant, I set this up for testing authentication problems we saw early on with ADFS1.)

    Thanks for the assistance!
    -Adam

    Wednesday, March 30, 2016 3:41 PM
  • Well to be exact, your SAML app does not authenticate the use. The IDP does (aka Claim Providers). The application just consumes the token and assumes that the authentication has been perform upstream. Neither the application uses LDAP attributes. It uses claims. Now the IDP might have get the values of those claims from an LDAP directory, but really the application is agnostic of this part.

    So make sure of the following:

    On the Relying party trust on ADFS2, on the issuance transform rules, query all the attributes you need and add them to the token you will issue for ADFS1.

    On the Claim Provider on ADFS1, on the acceptance rules, make sure you "pass through" all the claim you define in the previous steps.

    On the Relying Party trust on ADFS1 (so the SAML app trust), on the issuance transform rules, make sure you also "pass through" the claims on the top of the LDAP queries.

    You can copy/past the issuance transform rules you have on your SAML app trust here, we'll see if there are stuff missing.


    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Wednesday, March 30, 2016 3:48 PM
  • Thanks for the info, Pierre! 

    Here are the changes I've made:

    On the relying party trust of ADFS2, I've made the following in an LDAP Claims template to specify the attributes I need:

    • User-Principle-Name > UPN
    • SAM-Account-Name > uid
    • E-Mail-Addresses > mail
    • Given-Name > givenName
    • Surname > sn

    On ADFS1 in both the Relying Part Trust to SAML and the Claims Provider to ADFS2, I've passed through the following claims.

    • UPN
    • uid
    • mail
    • givenName
    • sn

    Although the login test on SAML does not instantly refresh anymore (it actually "loads" for a few seconds before prompting for login again), it doesn't appear that the token is being passed from ADFS2. I'm still receiving Audit Failure events on ADFS1 for an account on ADFS2's domain forest.

    I appreciate the help!
    -Adam

    Wednesday, March 30, 2016 4:24 PM
  • Interesting... Can you share more details about the failed audit events you are mentioning?


    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Wednesday, March 30, 2016 9:58 PM
  • Hi Pierre,

    Sure! Here's the log, this was generated on ADFS1:

    An account failed to log on.

    Subject:
    Security ID: NULL SID
    Account Name: -
    Account Domain: -
    Logon ID: 0x0

    Logon Type: 3

    Account For Which Logon Failed:
    Security ID: NULL SID
    Account Name: adfs2test
    Account Domain:      ADFS2

    Failure Information:
    Failure Reason: Unknown user name or bad password.
    Status: 0xc000006d
    Sub Status: 0xc0000064

    Process Information:
    Caller Process ID: 0x0
    Caller Process Name: -

    Network Information:
    Workstation Name: Workstation
    Source Network Address: 192.168.1.5
    Source Port: 16906

    Detailed Authentication Information:
    Logon Process: NtLmSsp 
    Authentication Package: NTLM
    Transited Services: -
    Package Name (NTLM only): -
    Key Length: 0

    This event is generated when a logon request fails. It is generated on the computer where access was attempted.

    The Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.

    The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network).

    The Process Information fields indicate which account and process on the system requested the logon.

    The Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.

    The authentication information fields provide detailed information about this specific logon request.
    - Transited services indicate which intermediate services have participated in this logon request.
    - Package name indicates which sub-protocol was used among the NTLM protocols.
    - Key length indicates the length of the generated session key. This will be 0 if no session key was requested.


    Thursday, March 31, 2016 2:02 PM