#9677 Refactor ipalib cookie storage
Opened 4 months ago by abbra. Modified 4 months ago

In multiple realm use case ipalib.rpc uses default Kerberos principal from the credentials collection to identify where to store or from where to load a session cookie. This is not necessary the same principal that would be used for communicating with an IPA server. It leads to a situation where a cookie gets stored and associated with a principal from a wrong realm.

[root@master1 ~]# kinit admin@IPA2.TEST
Password for admin@IPA2.TEST: 
[root@master1 ~]# kinit admin@IPA1.TEST
Password for admin@IPA1.TEST: 
[root@master1 ~]# klist
Ticket cache: KCM:0
Default principal: admin@IPA1.TEST

Valid starting       Expires              Service principal
10/02/2024 10:06:25  10/03/2024 09:21:51  krbtgt/IPA1.TEST@IPA1.TEST
[root@master1 ~]# klist -A
Ticket cache: KCM:0
Default principal: admin@IPA1.TEST

Valid starting       Expires              Service principal
10/02/2024 10:06:25  10/03/2024 09:21:51  krbtgt/IPA1.TEST@IPA1.TEST

Ticket cache: KCM:0:94394
Default principal: admin@IPA2.TEST

Valid starting       Expires              Service principal
10/02/2024 10:06:17  10/03/2024 09:30:48  krbtgt/IPA2.TEST@IPA2.TEST
[root@master1 ~]# kswitch -p admin@IPA2.TEST
[root@master1 ~]# ipa -d ping
[...]
ipa: DEBUG: [try 1]: Forwarding 'ping/1' to json server 'https://master1.ipa1.test/ipa/session/json'
ipa: DEBUG: New HTTP connection (master1.ipa1.test)
ipa: DEBUG: Destroyed connection context.rpcclient_140631705151024
----------------------------------------------------------------
IPA server version 4.13.0.dev202409271442+git. API version 2.255
----------------------------------------------------------------
[root@master1 ~]# klist -AC
Ticket cache: KCM:0:94394
Default principal: admin@IPA2.TEST

Valid starting       Expires              Service principal
10/02/2024 10:06:17  10/03/2024 09:30:48  krbtgt/IPA2.TEST@IPA2.TEST
config: fast_avail(krbtgt/IPA2.TEST@IPA2.TEST) = yes
config: pa_type(krbtgt/IPA2.TEST@IPA2.TEST) = 151
config: X-IPA-Session-Cookie(admin@IPA2.TEST) = ipa_session=MagBearerToke
        n=FWLfeuSCo%2bALdHh0daCS5rPeJXIvMflKg1SM7awTfHZfHmNke3VZ9ioA3830j
        4NtZRzl9I5ls4a6UAAbqQHkfOqVPTuuIZGzz3v0anKbGqYqB4pNO8edlbYaoANE2k
        deIA%2fRnv%2f21Zth9rOcRcEnHQFJZAAy%2bhO8H4zDh%2f%2ftFFyonNfKn4cBD
        NYiGdsPWOi1;\000

Ticket cache: KCM:0
Default principal: admin@IPA1.TEST

Valid starting       Expires              Service principal
10/02/2024 10:06:25  10/03/2024 09:21:51  krbtgt/IPA1.TEST@IPA1.TEST
config: fast_avail(krbtgt/IPA1.TEST@IPA1.TEST) = yes
config: pa_type(krbtgt/IPA1.TEST@IPA1.TEST) = 151
10/02/2024 10:06:41  10/03/2024 09:21:51  HTTP/master1.ipa1.test@IPA1.TEST

In the example above admin@IPA2.TEST is the default principal in the collection and its ccache gets the cookie stored even though the cookie is from IPA1.TEST realm because ipa ping command was talking to master1.ipa1.test and retrieved service ticket to HTTP/master1.ipa1.test@IPA1.TEST.


We need:

  • to discover proper target realm prior to actually communicating to the server
  • figure out the right ccache in the collection as a result of that discovery
  • pass down the right Kerberos principal to use in persistent storage so that the session cookie is associated with the correct principal

Log in to comment on this ticket.

Metadata