SSSD login stopped working on Ubuntu 22.04
by Joyce Babu
I have a FreeIPA installation with many Pop!_OS 21.10 clients. Today I upgraded one of the clients to Pop!_OS 22.04, and I can no longer authenticate with FreeIPA on the upgraded client.
In krb5kdc.log file on the server, I can see the error 'verify failure: Incorrect password in encrypted challenge'
=======
May 17 14:07:43 ipa.myhost.com krb5kdc[301](info): AS_REQ (8 etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), UNSUPPORTED:des3-hmac-sha1(16), DEPRECATED:arcfour-hmac(23), camellia128-cts-cmac(25), camellia256-cts-cmac(26)}) 192.168.10.14: NEEDED_PREAUTH: joyce(a)MYHOST.COM for krbtgt/MYHOST.COM(a)MYHOST.COM, Additional pre-authentication required
May 17 14:07:43 ipa.myhost.com krb5kdc[301](info): closing down fd 12
May 17 14:07:43 ipa.myhost.com krb5kdc[302](info): preauth (encrypted_challenge) verify failure: Incorrect password in encrypted challenge
May 17 14:07:43 ipa.myhost.com krb5kdc[302](info): AS_REQ (8 etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), UNSUPPORTED:des3-hmac-sha1(16), DEPRECATED:arcfour-hmac(23), camellia128-cts-cmac(25), camellia256-cts-cmac(26)}) 192.168.10.14: PREAUTH_FAILED: joyce(a)MYHOST.COM for krbtgt/MYHOST.COM(a)MYHOST.COM, Preauthentication failed
May 17 14:07:43 ipa.myhost.com krb5kdc[302](info): closing down fd 12
=======
If I try the same username/password on a Pop!_OS 21.10 client, I can login successfully and I see the following log message. I tried multiple times with multiple users, and had the same result.
=======
May 17 14:05:51 ipa.myhost.com krb5kdc[299](info): AS_REQ (8 etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), UNSUPPORTED:des3-hmac-sha1(16), DEPRECATED:arcfour-hmac(23), camellia128-cts-cmac(25), camellia256-cts-cmac(26)}) 192.168.10.24: NEEDED_PREAUTH: joyce(a)MYHOST.COM for krbtgt/MYHOST.COM(a)MYHOST.COM, Additional pre-authentication required
May 17 14:05:51 ipa.myhost.com krb5kdc[299](info): closing down fd 12
May 17 14:05:51 ipa.myhost.com krb5kdc[301](info): AS_REQ (8 etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), UNSUPPORTED:des3-hmac-sha1(16), DEPRECATED:arcfour-hmac(23), camellia128-cts-cmac(25), camellia256-cts-cmac(26)}) 192.168.10.24: ISSUE: authtime 1652796351, etypes {rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha1-96(18)}, joyce(a)MYHOST.COM for krbtgt/MYHOST.COM(a)MYHOST.COM
May 17 14:05:51 ipa.myhost.com krb5kdc[301](info): closing down fd 12
May 17 14:05:51 ipa.myhost.com krb5kdc[300](info): TGS_REQ (8 etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), UNSUPPORTED:des3-hmac-sha1(16), DEPRECATED:arcfour-hmac(23), camellia128-cts-cmac(25), camellia256-cts-cmac(26)}) 192.168.10.24: ISSUE: authtime 1652796351, etypes {rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha1-96(18)}, joyce(a)MYHOST.COM for host/ws024.office-mng.myhost.net(a)MYHOST.COM
May 17 14:05:51 ipa.myhost.com krb5kdc[300](info): closing down fd 12
=======
What changed in Ubuntu 22.04? Could this be due to incompatible encryption type?
1 year, 11 months
ca-error: Server at https://xx.com/ipa/xml failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction, explaining: SSL certificate problem: certificate has expired).
by rui liang
### Request for enhancement
((SEC_ERROR_EXPIRED_CERTIFICATE) Peer's Certificate has expired
At present, it is an online operation, so I dare not change the configuration at will.I tried to modify Linux times on the test environment, but there were some unexpected risks.Don't dare change the time online like this.Is there a good way to renew it?Thank you very much
#### Steps to Reproduce
root@fs-ambari-server:~# ipa host-add fs-hiido-alluxio-12-65-100.hiido.host.yydevops.com
ipa: ERROR: cert validation failed for "CN=fs-hiido-kerberos-server02.hiido.host.yydevops.com,O=YYDEVOPS.COM" ((SEC_ERROR_EXPIRED_CERTIFICATE) Peer's Certificate has expired.)
ipa: ERROR: cannot connect to 'https://fs-hiido-kerberos-server02.hiido.host.yydevops.com/ipa/json': (SEC_ERROR_EXPIRED_CERTIFICATE) Peer's Certificate has expired.
root@fs-ambari-server:~#
root@fs-ambari-server:~#
root@fs-ambari-server:~# cat /tmp/kinit_trace
[61194] 1653916457.285087: ccselect module realm chose cache KEYRING:persistent:0:0 with client principal admin(a)YYDEVOPS.COM for server principal HTTP/fs-hiido-kerberos-server02.hiido.host.yydevops.com(a)YYDEVOPS.COM
[61194] 1653916457.285138: Getting credentials admin(a)YYDEVOPS.COM -> HTTP/fs-hiido-kerberos-server02.hiido.host.yydevops.com(a)YYDEVOPS.COM using ccache KEYRING:persistent:0:0
[61194] 1653916457.285216: Retrieving admin(a)YYDEVOPS.COM -> HTTP/fs-hiido-kerberos-server02.hiido.host.yydevops.com(a)YYDEVOPS.COM from KEYRING:persistent:0:0 with result: 0/Success
[61194] 1653916457.285253: Creating authenticator for admin(a)YYDEVOPS.COM -> HTTP/fs-hiido-kerberos-server02.hiido.host.yydevops.com(a)YYDEVOPS.COM, seqnum 746871073, subkey aes256-cts/24EC, session key aes256-cts/BFE5
ssh fs-hiido-kerberos-server02.hiido.host.yydevops.com(a)YYDEVOPS.COM
root@fs-hiido-kerberos-server02:/var/log/ipa# ipa-getcert list
Number of certificates and requests being tracked: 4.
Request ID '20200528083036':
status: MONITORING
stuck: no
key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-YYDEVOPS-COM',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-YYDEVOPS-COM/pwdfile.txt'
certificate: type=NSSDB,location='/etc/dirsrv/slapd-YYDEVOPS-COM',nickname='Server-Cert'
CA: IPA
issuer:
subject:
expires: unknown
pre-save command:
post-save command: /usr/lib/ipa/certmonger/restart_dirsrv YYDEVOPS-COM
track: yes
auto-renew: yes
Request ID '20200528083056':
status: CA_UNREACHABLE
ca-error: Server at https://fs-hiido-kerberos-server02.hiido.host.yydevops.com/ipa/xml failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction, explaining: SSL certificate problem: certificate has expired).
stuck: no
key pair storage: type=FILE,location='/var/lib/ipa/private/httpd.key',pinfile='/var/lib/ipa/passwds/fs-hiido-kerberos-server02.hiido.host.yydevops.com-443-RSA'
certificate: type=FILE,location='/var/lib/ipa/certs/httpd.crt'
CA: IPA
issuer: CN=Certificate Authority,O=YYDEVOPS.COM
subject: CN=fs-hiido-kerberos-server02.hiido.host.yydevops.com,O=YYDEVOPS.COM
expires: 2022-05-29 16:31:00 CST
dns: fs-hiido-kerberos-server02.hiido.host.yydevops.com
principal name: HTTP/fs-hiido-kerberos-server02.hiido.host.yydevops.com(a)YYDEVOPS.COM
key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command: /usr/lib/ipa/certmonger/restart_httpd
track: yes
auto-renew: yes
#### Version/Release/Distribution
root@fs-hiido-kerberos-server02:/var/log/ipa# ipa --version
VERSION: 4.8.6, API_VERSION: 2.236
1 year, 11 months
DNS add error during replica install
by Ranbir
Hi All,
I have a freeipa domain that I've been upgrading from running on CentOS
7.9 to Rocky Linux 8.6. The domain is only two servers: one is still
CentOS 7.9 and one is now Rocky Linux 8.6. The old CentOS 7.9 server it
replaced has already been dropped from the domain.
I added a new Rocky Linux 8.6 replica to the domain. The install
completed and it appears to be functioning properly. During the
installation, I saw this:
Replica DNS records could not be added on master: Insufficient access:
Insufficient 'add' privilege to add the entry
'idnsname=ipa04,idnsname=theinside.rnr.,cn=dns,dc=theinside,dc=rnr'.
Is this something I need to fix and if so, how do I fix it?
Thanks in advance.
--
Ranbir
1 year, 11 months
Restore preserved user fails
by Jim Kinney
Took a user who left and did the "delete --preserve" from the gui. So now they only list as a Preserved user.
Demo of them returning to org failed when I tried to restore their account.
Error: ns-slapd -ERR - managed-entries-plugin - mep_add_managed_entry Unable to add managed entry "cn..." for origin entry "uid..." (Already exists).
IPA v4.9.8
--
Computers amplify human error
Super computers are really cool
1 year, 11 months
ipa-dnskeysync-replica - returned non-zero exit status
by lejeczek
Hi guys.
This is from a box which I recently updated - I mailed
earliel the list about pki* rpm packages issue - but also,
for other reasons, I did fresh installation of IPA/replica
on that box.
...
ipa-dnskeysync-replica: DEBUG master keys in local HSM: set()
ipa-dnskeysync-replica: DEBUG master keys in LDAP HSM:
{'0x89cb5ca422df63e9a', '0x4191a795f83cd3367607f'}
ipa-dnskeysync-replica: DEBUG new master keys in LDAP
HSM: {'0x89cb5d8ca422df63e9a', '0x4191a7953367607f'}
Traceback (most recent call last):
File "/usr/libexec/ipa/ipa-dnskeysync-replica", line 189,
in <module>
ldap2replica_master_keys_sync(ldapkeydb, localhsm)
File "/usr/libexec/ipa/ipa-dnskeysync-replica", line 90,
in ldap2replica_master_keys_sync
raise ValueError(
ValueError: Local HSM does not contain suitable unwrapping
key for master key 0x4191a795f83ade7634ec01cd3367607f
Traceback (most recent call last):
File "/usr/libexec/ipa/ipa-dnskeysyncd", line 113, in
<module>
while ldap_connection.syncrepl_poll(all=1,
msgid=ldap_search):
File
"/usr/lib64/python3.9/site-packages/ldap/syncrepl.py", line
465, in syncrepl_poll
self.syncrepl_refreshdone()
File
"/usr/lib/python3.9/site-packages/ipaserver/dnssec/keysyncer.py",
line 126, in syncrepl_refreshdone
self.hsm_replica_sync()
File
"/usr/lib/python3.9/site-packages/ipaserver/dnssec/keysyncer.py",
line 192, in hsm_replica_sync
ipautil.run([paths.IPA_DNSKEYSYNCD_REPLICA])
File
"/usr/lib/python3.9/site-packages/ipapython/ipautil.py",
line 598, in run
raise CalledProcessError(
ipapython.ipautil.CalledProcessError:
CalledProcessError(Command
['/usr/libexec/ipa/ipa-dnskeysync-replica'] returned
non-zero exit status 1: 'ipalib.plugable: DEBUG
...
DEBUG master keys in LDAP HSM: {\'0x89cb5d88042df63e9a\',
\'0x4191a795f83adecd3367607f\'}\nipa-dnskeysync-replica:
DEBUG new master keys in LDAP HSM:
{\'0x89cb5da422df63e9a\',
\'0x4191a795f83ade7634ec01cd3367607f\'}\nTraceback (most
recent call last):\n File
"/usr/libexec/ipa/ipa-dnskeysync-replica", line 189, in
<module>\n ldap2replica_master_keys_sync(ldapkeydb,
localhsm)\n File "/usr/libexec/ipa/ipa-dnskeysync-replica",
line 90, in ldap2replica_master_keys_sync\n raise
ValueError(\nValueError: Local HSM does not contain suitable
unwrapping key for master key 0x4191acd3367607f\n')
ipa-dnskeysyncd.service: Main process exited, code=exited,
status=1/FAILURE
...
Domain seems to function okey, IPA does not complain about
anything else except this 'ipa-dnskeysyncd.service'
I wonder if it's this one box having relevant/related
packages newer versions and other masters need updates to
"fix" the issue, or perhaps doing those updates on remaining
masters will make things worse..
or perhaps nature of the problems is altogether different.
All advises are much welcomed.
many thanks, L.
1 year, 11 months
Re: hostgroup automember rules
by Angus Clarke
Alexander's other suggestion was quite straight forward too, sharing the process for the archive.
To allow customers to enroll hosts themselves and have automembership operate on the "locality" attribute:
1. Create A/AAAA records in the local DNS for the host you intend to add (blah.int.ajc)
2.
3. Create automembership rule based on "l" attribute (locality)
1. An IPA user is needed with these privileges:
2. Host Administrators
3. Host Enrollment
1. On an already enrolled host:
2. [angusc@enrolled ~] $ kinit
3. [angusc@enrolled ~] $ ipa host-add blah.int.ajc --locality="worcester"
4.
5. At this point the automembership rule has been honoured
1. Enroll the client with ipa-client-install
2. [angusc@blah ~] $ ipa-client-install --mkhomedir --no-ntp --no-nisdomain --domain=int.ajc --server=infra1.int.ajc
Thanks for the pointers
Regards
Angus
________________________________
From: Angus Clarke <angus(a)charworth.com>
Sent: 26 May 2022 09:11
To: Rob Crittenden <rcritten(a)redhat.com>; FreeIPA users list <freeipa-users(a)lists.fedorahosted.org>; Alexander Bokovoy <abokovoy(a)redhat.com>
Subject: Re: [Freeipa-users] Re: hostgroup automember rules
Super that worked a treat thanks, however I see that the host can run the automember rebuild on any other host which might not be desirable.
I'll have a loot at Alexander's previous suggestion too with regards to creating a host entry with particular attributes set prior to running the ipa-client-install command.
Thanks again
Angus
________________________________
From: Rob Crittenden <rcritten(a)redhat.com>
Sent: 25 May 2022 20:24
To: FreeIPA users list <freeipa-users(a)lists.fedorahosted.org>; Alexander Bokovoy <abokovoy(a)redhat.com>
Cc: Angus Clarke <angus(a)charworth.com>
Subject: Re: [Freeipa-users] Re: hostgroup automember rules
This is controlled by the permission 'Add Automember Rebuild Membership
Task'. There is a related privilege, 'Automember Task Administrator'.
To limit what you're allowing to the minimum I'd create a new role like
'Hosts can rebuild automember' and add your host(s) to it.
rob
Angus Clarke via FreeIPA-users wrote:
> Hi Alexander
>
>> There are two ways of setting these fields:
>>
>> - prior to enrollment, by pre-creating a host and setting the
>> attributes at that time.
>>
>> - after the enrollment, right from the host using host keytab
>
> I started looking at the latter as it seems a simpler route, the host
> principal seems to lack the write to rebuild automembership for itself -
> is this something I can change?
>
> [root@blah ~]# kinit -k
> [root@blah ~]# ipa automember-rebuild --hosts=`hostname`
> ipa: ERROR: Insufficient access: Insufficient 'add' privilege to add the
> entry 'cn=automember rebuild membership,cn=tasks,cn=config'.
>
> Thanks a lot
> Angus
>
>
>
> ------------------------------------------------------------------------
> *From:* Alexander Bokovoy <abokovoy(a)redhat.com>
> *Sent:* 20 May 2022 13:39
> *To:* FreeIPA users list <freeipa-users(a)lists.fedorahosted.org>
> *Cc:* Angus Clarke <angus(a)charworth.com>
> *Subject:* Re: [Freeipa-users] hostgroup automember rules
>
> Hi Angus,
>
> On pe, 20 touko 2022, Angus Clarke via FreeIPA-users wrote:
>>Hello
>>
>>FreeIPA 4.6.8
>>
>>We are very happy with hostgroup automember rules based on servername
>>attribute however one of our internal customers uses a generic
>>servername template for all of their servers regardless of its
>>function.
>>
>>So I'm wondering what other attributes I might use for hostgroup
>>automember - perhaps some of the attributes can be configured by the
>>ipa-client-install (the host's "description" field perhaps) although I
>>don't see such mention in the man page ... Presumably they could use a
>>different enrollment user ("enrolledby") for each of their hostgroup
>>functions (not ideal.)
>>
>>There are various attribute fields in the WebUI but I don't find much
>>documentation for them. What is the "|" field - perhaps I can exploit
>>this somehow?
>
> Few years ago a customer of mine asked a similar question. Here is what
> I answered:
>
> ----------------------------------------------------------------------
> You can use nsHardwarePlatform attribute (part of nsHost objectclass).
> It is exposed as '--platform' in IPA CLI for 'ipa host-*' commands.
>
> Originally it was supposed to be filled by the IPA client join process
> to 'uname -m' value. ipa-join tools still sends it to the server but the
> value is ignored completely by the join process. As the result,
> nsHardwarePlatform attribute is never set on the host object.
>
> I don't see any code in IPA itself that would rely on the content of
> nsHardwarePlatform attribute. We have web UI tests upstream that modify
> the field to test that you can modify it but that's all.
>
> Alternatively, one can use userClass attribute (--class in IPA CLI for
> host-* commands). This one is also not utilized and is left specifically
> for the customers to define its semantics.
>
> Another alternative is nsHostLocation attribute (--location in IPA CLI
> for host-*
> commands). Again, the semantics is totally left for customers to define.
>
> ----------------------------------------------------------------------
>
> There are two ways of setting these fields:
>
> - prior to enrollment, by pre-creating a host and setting the
> attributes at that time.
>
> - after the enrollment, right from the host using host keytab
>
> The former can be done by a designated user/service account and can be
> tuned with custom permissions to allow such modification. The latter
> relies on the fact that the host principal has some write rights
> already:
>
> # kinit -k
>
> # ipa host-show `hostname` --rights --all
> dn: fqdn=dc.ipa.test,cn=computers,cn=accounts,dc=ipa,dc=test
> Host name: dc.ipa.test
> Principal name: host/dc.ipa.test(a)IPA.TEST
> Principal alias: host/dc.ipa.test(a)IPA.TEST
> SSH public key: [skip]
> SSH public key fingerprint: [skip]
> Requires pre-authentication: True
> Trusted for delegation: False
> Trusted to authenticate as user: False
> Password: False
> Member of host-groups: ipaservers
> Keytab: True
> Managed by: dc.ipa.test
> Managing: dc.ipa.test
> attributelevelrights: {'aci': '', 'cn': 'rscwo', 'description':
> 'rscwo', 'enrolledby': 'rsc', 'fqdn': 'rsc', 'ipaassignedidview': 'rsc',
> 'ipaclientversion': 'rsc', 'ipakrbauthzdata': 'rsc', 'ipasshpubkey':
> 'rscwo', 'ipauniqueid': 'rsc', 'krballowedtodelegateto': '',
> 'krbauthindmaxrenewableage': '', 'krbauthindmaxticketlife': '',
> 'krbcanonicalname': 'rsc', 'krbextradata': '', 'krblastadminunlock': '',
> 'krblastfailedauth': '', 'krblastpwdchange': 'rscwo',
> 'krblastsuccessfulauth': '', 'krbloginfailedcount': '',
> 'krbmaxrenewableage': '', 'krbmaxticketlife': '', 'krbobjectreferences':
> '', 'krbpasswordexpiration': 'rsc', 'krbprincipalaliases': 'rsc',
> 'krbprincipalauthind': 'rsc', 'krbprincipalexpiration': 'rsc',
> 'krbprincipalkey': 'swo', 'krbprincipalname': 'rsc', 'krbprincipaltype':
> '', 'krbpwdhistory': '', 'krbpwdpolicyreference': '', 'krbticketflags':
> '', 'krbticketpolicyreference': '', 'krbupenabled': '', 'l': 'rscwo',
> 'managedby': 'rsc', 'memberof': 'rsc', 'nsaccountlock': '',
> 'nshardwareplatform': 'rscwo', 'nshostlocation': 'rscwo', 'nsosversion':
> 'rscwo', 'objectclass': 'rsc', 'serverhostname': 'rsc',
> 'usercertificate': 'rscwo', 'userclass': 'rsc', 'userpassword': 'swo'}
> cn: dc.ipa.test
> ipauniqueid: b179f1ea-c4b8-11ec-9e86-52540083ff9d
> krblastpwdchange: 20220425165647Z
> objectclass: top, ipaobject, nshost, ipahost, ipaservice, pkiuser,
> krbprincipalaux, krbprincipal, krbticketpolicyaux, ipasshhost,
> ipaSshGroupOfPubKeys
> serverhostname: dc
>
> So, the host/dc.ipa.test(a)IPA.TEST principal can write to:
>
> - nsHardwarePlatform
> - nsHostLocation
> - nsOSVersion
> - l (locality)
> - description
>
> but it cannot write to 'userClass' attribute.
>
> A handy mapping between attributes and command parameters is
> 'show-mappings' command:
>
> # ipa show-mappings host-mod
> Parameter : LDAP attribute
> ========= : ==============
> desc : description?
> locality : l?
> location : nshostlocation?
> platform : nshardwareplatform?
> os : nsosversion?
> password : userpassword?
> random : random?
> certificate : usercertificate*
> krbprincipalname : krbprincipalname*
> macaddress : macaddress*
> sshpubkey : ipasshpubkey*
> class : userclass*
> auth-ind : krbprincipalauthind*
> requires-pre-auth : ipakrbrequirespreauth?
> ok-as-delegate : ipakrbokasdelegate?
> ok-to-auth-as-delegate : ipakrboktoauthasdelegate?
> rights : rights
> updatedns : updatedns?
>
> If you want to change parameters from the host itself, it would be
> possible with
>
> # kinit -k
> # ipa host-mod `hostname` --locality=foo --location=bar
> --platform=some-platform --desc=some-host
>
> --
> / Alexander Bokovoy
> Sr. Principal Software Engineer
> Security / Identity Management Engineering
> Red Hat Limited, Finland
>
>
> _______________________________________________
> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
> Fedora Code of Conduct: https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fe...
> List Guidelines: https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedorap...
> List Archives: https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.f...
> Do not reply to spam on the list, report it: https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpagure....
>
1 year, 12 months
Re: hostgroup automember rules
by Rob Crittenden
Angus Clarke wrote:
> Super that worked a treat thanks, however I see that the host can run
> the automember rebuild on any other host which might not be desirable.
There is no way that I know of to only do per-host rebuild. After all
it's just doing a regex so if a name matches the hostgroup is applied.
There is no way in advance to know which hosts this should apply to. I
don't see it as a problem.
rob
>
> I'll have a loot at Alexander's previous suggestion too with regards to
> creating a host entry with particular attributes set prior to running
> the ipa-client-install command.
>
> Thanks again
> Angus
> ------------------------------------------------------------------------
> *From:* Rob Crittenden <rcritten(a)redhat.com>
> *Sent:* 25 May 2022 20:24
> *To:* FreeIPA users list <freeipa-users(a)lists.fedorahosted.org>;
> Alexander Bokovoy <abokovoy(a)redhat.com>
> *Cc:* Angus Clarke <angus(a)charworth.com>
> *Subject:* Re: [Freeipa-users] Re: hostgroup automember rules
>
> This is controlled by the permission 'Add Automember Rebuild Membership
> Task'. There is a related privilege, 'Automember Task Administrator'.
>
> To limit what you're allowing to the minimum I'd create a new role like
> 'Hosts can rebuild automember' and add your host(s) to it.
>
> rob
>
> Angus Clarke via FreeIPA-users wrote:
>> Hi Alexander
>>
>>> There are two ways of setting these fields:
>>>
>>> - prior to enrollment, by pre-creating a host and setting the
>>> attributes at that time.
>>>
>>> - after the enrollment, right from the host using host keytab
>>
>> I started looking at the latter as it seems a simpler route, the host
>> principal seems to lack the write to rebuild automembership for itself -
>> is this something I can change?
>>
>> [root@blah ~]# kinit -k
>> [root@blah ~]# ipa automember-rebuild --hosts=`hostname`
>> ipa: ERROR: Insufficient access: Insufficient 'add' privilege to add the
>> entry 'cn=automember rebuild membership,cn=tasks,cn=config'.
>>
>> Thanks a lot
>> Angus
>>
>>
>>
>> ------------------------------------------------------------------------
>> *From:* Alexander Bokovoy <abokovoy(a)redhat.com>
>> *Sent:* 20 May 2022 13:39
>> *To:* FreeIPA users list <freeipa-users(a)lists.fedorahosted.org>
>> *Cc:* Angus Clarke <angus(a)charworth.com>
>> *Subject:* Re: [Freeipa-users] hostgroup automember rules
>>
>> Hi Angus,
>>
>> On pe, 20 touko 2022, Angus Clarke via FreeIPA-users wrote:
>>>Hello
>>>
>>>FreeIPA 4.6.8
>>>
>>>We are very happy with hostgroup automember rules based on servername
>>>attribute however one of our internal customers uses a generic
>>>servername template for all of their servers regardless of its
>>>function.
>>>
>>>So I'm wondering what other attributes I might use for hostgroup
>>>automember - perhaps some of the attributes can be configured by the
>>>ipa-client-install (the host's "description" field perhaps) although I
>>>don't see such mention in the man page ... Presumably they could use a
>>>different enrollment user ("enrolledby") for each of their hostgroup
>>>functions (not ideal.)
>>>
>>>There are various attribute fields in the WebUI but I don't find much
>>>documentation for them. What is the "|" field - perhaps I can exploit
>>>this somehow?
>>
>> Few years ago a customer of mine asked a similar question. Here is what
>> I answered:
>>
>> ----------------------------------------------------------------------
>> You can use nsHardwarePlatform attribute (part of nsHost objectclass).
>> It is exposed as '--platform' in IPA CLI for 'ipa host-*' commands.
>>
>> Originally it was supposed to be filled by the IPA client join process
>> to 'uname -m' value. ipa-join tools still sends it to the server but the
>> value is ignored completely by the join process. As the result,
>> nsHardwarePlatform attribute is never set on the host object.
>>
>> I don't see any code in IPA itself that would rely on the content of
>> nsHardwarePlatform attribute. We have web UI tests upstream that modify
>> the field to test that you can modify it but that's all.
>>
>> Alternatively, one can use userClass attribute (--class in IPA CLI for
>> host-* commands). This one is also not utilized and is left specifically
>> for the customers to define its semantics.
>>
>> Another alternative is nsHostLocation attribute (--location in IPA CLI
>> for host-*
>> commands). Again, the semantics is totally left for customers to define.
>>
>> ----------------------------------------------------------------------
>>
>> There are two ways of setting these fields:
>>
>> - prior to enrollment, by pre-creating a host and setting the
>> attributes at that time.
>>
>> - after the enrollment, right from the host using host keytab
>>
>> The former can be done by a designated user/service account and can be
>> tuned with custom permissions to allow such modification. The latter
>> relies on the fact that the host principal has some write rights
>> already:
>>
>> # kinit -k
>>
>> # ipa host-show `hostname` --rights --all
>> dn: fqdn=dc.ipa.test,cn=computers,cn=accounts,dc=ipa,dc=test
>> Host name: dc.ipa.test
>> Principal name: host/dc.ipa.test(a)IPA.TEST
>> Principal alias: host/dc.ipa.test(a)IPA.TEST
>> SSH public key: [skip]
>> SSH public key fingerprint: [skip]
>> Requires pre-authentication: True
>> Trusted for delegation: False
>> Trusted to authenticate as user: False
>> Password: False
>> Member of host-groups: ipaservers
>> Keytab: True
>> Managed by: dc.ipa.test
>> Managing: dc.ipa.test
>> attributelevelrights: {'aci': '', 'cn': 'rscwo', 'description':
>> 'rscwo', 'enrolledby': 'rsc', 'fqdn': 'rsc', 'ipaassignedidview': 'rsc',
>> 'ipaclientversion': 'rsc', 'ipakrbauthzdata': 'rsc', 'ipasshpubkey':
>> 'rscwo', 'ipauniqueid': 'rsc', 'krballowedtodelegateto': '',
>> 'krbauthindmaxrenewableage': '', 'krbauthindmaxticketlife': '',
>> 'krbcanonicalname': 'rsc', 'krbextradata': '', 'krblastadminunlock': '',
>> 'krblastfailedauth': '', 'krblastpwdchange': 'rscwo',
>> 'krblastsuccessfulauth': '', 'krbloginfailedcount': '',
>> 'krbmaxrenewableage': '', 'krbmaxticketlife': '', 'krbobjectreferences':
>> '', 'krbpasswordexpiration': 'rsc', 'krbprincipalaliases': 'rsc',
>> 'krbprincipalauthind': 'rsc', 'krbprincipalexpiration': 'rsc',
>> 'krbprincipalkey': 'swo', 'krbprincipalname': 'rsc', 'krbprincipaltype':
>> '', 'krbpwdhistory': '', 'krbpwdpolicyreference': '', 'krbticketflags':
>> '', 'krbticketpolicyreference': '', 'krbupenabled': '', 'l': 'rscwo',
>> 'managedby': 'rsc', 'memberof': 'rsc', 'nsaccountlock': '',
>> 'nshardwareplatform': 'rscwo', 'nshostlocation': 'rscwo', 'nsosversion':
>> 'rscwo', 'objectclass': 'rsc', 'serverhostname': 'rsc',
>> 'usercertificate': 'rscwo', 'userclass': 'rsc', 'userpassword': 'swo'}
>> cn: dc.ipa.test
>> ipauniqueid: b179f1ea-c4b8-11ec-9e86-52540083ff9d
>> krblastpwdchange: 20220425165647Z
>> objectclass: top, ipaobject, nshost, ipahost, ipaservice, pkiuser,
>> krbprincipalaux, krbprincipal, krbticketpolicyaux, ipasshhost,
>> ipaSshGroupOfPubKeys
>> serverhostname: dc
>>
>> So, the host/dc.ipa.test(a)IPA.TEST principal can write to:
>>
>> - nsHardwarePlatform
>> - nsHostLocation
>> - nsOSVersion
>> - l (locality)
>> - description
>>
>> but it cannot write to 'userClass' attribute.
>>
>> A handy mapping between attributes and command parameters is
>> 'show-mappings' command:
>>
>> # ipa show-mappings host-mod
>> Parameter : LDAP attribute
>> ========= : ==============
>> desc : description?
>> locality : l?
>> location : nshostlocation?
>> platform : nshardwareplatform?
>> os : nsosversion?
>> password : userpassword?
>> random : random?
>> certificate : usercertificate*
>> krbprincipalname : krbprincipalname*
>> macaddress : macaddress*
>> sshpubkey : ipasshpubkey*
>> class : userclass*
>> auth-ind : krbprincipalauthind*
>> requires-pre-auth : ipakrbrequirespreauth?
>> ok-as-delegate : ipakrbokasdelegate?
>> ok-to-auth-as-delegate : ipakrboktoauthasdelegate?
>> rights : rights
>> updatedns : updatedns?
>>
>> If you want to change parameters from the host itself, it would be
>> possible with
>>
>> # kinit -k
>> # ipa host-mod `hostname` --locality=foo --location=bar
>> --platform=some-platform --desc=some-host
>>
>> --
>> / Alexander Bokovoy
>> Sr. Principal Software Engineer
>> Security / Identity Management Engineering
>> Red Hat Limited, Finland
>>
>>
>> _______________________________________________
>> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
>> To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
>> Fedora Code of Conduct: https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fe...
>> List Guidelines: https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedorap...
>> List Archives: https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.f...
>> Do not reply to spam on the list, report it: https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpagure....
>>
>
1 year, 12 months
Re: hostgroup automember rules
by Rob Crittenden
This is controlled by the permission 'Add Automember Rebuild Membership
Task'. There is a related privilege, 'Automember Task Administrator'.
To limit what you're allowing to the minimum I'd create a new role like
'Hosts can rebuild automember' and add your host(s) to it.
rob
Angus Clarke via FreeIPA-users wrote:
> Hi Alexander
>
>> There are two ways of setting these fields:
>>
>> - prior to enrollment, by pre-creating a host and setting the
>> attributes at that time.
>>
>> - after the enrollment, right from the host using host keytab
>
> I started looking at the latter as it seems a simpler route, the host
> principal seems to lack the write to rebuild automembership for itself -
> is this something I can change?
>
> [root@blah ~]# kinit -k
> [root@blah ~]# ipa automember-rebuild --hosts=`hostname`
> ipa: ERROR: Insufficient access: Insufficient 'add' privilege to add the
> entry 'cn=automember rebuild membership,cn=tasks,cn=config'.
>
> Thanks a lot
> Angus
>
>
>
> ------------------------------------------------------------------------
> *From:* Alexander Bokovoy <abokovoy(a)redhat.com>
> *Sent:* 20 May 2022 13:39
> *To:* FreeIPA users list <freeipa-users(a)lists.fedorahosted.org>
> *Cc:* Angus Clarke <angus(a)charworth.com>
> *Subject:* Re: [Freeipa-users] hostgroup automember rules
>
> Hi Angus,
>
> On pe, 20 touko 2022, Angus Clarke via FreeIPA-users wrote:
>>Hello
>>
>>FreeIPA 4.6.8
>>
>>We are very happy with hostgroup automember rules based on servername
>>attribute however one of our internal customers uses a generic
>>servername template for all of their servers regardless of its
>>function.
>>
>>So I'm wondering what other attributes I might use for hostgroup
>>automember - perhaps some of the attributes can be configured by the
>>ipa-client-install (the host's "description" field perhaps) although I
>>don't see such mention in the man page ... Presumably they could use a
>>different enrollment user ("enrolledby") for each of their hostgroup
>>functions (not ideal.)
>>
>>There are various attribute fields in the WebUI but I don't find much
>>documentation for them. What is the "|" field - perhaps I can exploit
>>this somehow?
>
> Few years ago a customer of mine asked a similar question. Here is what
> I answered:
>
> ----------------------------------------------------------------------
> You can use nsHardwarePlatform attribute (part of nsHost objectclass).
> It is exposed as '--platform' in IPA CLI for 'ipa host-*' commands.
>
> Originally it was supposed to be filled by the IPA client join process
> to 'uname -m' value. ipa-join tools still sends it to the server but the
> value is ignored completely by the join process. As the result,
> nsHardwarePlatform attribute is never set on the host object.
>
> I don't see any code in IPA itself that would rely on the content of
> nsHardwarePlatform attribute. We have web UI tests upstream that modify
> the field to test that you can modify it but that's all.
>
> Alternatively, one can use userClass attribute (--class in IPA CLI for
> host-* commands). This one is also not utilized and is left specifically
> for the customers to define its semantics.
>
> Another alternative is nsHostLocation attribute (--location in IPA CLI
> for host-*
> commands). Again, the semantics is totally left for customers to define.
>
> ----------------------------------------------------------------------
>
> There are two ways of setting these fields:
>
> - prior to enrollment, by pre-creating a host and setting the
> attributes at that time.
>
> - after the enrollment, right from the host using host keytab
>
> The former can be done by a designated user/service account and can be
> tuned with custom permissions to allow such modification. The latter
> relies on the fact that the host principal has some write rights
> already:
>
> # kinit -k
>
> # ipa host-show `hostname` --rights --all
> dn: fqdn=dc.ipa.test,cn=computers,cn=accounts,dc=ipa,dc=test
> Host name: dc.ipa.test
> Principal name: host/dc.ipa.test(a)IPA.TEST
> Principal alias: host/dc.ipa.test(a)IPA.TEST
> SSH public key: [skip]
> SSH public key fingerprint: [skip]
> Requires pre-authentication: True
> Trusted for delegation: False
> Trusted to authenticate as user: False
> Password: False
> Member of host-groups: ipaservers
> Keytab: True
> Managed by: dc.ipa.test
> Managing: dc.ipa.test
> attributelevelrights: {'aci': '', 'cn': 'rscwo', 'description':
> 'rscwo', 'enrolledby': 'rsc', 'fqdn': 'rsc', 'ipaassignedidview': 'rsc',
> 'ipaclientversion': 'rsc', 'ipakrbauthzdata': 'rsc', 'ipasshpubkey':
> 'rscwo', 'ipauniqueid': 'rsc', 'krballowedtodelegateto': '',
> 'krbauthindmaxrenewableage': '', 'krbauthindmaxticketlife': '',
> 'krbcanonicalname': 'rsc', 'krbextradata': '', 'krblastadminunlock': '',
> 'krblastfailedauth': '', 'krblastpwdchange': 'rscwo',
> 'krblastsuccessfulauth': '', 'krbloginfailedcount': '',
> 'krbmaxrenewableage': '', 'krbmaxticketlife': '', 'krbobjectreferences':
> '', 'krbpasswordexpiration': 'rsc', 'krbprincipalaliases': 'rsc',
> 'krbprincipalauthind': 'rsc', 'krbprincipalexpiration': 'rsc',
> 'krbprincipalkey': 'swo', 'krbprincipalname': 'rsc', 'krbprincipaltype':
> '', 'krbpwdhistory': '', 'krbpwdpolicyreference': '', 'krbticketflags':
> '', 'krbticketpolicyreference': '', 'krbupenabled': '', 'l': 'rscwo',
> 'managedby': 'rsc', 'memberof': 'rsc', 'nsaccountlock': '',
> 'nshardwareplatform': 'rscwo', 'nshostlocation': 'rscwo', 'nsosversion':
> 'rscwo', 'objectclass': 'rsc', 'serverhostname': 'rsc',
> 'usercertificate': 'rscwo', 'userclass': 'rsc', 'userpassword': 'swo'}
> cn: dc.ipa.test
> ipauniqueid: b179f1ea-c4b8-11ec-9e86-52540083ff9d
> krblastpwdchange: 20220425165647Z
> objectclass: top, ipaobject, nshost, ipahost, ipaservice, pkiuser,
> krbprincipalaux, krbprincipal, krbticketpolicyaux, ipasshhost,
> ipaSshGroupOfPubKeys
> serverhostname: dc
>
> So, the host/dc.ipa.test(a)IPA.TEST principal can write to:
>
> - nsHardwarePlatform
> - nsHostLocation
> - nsOSVersion
> - l (locality)
> - description
>
> but it cannot write to 'userClass' attribute.
>
> A handy mapping between attributes and command parameters is
> 'show-mappings' command:
>
> # ipa show-mappings host-mod
> Parameter : LDAP attribute
> ========= : ==============
> desc : description?
> locality : l?
> location : nshostlocation?
> platform : nshardwareplatform?
> os : nsosversion?
> password : userpassword?
> random : random?
> certificate : usercertificate*
> krbprincipalname : krbprincipalname*
> macaddress : macaddress*
> sshpubkey : ipasshpubkey*
> class : userclass*
> auth-ind : krbprincipalauthind*
> requires-pre-auth : ipakrbrequirespreauth?
> ok-as-delegate : ipakrbokasdelegate?
> ok-to-auth-as-delegate : ipakrboktoauthasdelegate?
> rights : rights
> updatedns : updatedns?
>
> If you want to change parameters from the host itself, it would be
> possible with
>
> # kinit -k
> # ipa host-mod `hostname` --locality=foo --location=bar
> --platform=some-platform --desc=some-host
>
> --
> / Alexander Bokovoy
> Sr. Principal Software Engineer
> Security / Identity Management Engineering
> Red Hat Limited, Finland
>
>
> _______________________________________________
> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-leave(a)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.fedoraho...
> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
>
1 year, 12 months
Re: hostgroup automember rules
by Alexander Bokovoy
Hi Angus,
On pe, 20 touko 2022, Angus Clarke via FreeIPA-users wrote:
>Hello
>
>FreeIPA 4.6.8
>
>We are very happy with hostgroup automember rules based on servername
>attribute however one of our internal customers uses a generic
>servername template for all of their servers regardless of its
>function.
>
>So I'm wondering what other attributes I might use for hostgroup
>automember - perhaps some of the attributes can be configured by the
>ipa-client-install (the host's "description" field perhaps) although I
>don't see such mention in the man page ... Presumably they could use a
>different enrollment user ("enrolledby") for each of their hostgroup
>functions (not ideal.)
>
>There are various attribute fields in the WebUI but I don't find much
>documentation for them. What is the "|" field - perhaps I can exploit
>this somehow?
Few years ago a customer of mine asked a similar question. Here is what
I answered:
----------------------------------------------------------------------
You can use nsHardwarePlatform attribute (part of nsHost objectclass).
It is exposed as '--platform' in IPA CLI for 'ipa host-*' commands.
Originally it was supposed to be filled by the IPA client join process
to 'uname -m' value. ipa-join tools still sends it to the server but the
value is ignored completely by the join process. As the result,
nsHardwarePlatform attribute is never set on the host object.
I don't see any code in IPA itself that would rely on the content of
nsHardwarePlatform attribute. We have web UI tests upstream that modify
the field to test that you can modify it but that's all.
Alternatively, one can use userClass attribute (--class in IPA CLI for
host-* commands). This one is also not utilized and is left specifically
for the customers to define its semantics.
Another alternative is nsHostLocation attribute (--location in IPA CLI for host-*
commands). Again, the semantics is totally left for customers to define.
----------------------------------------------------------------------
There are two ways of setting these fields:
- prior to enrollment, by pre-creating a host and setting the
attributes at that time.
- after the enrollment, right from the host using host keytab
The former can be done by a designated user/service account and can be
tuned with custom permissions to allow such modification. The latter
relies on the fact that the host principal has some write rights
already:
# kinit -k
# ipa host-show `hostname` --rights --all
dn: fqdn=dc.ipa.test,cn=computers,cn=accounts,dc=ipa,dc=test
Host name: dc.ipa.test
Principal name: host/dc.ipa.test(a)IPA.TEST
Principal alias: host/dc.ipa.test(a)IPA.TEST
SSH public key: [skip]
SSH public key fingerprint: [skip]
Requires pre-authentication: True
Trusted for delegation: False
Trusted to authenticate as user: False
Password: False
Member of host-groups: ipaservers
Keytab: True
Managed by: dc.ipa.test
Managing: dc.ipa.test
attributelevelrights: {'aci': '', 'cn': 'rscwo', 'description': 'rscwo', 'enrolledby': 'rsc', 'fqdn': 'rsc', 'ipaassignedidview': 'rsc', 'ipaclientversion': 'rsc', 'ipakrbauthzdata': 'rsc', 'ipasshpubkey': 'rscwo', 'ipauniqueid': 'rsc', 'krballowedtodelegateto': '', 'krbauthindmaxrenewableage': '', 'krbauthindmaxticketlife': '', 'krbcanonicalname': 'rsc', 'krbextradata': '', 'krblastadminunlock': '', 'krblastfailedauth': '', 'krblastpwdchange': 'rscwo', 'krblastsuccessfulauth': '', 'krbloginfailedcount': '', 'krbmaxrenewableage': '', 'krbmaxticketlife': '', 'krbobjectreferences': '', 'krbpasswordexpiration': 'rsc', 'krbprincipalaliases': 'rsc', 'krbprincipalauthind': 'rsc', 'krbprincipalexpiration': 'rsc', 'krbprincipalkey': 'swo', 'krbprincipalname': 'rsc', 'krbprincipaltype': '', 'krbpwdhistory': '', 'krbpwdpolicyreference': '', 'krbticketflags': '', 'krbticketpolicyreference': '', 'krbupenabled': '', 'l': 'rscwo', 'managedby': 'rsc', 'memberof': 'rsc', 'nsaccountlock': '', 'nshardwareplatform': 'rscwo', 'nshostlocation': 'rscwo', 'nsosversion': 'rscwo', 'objectclass': 'rsc', 'serverhostname': 'rsc', 'usercertificate': 'rscwo', 'userclass': 'rsc', 'userpassword': 'swo'}
cn: dc.ipa.test
ipauniqueid: b179f1ea-c4b8-11ec-9e86-52540083ff9d
krblastpwdchange: 20220425165647Z
objectclass: top, ipaobject, nshost, ipahost, ipaservice, pkiuser, krbprincipalaux, krbprincipal, krbticketpolicyaux, ipasshhost, ipaSshGroupOfPubKeys
serverhostname: dc
So, the host/dc.ipa.test(a)IPA.TEST principal can write to:
- nsHardwarePlatform
- nsHostLocation
- nsOSVersion
- l (locality)
- description
but it cannot write to 'userClass' attribute.
A handy mapping between attributes and command parameters is
'show-mappings' command:
# ipa show-mappings host-mod
Parameter : LDAP attribute
========= : ==============
desc : description?
locality : l?
location : nshostlocation?
platform : nshardwareplatform?
os : nsosversion?
password : userpassword?
random : random?
certificate : usercertificate*
krbprincipalname : krbprincipalname*
macaddress : macaddress*
sshpubkey : ipasshpubkey*
class : userclass*
auth-ind : krbprincipalauthind*
requires-pre-auth : ipakrbrequirespreauth?
ok-as-delegate : ipakrbokasdelegate?
ok-to-auth-as-delegate : ipakrboktoauthasdelegate?
rights : rights
updatedns : updatedns?
If you want to change parameters from the host itself, it would be
possible with
# kinit -k
# ipa host-mod `hostname` --locality=foo --location=bar --platform=some-platform --desc=some-host
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
1 year, 12 months
Are URI dns records required?
by Ranbir
Hello,
My employer uses Windows for DNS and would prefer to keep using that
instead of freeipa's integrated DNS. Ok, sure, why not? I don't like
it, but there are bigger battles to fight.
I did the install on the first server without DNS, grabbed the DNS
records that needed to be imported into Windows DNS and handed them to
the Windows admin. He came back telling me that URI records aren't
supported in Windows DNS. Sweeeeeeeeet.
I can see that SRV records are still listed. Does that mean the URI
records can be safely left out?
Thanks,
--
Ranbir
1 year, 12 months
