[Freeipa-users] Re: hostgroup automember rules
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/ 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
Sent: 26 May 2022 09:11
To: Rob Crittenden ; FreeIPA users list
; Alexander Bokovoy
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
Sent: 25 May 2022 20:24
To: FreeIPA users list ; Alexander
Bokovoy
Cc: Angus Clarke
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
> *Sent:* 20 May 2022 13:39
> *To:* FreeIPA users list
> *Cc:* Angus Clarke
> *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
[Freeipa-users] Re: hostgroup automember rules
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
> *Sent:* 25 May 2022 20:24
> *To:* FreeIPA users list ;
> Alexander Bokovoy
> *Cc:* Angus Clarke
> *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
>> *Sent:* 20 May 2022 13:39
>> *To:* FreeIPA users list
>> *Cc:* Angus Clarke
>> *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.
>>
>> --
>>
>
[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
Sent: 25 May 2022 20:24
To: FreeIPA users list ; Alexander
Bokovoy
Cc: Angus Clarke
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
> *Sent:* 20 May 2022 13:39
> *To:* FreeIPA users list
> *Cc:* Angus Clarke
> *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.t...@ipa.test
>Principal alias: host/dc.ipa.t...@ipa.test
>SSH public key: [skip]
>
[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
> *Sent:* 20 May 2022 13:39
> *To:* FreeIPA users list
> *Cc:* Angus Clarke
> *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.t...@ipa.test
> Principal alias: host/dc.ipa.t...@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':
> '',
[Freeipa-users] Re: hostgroup automember rules
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
Sent: 20 May 2022 13:39
To: FreeIPA users list
Cc: Angus Clarke
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.t...@ipa.test
Principal alias: host/dc.ipa.t...@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',
[Freeipa-users] Re: hostgroup automember rules
Thanks a lot Alexander.
From: Alexander Bokovoy
Sent: 20 May 2022 13:39
To: FreeIPA users list
Cc: Angus Clarke
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.t...@ipa.test
Principal alias: host/dc.ipa.t...@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.t...@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
[Freeipa-users] Re: hostgroup automember rules
Thanks a lot Flo.
From: Florence Blanc-Renaud
Sent: 20 May 2022 13:12
To: FreeIPA users list
Cc: Angus Clarke
Subject: Re: [Freeipa-users] hostgroup automember rules
Hi,
On Fri, May 20, 2022 at 11:48 AM Angus Clarke via FreeIPA-users
mailto:freeipa-users@lists.fedorahosted.org>>
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?
The automember group functionality is described in this chapter: Automating
group membership using IdM
CLI.
You can define a new hostgroup with an automember rule based on any attribute
defined in the schema. Just be aware that the conditions are defined using
Perl-compatible regular expressions (PCRE) format.
The 'l' attribute is an alias for 'locality' or 'localityname' and can contain
any string. For any attribute you can find its description in the LDAP schema.
The host entries have multiple object classes. For instance if you run
ipa host-show server.ipa.test --all --raw
you can see all its objectclasses:
objectClass: top
objectClass: ipaobject
objectClass: nshost
objectClass: ipahost
objectClass: ipaservice
objectClass: pkiuser
objectClass: krbprincipalaux
objectClass: krbprincipal
objectClass: krbticketpolicyaux
objectClass: ipasshhost
objectClass: ipaSshGroupOfPubKeys
Each object class defines the mandatory/optional attributes that the entry can
contain. For instance in order to find the attributes for the nshost
objectclass:
ldapsearch -LLL -o ldif-wrap=no -b cn=schema -s base objectclasses | grep -i
nshost
objectclasses: ( nsHost-oid NAME 'nsHost' DESC 'Netscape defined objectclass'
SUP top STRUCTURAL MUST cn MAY ( serverHostName $ description $ l $
nsHostLocation $ nsHardwarePlatform $ nsOsVersion ) X-ORIGIN 'Netscape' )
The nshost objectclass allows the presence of serverhostname, description, l
etc...
Now to find what description can contain:
ldapsearch -LLL -o ldif-wrap=no -b cn=schema -s base attributetypes | grep -i
description
attributetypes: ( 2.5.4.13 NAME 'description' EQUALITY caseIgnoreMatch SUBSTR
caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'RFC
4519' )
The SYNTAX part defines the type of data (the RFC
4517
defines 1.3.6.1.4.1.1466.115.121.1.15 as a DirectoryString).
With this knowledge, you can pick an attribute where you want to store
information that can be used to group the hosts together, and create the
matching rule using this attribute.
If you are curious about LDAP schema in general, you can read the RFC
4519.
HTH,
flo
Any advice gladly received.
Thanks a lot
Angus
___
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:
[Freeipa-users] Re: 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.t...@ipa.test
Principal alias: host/dc.ipa.t...@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.t...@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
[Freeipa-users] Re: hostgroup automember rules
Hi,
On Fri, May 20, 2022 at 11:48 AM Angus Clarke via FreeIPA-users <
freeipa-users@lists.fedorahosted.org> 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?
>
The automember group functionality is described in this chapter: Automating
group membership using IdM CLI
.
You can define a new hostgroup with an automember rule based on any
attribute defined in the schema. Just be aware that the conditions are
defined using Perl-compatible regular expressions (PCRE) format.
The 'l' attribute is an alias for 'locality' or 'localityname' and can
contain any string. For any attribute you can find its description in the
LDAP schema.
The host entries have multiple object classes. For instance if you run
ipa host-show server.ipa.test --all --raw
you can see all its objectclasses:
objectClass: top
objectClass: ipaobject
objectClass: nshost
objectClass: ipahost
objectClass: ipaservice
objectClass: pkiuser
objectClass: krbprincipalaux
objectClass: krbprincipal
objectClass: krbticketpolicyaux
objectClass: ipasshhost
objectClass: ipaSshGroupOfPubKeys
Each object class defines the mandatory/optional attributes that the entry
can contain. For instance in order to find the attributes for the *nshost*
objectclass:
ldapsearch -LLL -o ldif-wrap=no -b cn=schema -s base objectclasses | grep
-i nshost
objectclasses: ( nsHost-oid NAME 'nsHost' DESC 'Netscape defined
objectclass' SUP top STRUCTURAL MUST cn MAY ( serverHostName $ description
$ l $ nsHostLocation $ nsHardwarePlatform $ nsOsVersion ) X-ORIGIN
'Netscape' )
The *nshost* objectclass allows the presence of *serverhostname*,
*description*, *l* etc...
Now to find what *description* can contain:
ldapsearch -LLL -o ldif-wrap=no -b cn=schema -s base attributetypes | grep
-i description
attributetypes: ( 2.5.4.13 NAME 'description' EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
X-ORIGIN 'RFC 4519' )
The SYNTAX part defines the type of data (the RFC 4517
defines
1.3.6.1.4.1.1466.115.121.1.15 as a DirectoryString).
With this knowledge, you can pick an attribute where you want to store
information that can be used to group the hosts together, and create the
matching rule using this attribute.
If you are curious about LDAP schema in general, you can read the RFC 4519
.
HTH,
flo
> Any advice gladly received.
>
> Thanks a lot
> Angus
> ___
> 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 on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
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 on the list, report it:
https://pagure.io/fedora-infrastructure
