12

When using kinit to acquire a Kerberos ticket I have configured it to use a default realm, e.g. GERT.LAN by editing /etc/krb5.conf:

[libdefaults]
        default_realm = GERT.LAN

That's great since I don't have to supply that all the time on the command line.

⟫ kinit
gert@GERT.LAN's Password:

However, my local username gert does not match the remote username gertvdijk. Now I have to supply the full principal name as an argument still. If this is just kinit I could create a bash alias, but more Kerberos tools appear to try my local username. For example Kredentials does not allow me to use another than default principal.

So, basically, what I want is to create a mapping between the local user gert and the remote principal gertvdijk@GERT.LAN.

Ironically, when using a more complicated setup with PAM I am able to achieve this. In krb5.conf:

[appdefaults]
        pam = {
                mappings = gert gertvdijk@GERT.LAN
        }

But I don't want to use the Kerberos PAM module anymore since I've locked out myself so many times by thinking the Kerberos server isn't reachable and I'm trying to enter the local password...

So, long story short, is there a way to configure a default principal or a mapping from local usernames?

gertvdijk
  • 67,007
  • 33
  • 188
  • 283

3 Answers3

4

The default principal can be set in ~/.k5identity

$ cat .k5identity
user@EXAMPLE.COM

Then kinit will use it as a default identity.

Misc
  • 1,072
  • 6
  • 11
  • Sweet! Also more configuration is possible I see: http://web.mit.edu/kerberos/krb5-devel/doc/user/user_config/k5identity.html – gertvdijk Jun 15 '14 at 13:32
  • Just set up kerberos on my machine pointing to institute kdc to test this. Doesn't work for me. :( – Mahesh Jun 15 '14 at 13:56
  • Setting realm value alongside principal works. – Mahesh Jun 15 '14 at 14:00
  • 3
    Does not work for me in practice; still selects `gert@GERT.LAN` as principal. I'm using the `heimdal-clients` package providing me `/usr/bin/kinit`. The MIT version appears not to work on the Windows domain, so I can't test that. – gertvdijk Jun 16 '14 at 08:17
  • 2
    It also does not work wit MIT krb5's kinit as of now. `kinit` will not take this file into account. I believe the documentation mentions that this is for requesting tickets for a service, not when requesting the initial TGT. Bummer. – gertvdijk May 16 '18 at 18:32
  • 2
    This does not work (anymore). – Michael-O Mar 14 '19 at 09:15
1

I belive currently there is no solution for that. From the kinit man page:

kinit obtains and caches an initial ticket-granting ticket for principal.
If principal is absent, kinit chooses an appropriate principal name based
on existing credential cache contents or the local username of the user in‐
voking kinit. Some options modify the choice of principal name.

meaning you have to use an option at least once at the first time, later the user from the existing (but may be expired) ticket will be used.

But at least you can have a workaround for it, like:

alias kinit='/usr/bin/kinit $KRB_USER'

which falls back to the original in case the KRB_USER is not defined.

redseven
  • 642
  • 1
  • 7
  • 12
0

Use a default realm and use a user mapping in your /etc/krb5.conf like this:

[libdefaults]
    default_realm = GERT.LAN

[realms]
    GERT.LAN = {
        auth_to_local_names = {
            gert = gert.vandijk
        }
    }

Now kinit/kpasswd will map this when invoking it as the local user and map that to a domain username.

gertvdijk
  • 67,007
  • 33
  • 188
  • 283
  • Hmm, this did not survive a reboot somehow. Will investigate further at a later time. – gertvdijk May 17 '18 at 08:45
  • 1
    Isn't `auth_to_local_names` the *opposite* of what you described? It [specifies](https://web.mit.edu/kerberos/www/krb5-latest/doc/admin/host_config.html) *"explicit mappings from principal names to local accounts"*. – Jonathon Reinhart Jun 02 '21 at 01:32