Table of Contents
Overview
It’s nothing new that more and more companies are choosing the M365 way and what’s the first thing to do to give your users SSO and the option to sign in to the office portal with their “E-Mail” address? Correct, changing the UPN Suffix to the public Domain Name so it is matching with the E-Mail Address.
Thanks to PowerShell, that is not a huge effort, but what about users which are using certbased authentication to the ADC? What happens if I change their UPN? Logon is not possible, anymore, because there is the old UPN listed on the certificate.
Option 1
Change UPN and force the autodeployment of new user-certs via the PKI Infrastructure.
Option 2
How to deal with that if most users are in field work and offline because there is no Client-VPN or anything else – only ADC clientless access to their webapps (ICA, Exchange, ERP, etc.) so in perspective of the PKI, the client is offline and gets no new user certificate enrolled.
So I was thinking about what is changing if the UPN changes and how can I reach that the old AND the new user certificates get accepted by logging in to the ADC.
In my case it is a nFactor scenario (Corporate device uses Usercert + LDAP / if no Corporate Device Fallback to LDAP + RADIUS)
Example:
Domain FQDN: corp.internal
Current UPN: sAMAccountName@corp.internal
New UPN: sAMAccountName@corp.com
Configuration
I was thinking about which logon name attribute is NOT changing? Correct, it’s corp.internal\sAMAccountName what stays identical.
So the goal is to modify the CertExtract LoginSchema XML to add the following expression:
"corp.internal" + "\\" + aaa.user.name.before_str("@")