A client name with an '@'

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

A client name with an '@'

Nordgren, Bryce L -FS
Hi,

I'm trying to set up the MIT Kerberos server (1.12.2 / Fedora 21) to PKINIT from my organizations' smart cards.

They have a MS user principal name of the form: [hidden email]

I tried creating a realm "FEDIDCARD.GOV" with a user principal 12001000550281. This resulted in a client name mismatch when trying to kinit to [hidden email].

I then tried creating a "[hidden email]" principal in my realm. Unfortunately, I cannot kinit using the principal "[hidden email]@FEDIDCARD.GOV". kinit gives a "Malformed representation of principal when parsing name..." error.

Is there a solution to this? Some special syntax that tells the command line tools to ignore '@' signs in a client principal name? Or am I thinking wrong: Does kinit parse the user principal name into client and realm? Should I rename my realm to lowercase fedidcard.gov?

Thanks,
Bryce
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: A client name with an '@'

Nico Williams
On Mon, Jun 01, 2015 at 10:04:46PM +0000, Nordgren, Bryce L -FS wrote:
> I then tried creating a "[hidden email]" principal in my
> realm. Unfortunately, I cannot kinit using the principal
> "[hidden email]@FEDIDCARD.GOV". kinit gives a "Malformed
> representation of principal when parsing name..." error.

You have to escape the first '@' with a backslah.  Mind your shell
quoting, since your shell may require you to escape the escape
backslash.

On a typical Unix shell you could:

$ kinit 12001000550281\\@[hidden email]

or

$ kinit '12001000550281\@[hidden email]'

Nico
--
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

RE: A client name with an '@'

Nordgren, Bryce L -FS
> $ kinit '12001000550281\@[hidden email]'

Thanks! Making progress!

It now prints a single backslash when describing the principal, both in errors emitted from kinit and the "listprincs" command in kadmin.local. However, I'm back to "client name mismatch" out of kinit, presumably because the MS User Principal Name in the certificate lacks the backslash.

Bryce




________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: A client name with an '@'

Todd Grayson
Bryce

Its either [hidden email] <[hidden email]> or
its [hidden email] <[hidden email]>

as far as your shell escaping with a \, in a command line you will not
escape the @, if you are scripting it, you might.

to the left of the @ is the principal name, traditionally lowercase.  To
the right is the REALM, traditionally uppercase.  AD userPrincipalName
entries should be able to handle the uppercase value being presented at
authentication for the user.

The userPrincipalName is the kerberos principal name, within AD.  You do
not have to nest the lowercase instance into the uppercase realm (in other
words, dont use 12001000550281\@[hidden email] ).  You should
be able to get it to work presenting consistent case and based on the
example I give above.



On Mon, Jun 1, 2015 at 5:02 PM, Nordgren, Bryce L -FS <[hidden email]>
wrote:

> > $ kinit '12001000550281\@[hidden email]'
>
> Thanks! Making progress!
>
> It now prints a single backslash when describing the principal, both in
> errors emitted from kinit and the "listprincs" command in kadmin.local.
> However, I'm back to "client name mismatch" out of kinit, presumably
> because the MS User Principal Name in the certificate lacks the backslash.
>
> Bryce
>
>
>
>
> ________________________________________________
> Kerberos mailing list           [hidden email]
> https://mailman.mit.edu/mailman/listinfo/kerberos
>



--
Todd Grayson
Customer Operations Engineering
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

RE: A client name with an '@'

Nordgren, Bryce L -FS

>>Or am I thinking wrong: Does kinit parse the user principal name into client and realm?
>>Should I rename my realm to lowercase fedidcard.gov?

> Its either [hidden email] or its [hidden email]

That it is. Deleting the realm and recreating a lowercase realm fixed the issue. (I can't change the smart cards.) Now I probably should make sure that everyone's UPN is from the same realm...

Thanks all,
Bryce



________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: A client name with an '@'

Luke Howard
In reply to this post by Nordgren, Bryce L -FS
You could try the -C and -E options to kinit:

        -C canonicalize
        -E client is enterprise principal name

— Luke

> On 2 Jun 2015, at 1:02 am, Nordgren, Bryce L -FS <[hidden email]> wrote:
>
>> $ kinit '12001000550281\@[hidden email]'
>
> Thanks! Making progress!
>
> It now prints a single backslash when describing the principal, both in errors emitted from kinit and the "listprincs" command in kadmin.local. However, I'm back to "client name mismatch" out of kinit, presumably because the MS User Principal Name in the certificate lacks the backslash.
>
> Bryce
>
>
>
>
> ________________________________________________
> Kerberos mailing list           [hidden email]
> https://mailman.mit.edu/mailman/listinfo/kerberos

--
www.lukehoward.com
soundcloud.com/lukehoward


________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

RE: A client name with an '@'

Nordgren, Bryce L -FS
> You could try the -C and -E options to kinit:
>
> -C canonicalize
> -E client is enterprise principal name
>
> — Luke

I could, but I'm not certain the MIT Kerberos KDC (to which kinit is connecting) knows how to canonicalize. Boy if I could get user principal mapping going, that would be sweet.

For the moment, I seem to be PKINITing successfully.

Bryce

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: A client name with an '@'

Rick van Rein (OpenFortress)
Hi,


Nordgren, Bryce L -FS wrote:
>
> I could, but I'm not certain the MIT Kerberos KDC (to which kinit is
> connecting) knows how to canonicalize.


It does not.  It will however handle usernames with an embedded @ as any
other, as you've already found.

> Boy if I could get user principal mapping going, that would be sweet.

Or you might retain the uppercase realm and try to cross-sign between
the uppercase and lowercase realms.  Your (somewhat silly) clients logon
to the lowercase realm and gain access to the (less errorprone) uppercase
realm.

Cheers,
-Rick

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: A client name with an '@'

Luke Howard
In reply to this post by Nordgren, Bryce L -FS
Ah, I didn’t read the context. MIT has supported client name canonicalisation in AS-REQs for a while so it might be worth a try.

Also: re earlier message, enterprise principal names (UPNs) imply canonicalisation, so you shouldn’t need to set the canon flag if you’re using this name type.

— Luke

> On 2 Jun 2015, at 11:37 pm, Nordgren, Bryce L -FS <[hidden email]> wrote:
>
>> You could try the -C and -E options to kinit:
>>
>> -C canonicalize
>> -E client is enterprise principal name
>>
>> — Luke
>
> I could, but I'm not certain the MIT Kerberos KDC (to which kinit is connecting) knows how to canonicalize. Boy if I could get user principal mapping going, that would be sweet.
>
> For the moment, I seem to be PKINITing successfully.
>
> Bryce

--
www.lukehoward.com
soundcloud.com/lukehoward


________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: A client name with an '@'

Ken Hornstein
In reply to this post by Rick van Rein (OpenFortress)
>> Boy if I could get user principal mapping going, that would be sweet.
>
>Or you might retain the uppercase realm and try to cross-sign between
>the uppercase and lowercase realms.  Your (somewhat silly) clients logon
>to the lowercase realm and gain access to the (less errorprone) uppercase
>realm.

I think if you had two realms that differed only by case, that would be
a recipe for a disaster (what happened when you tried to look up realm
information in DNS, which is case-insensitive for lookup?).

Also, the venerably Russ Allberry created a lowercase realm for Stanford,
and repeatedly has said that if he had to do it all over again he wouldn't
have done a lowercase realm; too much software assumes an uppercase realm.
Maybe that has changed in the intervening years.

--Ken
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

RE: A client name with an '@'

Nordgren, Bryce L -FS

> Also, the venerably Russ Allberry created a lowercase realm for Stanford, and
> repeatedly has said that if he had to do it all over again he wouldn't have
> done a lowercase realm; too much software assumes an uppercase realm.
> Maybe that has changed in the intervening years.

Kind of moot. These smart cards are issued from GSA credentialing centers for USDA and certificate production is outside my sphere of influence. The really odd part is that the lowercase realm is encoded into the certificate, but the realm in Active Directory is uppercase. I don't know if this is some kind of oversight, some kind of requirement to make Active Directory canonicalize correctly, or if they're intentionally making it hard to use.

Thanks for all your help!
Bryce

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: A client name with an '@'

Nico Williams
On Wed, Jun 03, 2015 at 04:29:19PM +0000, Nordgren, Bryce L -FS wrote:
> Kind of moot. These smart cards are issued from GSA credentialing
> centers for USDA and certificate production is outside my sphere of
> influence. The really odd part is that the lowercase realm is encoded
> into the certificate, but the realm in Active Directory is uppercase.
> I don't know if this is some kind of oversight, some kind of
> requirement to make Active Directory canonicalize correctly, or if
> they're intentionally making it hard to use.

AD matches realms case-insensitively (though case-preserving).
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: A client name with an '@'

Nico Williams
In reply to this post by Ken Hornstein
On Wed, Jun 03, 2015 at 11:21:04AM -0400, Ken Hornstein wrote:
> >Or you might retain the uppercase realm and try to cross-sign between
> >the uppercase and lowercase realms.  Your (somewhat silly) clients logon
> >to the lowercase realm and gain access to the (less errorprone) uppercase
> >realm.
>
> I think if you had two realms that differed only by case, that would be
> a recipe for a disaster (what happened when you tried to look up realm
> information in DNS, which is case-insensitive for lookup?).

Or hack on the KDCs to implement AD-style case-insensitive/preserving
realm matching.  I'm starting to think that we ought to do this in
Heimdal and MIT Kerberos, at least as an option.

> Also, the venerably Russ Allberry created a lowercase realm for Stanford,
> and repeatedly has said that if he had to do it all over again he wouldn't
> have done a lowercase realm; too much software assumes an uppercase realm.
> Maybe that has changed in the intervening years.

I'd stay away from lower-case realm naming.

We keep putting off reckoning with I18N.  But the more we do it the more
we'll effectively end up with the right solution (namely, recognize that
we just-send-8, say that only UTF-8 will interop reliably, then make
KerberosString be UTF8String with an IA5String implicit universal tag,
list domainname slots in the protocol and put U-labels in them,
recognize A-labels as aliasing U-labels in KDBs; with IDNA2008 we could
even do the right thing as to treating realms as domainnames that are
strangely capitalized).

Nico
--
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

RE: A client name with an '@'

Nordgren, Bryce L -FS

> Or hack on the KDCs to implement AD-style case-insensitive/preserving
> realm matching.  I'm starting to think that we ought to do this in Heimdal and
> MIT Kerberos, at least as an option.

This plus canonicalizing is how our corporate system might work. I don't think there's a FEDIDCARD.GOV realm (or fedidcard.gov either) outside the scope of my PKINIT test. I think our corporate AD sees users from that domain and knows (somehow) how to map them into the USDA.NET realm. Klist has never shown me a FEDIDCARD.GOV ticket on my windows box, and I can't locate a FEDIDCARD.GOV KDC inside or outside the firewall.

Maybe canonicalizing isn't the right word for this..."appropriating user identities from unrelated virtual realms" may be more descriptive.

I had nothing to do with it. :)

Bryce

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: A client name with an '@'

Russ Allbery-2
In reply to this post by Ken Hornstein
Ken Hornstein <[hidden email]> writes:

> Also, the venerably Russ Allbery created a lowercase realm for
> Stanford, and repeatedly has said that if he had to do it all over again
> he wouldn't have done a lowercase realm; too much software assumes an
> uppercase realm.  Maybe that has changed in the intervening years.

It worked okay (still is, so far as I know), but all the documentation
everywhere was "wrong" and it definitely wasn't worth the confusion.  We
never tried having realms that only differed in case, though.  That really
would have broken all DNS-based service discovery, etc.

--
Russ Allbery ([hidden email])              <http://www.eyrie.org/~eagle/>
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: A client name with an '@'

Simo Sorce-3
In reply to this post by Nordgren, Bryce L -FS
On Wed, 2015-06-03 at 17:07 +0000, Nordgren, Bryce L -FS wrote:

> > Or hack on the KDCs to implement AD-style case-insensitive/preserving
> > realm matching.  I'm starting to think that we ought to do this in Heimdal and
> > MIT Kerberos, at least as an option.
>
> This plus canonicalizing is how our corporate system might work. I
> don't think there's a FEDIDCARD.GOV realm (or fedidcard.gov either)
> outside the scope of my PKINIT test. I think our corporate AD sees
> users from that domain and knows (somehow) how to map them into the
> USDA.NET realm. Klist has never shown me a FEDIDCARD.GOV ticket on my
> windows box, and I can't locate a FEDIDCARD.GOV KDC inside or outside
> the firewall.
>
> Maybe canonicalizing isn't the right word for this..."appropriating
> user identities from unrelated virtual realms" may be more
> descriptive.
>
> I had nothing to do with it. :)

In AD there is a mapping function to know which user a certificate
belongs to. AD does not care at all about the name you have in there
outside the mapping. Once mapped what matters is the UPN on the user
account, IIRC.

Simo.

--
Simo Sorce * Red Hat, Inc * New York

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos