Bug 1423871

Now that sssd-kcm is available, adcli ideally should also support this ccache type.

Thorsten,

do you remember under which circumstances adcli only was able to use FILE ccaches? I tried to reproduce and it worked well e.g. with KEYRING (see below). Maybe only the help output and the man page must be updated to better reflect that all ccaches types are supported?


[root@rhel74 ~]# kinit admin
Password for admin: 
[root@rhel74 ~]# klist
Ticket cache: KEYRING:persistent:0:0
Default principal: admin

Valid starting       Expires              Service principal
11.09.2017 10:56:17  12.09.2017 10:56:15  krbtgt/IPAF26.DEVEL
[root@rhel74 ~]# KRB5_TRACE=/dev/stdout adcli join --login-ccache ad.devel -v
 * Using domain name: ad.devel
 * Calculated computer account name from fqdn: RHEL74
 * Calculated domain realm from name: AD.DEVEL
 * Discovering domain controllers: _ldap._tcp.ad.devel
 * Sending netlogon pings to domain controller: cldap://192.168.122.166
 * Received NetLogon info from: ad-server.ad.devel
 * Discovering site domain controllers: _ldap._tcp.._sites.dc._msdcs.ad.devel
 ! Couldn't resolve SRV site records: _ldap._tcp.._sites.dc._msdcs.ad.devel: Non-recoverable failure in name resolution
 * Wrote out krb5.conf snippet to /tmp/adcli-krb5-QvS6NB/krb5.d/adcli-krb5-conf-kN8KPQ
[14434] 1505141792.500500: Getting credentials admin -> ldap/ad-server.ad.devel using ccache KEYRING:persistent:0:0
[14434] 1505141792.500562: Retrieving admin -> ldap/ad-server.ad.devel from KEYRING:persistent:0:0 with result: -1765328243/Matching credential not found
[14434] 1505141792.500585: Retrieving admin -> krbtgt/AD.DEVEL from KEYRING:persistent:0:0 with result: -1765328243/Matching credential not found
[14434] 1505141792.500606: Retrieving admin -> krbtgt/IPAF26.DEVEL from KEYRING:persistent:0:0 with result: 0/Success
[14434] 1505141792.500609: Starting with TGT for client realm: admin -> krbtgt/IPAF26.DEVEL
[14434] 1505141792.500632: Retrieving admin -> krbtgt/AD.DEVEL from KEYRING:persistent:0:0 with result: -1765328243/Matching credential not found
[14434] 1505141792.500635: Requesting TGT krbtgt/AD.DEVEL using TGT krbtgt/IPAF26.DEVEL
[14434] 1505141792.500668: Generated subkey for TGS request: aes256-cts/53E1
[14434] 1505141792.500700: etypes requested in TGS request: aes256-cts, aes128-cts, aes256-sha2, aes128-sha2, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts
[14434] 1505141792.500761: Encoding request body and padata into FAST request
[14434] 1505141792.500799: Sending request (1473 bytes) to IPAF26.DEVEL
[14434] 1505141792.500928: Initiating TCP connection to stream 192.168.122.225:88
[14434] 1505141792.501343: Sending TCP request to stream 192.168.122.225:88
[14434] 1505141792.503520: Received answer (1417 bytes) from stream 192.168.122.225:88
[14434] 1505141792.503528: Terminating TCP connection to stream 192.168.122.225:88
[14434] 1505141792.503579: Response was from master KDC
[14434] 1505141792.503595: Decoding FAST response
[14434] 1505141792.503672: FAST reply key: aes256-cts/52D2
[14434] 1505141792.503694: TGS reply is for admin -> krbtgt/AD.DEVEL with session key aes256-cts/99AA
[14434] 1505141792.503707: TGS request result: 0/Success
[14434] 1505141792.503712: Storing admin -> krbtgt/AD.DEVEL in KEYRING:persistent:0:0
[14434] 1505141792.503822: Received TGT for AD.DEVEL; advancing current realm
[14434] 1505141792.503853: Retrieving admin -> krbtgt/AD.DEVEL from KEYRING:persistent:0:0 with result: 0/Success
[14434] 1505141792.503856: Found cached TGT for intermediate realm: admin -> krbtgt/AD.DEVEL
[14434] 1505141792.503859: Requesting tickets for ldap/ad-server.ad.devel, referrals on
[14434] 1505141792.503872: Generated subkey for TGS request: aes256-cts/2F99
[14434] 1505141792.503889: etypes requested in TGS request: aes256-cts, aes128-cts, aes256-sha2, aes128-sha2, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts
[14434] 1505141792.503921: Encoding request body and padata into FAST request
[14434] 1505141792.503954: Sending request (1496 bytes) to AD.DEVEL
[14434] 1505141792.503966: Resolving hostname ad-server.ad.devel
[14434] 1505141792.504561: Initiating TCP connection to stream 192.168.122.166:88
[14434] 1505141792.504849: Sending TCP request to stream 192.168.122.166:88
[14434] 1505141792.505944: Received answer (1233 bytes) from stream 192.168.122.166:88
[14434] 1505141792.505950: Terminating TCP connection to stream 192.168.122.166:88
[14434] 1505141792.505974: Response was from master KDC
[14434] 1505141792.505982: Decoding FAST response
[14434] 1505141792.506022: TGS reply is for admin -> ldap/ad-server.ad.devel with session key aes256-cts/4838
[14434] 1505141792.506033: TGS request result: 0/Success
[14434] 1505141792.506035: Received creds for desired service ldap/ad-server.ad.devel
[14434] 1505141792.506038: Storing admin -> ldap/ad-server.ad.devel in KEYRING:persistent:0:0
[14434] 1505141792.506166: Creating authenticator for admin -> ldap/ad-server.ad.devel, seqnum 818542917, subkey aes256-cts/2BAA, session key aes256-cts/4838
[14434] 1505141792.511074: Read AP-REP, time 1505141792.506181, subkey aes256-cts/DAB5, seqnum 839527403
 * Looked up short domain name: AD
 * Using fully qualified name: rhel74.test.devel
 * Using domain name: ad.devel

(In reply to Sumit Bose from comment #3)
> Thorsten,
> 
> do you remember under which circumstances adcli only was able to use FILE
> ccaches? I tried to reproduce and it worked well e.g. with KEYRING (see
> below). Maybe only the help output and the man page must be updated to
> better reflect that all ccaches types are supported?

The man page says:

"""
 -C, --login-ccache=/path/to/file
           Use the specified kerberos credential cache to authenticate with the domain.
"""

So I expected a file path is needed to point the tool to the desired cache.

> [root@rhel74 ~]# kinit admin
> Password for admin: 
> [root@rhel74 ~]# klist
> Ticket cache: KEYRING:persistent:0:0
> Default principal: admin
> 
> Valid starting       Expires              Service principal
> 11.09.2017 10:56:17  12.09.2017 10:56:15  krbtgt/IPAF26.DEVEL
> [root@rhel74 ~]# KRB5_TRACE=/dev/stdout adcli join --login-ccache ad.devel -v

Here no cache has been specified. Which one is actually used in case you have multiple caches in a larger collection?

(In reply to Thorsten Scherf from comment #4)
> (In reply to Sumit Bose from comment #3)
> > Thorsten,
> > 
> > do you remember under which circumstances adcli only was able to use FILE
> > ccaches? I tried to reproduce and it worked well e.g. with KEYRING (see
> > below). Maybe only the help output and the man page must be updated to
> > better reflect that all ccaches types are supported?
> 
> The man page says:
> 
> """
>  -C, --login-ccache=/path/to/file
>            Use the specified kerberos credential cache to authenticate with
> the domain.
> """
> 
> So I expected a file path is needed to point the tool to the desired cache.

ok, so this is a man page issue.

> 
> > [root@rhel74 ~]# kinit admin
> > Password for admin: 
> > [root@rhel74 ~]# klist
> > Ticket cache: KEYRING:persistent:0:0
> > Default principal: admin
> > 
> > Valid starting       Expires              Service principal
> > 11.09.2017 10:56:17  12.09.2017 10:56:15  krbtgt/IPAF26.DEVEL
> > [root@rhel74 ~]# KRB5_TRACE=/dev/stdout adcli join --login-ccache ad.devel -v
> 
> Here no cache has been specified. Which one is actually used in case you
> have multiple caches in a larger collection?

This is selected by libkrb5. First libkrb5 searches for a principal from the same realm as the requested service which would also be the typical adcli case if a collection is used. If there is no principal from the same realm the currently active one will be used. If this is not the right one the use can use kswitch.

(In reply to Sumit Bose from comment #5)
> (In reply to Thorsten Scherf from comment #4)
> > (In reply to Sumit Bose from comment #3)
> > > Thorsten,
> > > 
> > > do you remember under which circumstances adcli only was able to use FILE
> > > ccaches? I tried to reproduce and it worked well e.g. with KEYRING (see
> > > below). Maybe only the help output and the man page must be updated to
> > > better reflect that all ccaches types are supported?
> > 
> > The man page says:
> > 
> > """
> >  -C, --login-ccache=/path/to/file
> >            Use the specified kerberos credential cache to authenticate with
> > the domain.
> > """
> > 
> > So I expected a file path is needed to point the tool to the desired cache.
> 
> ok, so this is a man page issue.

Ack.

> > 
> > > [root@rhel74 ~]# kinit admin
> > > Password for admin: 
> > > [root@rhel74 ~]# klist
> > > Ticket cache: KEYRING:persistent:0:0
> > > Default principal: admin
> > > 
> > > Valid starting       Expires              Service principal
> > > 11.09.2017 10:56:17  12.09.2017 10:56:15  krbtgt/IPAF26.DEVEL
> > > [root@rhel74 ~]# KRB5_TRACE=/dev/stdout adcli join --login-ccache ad.devel -v
> > 
> > Here no cache has been specified. Which one is actually used in case you
> > have multiple caches in a larger collection?
> 
> This is selected by libkrb5. First libkrb5 searches for a principal from the
> same realm as the requested service which would also be the typical adcli
> case if a collection is used. If there is no principal from the same realm
> the currently active one will be used. If this is not the right one the use
> can use kswitch.

Alright. Thank you for the explanation. Let's turn this BZ into a doc (man-page) bug then.

I updated the description and the keywords a bit to reflect the scope of this ticket.

version:
adcli-0.8.1-4.el7.x86_64

Steps:
1. man adcli  and search for --login-ccache

Actual result:
....
....
-C, --login-ccache=ccache_name
           Use the specified kerberos credential cache to authenticate with the domain. If no credential cache is specified, the default kerberos credential cache will
           be used. Credential caches of type FILE can be given with the path to the file. For other credential cache types, e.g. DIR, KEYRING or KCM, the type must be specified explicitly together with a suitable identifier.
...
...

Based on above observation marking this bug as verified.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:0966

There is definitely a bug, it's just not with "join", but with any other command that accepts "--logic-ccache", e.g. with "create-group".

There are actually two bugs and not just one:

1. "--login-ccache" does not accept arguments in its short form (-C) neither as an argument to its long form (the long form with '=' actually works)
2. "--login-ccache" with no argument is only looking into the in-process cache store, which is obviously not populated.
===
bash-4.2# echo $AD_PASS | kinit -V -l 600 -r 600 -f -P  Administrator
Using existing cache: persistent:0:0
Using principal: Administrator
Password for Administrator: 
Authenticated to Kerberos v5
bash-4.2# klist
Ticket cache: KEYRING:persistent:0:0
Default principal: Administrator

Valid starting     Expires            Service principal
04/22/19 20:50:08  04/22/19 21:00:08  krbtgt/AD.TEST
        renew until 04/22/19 21:00:08
bash-4.2# KRB5_TRACE=/dev/stdout adcli create-group -C KEYRING:persistent:0:0 --domain ad.test -v tempgroup
adcli: specify one group to create
bash-4.2# KRB5_TRACE=/dev/stdout adcli create-group --login-ccache KEYRING:persistent:0:0 --domain ad.test -v tempgroup
adcli: specify one group to create
bash-4.2# KRB5_TRACE=/dev/stdout adcli create-group --login-ccache --domain ad.test -v tempgroup
 * Using domain name: ad.test
 * Calculated computer account name from fqdn: IP-10-0-3-150
 * Calculated domain realm from name: AD.TEST
 * Discovering domain controllers: _ldap._tcp.ad.test
 * Sending netlogon pings to domain controller: cldap://10.0.1.126
 * Received NetLogon info from: aws-aecdfc6a54.ad.test
 * Wrote out krb5.conf snippet to /tmp/adcli-krb5-vxAEOM/krb5.d/adcli-krb5-conf-YxlsSu
[13925] 1555966257.27726: Resolving unique ccache of type MEMORY
Password for Administrator:
===