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 <[email protected]> > *Sent:* 20 May 2022 13:39 > *To:* FreeIPA users list <[email protected]> > *Cc:* Angus Clarke <[email protected]> > *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/[email protected] > Principal alias: host/[email protected] > 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/[email protected] 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 -- [email protected] > To unsubscribe send an email to [email protected] > 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/[email protected] > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > _______________________________________________ FreeIPA-users mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
