I am trying to configure PrivacyIdea to use it for 2FA with Exchange OWA. I have gone through soem documentations and installed PrivacyIDEA server and ADFS adn configured Privacyidea adfs provider. But I am not able to get any guide on how to integrate it completely and use 2FA with OWA. Please provide me step by step guide on configuring Privacyidea with OWA.
That guide will get you 99% of the way there but the ADFS rules are slightly wrong syntactically…don’t recall where. However, if you use ADFS on Server 2019 (possibly 2016), implementing MFA can all be done through it’s GUI, no need for custom rules like provided in the guide.
High level steps:
Install ADFS on Windows Server
Install PrivacyIDEA-ADFS provider plugin on Windows ADFS server
Configure relying party trust in ADFS to use the PrivacyIDEA-ADFS provider
This is actually one of the easier integrations to setup…although I guess that depends on your comfort level with Windows vs. Linux.
I could probably write up a guide once I get my lab set back up and working.
For some reason blog.quickbreach.io was not accessible from my network. But I managed to configure Privacyidea server and ADFS.
My owa page now comes up with ADFS page and then requesting for OTP, but keeps on getting login failed even with correct OTP from privacyidea android app. When I test OTP on privacyidea server it can successfully verify OTP. Not sure why ADFS is not able to verify OTP. Please help.
Did you properly configure the PrivacyIDEA-ADFS provider config.xml file specifying your PI server in it before you installed it on the ADFS server? If you have to make a config change, that config file isn’t referenced after installation, so you’d have to uninstall the provider then reinstall it.
Do you have a load balancer in front of the PI server? I had issues with my lab setup going through a virtual kemp. Never worked on getting that to play nice though…
Enable debug logging in your pi.cfg file and run through an auth attempt, there’s usually something in there to help.
I configured my PrivacyIDEA server without SSL cert. Hence I was getting SSL errors. I updated config file for PrivacyIDEA-ADFS Provider and disabled SSL cert and that resolved the issue. I will be getting my SSL cert soon and then I will enable Cert check again. For now 2FS is working with OWA
As a next step I am trying to implement 2FS for RDP connections. I downloaded PrivacyIDEA Credential Provider, but it is missing required dll files. I believe Credential Provider is only available with enterprise edition and not as open source or is there other way to implement 2FA for RDP sessions.
The credential provider is available for anyone to use, but you have to compile it yourself. I went down that rabbit hole and got pretty close but could never get it to work right. I found all the dependencies and the compiled MSI installer would run but it appeared as if it wasn’t doing anything. There are registry keys it was configured to change but when I looked at the keys post-install, they didn’t exist or were not modified as expected.
I read somewhere that the window auth mechanisms were actually pretty easy to work through (if your an experienced developer) so developing an intercept application wasn’t too difficult. It may have even been PrivacyIDEA that wrote the article. It’s been too long and I don’t remember.
My point is, there’s definitely a way to do it, but if you’re anything but an experienced developer, you probably aren’t gonna be able to do it.
I also downloaded Credential Provider Installer and tried to install manually, but I am unable to find PrivacyIDEACredentialProvider.dll file anywhere. Also can’t find MSI package, it seems to be only available with enterprise edition. If you have link to download MSI package or PrivacyIDEACredentialProvider.dll, please share.
I am not a developer so won’t even try to go for other option.
What’s available online is the source code, you have to compile it like @cornelinux said. If you’ve got time to spend, download Visual Studio 2017 (I think that’s the correct version) and then get to work reverse engineering it through the error messages. There are package dependencies you’ll have to download, Wix I think is one of them. There’s also a couple lines to change within one of the files. The person that developed it kept all the files in their user profile so the code tries to save or lookup files located in like C:\users\derrick or something like that. It’s been close to a year since I tried to figure it out and came up short. I was surprised at how far I was able to get, but not surprised that I couldn’t get it to work in the end…I’m not a developer by any means. I tried to enlist a developer friend but he turned me down because he hated going through other peoples code (though he may have just not wanted to do it )
If you pay for Enterprise, then you’ll be given the compiled MSI installer
Adding to this in hope that others find it useful… Using the various resources that are further up this thread (for which thanks), I have got ADFS + Google authenticator working both on the intranet and the extranet but there are a couple of things along the way that required a bit more digging.
Exchange 2019 on Win2019
ADFS on WIn2019, upgraded to latest version
… both behind an inner firewall
WAP in a DMZ
Internal CA but a LetsEncrypt-provided cert on the Internet-facing interface on the WAP server
I used this provider: [[GitHub - privacyidea/adfs-provider: Authentication provider for Microsoft AD FS to use with privacyIDEA.]([GitHub - privacyidea/adfs-provider: Authentication provider for Microsoft AD FS to use with privacyIDEA.]] at v 1.0.1. It’s easy to install. All the required parameters are dealt with in an installation dialog. The bit that’s “tricky” here (for me) was the choice around providing (or not) the service_user, service_pass (and which they were) and the choices about trigger_challenges vs send_empty_pass. I went for:
Service user = the account name used to log on to the PrivacyIDEA website
Service pass = password for the same
Trigger Challenges = 1
Notes: (1) The password for the service account is stored in clear text in the registry and (2) is written in clear text in the registry
The ADFS signing certifcate needs to be copied to your Exchange Server and put in Trusted Root Certification Authorities
When this certificate expires it will need to be update manually in the Exchange Server
I had replaced the self-signed certificate on the PrivacyIDEA server with one signed by the internal CA
Claim issuance policies:
The “*” in the text provided in the Quickbreach post should be replaced by “==”
If you have a sub-domain setup then UPN != corporate email… I did briefly try adding another rule to see if I could work with email address but that did not work but domain\username did as well as UPN
I reached a point where going to the OWA URL would pop up the ADFS login page and then when i had provided AD credentials I would get an error (Event ID 364 including this “Microsoft.IdentityServer.Web.WebConfigurationException: No style sheet is configured in the active theme for default locale [en-GB/2057].”). Fixing this involved hunting down the SID for the ADFS service account and then updating the internationalisation (??) data for that SID in the registry. See here for something similar and the fix required AD FS 4.0, Custom MFA Provider, International locales, and style sheet exception
With these in place, I could make everything work on the intranet but it failed on the Internet-facing interface.
Making it work on the Internet-facing interface:
I needed to add a CNAME for the interface that referred to my adfs FQDN but aliased the single public IP address I have.
Just read the bit about the service account password. That should have said, “Notes: (1) The password for the service account is stored in clear text in the registry and (2) is written in clear text in the log file (if you enable logging)”
Actually you can not add 2FA directly on the RD Gateway level (since it does RADIUS NPS and Kerberos Tickets).
You need to add the above mentioned Credential Provider on the Terminal Server behind the RD Gateway. So the RD Gateway verifies the first factor (AD Password) and then the TS only needs to verify the 2nd factor using the Credential Provider.