RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1423871 - adcli man page should not only mention FILE type credential caches
Summary: adcli man page should not only mention FILE type credential caches
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: adcli
Version: 7.3
Hardware: All
OS: Linux
unspecified
low
Target Milestone: rc
: ---
Assignee: Sumit Bose
QA Contact: ipa-qe
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-02-17 15:04 UTC by Thorsten Scherf
Modified: 2019-04-22 20:59 UTC (History)
6 users (show)

Fixed In Version: adcli-0.8.1-4.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-04-10 18:13:14 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2018:0966 0 None None None 2018-04-10 18:13:30 UTC

Description Thorsten Scherf 2017-02-17 15:04:20 UTC 
Description of problem:

The adcli option "--login-ccache" only supports a FILE type Kerberos credential cache. Ideally it should also support other cache types like KEYRING.

Version-Release number of selected component (if applicable):


How reproducible:
adcli-0.8.1-3.el7.x86_64

Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:
Comment 1 Thorsten Scherf 2017-08-16 12:33:55 UTC 
Now that sssd-kcm is available, adcli ideally should also support this ccache type.
Comment 3 Sumit Bose 2017-09-11 15:00:27 UTC 
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
Comment 4 Thorsten Scherf 2017-09-11 15:16:43 UTC 
(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?
Comment 5 Sumit Bose 2017-09-11 16:33:46 UTC 
(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.
Comment 6 Thorsten Scherf 2017-09-12 09:53:35 UTC 
(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.
Comment 7 Sumit Bose 2017-09-12 11:41:41 UTC 
I updated the description and the keywords a bit to reflect the scope of this ticket.
Comment 9 Mohammad Rizwan 2017-12-05 12:21:18 UTC 
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.
Comment 12 errata-xmlrpc 2018-04-10 18:13:14 UTC 
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
Comment 13 (GalaxyMaster) 2019-04-22 20:59:15 UTC 
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:
===
Note You need to log in before you can comment on or make changes to this bug.