Multiple principals from different realms via kinit?

[ольга крыжановская]

How can I use multiple principals from different realms via kinit?

I tried:
kinit fle...@WARONTERROR.COM
...
klist shows tgt for fle...@WARONTERROR.COM

now I do the same for ol...@MYLAPTOP.COM but klist only shows the tgt
for ol...@MYLAPTOP.COM, the tgt for fle...@WARONTERROR.COM is no longer
listed.

Why? How can I use both at the same time?

Olga
--
, _ _ ,
{ \/`o;====- Olga Kryzhanovska -====;o`\/ }
.----'-/`-/ olga.kry...@gmail.com \-`\-'----.
`'-..-| / http://twitter.com/fleyta \ |-..-'`
/\/\ Solaris/BSD//C/C++ programmer /\/\
`--` `--`

[Rick van Rein]

Hi Olga,

> Why? How can I use both at the same time?

What is shown is your current identity � that�s only one.

Try kswitch (possibly with -i) to switch what is your current identity. The others are still available, but not shown.

-Rick

[Benjamin Kaduk]

On Wed, 27 Aug 2014, ольга крыжановская wrote:

> How can I use multiple principals from different realms via kinit?
>
> I tried:
> kinit fle...@WARONTERROR.COM
> ...
> klist shows tgt for fle...@WARONTERROR.COM

klist -A shows tickets in all caches in the collection, not just the
current cache (as klist without -A does). You'll generally want to be
using a collection-enabled cache type such as DIR: or a post-1.12 KEYRING:
in order to get the best behavior when using multiple client principals.

As mentioned already, kswitch is also useful in these situations.

-Ben

[ольга крыжановская]

How do I enable collections? How does the output of klist/klist -A
look like if the feature is working?

Olga

[Cedric Blancher]

On 27 August 2014 18:16, Benjamin Kaduk <ka...@mit.edu> wrote:
> On Wed, 27 Aug 2014, ольга крыжановская wrote:
>
>> How can I use multiple principals from different realms via kinit?
>>
>> I tried:
>> kinit fle...@WARONTERROR.COM
>> ...
>> klist shows tgt for fle...@WARONTERROR.COM
>
> klist -A shows tickets in all caches in the collection, not just the
> current cache (as klist without -A does). You'll generally want to be
> using a collection-enabled cache type such as DIR: or a post-1.12 KEYRING:
> in order to get the best behavior when using multiple client principals.
>
> As mentioned already, kswitch is also useful in these situations.

How do services like NFSv4, HTTP/spnego or GSSAPI know which of the
entries is the one they want?

Ced
--
Cedric Blancher <cedric....@gmail.com>
Institute Pasteur

[Simo Sorce]

They'll make a guess based on the realm, or pick the primary.

Simo.

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

[Cedric Blancher]

How do they 'guess'?

Is it possible to get rid of the notion of a primary one day?

[Greg Hudson]

On 08/28/2014 06:05 AM, ольга крыжановская wrote:
> How do I enable collections?

Set KRB5CCNAME to use a collection-enabled cache type, typically DIR.
For example:

mkdir /tmp/mydir
KRB5CCNAME=DIR:/tmp/mydir
export KRB5CCNAME
kinit princ1
klist # shows princ1 tickets in DIR::/tmp/mydir/tktXXXXX
kinit princ2
klist # shows princ2 tickets in DIR::/tmp/mydir/tktYYYYY
klist -l # shows a list with both ccaches
klist -A # shows tickets in both ccaches
kswitch -p princ1
klist # shows princ1 tickets

If klist shows a FILE ccache, then collection behavior are not enabled,
and only the most recently-acquired tickets can be used.

[Greg Hudson]

On 08/28/2014 10:17 AM, Cedric Blancher wrote:
>>> How do services like NFSv4, HTTP/spnego or GSSAPI know which of the
>>> entries is the one they want?

NFS is a special case, as the program making the decision doesn't have
access to the environment of the process which made the filesystem call.
I'm not sure what the state of the art is here; typically gssd needs
some knowledge of where the login system puts credentials, and it might
make a choice based on the username.

>> They'll make a guess based on the realm, or pick the primary.
>
> How do they 'guess'?

If an application doesn't specify a client name, there are three
mechanisms in order of priority:

1. The .k5identity file allows you to configure a client principal based
on the target principal. See:
http://web.mit.edu/kerberos/krb5-latest/doc/user/user_config/k5identity.html

2. If the realm of the target service is known via a [domain_realm]
mapping in krb5.conf, a client principal in that realm will be selected.

3. The primary cache.

It is also possible to write a plugin module which controls ccache
selection, but I'm not aware of anyone doing so.

You can also set KRB5CCNAME to the name of a subsidiary cache within the
collection, to control the choice for a particular process.

> Is it possible to get rid of the notion of a primary one day?

It might be possible, but why would we want to?

[Nordgren, Bryce L -FS]

> -----Original Message-----
> From: kerberos...@mit.edu [mailto:kerberos...@mit.edu] On
> Behalf Of Greg Hudson
> Sent: Thursday, August 28, 2014 10:30 AM
> To: Cedric Blancher; <kerb...@mit.edu>
> Subject: Re: Multiple principals from different realms via kinit?
>
> NFS is a special case, as the program making the decision doesn't have access
> to the environment of the process which made the filesystem call.
> I'm not sure what the state of the art is here; typically gssd needs some
> knowledge of where the login system puts credentials, and it might make a
> choice based on the username.

I think the golden rule is that each application must be self-consistent, repeatable and deterministic, but not necessarily the same. NFS is special not only for the reason mentioned above, but also because it supports three way mapping between GSS Auth Name (Kerberos principal), local system ID, and a "portable" NFS ID. It also supports a many-to-one mapping from gss auth names to local system ID/NFS ID. Many to one means that once you provide a Kerberos principal, there really is no choice about which Local ID or NFS ID are used. NFS doesn't perform initial authentication, so it doesn't have to worry about the reverse process.

Sssd allows for static configuration of domains, each of which has a one-to-one mapping between local ID and Kerberos principal. The mapping is performed by a configurable regexp. Connection information for the KDC in each domain may be overridden.

Apache's mod_auth_kerb provides the authenticated Kerberos principal (name@REALM) as the REMOTE_USER variable, which applications can remap to usernames as they please (http://www.mediawiki.org/wiki/Extension:LDAP_Authentication/Kerberos_Configuration_Examples).

So the short answer is: it's application dependent. The onus is on the application to translate a Kerberos principal into an identity locally meaningful. However, the application doesn't have access to your credential cache. If you (or the client you're using) supply an identity that the application doesn't (can't) recognize, then expect it to fail. The client side of the application protocol should make it a point to try all your cached identities and/or allow you to specify one you haven't "kinit"ed yet.

Bryce






This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately.

[Martin]

Do the mechanisms you list work for constrained delegation?
krb5 version: 1.16.1

I'm testing with t_s4u using the same approach above ( KRB5CCNAME=DIR:/tmp/mydir) etc.

My tests always use #3 (last kinit command run or kswitch). I'd really like to use #2 if possible.
I can't seem to get the .k5identity or realm of target service to heuristic(s) to kick in.
NOTE: each keytab has been successfully tested using FILE: or DIR (being the last kinit)

/etc/krb5.conf
#START krb5.conf
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log

[libdefaults]
default_realm = UICSYNERGY.BIZ
dns_lookup_realm = true
dns_lookup_kdc = true
dns_canonicalize_hostname = false
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
default_client_keytab_name = /etc/krb5.keytab

[realms]
UICSYNERGY.BIZ = {
kdc = uicsynergy.biz
default_domain = uicsynergy.biz
}
ICSYNERGY.NET = {
kdc = icsynergy.net
default_domain = icsynergy.net
}

[domain_realm]
.uicsynergy.biz = UICSYNERGY.BIZ
uicsynergy.biz = UICSYNERGY.BIZ
.icsynergy.net = ICSYNERGY.NET
icsynergy.net = ICSYNERGY.NET
#END krb5.conf

Steps:
Create a keytab on each AD DC.

$ mkdir /tmp/mydir
$ export KRB5CCNAME=DIR:/tmp/mydir
$ kinit -k -t ./spgateway_icsynergy_net.keytab host/gw.icsyn...@ICSYNERGY.NET
$ kinit -k -t ./spgateway_uicsynergy_biz.keytab host/gw.icsyn...@UICSYNERGY.BIZ
$ klist -A
Ticket cache: DIR::/tmp/mydir/tktCzQyfj
Default principal: host/gw.icsyn...@UICSYNERGY.BIZ

Valid starting Expires Service principal
07/24/2018 16:49:20 07/25/2018 02:49:20 krbtgt/UICSYNE...@UICSYNERGY.BIZ
renew until 07/31/2018 16:49:20

Ticket cache: DIR::/tmp/mydir/tktVQeLF4
Default principal: host/gw.icsyn...@ICSYNERGY.NET

Valid starting Expires Service principal
07/24/2018 16:48:47 07/25/2018 02:48:47 krbtgt/ICSYNE...@ICSYNERGY.NET
renew until 07/31/2018 16:48:47

>> WORKS
$ /opt/spgateway/bin/t_s4u u:tus...@UICSYNERGY.BIZ h:HT...@ics-dc-2.uicsynergy.biz ./spgateway_uicsynergy_biz.keytab
<< WORKS

>> FAILS
$ /opt/spgateway/bin/t_s4u u:tus...@ICSYNERGY.NET h:HT...@ics-dc-1.icsynergy.net ./spgateway_icsynergy_net.keytab
Protocol transition tests follow
-----------------------------------

[25007] 1532451100.523203: Getting credentials tus...@ICSYNERGY.NET -> host/gw.icsyn...@UICSYNERGY.BIZ using ccache DIR::/tmp/mydir/tktCzQyfj
[25007] 1532451100.523204: Retrieving tus...@ICSYNERGY.NET -> host/gw.icsyn...@UICSYNERGY.BIZ from DIR::/tmp/mydir/tktCzQyfj with result: -1765328243/Matching credential not found (filename: /tmp/mydir/tktCzQyfj)
[25007] 1532451100.523205: Getting credentials host/gw.icsyn...@UICSYNERGY.BIZ -> krbtgt/ICSYNE...@UICSYNERGY.BIZ using ccache DIR::/tmp/mydir/tktCzQyfj
[25007] 1532451100.523206: Retrieving host/gw.icsyn...@UICSYNERGY.BIZ -> krbtgt/ICSYNE...@UICSYNERGY.BIZ from DIR::/tmp/mydir/tktCzQyfj with result: -1765328243/Matching credential not found (filename: /tmp/mydir/tktCzQyfj)
[25007] 1532451100.523207: Retrieving host/gw.icsyn...@UICSYNERGY.BIZ -> krbtgt/UICSYNE...@UICSYNERGY.BIZ from DIR::/tmp/mydir/tktCzQyfj with result: 0/Success
[25007] 1532451100.523208: Starting with TGT for client realm: host/gw.icsyn...@UICSYNERGY.BIZ -> krbtgt/UICSYNE...@UICSYNERGY.BIZ
[25007] 1532451100.523209: Requesting tickets for krbtgt/ICSYNE...@UICSYNERGY.BIZ, referrals on
[25007] 1532451100.523210: Generated subkey for TGS request: aes256-cts/B5F0
[25007] 1532451100.523211: etypes requested in TGS request: aes256-cts, aes128-cts, aes256-sha2, aes128-sha2, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts
[25007] 1532451100.523213: Encoding request body and padata into FAST request
[25007] 1532451100.523214: Sending request (1769 bytes) to UICSYNERGY.BIZ
[25007] 1532451100.523215: Resolving hostname uicsynergy.biz
[25007] 1532451100.523216: Initiating TCP connection to stream 192.168.0.180:88
[25007] 1532451100.523217: Sending TCP request to stream 192.168.0.180:88
[25007] 1532451100.523218: Received answer (99 bytes) from stream 192.168.0.180:88
[25007] 1532451100.523219: Terminating TCP connection to stream 192.168.0.180:88
[25007] 1532451100.523220: Sending DNS URI query for _kerberos.UICSYNERGY.BIZ.
[25007] 1532451100.523221: No URI records found
[25007] 1532451100.523222: Sending DNS SRV query for _kerberos-master._udp.UICSYNERGY.BIZ.
[25007] 1532451100.523223: Sending DNS SRV query for _kerberos-master._tcp.UICSYNERGY.BIZ.
[25007] 1532451100.523224: No SRV records found
[25007] 1532451100.523225: Response was not from master KDC
[25007] 1532451100.523226: TGS request result: -1765328377/Server not found in Kerberos database
[25007] 1532451100.523227: Requesting tickets for krbtgt/ICSYNE...@UICSYNERGY.BIZ, referrals off
[25007] 1532451100.523228: Generated subkey for TGS request: aes256-cts/30A5
[25007] 1532451100.523229: etypes requested in TGS request: aes256-cts, aes128-cts, aes256-sha2, aes128-sha2, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts
[25007] 1532451100.523231: Encoding request body and padata into FAST request
[25007] 1532451100.523232: Sending request (1769 bytes) to UICSYNERGY.BIZ
[25007] 1532451100.523233: Resolving hostname uicsynergy.biz
[25007] 1532451100.523234: Initiating TCP connection to stream 192.168.0.180:88
[25007] 1532451100.523235: Sending TCP request to stream 192.168.0.180:88
[25007] 1532451100.523236: Received answer (99 bytes) from stream 192.168.0.180:88
[25007] 1532451100.523237: Terminating TCP connection to stream 192.168.0.180:88
[25007] 1532451100.523238: Sending DNS URI query for _kerberos.UICSYNERGY.BIZ.
[25007] 1532451100.523239: No URI records found
[25007] 1532451100.523240: Sending DNS SRV query for _kerberos-master._udp.UICSYNERGY.BIZ.
[25007] 1532451100.523241: Sending DNS SRV query for _kerberos-master._tcp.UICSYNERGY.BIZ.
[25007] 1532451100.523242: No SRV records found
[25007] 1532451100.523243: Response was not from master KDC
[25007] 1532451100.523244: TGS request result: -1765328377/Server not found in Kerberos database
gss_acquire_cred_impersonate_name: Unspecified GSS failure. Minor code may provide more information
gss_acquire_cred_impersonate_name: Server not found in Kerberos database

<< FAILS