Using scoped attributes as the C14N subject

[Wessel, Keith]

One somewhat related follow-up to this. I _thought_ that Microsoft AD Kerberos returned a scoped value as the principal and that, after all this time, my regex transform was parsing off the domain. But it appears that my regex transform was doing nothing as the log suggests:

INFO [net.shibboleth.idp.authn.impl.KerberosCredentialVal
idator:210] - Credential Validator krb5: Login by 'kwessel' succeeded

This may be out of scope for this list, but can anyone shed any light on if there's a Kerberos or Shib setting to get a fully "scoped" value back from AD Kerberos? Or is this all on Microsoft's side?

If I can't get this matching to work, my query in my data connector will need to check for both userPrincipalName for browser a uthentication coming from our upstream IdP and for sAMAccountName for ECP connections that went against Kerberos. That's not a big deal and, frankly, wont' slow things down to an even noticeable amount. It would just be cleaner if I was always looking for scoped userPrincipalNames.

Thanks,
Keith


-----Original Message-----
From: Wessel, Keith 
Sent: Tuesday, August 16, 2022 1:28 PM
To: Shib Users <users at shibboleth.net>
Subject: RE: Using scoped attributes as the C14N subject

I missed that note. Thanks. Sadly, still on 4.1, probably for a few more days. I'll upgrade my sandbox, though, and this should work.

Thanks, and sorry for not checking the release notes first.

Keith


-----Original Message-----
From: Cantor, Scott <cantor.2 at osu.edu> 
Sent: Tuesday, August 16, 2022 12:14 PM
To: Shib Users <users at shibboleth.net>
Cc: Wessel, Keith <kwessel at illinois.edu>
Subject: Re: Using scoped attributes as the C14N subject

Are you on 4.2 or 4.1-? Anything older than 4.2 has a bug that drops the scope, it's in the 4.2 notes (which obviously you wouldn't notice if running 4.1.).

-- Scott