Alexander Bokovoy via FreeIPA-users wrote:
> On Срд, 25 кас 2023, Kroon PC, Peter via FreeIPA-users wrote:
>> Hi all,
>>
>> After upgrading to Rocky linux 9.2 I'm running into issues with my IPA
>> server (4.10.1-9.el9_2). In particular, my IPA CLI seems FUBARred:
>>
>> $ kinit admin
>> Password for ad...@example.com:
>> $ ipa show-user admin
>> ipa: ERROR: Insufficient access: SASL(-1): generic failure: GSSAPI
>> Error: No credentials were supplied, or the credentials were
>> unavailable or inaccessible (Credential cache is empty)
>>
>> /var/log/krb5kdc.log:
>> okt 24 16:17:48 freeipa.example.com krb5kdc[10493]: TGS_REQ (4 etypes
>> {aes256-cts-hmac-sha1-96(18), aes256-cts-hmac-sha384-192(20),
>> aes128-cts-hmac-sha256-128(19), aes128-cts-hmac-sha1-96(17)})
>> 192.168.12.57: S4U2PROXY_NO_HEADER_PAC: authtime 0, etypes
>> {rep=UNSUPPORTED:(0)} HTTP/freeipa.example....@example.com for
>> ldap/freeipa.example....@example.com, TGT has been revoked
>>
>> As the log shows, the KDC states there is no PAC, and therefore revokes
>> the TGT (note, I had to RTFS to decipher the S4U2PROXY_NO_HEADER_PAC).
>> Because of this, the web gui also doesn't work.
> 
> That is correct description of the reason why it does not work.
> 
>>
>> $ ldapsearch -Y GSSAPI -b cn=users,cn=accounts,dc=example,dc=nl
>> "ipaNTSecurityIdentifier=*" uid ipaNTSecurityIdentifier
>> SASL/GSSAPI authentication started
>> SASL username: ad...@example.com
>> SASL SSF: 256
>> SASL data security layer installed.
>> # extended LDIF
>> #
>> # LDAPv3
>> # base <cn=users,cn=accounts,dc=example,dc=com> with scope subtree
>> # filter: ipaNTSecurityIdentifier=*
>> # requesting: uid ipaNTSecurityIdentifier
>> #
>>
>> # admin, users, accounts, example.com
>> dn: uid=admin,cn=users,cn=accounts,dc=example,dc=com
>> uid: admin
>> ipaNTSecurityIdentifier: S-1-5-21-3777974847-1414448952-306354440-500
>>
>> # search result
>> search: 4
>> result: 0 Success
>>
>> # numResponses: 2
>> # numEntries: 1
>>
>> Out of the ~200 or so users only the admin user has a
>> ipaNTSecurityIdentifier, but I don't know if it's correct...
>> I can't run `ipa config-mod --enable-sid --add-sids`, since my ipa CLI
>> is broken. I do still have LDAP access fortunately.
> 
> You can run it, see below. If you'd run, do you have any error messages in
> the dirsrv errors log related to sidgen plugin?
> 
>>
>> I tried to set `disable_pac = true` in /var/kerberos/krb5kdc/kdc.conf,
>> but that results in the exact same error.  Setting ipaKrbAuthzData=None
>> in cn=ipaConfig also has no effect.
> 
> No, one cannot disable PAC globally in FreeIPA. S4U operations
> require PAC presence since last year, so for any real Kerberos service
> that uses S4U (like IPA API or web UI) one cannot disable PAC
> enforcement.
> 
> Look at your ID range and SID configuration. You can avoid admin issue
> currently by running 'ipa' tool on IPA server as root with '-e
> in_server=true' option. This will force the tool to simulate direct
> access (as if it is running within httpd) and talk directly to LDAPI
> socket.
> 
> Something like below:
> 
> # KRB5CACHE=/dev/null ipa -e in_server=true trustconfig-show
> ipa: WARNING: API Version number was not sent, forward compatibility not
> guaranteed. Assuming server's API version, 2.253
>   Domain: ipa1.test
>   Security Identifier: S-1-5-21-790702333-3825749031-3739951824
>   NetBIOS name: IPA1
>   Domain GUID: 529fcbe9-3e34-436d-a541-6ffa88e7dac1
>   Fallback primary group: Default SMB Group
>   IPA AD trust agents: master1.ipa1.test
>   IPA AD trust controllers: master1.ipa1.test
> 
> # KRB5CACHE=/dev/null ipa -e in_server=true idrange-find
> ipa: WARNING: API Version number was not sent, forward compatibility not
> guaranteed. Assuming server's API version, 2.253
> ----------------
> 5 ranges matched
> ----------------
>   Range name: IPA1.TEST_id_range
>   First Posix ID of the range: 1055600000
>   Number of IDs in the range: 200000
>   First RID of the corresponding RID range: 1000
>   First RID of the secondary RID range: 100000000
>   Range type: local domain range
> 
> ... [ skip ] ...
> 
> 

In my testing you can't run config-mod without a principal, and running
in-server does not have a principal.

# KRB5CACHE=/dev/null ipa -e in_server=true config-mod --add-sids
--enable-sid
[snip]
  File "/usr/lib/python3.11/site-packages/ipaserver/plugins/config.py",
line 701, in pre_callback
    self._enable_sid(ldap, options)
  File "/usr/lib/python3.11/site-packages/ipaserver/plugins/config.py",
line 512, in _enable_sid
    if not principal_has_privilege(self.api, context.principal, privilege):
                                             ^^^^^^^^^^^^^^^^^
AttributeError: '_thread._local' object has no attribute 'principal'
ipa: ERROR: an internal error has occurred

rob
_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Reply via email to