VMware Workspace ONE Community
cohiba_274
Contributor
Contributor

Certificate Authentication - Updated UPN breaks Kerberos

Hello,

I don't post often in this forum but now I'm desperate. I've been trying to make things work the paste couple of days and I could not get it.

We are using SEG and client certificate authentication for activesync.

The issue is that we need to update our users UPN from domain.local to domain.com (domain.com is our email domain)

My understanding is that things should not break because the SEG would take the certificate UPN (@DOMAIN.LOCAL) and try to request the kerberos ticket sing that UPN.

The issue would be with new users, requesting certificate with updated UPN (@DOMAIN.COM), the SEG would request the kerberos ticket using the updated UPN  taken from the certificate..

From what I was reading, the way to go would be to add a kerberos principal name under the the alSecurityIdentities attribute so the SEG would request the kerberos ticket using that name.

Set-ADUser -Identity TESTUSER -Add @{'altSecurityIdentities'="Kerberos:TESTUSER@DOMAIN.INTERNAL"}

But this is not what's happening, if I update the UPN, everything breaks (eventually). The existing users receives certificate errors and new user could not authenticate either.

I understand that I have a limited comprehension of kerberos but any help would be appreciated.

 

Thanks!

0 Kudos
3 Replies
cohiba_274
Contributor
Contributor

I made some progress and I was able to make the new users working.

I did change the certificate request template and I modified the format of the User Principal Name in the SAN type.

It was set to {UserPrincipalName} and I switched it to {EnrollmentUser}@DOMAIN.INTERNAL

Now I can enroll new device and the authentication is working fine but that doesn't solve the issue that existing users with existing profiles are experiencing problems when I modify their UPN... How can I force the SEG to user the sAMAccountName@DOMAIN.INTERNAL instead of UPN?

Thanks!

0 Kudos
somemdm
Enthusiast
Enthusiast

Looks like the reason is in the log.

The SEG is beginning the impersonation request by resolving the KCD or primary domain controller for DOMAIN.INTERNAL (resolving to 192.168.111.111):

Sending DNS SRV query for _kerberos-master._tcp.DOMAIN.INTERNAL

Which is obviously not the KCD master or primary domain controller for DOMAIN.COM:

TGS request result: -1765328377/Server not found in Kerberos database

You could try and find the KCD master for DOMAIN.COM by running this: nslookup -type=srv _kerberos._tcp.DOMAIN.COM or (in your case as it doesn't look standard) nslookup -type=srv _kerberos-master._tcp.DOMAIN.COM

So I would say your realm or Kerberos config needs to be looked at. Or you could have separate SEGs for each domain, pointing to different realms, with different keytabs etc.

0 Kudos
cohiba_274
Contributor
Contributor

Hello somedm,

Thanks for the reply, I did change my DNS as suggested and it was still not working.

It end up that the issue was a mismatch between the UPN prefix and the sAMAccountName.

I was setting the "Kerberos:TESTUSER@DOMAIN.INTERNAL" value using the UPN prefix and it was not working.

I tried to use the sAMAccountName instead and gladly it worked.

So for example the user Bob Lacroix had a UPN of blacroix@domain.com and the sAMAccountName BLAC

I had to set the altSecurityIdentities to "Kerberos:BLAC@DOMAIN.INTERNAL" and NOT "Kerberos:BLACROIX@DOMAIN.INTERNAL"

I've been able to change the UPN of all my users.

Thanks

0 Kudos