# Help with ADFS integration

**URL:** <https://discourse.openondemand.org/t/help-with-adfs-integration/1594>\
**Category:** Get Help\
**Created:** [July 22, 2021, 3:13pm UTC](https://discourse.openondemand.org/t/help-with-adfs-integration/1594 "2021-07-22T15:13:54Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![rgas20](https://sea1.discourse-cdn.com/flex015/user_avatar/discourse.openondemand.org/rgas20/32/309_2.png) [@rgas20](https://discourse.openondemand.org/u/rgas20)\
**Post date:** [July 22, 2021, 3:13pm UTC](https://discourse.openondemand.org/t/help-with-adfs-integration/1594/1 "2021-07-22T15:13:55Z")

</div>

Hi,

Since the release of OnDemand 2.0 we’ve been focusing on getting it integrated with ADFS. We’ve been following the guide here: [SAML Authentication with Active Directory Federated Services (ADFS) and mod\_auth\_mellon — Open OnDemand 1.8.12 documentation](https://osc.github.io/ood-documentation/master/authentication/adfs-with-auth-mellon.html). I followed it exactly with the exception of [this discussion](https://discourse.openondemand.org/t/ood-1-8-and-saml2-and-adfs-authentication/1137) in which reply #7 says to switch the arguments for the Mellon metadata generation. This extra step seems to have gotten us started.

I have given our .pfx and metadata to our administrator who has imported that info. However we are now having issues getting the server to accept logins. In the logs I get the following error:

`[auth_mellon:error] [pid 7990] [client nnn.nnn.nnn.nnn:60506] Error processing authn response. Lasso error: [-432] Status code is not success, SAML Response: StatusCode1="urn:oasis:names:tc:SAML:2.0:status:Requester", StatusCode2="urn:oasis:names:tc:SAML:2.0:status:InvalidNameIDPolicy", StatusMessage="(null)", referer: https://adfs.domain.edu/`

The issue seems to be “InvalidNameIDPolicy”.

At our site the sAMAccountname is used. Our administrator has tried setting the LDAP Attribute to sAMAccountname with the outgoing claim type of Name ID, however when signing in we get the same error message as above in the logs and " Unauthorized. This server could not verify that you are authorized to access the document requested. Either you supplied the wrong credentials (e.g., bad password), or your browser doesn’t understand how to supply the credentials required." for the browser.

Any assistance with this would be appreciated. Wondering if anyone else has this set up at their site and what changes, if any, were needed to get this to work.

---

<div class="post-metadata">

**Author:** ![jeff.ohrstrom](https://sea1.discourse-cdn.com/flex015/user_avatar/discourse.openondemand.org/jeff.ohrstrom/32/136_2.png) [@jeff.ohrstrom](https://discourse.openondemand.org/u/jeff.ohrstrom)\
**Post date:** [July 22, 2021, 4:47pm UTC](https://discourse.openondemand.org/t/help-with-adfs-integration/1594/2 "2021-07-22T16:47:34Z")

</div>

What’s the identity provider (IDP) you’re connecting to? After a little bit of googling it seems to indicate that your IDP doesn’t like what you’re giving it. Searching the `mod_auth_mellon` github shows nothing from that error.

Indeed this service now article has a good explanation of your issue. In sum, your IDP doesn’t like what you’re sending it. So, I guess I’d look for what your sending it and what it’s expecting - maybe the team that runs your IDP may have some insight? They may be able to pull logs from it indicating what the issue is.

[https://support.servicenow.com/kb?id=kb\_article\_view&sysparm\_article=KB0657094](https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0657094)

This service now ticket may also provide some additional help.  
[https://support.servicenow.com/kb?id=kb\_article\_view&sysparm\_article=KB0819297](https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0819297)

---

<div class="post-metadata">

**Author:** ![bp85](https://sea1.discourse-cdn.com/flex015/user_avatar/discourse.openondemand.org/bp85/32/640_2.png) [@bp85](https://discourse.openondemand.org/u/bp85)\
**Post date:** [July 27, 2021, 7:16pm UTC](https://discourse.openondemand.org/t/help-with-adfs-integration/1594/3 "2021-07-27T19:16:32Z")

</div>

we had similar issues and following seems to have resolved the issue

1. make sure you’ve `<NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</NameIDFormat>` in mellon\_metadata.xml and same policy is configured for OOD app in ADFS.
2. download a fresh copy of IdP metadata.

make sure to restart apache after above changes.

Hopefully that helps.

---

<div class="post-metadata">

**Author:** ![rgas20](https://sea1.discourse-cdn.com/flex015/user_avatar/discourse.openondemand.org/rgas20/32/309_2.png) [@rgas20](https://discourse.openondemand.org/u/rgas20)\
**Post date:** [July 29, 2021, 11:28pm UTC](https://discourse.openondemand.org/t/help-with-adfs-integration/1594/4 "2021-07-29T23:28:49Z")

</div>

@jeff.ohrstrom @bp85 thank you both for the suggestions. We are getting closer to finding a solution.

In the logs we have the following: Mapped ‘first.last@domain.edu’ =\> ‘first.last@domain.edu’ [0.012 ms

Tweaking the ADFS rules we have also been able to pass credentials in this format:

‘domain\first.last’ =\> ‘domain\first.last’

Is there a way in the user mapping script to strip away the @domain.edu portion that the username maps to or the preceding domain\ ? If we can get OOD to drop that and then it will map to the correct username and I think we should be good to go.

---

<div class="post-metadata">

**Author:** ![jeff.ohrstrom](https://sea1.discourse-cdn.com/flex015/user_avatar/discourse.openondemand.org/jeff.ohrstrom/32/136_2.png) [@jeff.ohrstrom](https://discourse.openondemand.org/u/jeff.ohrstrom)\
**Post date:** [July 30, 2021, 1:31pm UTC](https://discourse.openondemand.org/t/help-with-adfs-integration/1594/5 "2021-07-30T13:31:01Z")

</div>

Yes thank you for the help @bp85!

Yes you can map a user with a regular expression. In 2.0 it’s `user_map_match` in `ood_portal.yml`.

Here are the docs for the same.  
[https://osc.github.io/ood-documentation/latest/reference/files/ood-portal-yml.html](https://osc.github.io/ood-documentation/latest/reference/files/ood-portal-yml.html)

---

<div class="post-metadata">

**Author:** ![rgas20](https://sea1.discourse-cdn.com/flex015/user_avatar/discourse.openondemand.org/rgas20/32/309_2.png) [@rgas20](https://discourse.openondemand.org/u/rgas20)\
**Post date:** [August 2, 2021, 1:32pm UTC](https://discourse.openondemand.org/t/help-with-adfs-integration/1594/6 "2021-08-02T13:32:06Z")

</div>

We have this all working now. Thank you!

---

<div class="post-metadata">

**Author:** ![jeff.ohrstrom](https://sea1.discourse-cdn.com/flex015/user_avatar/discourse.openondemand.org/jeff.ohrstrom/32/136_2.png) [@jeff.ohrstrom](https://discourse.openondemand.org/u/jeff.ohrstrom)\
**Post date:** [August 9, 2022, 3:43pm UTC](https://discourse.openondemand.org/t/help-with-adfs-integration/1594/8 "2022-08-09T15:43:43Z")

</div>

I think the next thing we can do is up the logging level for this module.

You can add this to a conf file in `/opt/rh/httpd24/root/etc/httpd/conf.d/debug.conf`. You should be able to update and modify this file as you please without impacting the OOD conf.

The line you want to increase the log level is

```auto
LogLevel info mod_auth_mellon:trace

```

or maybe

```auto
LogLevel info auth_mellon:trace

```

(I don’t know if the `mod_` is needed or not)