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....
>