ADFS Agent and ODA

[MattPayton]

We've been using ADFS (ver 3.0 on server 2012R2) and the RSA ADFS agent (currently version 1.0.1) to require authentication via RSA SecurID (Auth Manager 8.2 SP1) when logging in to our Office 365 tenant from outside our corporate network.

This has been working for about 18 months, and still does for users with hardware/software tokens, but we are now just starting to enable some users for On-Demand authentication. ODA is working for our Cisco VPN, but not Office 365. Users are prompted for an RSA token as expected, but after entering their PIN they (eventually) get a generic error - "An error occurred. Contact your Administrator for more information"

The token is sent(either email or sms), but access is never granted.

Is anybody else using ODA with ADFS and Office 365 ? If so did you have to do anything specific or different that for using tokens ?

[JayGuillette · Accepted solution]

The ADFS agent has an RSA Control Center, which is easiest for testing.  Try an ODA enabled logon there first, just enter the ODA PIN, have the Security Console Real Time Authentication monitor up to watch.  Successful PIN should trigger the email or SMS text with the OD TokenCode, and User should be able to copy that into the Test logon screen, which typically is prompting for Next TokenCode (in this case On Demand TokenCode).

Problems;

 1. Wrong PIN, so auth fails, make sure you configure a default On Demand PIN for enabled ODA user

 2. ODA PIN correct, but delivery of OD TokenCode gets lost

     a. might need to check various logs, 

     b. email is typically easier to get running than SMS - you get more credit for small success than a big failure

     c. There is a KB on troubleshooting ODA, with tcpdump watching for port 25 traffic to SMS or SMTP gateways.

https://community.rsa.com/docs/DOC-45592 

 3. If there are load balancers involved, an ODA logon is 2 steps, therefore persistence is rewarded (not just in life but in LB configurations).  If the load balancers do something weird, like NAT the UDP ports, the RSA AM Server would drop/ignore the 2nd part of the ODA auth, the TokenCode, if it saw a different source UDP port number from the AD FS agent to the AM server.  RSA has its own persistence, because UDP does not.   Open a case if you are here, or search RSA link for F5 Load Balancer and ODA knowledge base articles

[EdwardDavis]

Try this:

1) go to a special link (reformat this to fit your setup, your primary or web tier) to get just an on demand code sent to you

https://rsa-machine.name.server.com:7004/console-selfservice/OnDemandOTTLogin.do?action=nvPreEdit 

change the server name to your primary, a replica, or a web tier. This will get an on-demand code fired to you.

(If web tier change the port 7004 to match what port you actually use)

2) Now try to login to O365 using your ODA pin + the code you just got sent (just like using a pin and keyfob token)

If the above works, it might be that the O365 is not able to perform the 3-way handshake needed to ask for

next tokencode. 

[MattPayton]

Authentication from the ADFS servers via the RSA Control Panel works with an ODA token. Generating an ODA token via the direct link to the Auth Manager server, then entering the PIN+Tokencode when prompted also works to authenticate/log in to Office 365.

So...It looks like it may be that ADFS doesn't know what to do with the ODA requirement for the 2nd prompt. I will open a ticket with MS to see if there is something I can do on the ADFS side.

Thanks all.

[MattPayton]

I also just tried clicking the back button when on the error page, which displayed the RSA tokencode prompt again, and entering PIN+Tokencode and that worked as well.

Anyway, I've opened a ticket with MS, so maybe they can offer something.

[GabrielPython]

And what happens when your HW Token is in New PIN or Next TokenCode ?

Did You get the second prompt from Office 365 ?

[MattPayton]

Well...It probably wouldn't have worked, but after some help from RSA support I found that session Affinity or Sticky session option wasn't set on the agent, and as we have multiple ADFS servers, this is required. I honestly don't know how it wasn't since I remember specifically going over this option when we initially deployed the RSA agent and MFA policy in ADFS. Per the documentation you have to set "AreAuthSessionsSticky to true in SecurIDAuthProviderConfig.xml prior to registering the agent. It was set on one ADFS server, but not the other, so somebody (probably me) missed a step.

Anyway, with it set, and after unregistering and reregistering the agent ODA is working, as well as new PIN, next tokencode etc.

Time to take a step back and go over all the settings to make sure I'm not missing anything else.

Thanks all.