Re: [Freeipa-users] A crazy idea maybe, migration to Free-IPA 4.1.
Thanks, this option worked in that script! 24-Oct-14 12:43, Alexander Bokovoy пишет: You can specify multiple servers yourself too as -H "ldap://ipa1.example.com ldap://ipa2.example.com ldap://ipa3.example.com"; -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] A crazy idea maybe, migration to Free-IPA 4.1.
On Fri, 24 Oct 2014, Orkhan Gasimov wrote:
Awesome, it worked!
Just one final question: how to make that script search not only in
ipa1.example.com's LDAP database, but also in ipa2.example.com's LDAP
in case ipa1 is inaccessible? It's vital for a production environment!
There are two things here:
- ldapsearch should use DNS SRV records to discover servers
- ldapsearch call should rotate over all servers in case of an error
First is achieved with -H option if you don't specify a host but rather
use DN: dc=example,dc=com, encoded in a way of RFC 2396:
dc%3Dexample%2Cdc%3Dcom
where %3D is escape sequence for '=' and %2C is escape sequence for ','
ldapsearch -H ldap://dc%3Dexample%2Cdc%3Dcom
would request ldapsearch to first go and resolve DNS SRV record
_ldap._tcp.example.com and then connect to the list of servers returned.
All tools from OpenLDAP client side use this technique and rotate over
list of servers. You can specify multiple servers yourself too as
-H "ldap://ipa1.example.com ldap://ipa2.example.com ldap://ipa3.example.com";
but using DNS SRV records is more reliable because you don't need to
change your script when you decommission the servers.
I tried copying the whole section of code from " ldapsearch ..." to
"... done"
and putting it after a new instance of " if [ ! -s "$tmpf" ]; then ",
but it didn't work (I'm not a programmer...).
My current cron script is like this:
https://cloud.mail.ru/public/fdf2e60c5df8%2Fsudo.sh
Programmers, please take a glance at the file - logically it shouldn't
be difficult to make necessary modifications,
but I don't know how...
23-Oct-14 21:40, Alexander Bokovoy пишет:
try adding something like this:
old_krb5_ccache=${KRB5_CCACHE}
KRB5_CCACHE=/tmp/_hostgroups_access.ccache.$$
export KRB5_CCACHE
kinit -k -t /etc/krb5.keytab host/`hostname`
# perform actual search
ldapsearch -Y GSSAPI .
# end of script
kdestroy
KRB5_CCACHE=${old_krb5_ccache}
export KRB5_CCACHE
--
/ Alexander Bokovoy
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] A crazy idea maybe, migration to Free-IPA 4.1.
Awesome, it worked!
Just one final question: how to make that script search not only in
ipa1.example.com's LDAP database, but also in ipa2.example.com's LDAP in
case ipa1 is inaccessible? It's vital for a production environment!
I tried copying the whole section of code from " ldapsearch ..." to "...
done"
and putting it after a new instance of " if [ ! -s "$tmpf" ]; then ",
but it didn't work (I'm not a programmer...).
My current cron script is like this:
https://cloud.mail.ru/public/fdf2e60c5df8%2Fsudo.sh
Programmers, please take a glance at the file - logically it shouldn't
be difficult to make necessary modifications,
but I don't know how...
23-Oct-14 21:40, Alexander Bokovoy пишет:
try adding something like this:
old_krb5_ccache=${KRB5_CCACHE}
KRB5_CCACHE=/tmp/_hostgroups_access.ccache.$$
export KRB5_CCACHE
kinit -k -t /etc/krb5.keytab host/`hostname`
# perform actual search
ldapsearch -Y GSSAPI .
# end of script
kdestroy
KRB5_CCACHE=${old_krb5_ccache}
export KRB5_CCACHE
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] A crazy idea maybe, migration to Free-IPA 4.1.
Very interesting!
You're right, I used simple "ldapsearch -x" command on the client when
browsing the LDAP database. With IPA 3.3 it returned a whole lot of info about
hostgroups, but with IPA 4.1 - only a single string 'cn=ng,cn=compat,$SUFFIX'.
That's why current script didn't work.
Tomorrow at work I'll try your advice, and if there's no another problem
between the chair and the keyboard, I'll definitely stick with FreeIPA 4.1!
Отправлено от Blue Mail
На 21:40, 23.10.2014, в 21:40, Alexander Bokovoy
написал:п>On Thu, 23 Oct 2014, Орхан Касумов wrote:
>>
>>Alright then, thanks for info!
>>Tomorrow is the deadline for my researches on FreeIPA.
>>Then I have to start deploying a centralized management solution in
>our production environment.
>>Please help me to make a final decision on which version of FreeIPA to
>choose - 3.3 or 4.1?
>>I'd like to have all the benefits of the latest version, but all our
>production servers are FreeBSD.
>>With all information sources at my disposal right now I tend to choose
>FreeIPA 3.3.
>>The cause is that otherwise I can't use host groups with sudo commands
>-
>>the cron script proposed at FreeBSD forums works with old way of
>storing host group information in the LDAP directory of FreeIPA.
>>Is there any workaround for this? (P.S. Here's what I'm talking about:
>>>" The tricky part was getting sudo to work with host groups.
>FreeIPA
>>>keeps host groups in netgroups, and FreeBSD's support for netgroups
>is
>>>limited. One solution would have been to enable NIS services on the
>>>FreeIPA server so that we could use proper netgroups on FreeBSD
>>>clients. We didn't like that solution, so instead we wrote a script
>>>that pulls all netgroup data from FreeIPA and stores it in
>>>/etc/netgroup . We run the script every hour via cron . "
>>>
>>>The script looks for host groups in
>>>'cn=hostgroups,cn=accounts,dc=', and that works with FreeIPA
>>>3.3. But in FreeIPA v4 host groups get in
>>>'cn=ng,cn=compat,dc='. So the script needs modification. But
>I
>>>don't know how to modify the script, simply changing the string
>passed
>>>to the ldapsearch command doesn't work.)
>I think you completely missed the way FreeIPA works. :)
>
>Host groups are always in cn=hostgroups,cn=accounts,$SUFFIX, no changes
>were done.
>
>What you see in cn=ng,cn=compat,$SUFFIX are net groups for
>compatibility
>with older applications which expect old LDAP schema. The tree in
>cn=compat,$SUFFIX is provided through schema compatibility plugin and
>was also provided this way for quite a long time.
>
>What I think you are stumbling upon is the fact that starting with
>FreeIPA 4.0 we are providing more fine-grained access control to the
>data in LDAP tree.
>
>For example:
>$ ipa permission-find
>--subtree=cn=hostgroups,cn=accounts,dc=ipacloud,dc=test --right=read
>-
>2 permissions matched
>-
> Permission name: System: Read Hostgroup Membership
> Granted rights: read, compare, search
> Effective attributes: member, memberhost, memberof, memberuser
> Default attributes: member, memberof, memberuser, memberhost
> Bind rule type: all
> Subtree: cn=hostgroups,cn=accounts,dc=ipacloud,dc=test
> Type: hostgroup
>
> Permission name: System: Read Hostgroups
> Granted rights: read, compare, search
> Effective attributes: businesscategory, cn, createtimestamp,
>description, entryusn, ipauniqueid, modifytimestamp, o, objectclass,
>ou,
>owner, seealso
> Default attributes: cn, businesscategory, objectclass, description, o,
>ipauniqueid, owner, ou, seealso
> Bind rule type: all
> Subtree: cn=hostgroups,cn=accounts,dc=ipacloud,dc=test
> Type: hostgroup
>
>Number of entries returned 2
>
>
>As you can see, both permissions require bind rule type 'all' which
>means 'all authenticated users'.
>
>On contrast, in schema compat tree you'll get the whole tree
>anonymously
>
>$ ipa permission-find --target=cn=ng,cn=compat,dc=ipacloud,dc=test
>--right=read
>
>1 permission matched
>
> Permission name: System: Read Netgroup Compat Tree
> Granted rights: read, compare, search
>Effective attributes: cn, createtimestamp, entryusn, membernisnetgroup,
>modifytimestamp, nisnetgrouptriple, objectclass
>Default attributes: objectclass, nisnetgrouptriple, membernisnetgroup,
>cn
> Bind rule type: anonymous
> Subtree: dc=ipacloud,dc=test
> Target DN: cn=ng,cn=compat,dc=ipacloud,dc=test
>
>Number of entries returned 1
>
>
>This means that your script should work as before, only that it needs
>to
>authenticate before connecting. As you run it as root, you can use host
>keytab, try adding something like this:
>
>old_krb5_ccache=${KRB5_CCACHE}
>KRB5_CCACHE=/tmp/_hostgroups_access.ccache.$$
>export KRB5_CCACHE
>kinit -k -t /etc/krb5.keytab host/`hostname`
># perform actual search
>ldapsearch -Y GSSAPI .
>
># end of sc
Re: [Freeipa-users] A crazy idea maybe, migration to Free-IPA 4.1.
On Thu, 23 Oct 2014, Орхан Касумов wrote:
Alright then, thanks for info!
Tomorrow is the deadline for my researches on FreeIPA.
Then I have to start deploying a centralized management solution in our
production environment.
Please help me to make a final decision on which version of FreeIPA to choose -
3.3 or 4.1?
I'd like to have all the benefits of the latest version, but all our production
servers are FreeBSD.
With all information sources at my disposal right now I tend to choose FreeIPA
3.3.
The cause is that otherwise I can't use host groups with sudo commands -
the cron script proposed at FreeBSD forums works with old way of storing host
group information in the LDAP directory of FreeIPA.
Is there any workaround for this? (P.S. Here's what I'm talking about:
" The tricky part was getting sudo to work with host groups. FreeIPA
keeps host groups in netgroups, and FreeBSD's support for netgroups is
limited. One solution would have been to enable NIS services on the
FreeIPA server so that we could use proper netgroups on FreeBSD
clients. We didn't like that solution, so instead we wrote a script
that pulls all netgroup data from FreeIPA and stores it in
/etc/netgroup . We run the script every hour via cron . "
The script looks for host groups in
'cn=hostgroups,cn=accounts,dc=', and that works with FreeIPA
3.3. But in FreeIPA v4 host groups get in
'cn=ng,cn=compat,dc='. So the script needs modification. But I
don't know how to modify the script, simply changing the string passed
to the ldapsearch command doesn't work.)
I think you completely missed the way FreeIPA works. :)
Host groups are always in cn=hostgroups,cn=accounts,$SUFFIX, no changes
were done.
What you see in cn=ng,cn=compat,$SUFFIX are net groups for compatibility
with older applications which expect old LDAP schema. The tree in
cn=compat,$SUFFIX is provided through schema compatibility plugin and
was also provided this way for quite a long time.
What I think you are stumbling upon is the fact that starting with
FreeIPA 4.0 we are providing more fine-grained access control to the
data in LDAP tree.
For example:
$ ipa permission-find --subtree=cn=hostgroups,cn=accounts,dc=ipacloud,dc=test
--right=read
-
2 permissions matched
-
Permission name: System: Read Hostgroup Membership
Granted rights: read, compare, search
Effective attributes: member, memberhost, memberof, memberuser
Default attributes: member, memberof, memberuser, memberhost
Bind rule type: all
Subtree: cn=hostgroups,cn=accounts,dc=ipacloud,dc=test
Type: hostgroup
Permission name: System: Read Hostgroups
Granted rights: read, compare, search
Effective attributes: businesscategory, cn, createtimestamp,
description, entryusn, ipauniqueid, modifytimestamp, o, objectclass, ou,
owner, seealso
Default attributes: cn, businesscategory, objectclass, description, o,
ipauniqueid, owner, ou, seealso
Bind rule type: all
Subtree: cn=hostgroups,cn=accounts,dc=ipacloud,dc=test
Type: hostgroup
Number of entries returned 2
As you can see, both permissions require bind rule type 'all' which
means 'all authenticated users'.
On contrast, in schema compat tree you'll get the whole tree anonymously
$ ipa permission-find --target=cn=ng,cn=compat,dc=ipacloud,dc=test --right=read
1 permission matched
Permission name: System: Read Netgroup Compat Tree
Granted rights: read, compare, search
Effective attributes: cn, createtimestamp, entryusn, membernisnetgroup,
modifytimestamp, nisnetgrouptriple, objectclass
Default attributes: objectclass, nisnetgrouptriple, membernisnetgroup, cn
Bind rule type: anonymous
Subtree: dc=ipacloud,dc=test
Target DN: cn=ng,cn=compat,dc=ipacloud,dc=test
Number of entries returned 1
This means that your script should work as before, only that it needs to
authenticate before connecting. As you run it as root, you can use host
keytab, try adding something like this:
old_krb5_ccache=${KRB5_CCACHE}
KRB5_CCACHE=/tmp/_hostgroups_access.ccache.$$
export KRB5_CCACHE
kinit -k -t /etc/krb5.keytab host/`hostname`
# perform actual search
ldapsearch -Y GSSAPI .
# end of script
kdestroy
KRB5_CCACHE=${old_krb5_ccache}
export KRB5_CCACHE
note that ldapsearch -Y GSSAPI will use Kerberos authentication when
talking to IPA LDAP server and use host/`hostname` principal for that.
This should be enough for allowing access to the host groups.
--
/ Alexander Bokovoy
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] A crazy idea maybe, migration to Free-IPA 4.1.
Alright then, thanks for info! Tomorrow is the deadline for my researches on FreeIPA. Then I have to start deploying a centralized management solution in our production environment. Please help me to make a final decision on which version of FreeIPA to choose - 3.3 or 4.1? I'd like to have all the benefits of the latest version, but all our production servers are FreeBSD. With all information sources at my disposal right now I tend to choose FreeIPA 3.3. The cause is that otherwise I can't use host groups with sudo commands - the cron script proposed at FreeBSD forums works with old way of storing host group information in the LDAP directory of FreeIPA. Is there any workaround for this? (P.S. Here's what I'm talking about: >" The tricky part was getting sudo to work with host groups. FreeIPA keeps >host groups in netgroups, and FreeBSD's support for netgroups is limited. One >solution would have been to enable NIS services on the FreeIPA server so that >we could use proper netgroups on FreeBSD clients. We didn't like that >solution, so instead we wrote a script that pulls all netgroup data from >FreeIPA and stores it in /etc/netgroup . We run the script every hour via >cron . " > >The script looks for host groups in 'cn=hostgroups,cn=accounts,dc=', >and that works with FreeIPA 3.3. But in FreeIPA v4 host groups get in >'cn=ng,cn=compat,dc='. So the script needs modification. But I don't >know how to modify the script, simply changing the string passed to the >ldapsearch command doesn't work.) Thu, 23 Oct 2014 16:41:55 +0300 от Alexander Bokovoy : >On Thu, 23 Oct 2014, Orkhan Gasimov wrote: >>And another interesting behaviour. >> >>Say a user "netuser" is a member of a user group "netstaff", >>and a host "bsd.example.com" is a member of a host group "nethosts". >>We then create an HBAC rule "netstaff_to_nethosts": >> >>Who: User Groups -> netstaff -- Accessing: Host Groups -> nethosts -- >>Via Service: Specified Services and Groups -> sshd >Here you are allowing only sshd service for use. > >> >>And we create a SUDO rule "test": >> >>Who: Specified Users and Groups -> netuser -- Access this host: >>bsd.example.com -- Run Commands: Any Command >> >>Expected result is this: user "netuser" should be able to SSH to host >>"bsd.example.com" and successfully issue the command "sudo shutdown -r >>now". >> >>What happens instead: user "netuser" is able to SSH to host >>"bsd.example.com", but issuing the command "sudo shutdown -r now" >>produces this output (password is entered correctly): >> >>$ shutdown -r now >>Password: >>Ying Tong Iddle I Po >>Password: >>Do you think like you type? >>Password: >>Have you considered trying to match wits with a rutabaga? >> >>This is funny, and you can continue trying sudo and getting funny >>outputs; but the only way for the command to work properly is to >>change the HBAC rule: >> >>Who: User Groups -> netstaff -- Accessing: Host Groups -> nethosts -- >>Via Service: Specified Services and Groups -> ANY SERVICE >> >>Is this the correct behavior? I don't remember anything like this in >>FreeIPA 3.3. >Yes. The behaviour did not change since may be FreeIPA 2.0. > >sudo does authenticate and authorize user first via PAM stack and then applies >own >ruleset. So HBAC rules get applied here and since you don't have >allow_all rule that would allow any user to access any service on any >host, you get denial. > >Instead of using only sshd service in HBAC rule, make a service group >and add both sshd and sudo there. > >Alternatively you can add multiple HBAC rules, one for sshd, one for >sudo. > > >-- >/ Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] A crazy idea maybe, migration to Free-IPA 4.1.
On Thu, 23 Oct 2014, Orkhan Gasimov wrote: And another interesting behaviour. Say a user "netuser" is a member of a user group "netstaff", and a host "bsd.example.com" is a member of a host group "nethosts". We then create an HBAC rule "netstaff_to_nethosts": Who: User Groups -> netstaff -- Accessing: Host Groups -> nethosts -- Via Service: Specified Services and Groups -> sshd Here you are allowing only sshd service for use. And we create a SUDO rule "test": Who: Specified Users and Groups -> netuser -- Access this host: bsd.example.com -- Run Commands: Any Command Expected result is this: user "netuser" should be able to SSH to host "bsd.example.com" and successfully issue the command "sudo shutdown -r now". What happens instead: user "netuser" is able to SSH to host "bsd.example.com", but issuing the command "sudo shutdown -r now" produces this output (password is entered correctly): $ shutdown -r now Password: Ying Tong Iddle I Po Password: Do you think like you type? Password: Have you considered trying to match wits with a rutabaga? This is funny, and you can continue trying sudo and getting funny outputs; but the only way for the command to work properly is to change the HBAC rule: Who: User Groups -> netstaff -- Accessing: Host Groups -> nethosts -- Via Service: Specified Services and Groups -> ANY SERVICE Is this the correct behavior? I don't remember anything like this in FreeIPA 3.3. Yes. The behaviour did not change since may be FreeIPA 2.0. sudo does authenticate and authorize user first via PAM stack and then applies own ruleset. So HBAC rules get applied here and since you don't have allow_all rule that would allow any user to access any service on any host, you get denial. Instead of using only sshd service in HBAC rule, make a service group and add both sshd and sudo there. Alternatively you can add multiple HBAC rules, one for sshd, one for sudo. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] A crazy idea maybe, migration to Free-IPA 4.1.
And another interesting behaviour. Say a user "netuser" is a member of a user group "netstaff", and a host "bsd.example.com" is a member of a host group "nethosts". We then create an HBAC rule "netstaff_to_nethosts": Who: User Groups -> netstaff -- Accessing: Host Groups -> nethosts -- Via Service: Specified Services and Groups -> sshd And we create a SUDO rule "test": Who: Specified Users and Groups -> netuser -- Access this host: bsd.example.com -- Run Commands: Any Command Expected result is this: user "netuser" should be able to SSH to host "bsd.example.com" and successfully issue the command "sudo shutdown -r now". What happens instead: user "netuser" is able to SSH to host "bsd.example.com", but issuing the command "sudo shutdown -r now" produces this output (password is entered correctly): $ shutdown -r now Password: Ying Tong Iddle I Po Password: Do you think like you type? Password: Have you considered trying to match wits with a rutabaga? This is funny, and you can continue trying sudo and getting funny outputs; but the only way for the command to work properly is to change the HBAC rule: Who: User Groups -> netstaff -- Accessing: Host Groups -> nethosts -- Via Service: Specified Services and Groups -> ANY SERVICE Is this the correct behavior? I don't remember anything like this in FreeIPA 3.3. 23-Oct-14 15:21, Orkhan Gasimov пишет: Yet with FreeIPA v4 we've got another thing to keep in mind regarding FreeBSD - FreeIPA integration: the cron script proposed at FreeBSD forums won't work. Here's what was said in the post: "The tricky part was gettingsudoto work with host groups. FreeIPA keeps host groups in netgroups, and FreeBSD's support for netgroups is limited. One solution would have been to enable NIS services on the FreeIPA server so that we could use proper netgroups on FreeBSD clients. We didn't like that solution, so instead we wrote a script that pulls all netgroup data from FreeIPA and stores it in/etc/netgroup. We run the script every hour viacron." The script looks for host groups in 'cn=hostgroups,cn=accounts,dc=', and that works with FreeIPA 3.3. But in FreeIPA v4 host groups get in 'cn=ng,cn=compat,dc='. So the script needs modification. 23-Oct-14 12:09, Orkhan Gasimov пишет: I already deployed FreeIPA 4.1 on Fedora 21 server alpha-release. Everything is good as far as FreeIPA server operation is concerned. 23-Oct-14 01:06, William Graboyes пишет: 3) am I insane for wanting to introduce FC21 into my environment? -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] A crazy idea maybe, migration to Free-IPA 4.1.
Yet with FreeIPA v4 we've got another thing to keep in mind regarding FreeBSD - FreeIPA integration: the cron script proposed at FreeBSD forums won't work. Here's what was said in the post: "The tricky part was gettingsudoto work with host groups. FreeIPA keeps host groups in netgroups, and FreeBSD's support for netgroups is limited. One solution would have been to enable NIS services on the FreeIPA server so that we could use proper netgroups on FreeBSD clients. We didn't like that solution, so instead we wrote a script that pulls all netgroup data from FreeIPA and stores it in/etc/netgroup. We run the script every hour viacron." The script looks for host groups in 'cn=hostgroups,cn=accounts,dc=', and that works with FreeIPA 3.3. But in FreeIPA v4 host groups get in 'cn=ng,cn=compat,dc='. So the script needs modification. 23-Oct-14 12:09, Orkhan Gasimov пишет: I already deployed FreeIPA 4.1 on Fedora 21 server alpha-release. Everything is good as far as FreeIPA server operation is concerned. 23-Oct-14 01:06, William Graboyes пишет: 3) am I insane for wanting to introduce FC21 into my environment? -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] A crazy idea maybe, migration to Free-IPA 4.1.
I already deployed FreeIPA 4.1 on Fedora 21 server alpha-release. Everything is good as far as FreeIPA server operation is concerned. 23-Oct-14 01:06, William Graboyes пишет: 3) am I insane for wanting to introduce FC21 into my environment? -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
[Freeipa-users] A crazy idea maybe, migration to Free-IPA 4.1.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello List, So the whole not being able to change the CA easily is becoming a regular point of contention in meetings. If I have read the e-mails on this list correctly this issue is fixed in 4.1. After spending a large amount of time thinking about this, I believe I have come to a solution that will appease management, my coworkers, and myself. Here is what I am thinking of doing. I am thinking I will install FC21 VM with free-IPA (which should be 4.1) then migrating my current install over there, followed by changing the CA to that of my contracted CA and third party issuer. The questions that come to mind are: 1) how does one migrate the information over to a new install, in this case 3.3 to 4.1 on separate servers? 2) is there any documentation on the process of changing the CA in 4.1? 3) am I insane for wanting to introduce FC21 into my environment? 4) has anyone done this, and what was your experience with doing so? Thanks, Bill -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUSA5LAAoJEJFMz73A1+zrVu4P/3rcjvj5Vlcf3M1mAFLIyRWS NMf5Qu+gRK9wR4MQkp3QJ46NC88TwZmwtYy6z31tMqwbRKzLR4/IUOGq89K/mjIl CuzGc5S0dW5ctfJPv+5E+shfytYtHeUsTSmMTFwazEGKq8bMEo0Lr7prZera2t8t NPeYSpECwPMU46g8ufS2oPSOQACmkIhAPfKAr5BATpM1g5JAJJ89oidd9ob7tu7n UKcTjqtEhXxbLVXi0+H65O9sZzgpDTk1Gfl52DOii/XVEgBsL8ybmk5902zAJsOg W2eamMVivFJD8SVas97DvRar0GMRNXilNZS6Q316N9mjOoVJJHONUb/VZ0t10BLc FRbc6hMRQJ3TQCdp37DYcaTblVnRanQJ9HBbih4hcErWG42mWEPzaQJljDO/If5f DfzTGai3Fd+1TIhOsX81XKH/8NCK+qpoaEJlsOJd2iScxv8f9AqMGKv1TAhZiJGY WXXma39WdoLy/p1DMDM6kg+gAnmxBxGU+5RxjXl+HkOkvK8nn3nUJa3GHD3a4Iep L6FLiRjZ8UuJbKsXPPIpKAioil8Lt1JbcFykCKFuEM6wQ5ehpOPRMYeZEqedvXPD Is3yEqtyXX+B/wEcCljL4kD9Wmntfkfh59ondcnlHZTkiQM/Fs6eY0FqEKIvcgj1 jbyjtbGUn5KRsXdGjBde =WagT -END PGP SIGNATURE- -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
