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. I followed it exactly with the exception of this discussion 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.
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.
This service now ticket may also provide some additional help.
we had similar issues and following seems to have resolved the issue
- 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.
- download a fresh copy of IdP metadata.
make sure to restart apache after above changes.
Hopefully that helps.
@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 ‘firstname.lastname@example.org’ => ‘email@example.com’ [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.
Yes thank you for the help @bp85!
Yes you can map a user with a regular expression. In 2.0 it’s
Here are the docs for the same.
We have this all working now. Thank you!
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
LogLevel info mod_auth_mellon:trace
LogLevel info auth_mellon:trace
(I don’t know if the
mod_ is needed or not)