locked
Can not find the attribute and can not create rule in ADFS RRS feed

  • Question

  • There is attribute in AD with name “profilePath” with value of i:0#.w|mit\ramkumar.cheekoti  (screen1), Now I want to send this to the Enterprise application through SAML xml file, but I am unable to find the “profilePath” attribute in the LDAP attribute list while creating rule in ADFS (screen2), please help.

    screen 1:

    Screen 2:




    Thanks, Ram Ch


    • Edited by Cheekoti Ram Friday, April 19, 2019 12:50 PM forgot
    Friday, April 19, 2019 12:49 PM

Answers

  • You can disable encryption for the Relying Party Trust using this PowerShell cmdlet:

    Set-AdfsRelyingPartyTrust -TargetName name_of_your_RPT -EncryptClaims $false

    Most Service Providers accept unencrypted SAML Tokens so you should not have any problems signing in.

    If your Service Providers requires an encrypted SAML Token then don't worry about that at this stage.

    This will allow you to capture an UNENCRYPTED SAML Token regardless so that you can inspect the Assertions (aka Claim Types and their values).

    Once you're done simply enable encryption using the same cmdlet but with $true instead of $false.



    Tuesday, May 7, 2019 8:02 PM
  • I typed manually "profilePath" and chosen outgoing claim type as Subject but I dont see that value is being passed to service provider through SAML xml.

    I am not sure if I have chosen the right outgoing claim type , can you help me what to choose and how it will be sent properly

    Please note that service application has attribute called "NTLMID" so I want to map this NTMLID to the profilePath so that value will be assigned to the NTLMID.


    Thanks, Ram Ch

    • Marked as answer by Cheekoti Ram Wednesday, May 15, 2019 12:48 PM
    Monday, April 22, 2019 5:03 AM
  • Type NTLMID in the "Outgoing Claim Type".

    • Marked as answer by Cheekoti Ram Wednesday, May 15, 2019 12:48 PM
    Wednesday, April 24, 2019 9:08 PM
  • Yes.

    • Marked as answer by Cheekoti Ram Wednesday, May 15, 2019 12:48 PM
    Thursday, April 25, 2019 6:32 AM
  • Hello

    The instructions above are 100% spot on.

    First, use Fiddler, capture the SAML Token and check that it really contains the Claim Type / Assertion.

    Next, if it does, check that the Claim Type / Assertion name you are using REALLY matches what the application is looking for in the SAML Token. Is it looking for NTLMID or perhaps something like http://schemas.xmlsoap.org/ws/2005/05/identity/claims/NTLMID

    Remember that what you issue in the SAML Token must match exactly what the application is looking for when parsing the SAML Token.



    Thursday, April 25, 2019 11:12 AM
  • The data is encrypted which is why you don't see the attributes in the clear.

    • Marked as answer by Cheekoti Ram Wednesday, May 15, 2019 12:48 PM
    Monday, May 6, 2019 6:45 PM
  • How do I decrypt?

    Thanks, Ram Ch

    • Marked as answer by Cheekoti Ram Wednesday, May 15, 2019 12:48 PM
    Monday, May 6, 2019 7:03 PM

All replies

  • Just type it as-is in the field.

    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.

    Friday, April 19, 2019 5:18 PM
  • I typed manually "profilePath" and chosen outgoing claim type as Subject but I dont see that value is being passed to service provider through SAML xml.

    I am not sure if I have chosen the right outgoing claim type , can you help me what to choose and how it will be sent properly

    Please note that service application has attribute called "NTLMID" so I want to map this NTMLID to the profilePath so that value will be assigned to the NTLMID.


    Thanks, Ram Ch

    • Marked as answer by Cheekoti Ram Wednesday, May 15, 2019 12:48 PM
    Monday, April 22, 2019 5:03 AM
  • Type NTLMID in the "Outgoing Claim Type".

    • Marked as answer by Cheekoti Ram Wednesday, May 15, 2019 12:48 PM
    Wednesday, April 24, 2019 9:08 PM
  • Thanks for the response.

    Sure, will do that. but my question is in the list of OutgoingClaim types , we dont find NTLMID right, is it not a issue?

    Manually typing is fine?


    Thanks, Ram Ch

    Thursday, April 25, 2019 4:40 AM
  • Yes.

    • Marked as answer by Cheekoti Ram Wednesday, May 15, 2019 12:48 PM
    Thursday, April 25, 2019 6:32 AM
  • Okay, I did as you mentioned, but it did not work, I did not get value in service application, below screen is from service application

    can you please help


    Thanks, Ram Ch

    Thursday, April 25, 2019 7:30 AM
  • Hello

    The instructions above are 100% spot on.

    First, use Fiddler, capture the SAML Token and check that it really contains the Claim Type / Assertion.

    Next, if it does, check that the Claim Type / Assertion name you are using REALLY matches what the application is looking for in the SAML Token. Is it looking for NTLMID or perhaps something like http://schemas.xmlsoap.org/ws/2005/05/identity/claims/NTLMID

    Remember that what you issue in the SAML Token must match exactly what the application is looking for when parsing the SAML Token.



    Thursday, April 25, 2019 11:12 AM
  • I can login successfully but I can not the saml attributes in the xml response, I see authencation is sucess but dont find attributes. However I logged in through SSO with out any issues.

    below is saml  trace from firefox.


    Thanks, Ram Ch

    Monday, May 6, 2019 4:00 PM
  • The data is encrypted which is why you don't see the attributes in the clear.

    • Marked as answer by Cheekoti Ram Wednesday, May 15, 2019 12:48 PM
    Monday, May 6, 2019 6:45 PM
  • How do I decrypt?

    Thanks, Ram Ch

    • Marked as answer by Cheekoti Ram Wednesday, May 15, 2019 12:48 PM
    Monday, May 6, 2019 7:03 PM
  • You can disable encryption for the Relying Party Trust using this PowerShell cmdlet:

    Set-AdfsRelyingPartyTrust -TargetName name_of_your_RPT -EncryptClaims $false

    Most Service Providers accept unencrypted SAML Tokens so you should not have any problems signing in.

    If your Service Providers requires an encrypted SAML Token then don't worry about that at this stage.

    This will allow you to capture an UNENCRYPTED SAML Token regardless so that you can inspect the Assertions (aka Claim Types and their values).

    Once you're done simply enable encryption using the same cmdlet but with $true instead of $false.



    Tuesday, May 7, 2019 8:02 PM