Can the Vault kerberos auth method authenticate other Kerberos principals?

Hi all,

I have a environment where end-users have Windows laptops that are joined to
the corporate Active Directory domain. From this laptop, they use Putty to log into
a Linux server that has ‘sssd’ configured to automatically logs using their Windows
credentials ( Kerberos authentication negotiated by SpNego ). This all works fine.

What I try to accomplish now is to use the Kerberos credentials on the Linux server
to authenticate to HashiCorp Vault ( and hence getting a Vault token ).
Vault already is succesfully configured for LDAP authentication to Active Directory.

Reading ‘GitHub - hashicorp/vault-plugin-auth-kerberos: A plugin for HashiCorp Vault enabling Kerberos authentication.’ I got the impression
that the Kerberos auth method has an service account configured that is able to verify
other principal credentials.

Vault 1.12.2 is deployed on OpenShift and has the Raft cluster configured, so there are
3 pods running. The ‘vault’ client executable is installed on the Linux server.

Steps :

  • logon to vault using the ‘Initial Root Token’
  • issue ‘vault auth enable … kerberos’ ( as described by Kerberos - Auth Methods | Vault | HashiCorp Developer )
  • created a server entry in Active Directory ( let’s call it ‘my-service’ )
  • created a keytab file for this server entry and base64 encoded it
  • issue ‘vault write auth/kerberos/config keytab=@… service_account=…’ ( as described by Kerberos - Auth Methods | Vault | HashiCorp Developer )
  • issue 'vault write auth/kerberos/config/ldap binddn=… ’ for the server entry
  • issue ‘vault write auth/kerberos/groups/my-group policies=admin’

Verification :

  • I can do a succesful ‘ldapsearch’ using the server entry as the bind user
  • I can succesfully obtain Kerberos credentials using ‘kinit -k -t <keytab_file_for_server_entry>’
  • using the Kerberos credentials from the previous step, I can succesfully
    'vault login -method=kerberos \
        realm=MYREALM.COM \
        keytab_path=vault.keytab  \
        krb5conf_path=krb5.conf \
        service=HTTP/my-service \
        username=HTTP/my-service'

but… after I ‘kinit myuser’ and specify the password, I cannot run

    'vault login -method=kerberos \
        realm=MYREALM.COM \
        keytab_path=vault.keytab  \
        krb5conf_path=krb5.conf \
        service=HTTP/my-service \
        username=myuser'

which results in :

Error authenticating: couldn't log in: [Root cause: Encrypting_Error] KRBMessage_Handling_Error: AS Exhange Error: issue with settings PAData
on AS_REQ < Encrypting_Error: error getting key from credentials: matching key not found in keytab. looking for [myuser] realm: MYREALM.COM 
kvno: 0 etype: 23

OK, so… the ‘myuser’ actually is able to login without password because of ‘sssd’ SSO. But ‘klist’ then returns nothing.
I have to look into this because I think it’s something specific to sssd. However, I can succesfully obtain credentials using
‘kinit myuser’ ( and enter the password )… Now ‘klist’ shows a ticket and default principal.

Assuming that ‘kinit’ uses ‘/etc/krb5.conf’ and ‘/etc/krb5.keytab’, I tried

   'vault login -method=kerberos \
        realm=MYREALM.COM \
        keytab_path=/etc/krb5.keytab  \
        krb5conf_path=/etc/krb5.conf \
        service=HTTP/my-service \
        username=myuser'

Several problems also occur ( e.g. ‘vault login -method=kerberos …’ bombs if ‘krb5.conf’ contains ‘{}’ as value in the ‘[realms]’
section ), but eventually the same ‘matching key not found in keytab’ error occurs.

My big question now is : can the Vault ‘kerberos’ auth method authenticate a Kerberos principal other than the server entry
that is configured as the service for the Kerberos auth method ?

Thanks in advance !

Oh, and to be more specific about my goals here, eventually I want to get a Vault token
from python… something like :

#!/opt/pythonenvs/ansible/bin/python

import requests
from requests_kerberos import HTTPKerberosAuth
from requests.packages.urllib3.exceptions import InsecureRequestWarning

requests.packages.urllib3.disable_warnings(InsecureRequestWarning)

r = requests.post('https://vault.apps.cc.myrealm.com/v1/auth/kerberos/login'),
auth=HTTPKerberosAuth(),
verify=False)

vaulttoken = r.json()['auth']['client_token']

thanks.

I’m not totally sure I fully understand your setup, but it sounds like you have some existing sssd-based Kerberos integration which is sufficient to allow automatic login from Windows to Linux, but I am making a guess that it does NOT enable the Linux session to further use Kerberos authentication to other things, such as Vault.

In particular, the fact that klist returns nothing even after a “successful” kinit is particularly suggestive of this.

Hi Max, thanks for responding…

OK, so my story is still a bit blurry… let me clarify a bit more :

If I login to Linux using Windows user ‘myuser’ , I get logged-on without password ( SSO ).
Issueing ‘klist’ then says :

klist: Credentials cache keyring 'persistent:808521:krb_ccache_x2hJGE1' not found

Next, on typing ‘kinit’ as ‘myuser’ , it’s asking for a password… I then enter the Active Directory password for ‘myuser’, and a Kerberos ticket is obtained…

$ kinit
Password for myuser@MYREALM.COM:
******

$ klist
Ticket cache: KEYRING:persistent:808521:krb_ccache_x2hJGE1
Default principal: myuser@MYREALM.COM

Valid starting.......

thanks !

I was unfamiliar with this KEYRING:persistent:... thing, so I Googled - and found Stealing Kerberos credentials in kernel keyrings | by Eduardo Blázquez | Medium - interesting! News to me.

This then leads me to guess that the problem is that Vault’s Kerberos support doesn’t support KEYRING:persistent:.... This guess is borne out by checking that Vault uses GitHub - jcmturner/gokrb5: Pure Go Kerberos library for clients and services and that project doesn’t contain the word persistent anywhere in it, and in Keyring Support · Issue #268 · jcmturner/gokrb5 · GitHub the author says:

It’s not in the scope of this library to interact with the keychain.

Meaning that Go-based software is probably all going to be incompatible with Kerberos keys stored in the Linux persistent keyrings.

You could:

  • Decide to reconfigure /etc/krb5.conf to use traditional file-based credential caches.

  • Skip use of the vault CLI and go directly to experimenting with authenticating to Vault using Python.

Thanks again Max, I appreciate your help !

then yes, I already started experimenting interfacing thru python… This is my code :

#!/opt/pythonenvs/ansible/bin/python

import requests
import logging
from requests_kerberos import HTTPKerberosAuth
from requests.packages.urllib3.exceptions import InsecureRequestWarning

requests.packages.urllib3.disable_warnings(InsecureRequestWarning)

logging.basicConfig(level=logging.DEBUG)

r = requests.post('https://vault.apps.cc04.myrealm.com/v1/auth/kerberos/login',
        auth=HTTPKerberosAuth(),
        verify=False)

and the output ( including some debug output ) is :

DEBUG:urllib3.connectionpool:Starting new HTTPS connection (1): vault.apps.cc04.myrealm.com:443
DEBUG:urllib3.connectionpool:https://vault.apps.cc04.myrealm.com:443 "POST /v1/auth/kerberos/login HTTP/1.1" 401 39
DEBUG:requests_kerberos.kerberos_:handle_401(): Handling: 401
DEBUG:spnego._gss:GSSAPI step input:
DEBUG:spnego._gss:GSSAPI step output: YIITyQYJKoZIhvcSAQICAQBughO4MIITtKADAgEFoQMCAQ6iBwMFACAAAACjghLAYYISvDCCErigAwIBBaEXGxVQQy5CRUxBU1RJTkdESUVOU1QuTkyiOTA3oAMCAQOhMDAuGwRIVFRQGyZ2YXVsdC5hcHBzLmNjMDQuY2hwLmJlbGFzdGluZ2RpZW5zdC5ubKOCElswghJXoAMCARehAwIBAaKCEkkEghJFDwgujArOCo6ovAMioJJjjWLYmPpuLZqN67eyxnIJ1aMjP0J6oqhtnbNZ5/kU+YJzkNIlDvGrkxzVaE+CJNZ9ym5dJB1P1BTdyvDvdM7xPZ7gm34VKa4HkB5JAScWnsGE5IrsT+5vpYMZSFja0cneAp4WeQgHI0PqefXu1AIk8c0FA5Os5PjuOLCCJmBCdv4RLq2Pgt1ZpezgNjzVAk2s8g9bGKfesSnZvUoZCm47son4/fxgsqtTivaPjHWgzfoNPIx2zmz6QOe5ck/G/PP7bpJ647uS9PBypWu1Vxgwed+15BvdDoyoXvkGopbD9i82/6NCsnxryDN52z2sbRdRm2snzn5dmqy0fGK+TfidyIV0Vci00WEZjSRhMgmo1mY5y2GYBVyE26Bi4uquDLrxj4pTbQmxlvHk6tu0EEqur+2hPcHgMq4mx7SCJf1Ot2v1sjpIsDj9cYBxH7jZrw185zOY7N+EbbHnOA45EMuhRydRNYuKz7KIGRtqzC+MLiRCSXJABFoOwyL0bXBO5KAiD877KxpRlqoKcAcn9M5HJVLVf4r0CpFsZiQ+Jt/eNxXcU3TZwPEBkp9mCbivCnAKYio1jQ3zaaWkg3WHZX7rowT3aq00qb7rEHSXnqpLyqkSrkmhpQWFuV4NHYOojua6NzJv0Bz3HLkuVXoU2PIw+nUalS20Di8WgGPM8Y+8sUZ+fl6qGRhl0N8RrPkTI0hQN/bXgXhwjfWOxpjVRQxTKaJm9z48oVpSkAcrEHN+DqNtpB9NOmE3TFQD+EMguOjwkjtGqBH72O88pUNGGIJZo+CozAyzqKc24Wvv/NyB3KzpEbIQJ1pKwdy+/a/iIB84niS0xzS/e9Gl0cbXd5mM1XepcRUTQrn82r/jtOFaPiWx3oK1qM27Hy5CSNpt0j+EuQC6nidxHSv35+DMlglXvS04Ykh/wb8l1NA2/2O7BgYVtzt1tTPdtPMliMyaXSi5fibM8Mcj1qx5MMGfvWpJw8jK80xbQWjJNhI1YXM8P2/6SqdtXKM8+aOr1PfeQ2xqGtGnFx10f6Vo2qaXMeZIh8xSBc/TlLhPFz1QJn7w7H6040iwSGjdZ7/P7n5QB0bKQcbSEDofdrfNK8YaQUbl89C9d+MkI/J/1QTSfC9XckNQojSUSrSMBAtea9RJzYfO4fZBM00Q8LYolOZ+kasdVfJSRfjRT9mQfU7Y5Awv38E4Ne5vTIEJeCANkNaTIpWMWnnY6HCxx9y51jkYFz+eYm8P46P4Bo+ShpLA8xUC5MBGrp7qbO7dNlSRn1oE5yoUnsIv5n/SKxhBx9nheoSuYUqESsecnFrZEZjeMSJE0AtbDrcqLki1bQ2ayPzdOgjVttHf9huJPiZhffjBzFPaOUsvbabtAHMOYI1J16T9bf7f5f6IlfVa3x7A45rwiLfhdjhLP5kMOPCQnBS7yzDMV2vPUwb+tQPHvOQ/EuxKy8tihFTrhax8MHhm/byat/3ZbGhwHLgCijEhCTY+SlJi95+luR6RX+GwUcm7XLi+8t3c61n5EkLXfomr2WC0PRFZWiLV3aBhONHL394G6iKf022h0lac7JxTgbkluTCM7vrxCZHxKLIj3alsKwJ6h3JGHMAfXYoC12F60D2Ivcom9dqyFqQMwwdjpXRCxC5uFoQWdHEr3L+ZZVt70XzYwx9FZU0kzEl+I9jFFAN3gbjnOX90Hx8VWTNbJYehC0vEltIRAIVuEjwW9/W+vWv6Tnp1ejdvoehS3QvIAgZigch2Uk1Pp67lrgEPS5McobRGl7St+oslhCTcR96Q4Zu4kbRgdGUTXN6K/WofdTCCfuC6F8UyTJH7DHAx8QIPxbC7DHc9xS3eVhwhhAzgSdWwnCDlD5+1/BJ0u7tYM+JNfvoDL9DMpKuofEdeWKhcLfoIzfMOn73PPRFEXAW/jrC8LG94h3RWuKZNdAVdUmLU35sEyQcYtOhIwFfsyJvmIZ5eyadF11O0L+WYwOxemMDJCb6Ub6OP3vGM4CNC++ACyaBhx/urj0an2wtuWWF3oRjQPJAJPnpnqeTWqydu0yxFPgba51XrPkTEcbBCfZjE45CMXtTHndACCLS+Fejo6YH4nVp7iEj0s4EYRx2hUx5n8rAxRHjQThKcwf8ZIr0DURqszj/gddVTPrcK1aO5YMu0l/NqfAj51FXLhkZjF8thhdyTuCPQmFeyp1uGB6nDl7iko0X172U9epdmc98XSCliQC9IytaoyLnfPFM5Hu9ruezCjCmS7tMWD8df6MvfOJGt70dLgaYcXXyg0hI7+8pNJxlfGX9QCqQsw/MHVPW3XkUdeqMuDb/BYr1lUsEiDAlmh2Yel/0ATMqlCoaDZc9RLj8mlZsJwl/o2xyBtfCad2DSpE6Tlf2SFOWtmdEQ5g0lJTyR8Yd2FsNh+rswxqfUU3rmmncRkOd9wiLPpiqPRgQhZKDW/YD2XK8/uUxuzwuBR9gfaynIGdxTyhJYekR/rJqiybCwJkMVWtL0SYJXSCksd5rrqgS7PxciElXOG+oZGALZnhTD/Nz3tIoldVBkal5JAxbGv89FwmenV9XYIzb18dKsJhZO/8nx039l2kJDiQmsfrllIGYDiRddtka+vO/J169639zCefd8xK8VrkMORGpMSuP/yB5vRxFOPgHVlRLC9eYfSR52s6D/fWkUs17QzQ9GDDRADDW8vianD6+uuuFn6NQ2Cxw3ah9YY5yevj2eGokSUKMQKfHfaIwAqaBlvbwyu/5la3nK4wwDk95tl2zf1cvfflsnxU1BG3tck3QGKW47r56BrXZhA6LWWJ8DL3gd5fQRtJd/AMi6GXmABZN5VCraOGoZZMNuV7t0JZKG463W5xPQbFSDnT45mmV14KxasyVJNF1a3ZA+LiujW7TY7pyyAyufwGk5SNCD3zFoZ2SjtLlenY1pKiiuVGmY23l1raRjEEgMvVL9yFR+g9JNOgvb5OijAoLd9NmBcgfCWOmNljT/42RMoYJ/mpB1Xfc975oynt0m532A2g/oh/3YDw9gYvrsBq41dMKh6zQTdr2gLhiML+fT2jAt1vBBgAfJsf19c/wdUtREI83AepzyFLvyHJgsAFDdLliPL3XW03kMcmkrLUHZqcCsZ42VXCd7X1UiKBU5lgnziAK/xHKP01XpKnH7p83QccK9JwILnEy3UOG+iX9NUkQJMYl7vZYEdOAsyctlGrHBo9G7enzw5TARke4OsA1rP6wGj/HceJXoavGQR5aQELMo9SFthoGYI7LOCdxGa525KyDBqrOTUwb6xggoyAJ7cYDQ6pFIbnOakfFHPiSj6nQ/nptC2yZ/8sMI8lza/BajnEUZDBwnLW8/QyropBYUVSzooHsh7dV5pVpzOXGRfJhaTcVcHIU8GZy0iLg9nI2yVHMqQxfvMVHfH/oYee5BsoQDijTJxXbQp/8BpTyjsK6NU9i32E2bf1xrJoW01igmbPFvpUfTXtANmBj7HwseTPLzwvegazWphyvepd4uvyFVwu86ZYRzIHoc+dmF3p8+vr6j2tFLhevPNCwlnwSXRuT+yuCUoDl0xppmidqFnVJK5/Wo3Ev+fWZmnCuEArRmVLREOwrJOUg2WuAf+nVms22C42v2jdpkViLhH891s2tQugZCb8Z4TJqP0xkIFCG91uUO1LucS0pG15Bu3MiN3JmlvjIV21VXiUQCOc7OyXOIcaA8SxPMPHDeV5YmeNF1zLKKFPJvGeOxfExHPm+RC6lh8r/eFMsFrcIFlOkynobj07ryt66w61cG7s1FUco1gDfTTJGFLRG+AKS31UQ16/t50aTBUmemQi5b2hmKKVGg0K79WvpDyvfmNj9FebGb88qcZ8iIoNYHZvZd8lBWp+ZG+AW0DJ2c2yYUlfCMSOJenWqdcdeIfgIsG6OXFQTlBhTNReKIifrtAjDh/Y58xQrda+nP5PycbJhe2JFIY/dxU3NEvv5tHRu1ixvdfef6xSoQ0Uvs7zFhIlln/CFhWAgPerm0orbILVBHuEkX7fsRr90rlHMB/gb+dq6kDRcQun+5m2gqNUHVkuvpkWIJA32mVn3n07UMd7IDOnbJCg3W1nibiz7fzRwrumM3D7JPmMGb3v5357zPP+42dBZRf+u7YpPACmTKBiE7Nrd8Wm64vULD/rA0DjbDcJZ+TNMK4cSLTcre5gY0FKisVT0EgeK6OfGiQwmN51gGotzHI2uQxwYgOHv8SuJ+9uFQrgEYk0OGejl9Dfh4YWDdbCxZkJOruBF+hGhF57VukccKRmYZLxzeX8uH900+h+xZySH3pHWdLcvAOb2XoHcehCbxxg/WiFVfwK0VkMo+x/NnIgABtgSY3SmHw+m0zlEx0TrX7p1a6orL/RmZdzAGTNUA4Tk9g7qvbpDw+NBsOXi/pTRWJnweBhqGpcEXkqUD9ycPsoondMSC7CT80w77USvKg8uawpSOzsa2Nc4TrFSk0AHwncVxvpzhdC08gclGW2IAStsL0eittlYByctGYjol0o85Iq83TfHQGkg4tFH60yhyajTcJPDdCvXMb18rsZ/mI6ou6AmiFeHnoKkl6lzBwYUCv61AQVuoxQrGOyDg5GIkqX1ykp2+Ob3CRb3Numy4Oc0W3kIjgThHDlNOfWfjBy38hCmK8ZiiJ39kc8IULaoNgcQ1FJsxCxkFTD3SA/vbxvIMz/4D7BccVUnS273wbCbv9tLMD0Ou8Nqtm9gVAZh9NQv0lYPfAClGb4gYQ3POYNGjHdDs38SuY0v3yrIWVnJrNAzSy4ov1//Clh0nb7vAwaiIx8OCm877Km1z0bvRs+DKv8uGd3bWIjVY3oRgYdBVz5r97bTPbzxgnRnEDNw9kHiRyvh9vdMKZB4BhWsjyNDAwwTNwIto+TBi32SOJnaAGyQGiH70Mm+AlxCrWaB0RLXlHSp7W/AcPIq4jx4PHfDjQL/WZ2uVBp2bEmQTGxqIKUjWCqMkhCv3eRCrSR/CkG9/CXt8HA9nnrh7NIoMTtJPrRwvqsAnPZV3Ew4VtZpW6Q/zsab5FdJzyBBmVYYAsoPOYP/dEMKyWb0oRN+6Lr91OWrDb1SaWSzPo0fbgTf4Xv8y8v00rsrtL92AspMXJ686Ar9WC91FiC35LRtNXB4J5Jw9WKsxbVBCZDK0KLimoIhE3edY7S6QwE/hbYy4ilOrvg6YvyzbpQyH8c6y2XH/mQ4I5az0JpUOST18gGJ4ubgT+bW+sbw2AsYbkcGtomhyn+4d31/LwKk0ThZImgy/NLGyQHkoOv8qxXUeQzZ0hLDLSWl1YIGWcV1mJYymXsNTVh387PS7a/nywvA5puL6mu1Oo/SVBZHjLVOfNjxQBOJXEpbnOjRCBIMoV1OZ1bOPzCr2a+atheXw9ojem/pg5Hn8dQ3RK2P1117+nzGdHfBdkAzfpzlCxXk7IOq1gtFA8W6oUj7v/933+wrV78d/KmnwEjFC4zhtc2eaCnjgZt3Qx4zbNAnAllZ1sNiLf3xzwa+3kCBr6lhB7Wb1dkh+hVREU5bCOD7rVfw8EYV2K9emZPTyV6GxMSc8yZHKgQHwemLMaEjYQJBbVPSyy3bGZael+KUKD67AlkZinUXr1OZRR1LwvWhBduLpZyQ8ae4l8rsgHubnnakS8QQdOcRvojOob8d7s2NSQ2Uz1OWUF2qWOCdxuUMWKMl+n4hGvK1FG4QM1S14QV2osoI3AxkdRrJwiieaOc3Wuppv/p86m1xwpQiXOv1zLx45/aHcQlFJhIFH7eDahPM87Cm0QXgtJMzHxyRJj2XFWEgV+7mkG7Bw/7vk5PnAOfTXDDKTRpRTryshJqXXSye+7AJstkR+j31weKUuVuYdtszH9ej/P7/+lifUX6r3ckJOUU1HA2y4yARPNH1ldunKtrky3DRioOH86kTbsRlML+5pkkSGQ2ea+Nw7lY7pkEFErn0+j3ODLJg1ZB5MglTzEn2hEHQ+d858rK6A9OhwtKZ0YfmXeF1eESqCDt9LXX67UaQGdgO68JPqYldXcyQuuISKC+/bRnAwGaOexOzb9OymaJRFsSCUMtPH+12S89KwKfLyGoxRhc4JLONo/Ii1nJBdn/8Doc06hf+ux38ovxLcIH3TcRB4acFFRlcP3t+tnKBo19neM+/OM30prmFF6uVbu7iDo8jZLJga9dnzbKkz0QnFpZ50AZJBonOz7eTzNXVyQX9Dw25hPsQLL5Pm99XM/qSD3LG6RNc7pIHaMIHXoAMCARKigc8Egcy+QUVmf8HC0IbX5BRTUSfGYzKdI9YrRUw+mDTldiW/OeqahG+enPemYBjh5pcjera2Oy6GA3tlwofdxJK6f2u1R0x8WXDuYDCZmkr0TJDUhQELGh5ASzP/ysCcird1BMG0bqgD+w7Mtuzo7ITRZujEJsuE4lroioNvuSqj8z81AwKrbURDyEtandZehag4EUmlXKsIoW8MHjz3DgemBAbMURjc6SloEfE0m2EJeGizJsoW/n7VbGza2lfHswaBmNLicOP8qGbBKVmRmNw=
DEBUG:requests_kerberos.kerberos_:authenticate_user(): Authorization header: Negotiate <TOKEN_REMOVED_FOR_READABILITY>
DEBUG:urllib3.connectionpool:https://vault.apps.cc04.myrealm.com:443 "POST /v1/auth/kerberos/login HTTP/1.1" 200 608
DEBUG:requests_kerberos.kerberos_:authenticate_user(): returning <Response [200]>
DEBUG:requests_kerberos.kerberos_:handle_401(): returning <Response [200]>
DEBUG:requests_kerberos.kerberos_:handle_response(): returning <Response [200]>
DEBUG:requests_kerberos.kerberos_:handle_response() has seen 0 401 responses
DEBUG:requests_kerberos.kerberos_:handle_other(): Handling: 200
ERROR:requests_kerberos.kerberos_:handle_other(): Mutual authentication failed
Traceback (most recent call last):
  File "./krb2.py", line 12, in <module>
    r = requests.post('https://vault.apps.cc04.myrealm.com/v1/auth/kerberos/login',
  File "/opt/pythonenvs/ansible/lib/python3.8/site-packages/requests/api.py", line 119, in post
    return request('post', url, data=data, json=json, **kwargs)
  File "/opt/pythonenvs/ansible/lib/python3.8/site-packages/requests/api.py", line 61, in request
    return session.request(method=method, url=url, **kwargs)
  File "/opt/pythonenvs/ansible/lib/python3.8/site-packages/requests/sessions.py", line 542, in request
    resp = self.send(prep, **send_kwargs)
  File "/opt/pythonenvs/ansible/lib/python3.8/site-packages/requests/sessions.py", line 662, in send
    r = dispatch_hook('response', hooks, r, **kwargs)
  File "/opt/pythonenvs/ansible/lib/python3.8/site-packages/requests/hooks.py", line 31, in dispatch_hook
    _hook_data = hook(hook_data, **kwargs)
  File "/opt/pythonenvs/ansible/lib/python3.8/site-packages/requests_kerberos/kerberos_.py", line 397, in handle_response
    return self.handle_response(_r, num_401s=num_401s, **kwargs)
  File "/opt/pythonenvs/ansible/lib/python3.8/site-packages/requests_kerberos/kerberos_.py", line 417, in handle_response
    _r = self.handle_other(response)
  File "/opt/pythonenvs/ansible/lib/python3.8/site-packages/requests_kerberos/kerberos_.py", line 338, in handle_other
    raise MutualAuthenticationError("Unable to authenticate "
requests_kerberos.exceptions.MutualAuthenticationError: Unable to authenticate <Response [200]>

the debug output clearly shows the ‘gssapi.SecurityContext.step()’ returning some Kerberos token… And that token is used to create an ‘Authorization: Negotiate ’ header for the POST request to ‘v1/auth/kerberos/login’…

Eventually it reports ‘Unable to authenticate’, so I need to figure out what’s wrong.

The ‘vault-0’ pod logs do not show any clue at all about the failure…

Any idea would be welcome :slight_smile:

Configure your requests-kerberos library to not require mutual authentication, since that’s the bit that’s failing. See requests-kerberos · PyPI

Bullseye Max !

I modified my code to use OPTIONAL mutual_authentication. :

#!/opt/pythonenvs/ansible/bin/python

import requests
import logging
from requests_kerberos import HTTPKerberosAuth, OPTIONAL
from requests.packages.urllib3.exceptions import InsecureRequestWarning

requests.packages.urllib3.disable_warnings(InsecureRequestWarning)

logging.basicConfig(level=logging.DEBUG)

kerberos_auth = HTTPKerberosAuth(mutual_authentication=OPTIONAL)
r = requests.post('https://vault.apps.cc04.myrealm.com/v1/auth/kerberos/login',
        auth=kerberos_auth,
        verify=False)

print(r.json())

Now, there’s one additional extra step I have to do before this code succesfully returns a Vault token… : I need to run ‘kinit’ ( or ‘kinit myuser’ ) and provide the password to
get a Kerberos ticket ( that is also listed by ‘klist’ )…

So, thanks to Max I’m reallllly close to where I want. The missing link is how to retrieve the Kerberos credentials that ‘sssd’ assignes to me…

Thanks Max !

Does it actually, though? (Assign any credentials.) My impression is that sssd receives and validates credentials sufficient to allow the SSH login, but I’ve not seen anything that proves those credentials allow further authentication to other systems.

Hi Max,

I found this : SSSD and Active Directory | Ubuntu

see the ‘Kerberos Tickets’ section… It says that :
If you install krb5-user , your AD users will also get a kerberos ticket upon logging in:

however, I’m at RedHat 7… On RedHat, the ‘krb5-user’ package was called ‘krb5-auth-dialog’ but was available for RH6 only. Right now I’m searching on how to do that on RH7…

My intuition is that that only applies if you log in by providing your AD password. I would expect it not to apply when performing a SSH login using a non-password authentication mechanism.

I might be wrong, but that’s my best educated guess.