I have a quick win for those who are also in the process of migrating an ADFS configured AFAS Online setup to Azure Active Directory. I’ve already had an support call with them and besides the point they don’t support any troubleshooting IDP setups they did their best which in turn got me to sharing this.
So down to the point, the following article describes the SSO needed part for AFAS Online: https://help.afas.nl/help/EN/SE/plv2_Config_SSO.htm
The parts that need to be adjusted are at the endpoint part, they refer to the federation metadata document which is not the one you need. This needs to be the OpenID Connect metadata document listed at the endpoints. Microsoft now defaults to the /v2.0/ part. (On a side note there might be some situations you will want to use the v1 document which is not listed anymore as an endpoint to copy, to use this just delete the /v2.0/ part and the old version will be used)
The final part is the configuration adjustment in AFAS Online, there when you fill in all the values the documentation states that “Scopes” is an optional field which in turn isn’t. I’ve only got it to work with this filled with email and the same at the claim part.
If you don’t fill out the scopes section it will error out with missing claim “upn” if that is the one you chose or “email”
Hope it helps!
With the release of vCenter 7 you can now integrate it with Microsof Active Directory Federation Services (ADFS)
See the following blog article for an overview:
See the following configuration articles for a setup overview:
With this information I’ve configured my lab environment to a working SAML based login with a few minor issues.
I had my ADFS setup load balanced through a content switching setup for external access. This is working great for my simple office 365 integration point but not so much if you’re trying to do more.
Like stated in the following article don’t terminate the SSL connection:
The issue I came across was that vCenter was failing with the validation of the certificate, at first I thought the missing root/intermediates was the cause of this but this was not the case. Even after uploading my internal root/intermediate and the external certificates root/intermediate the SSL validation check would fail. The chain was valid in every case though.
The resolution was to make my internal DNS entry through a SSL-BRIDGE setup to my ADFS server and afterwards I could finish the configuration part without issues.
Now when presented with vCenter logon page if you put in an account from the federated domain it will redirect you accordingly to the ADFS logon point.
Hope it helps!
In my lab environment I was running Windows vCenter 6.7 and with the release of vCenter 7 a migration is needed because there is no Windows vCenter anymore.
The following articles will give you enough information on how the process works especially the how-to from Vladan Seget:
Basically the process is the same for vCenter 7 with in my case one issue.
At first try my migration failed at the stage when the migration assistant is shutting down the Windows vCenter and the VCSA 7 is being brought up with the original IP, hence resulting in a conflict and the upgrade is in a broken state. I followed the process and saw that especially Windows Server 2016 has the annoyance to delay the shutdown for minutes, this is a known issue and happens from time to time and to my knowledge has to do when updates were installed (even after multiple reboots).
So the migration assistant is doing its job and completes the migration and is shutting down the VM, except in my case. Resolution for this is when the script is completed and windows says it’s still shutting down etc. do a hard power off and after that the migration is moving further as expected.
1. Make sure Windows is up to date with all the updates and there are none outstanding
2. Make sure vCenter is up to date, in my case it was the latest update of 6.7
3. Make a snapshot before you start ? saves a lot of hassle later on
4. Force kill the Windows vCenter when it’s shutting down after the migration assistant completes
After this the migration in my case completed flawlessly.
Hope it helps!
I’ve updated my lab environment with Citrix Gateway push OTP support and had some trouble in configuring the Citrix SSO app on my iPhone. For some reason it couldn’t setup the gateway connection and it wasn’t reachable. (Well that was my bad in checking all my devices but I’ll get to that)
Before the push OTP change I’ve worked with the authenticator app behavior and put in the code myself and this worked fine. The change to push OTP isn’t too difficult, and the following articles give you plenty of how-to information:
Keep in mind that if you have setup a previous OTP setup like I had the encryption part needs to be migrated otherwise it just won’t work. Registration cannot complete if you just flip it on and be done with it. Follow the migration part or just start fresh with OTP encryption enabled by default.
After I corrected the encryption problem I still could not register through the Citrix SSO app for push OTP functionality. It kept giving me the error gateway not reachable, fully checked everything in my environment was up and working. It kept me puzzling that it works fine with the previous authenticator method and if I re-registered it that way it would work (without the push of course because that functionality sits in the Citrix SSO app)
Finally after more troubleshooting I found the problem… because I’ve upgraded and integrated ADFS 2019 in my environment my content switching server and gateway etc. also needed to be SNI aware. Remember that everything worked fine on my Windows devices (even the Citrix SSO VPN functionality which I use quite often) but just not on my iPhone. Turning off SNI was the solution, it seems that the Citrix SSO app on iOS doesn’t support SNI.
Hope it helps!