Hey Tim,
>> Have you tried using kinit without --canonicalize against AD, while
>> playing around with the case?
> Yes, kinit NAME results in NAME@REALM principal in cache. kinit name results
> in name@REALM. This is what I am trying to avoid since I want a consistent
> principal name using the case of the principal defined in AD.
Of course you do.
>> Have you checked the ticket names in Keychain Access, menu item Ticket
>> Viewer? It may have been setup with your logon name or such, in
>> different case, and accepted as such by AD.
> This is same as using klist from Terminal which I have been using so I
> haven’t bothered with Ticket Viewer as it has no advantage compared to using
> klist to check case of principal.
I don't believe that's true -- my Ticket Viewer also contains other
user@REALM names than what kinit or kswitch show. IOW, it defines
ticket login names.
FWIW, you can specify enterprise-styled names using
user\@realm.name@REALM. These are strongly connected to
canonicalization, though I don't know if that will prove helpful here.
The classical method on Mac OS X appears to rely on the now-gone Mac OS
X Server technology, or more generally on LDAP:
default_principal Construct the principal from the authenticating
user's username, rather than obtaining it from the
AuthenticationAuthority of the user's OpenDirec-
tory record.
Yes, pam_krb5 is being used but I don’t know how to configure pam_krb5 so that
it sends the canonical flag in the as-req so that AD will issue TGT with
correct case.
I don't know anything more either, sorry.
>> Try the suggestions above first, they're a better way to get it going.
>> Rather than "making it work" you'll be asking the proper question. I
>> hope -- I don't use AD.
> I know I can create the user in Mac with same case as in AD and this will
> solve the issue but often the AD admin who creates the user in AD doesn’t use
> same case.
And you probably also know that it is possible in UNIX in general to
specify multiple usernames with the same uid/gid etc. in /etc/passwd,
and you could login as the 2nd entry and end up with the 1st for all
local purposes.
Sorry I can't help any further.
-Rick
________________________________________________
Kerberos mailing list [email protected]
https://mailman.mit.edu/mailman/listinfo/kerberos
