[Freeipa-users] Re: freeipa-client joins keep failing : Cannot find KDC for realm

2018-01-17 Thread Chris Moody via FreeIPA-users
That being said, just tried again on an ubuntu 14.04 node with these
same CLI params, and it failed, but the logs are complaining about
"SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked
as not trusted by the user", which never was reported in the ubuntu 16
system's logs.

Seems to mirror the bug/issue noted here:
https://pagure.io/freeipa/issue/7072

I am still curious why one has to explicitly call out '--server' for the
Ubuntu 16 system to join.

I can also start a different thread for the Ubuntu 14 system debugging
if need be, or can just continue here - your call.

-Chris


On 1/17/18 6:10 PM, Chris Moody via FreeIPA-users wrote:
> Just attempted the '--server' option you mention, as well as the
> '--domain' value that the parameter requires, and it actually SUCCEEDED
> in joining!
>
> I received "Client configuration complete." via the ipa-client-install
> command and was just able to successfully login to this node with a user
> in IPA.
>
> Which is wonderful news however I'm still now wondering what
> component might be failing or portion of autodiscovery perhaps
> missing/b0rk3d that's necessitating the --server param to be explicitly
> called.
>
> -Chris
>
>
> On 1/17/18 5:30 PM, Chris Moody via FreeIPA-users wrote:
>>> Might also be interesting to try to force a specific master by adding
>>> --server  to the install line, just to see.
>>>
>>> I'm guessing the client is old as it doesn't appear to support the
>>> newer-style ipa-getkeytab:
>
>
>
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org



smime.p7s
Description: S/MIME Cryptographic Signature
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


[Freeipa-users] Re: freeipa-client joins keep failing : Cannot find KDC for realm

2018-01-17 Thread Chris Moody via FreeIPA-users
Just attempted the '--server' option you mention, as well as the
'--domain' value that the parameter requires, and it actually SUCCEEDED
in joining!

I received "Client configuration complete." via the ipa-client-install
command and was just able to successfully login to this node with a user
in IPA.

Which is wonderful news however I'm still now wondering what
component might be failing or portion of autodiscovery perhaps
missing/b0rk3d that's necessitating the --server param to be explicitly
called.

-Chris


On 1/17/18 5:30 PM, Chris Moody via FreeIPA-users wrote:
>
>> Might also be interesting to try to force a specific master by adding
>> --server  to the install line, just to see.
>>
>> I'm guessing the client is old as it doesn't appear to support the
>> newer-style ipa-getkeytab:
>




smime.p7s
Description: S/MIME Cryptographic Signature
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


[Freeipa-users] Re: freeipa-client joins keep failing : Cannot find KDC for realm

2018-01-17 Thread Chris Moody via FreeIPA-users
Server:
=
[root@sfca-do-4 ~]# ipa --version
VERSION: 4.4.4, API_VERSION: 2.215

[root@sfca-do-4 ~]# cat /etc/fedora-release
Fedora release 25 (Twenty Five)


Client Node:
=
root@sfca-do-1:~# ipa-client-install --version
4.3.1

root@sfca-do-1:~# cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=16.04


I should also mention that my Ubuntu 14.04 nodes cannot join either, and
they have different freeipa-client versions in their repos and are
throwing some different log data if that's of any possible help.  The
only system that's been able to ipa-client-install join is the IPA
replication mate which is running the same rev of Fedora and
ipa-client/server.


Some more background, these servers for this client were recently built
and configured to use letsencrypt certificates so they can provide
public and ssl-accepted interfaces to users that this client services. 
Not sure if certificates and CAs could perhaps be playing into a
client-join (since I see no complaint about them in the install logs on
this client), but wanted to mention it anyway just in case there's some
reason that letsencrypt issued certs are perhaps factoring in.  Other
clients I service have successfully used similar setups to what I'm
trying to build currently, but were running on the 3.x services of IPA. 
This is my first pass at standing up functioning 4.x IPA servers.


Other replies inline.

On 1/17/18 2:36 PM, Rob Crittenden via FreeIPA-users wrote:
> Chris Moody wrote:
>> Thanks for taking a look gents.  Ask and ye shall receive.  :)
>>
> What version of IPA is this and what platform?
>
> Before an install can you ensure that there is nothing in
> /etc/krb5.conf.d/ (except may be crypto-policies)?
There is no /etc/krb5.conf.d/ dir on the client node.  I have tried with
both the system defaults in the /etc/krb5.conf file as well as with the
contents generated/output by the ipa-client-install command as I
mentioned initially if that's the component you're questioning.
>
> Same with /var/lib/sss/pubconf/krb5.include.d/
On client node:
root@sfca-do-1:~# ls -l /var/lib/sss/pubconf/krb5.include.d/
total 0

>
> Might also be interesting to try to force a specific master by adding
> --server  to the install line, just to see.
>
> I'm guessing the client is old as it doesn't appear to support the
> newer-style ipa-getkeytab:
Hmm... This client is fully updated/upgraded for any packages installed
via the Ubuntu repos.  Is the client version 4.3.1 not recent?  I can
manually add a different repo or pull source if need be to get whichever
client version you think might help.
>
> 2018-01-17T02:11:50Z DEBUG args=/usr/sbin/ipa-join -s
> sfca-do-4.ipa.xyz.com -b dc=ipa,dc=xyz,dc=com -h sfca-do-1.xyz.com
> 2018-01-17T02:11:51Z DEBUG Process finished, return code=0
> 2018-01-17T02:11:51Z DEBUG stdout=
> 2018-01-17T02:11:51Z DEBUG stderr=Failed to parse result: Failed to
> decode GetKeytab Control.
>
> Retrying with pre-4.0 keytab retrieval method...
> Keytab successfully retrieved and stored in: /etc/krb5.keytab
> Certificate subject base is: O=IPA.xyz.COM
>
> 2018-01-17T02:11:51Z INFO Enrolled in IPA realm IPA.xyz.COM
>
> It does look like it enrolls ok and gets a keytab.
>
> Note too that just about this it is able to get a TGT for the admin user
> via kinit:
>
> 2018-01-17T02:11:50Z DEBUG args=/usr/bin/kinit ad...@ipa.xyz.com -c
> /tmp/krbccCNSUmS/ccache
>
> The only difference between Kerberos usage between the enrollment and
> the rest is that during enrollment a fixed KDC is defined in the
> temporary krb5.conf:
>
> includedir /var/lib/sss/pubconf/krb5.include.d/
>
> [libdefaults]
>   default_realm = IPA.xyz.COM
>   dns_lookup_realm = false
>   dns_lookup_kdc = false
>   rdns = false
>   ticket_lifetime = 24h
>   forwardable = true
>   udp_preference_limit = 0
>   default_ccache_name = KEYRING:persistent:%{uid}
>
>
> [realms]
>   IPA.xyz.COM = {
> kdc = sfca-do-4.ipa.xyz.com:88
> master_kdc = sfca-do-4.ipa.xyz.com:88
> admin_server = sfca-do-4.ipa.xyz.com:749
> default_domain = xyz.com
> pkinit_anchors = FILE:/etc/ipa/ca.crt
>
>   }
>
> [domain_realm]
>   .xyz.com = IPA.xyz.COM
>   xyz.com = IPA.xyz.COM
>
>
> It is failing trying to autodiscover things later:
>
> includedir /var/lib/sss/pubconf/krb5.include.d/
>
> [libdefaults]
>   default_realm = IPA.xyz.COM
>   dns_lookup_realm = true
>   dns_lookup_kdc = true
>   rdns = false
>   ticket_lifetime = 24h
>   forwardable = true
>   udp_preference_limit = 0
>   default_ccache_name = KEYRING:persistent:%{uid}
>
>
> [realms]
>   IPA.xyz.COM = {
> pkinit_anchors = FILE:/etc/ipa/ca.crt
>
>   }
>
>
> [domain_realm]
>   .xyz.com = IPA.xyz.COM
>   xyz.com = IPA.xyz.COM
>
> Discovery appears to be working as expected:
>
> 2018-01-17T02:11:41Z DEBUG Search DNS for TXT record of _kerberos.xyz.com
> 2018-01-17T02:11:41Z DEBUG DNS record found: "IPA.xyz.COM"
> 2018-01-17T02:11:41Z DEBUG Search DNS for SRV record of
> _kerberos._udp.xyz.com
> 2018-01-17T02:11:41Z DEBUG DNS 

[Freeipa-users] Re: freeipa-client joins keep failing : Cannot find KDC for realm

2018-01-17 Thread Rob Crittenden via FreeIPA-users
Chris Moody wrote:
> Thanks for taking a look gents.  Ask and ye shall receive.  :)
> 

What version of IPA is this and what platform?

Before an install can you ensure that there is nothing in
/etc/krb5.conf.d/ (except may be crypto-policies)?

Same with /var/lib/sss/pubconf/krb5.include.d/

Might also be interesting to try to force a specific master by adding
--server  to the install line, just to see.

I'm guessing the client is old as it doesn't appear to support the
newer-style ipa-getkeytab:

2018-01-17T02:11:50Z DEBUG args=/usr/sbin/ipa-join -s
sfca-do-4.ipa.xyz.com -b dc=ipa,dc=xyz,dc=com -h sfca-do-1.xyz.com
2018-01-17T02:11:51Z DEBUG Process finished, return code=0
2018-01-17T02:11:51Z DEBUG stdout=
2018-01-17T02:11:51Z DEBUG stderr=Failed to parse result: Failed to
decode GetKeytab Control.

Retrying with pre-4.0 keytab retrieval method...
Keytab successfully retrieved and stored in: /etc/krb5.keytab
Certificate subject base is: O=IPA.xyz.COM

2018-01-17T02:11:51Z INFO Enrolled in IPA realm IPA.xyz.COM

It does look like it enrolls ok and gets a keytab.

Note too that just about this it is able to get a TGT for the admin user
via kinit:

2018-01-17T02:11:50Z DEBUG args=/usr/bin/kinit ad...@ipa.xyz.com -c
/tmp/krbccCNSUmS/ccache

The only difference between Kerberos usage between the enrollment and
the rest is that during enrollment a fixed KDC is defined in the
temporary krb5.conf:

includedir /var/lib/sss/pubconf/krb5.include.d/

[libdefaults]
  default_realm = IPA.xyz.COM
  dns_lookup_realm = false
  dns_lookup_kdc = false
  rdns = false
  ticket_lifetime = 24h
  forwardable = true
  udp_preference_limit = 0
  default_ccache_name = KEYRING:persistent:%{uid}


[realms]
  IPA.xyz.COM = {
kdc = sfca-do-4.ipa.xyz.com:88
master_kdc = sfca-do-4.ipa.xyz.com:88
admin_server = sfca-do-4.ipa.xyz.com:749
default_domain = xyz.com
pkinit_anchors = FILE:/etc/ipa/ca.crt

  }

[domain_realm]
  .xyz.com = IPA.xyz.COM
  xyz.com = IPA.xyz.COM


It is failing trying to autodiscover things later:

includedir /var/lib/sss/pubconf/krb5.include.d/

[libdefaults]
  default_realm = IPA.xyz.COM
  dns_lookup_realm = true
  dns_lookup_kdc = true
  rdns = false
  ticket_lifetime = 24h
  forwardable = true
  udp_preference_limit = 0
  default_ccache_name = KEYRING:persistent:%{uid}


[realms]
  IPA.xyz.COM = {
pkinit_anchors = FILE:/etc/ipa/ca.crt

  }


[domain_realm]
  .xyz.com = IPA.xyz.COM
  xyz.com = IPA.xyz.COM

Discovery appears to be working as expected:

2018-01-17T02:11:41Z DEBUG Search DNS for TXT record of _kerberos.xyz.com
2018-01-17T02:11:41Z DEBUG DNS record found: "IPA.xyz.COM"
2018-01-17T02:11:41Z DEBUG Search DNS for SRV record of
_kerberos._udp.xyz.com
2018-01-17T02:11:41Z DEBUG DNS record found: 10 100 88
sfca-do-4.ipa.xyz.com.

So I'm not entirely sure what is happening.

rob
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


[Freeipa-users] Re: freeipa-client joins keep failing : Cannot find KDC for realm

2018-01-17 Thread Chris Moody via FreeIPA-users
Affirmative, it is all caps in the logs.

I can re-send the log with the redactions case sensitive if that's
helpful.  My apologies for causing confusion via my obfuscation.

-Chris


On 1/17/18 12:36 PM, Robbie Harwood wrote:
> Chris Moody  writes:
>
>> On 1/17/18 8:27 AM, Robbie Harwood wrote:
>>> Chris Moody  writes:
>>>
 Thanks for taking a look gents.  Ask and ye shall receive.  :)

 -Chris

 ===[ CLI output ]==
 root@sfca-do-1:~# ipa-client-install -p admin --mkhomedir
 --hostname=`hostname`
 Discovery was successful!
 Client hostname: sfca-do-1.xyz.com
 Realm: IPA.xyz.COM
>>> Are you redacting this?  Because that "xyz" shouldn't be lowercased.
>>> Realm names are all-caps (because some implementations are
>>> case-sensitive and others are not).
>> Yes - I am redacting just the 2nd level domain name portion from any logs.
> Can you confirm that it's all-caps in the actual logs?
>
> Thanks,
> --Robbie



smime.p7s
Description: S/MIME Cryptographic Signature
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


[Freeipa-users] Re: freeipa-client joins keep failing : Cannot find KDC for realm

2018-01-17 Thread Robbie Harwood via FreeIPA-users
Chris Moody  writes:

> On 1/17/18 8:27 AM, Robbie Harwood wrote:
>> Chris Moody  writes:
>>
>>> Thanks for taking a look gents.  Ask and ye shall receive.  :)
>>>
>>> -Chris
>>>
>>> ===[ CLI output ]==
>>> root@sfca-do-1:~# ipa-client-install -p admin --mkhomedir
>>> --hostname=`hostname`
>>> Discovery was successful!
>>> Client hostname: sfca-do-1.xyz.com
>>> Realm: IPA.xyz.COM
>>
>> Are you redacting this?  Because that "xyz" shouldn't be lowercased.
>> Realm names are all-caps (because some implementations are
>> case-sensitive and others are not).
>
> Yes - I am redacting just the 2nd level domain name portion from any logs.

Can you confirm that it's all-caps in the actual logs?

Thanks,
--Robbie


signature.asc
Description: PGP signature
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


[Freeipa-users] Re: freeipa-client joins keep failing : Cannot find KDC for realm

2018-01-17 Thread Chris Moody via FreeIPA-users
Yes - I am redacting just the 2nd level domain name portion from any logs.

-Chris


On 1/17/18 8:27 AM, Robbie Harwood wrote:
> Chris Moody  writes:
>
>> Thanks for taking a look gents.  Ask and ye shall receive.  :)
>>
>> -Chris
>>
>> ===[ CLI output ]==
>> root@sfca-do-1:~# ipa-client-install -p admin --mkhomedir
>> --hostname=`hostname`
>> Discovery was successful!
>> Client hostname: sfca-do-1.xyz.com
>> Realm: IPA.xyz.COM
> Are you redacting this?  Because that "xyz" shouldn't be lowercased.
> Realm names are all-caps (because some implementations are
> case-sensitive and others are not).
>
> Thanks,
> --Robbie



smime.p7s
Description: S/MIME Cryptographic Signature
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


[Freeipa-users] Re: freeipa-client joins keep failing : Cannot find KDC for realm

2018-01-17 Thread Robbie Harwood via FreeIPA-users
Chris Moody  writes:

> Thanks for taking a look gents.  Ask and ye shall receive.  :)
>
> -Chris
>
> ===[ CLI output ]==
> root@sfca-do-1:~# ipa-client-install -p admin --mkhomedir
> --hostname=`hostname`
> Discovery was successful!
> Client hostname: sfca-do-1.xyz.com
> Realm: IPA.xyz.COM

Are you redacting this?  Because that "xyz" shouldn't be lowercased.
Realm names are all-caps (because some implementations are
case-sensitive and others are not).

Thanks,
--Robbie


signature.asc
Description: PGP signature
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


[Freeipa-users] Re: freeipa-client joins keep failing : Cannot find KDC for realm

2018-01-16 Thread Chris Moody via FreeIPA-users
My reply with the log output is pending moderator approval.

-Chris


On 1/16/18 1:11 PM, Rob Crittenden wrote:
> Robbie Harwood via FreeIPA-users wrote:
>> Chris Moody via FreeIPA-users 
>> writes:
>>
>>> 2018-01-15T21:55:24Z INFO Configured /etc/krb5.conf for IPA realm
>>> IPA.XYZ.COM
>>> 2018-01-15T21:55:24Z DEBUG Starting external process
>>> 2018-01-15T21:55:24Z DEBUG args=keyctl search @s user
>>> ipa_session_cookie:host/sfca-do-1.xyz@ipa.xyz.com
>>> 2018-01-15T21:55:24Z DEBUG Process finished, return code=1
>>> 2018-01-15T21:55:24Z DEBUG stdout=
>>> 2018-01-15T21:55:24Z DEBUG stderr=keyctl_search: Required key not available
>> I'm not familiar with what IPA's trying to do here, but this looks like
>> a problem?  Can someone else comment?
> This is perfectly normal. IPA stores the session cookie in the kernel
> keyring. Given this is a new install there is no cookie to find.
>
>>> I have tried manually setting /etc/krb5.conf to the contents that get>
>>> generated & display during the verbose client-install process (as seen
>>> above), that manually spell out the KDC details, and am able to run a
>>> 'kinit admin' just fine from the CLI on the client, so kerberos DOES
>>> function from the client.  It talks to the KDC beautifully and
>>> authenticates just fine... so I'm not sure how the client-install
>>> process is getting confused/lost when trying to find/contact the KDC.
>> Someone else who knows more than me: how is the install different than a
>> normal kinit?
> I think we'd need to see the full ipaclient-install.log.
>
> rob



smime.p7s
Description: S/MIME Cryptographic Signature
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


[Freeipa-users] Re: freeipa-client joins keep failing : Cannot find KDC for realm

2018-01-16 Thread Rob Crittenden via FreeIPA-users
Robbie Harwood via FreeIPA-users wrote:
> Chris Moody via FreeIPA-users 
> writes:
> 
>> 2018-01-15T21:55:24Z INFO Configured /etc/krb5.conf for IPA realm
>> IPA.XYZ.COM
>> 2018-01-15T21:55:24Z DEBUG Starting external process
>> 2018-01-15T21:55:24Z DEBUG args=keyctl search @s user
>> ipa_session_cookie:host/sfca-do-1.xyz@ipa.xyz.com
>> 2018-01-15T21:55:24Z DEBUG Process finished, return code=1
>> 2018-01-15T21:55:24Z DEBUG stdout=
>> 2018-01-15T21:55:24Z DEBUG stderr=keyctl_search: Required key not available
> 
> I'm not familiar with what IPA's trying to do here, but this looks like
> a problem?  Can someone else comment?

This is perfectly normal. IPA stores the session cookie in the kernel
keyring. Given this is a new install there is no cookie to find.

>> I have tried manually setting /etc/krb5.conf to the contents that get>
>> generated & display during the verbose client-install process (as seen
>> above), that manually spell out the KDC details, and am able to run a
>> 'kinit admin' just fine from the CLI on the client, so kerberos DOES
>> function from the client.  It talks to the KDC beautifully and
>> authenticates just fine... so I'm not sure how the client-install
>> process is getting confused/lost when trying to find/contact the KDC.
> 
> Someone else who knows more than me: how is the install different than a
> normal kinit?

I think we'd need to see the full ipaclient-install.log.

rob
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


[Freeipa-users] Re: freeipa-client joins keep failing : Cannot find KDC for realm

2018-01-16 Thread Alexander Bokovoy via FreeIPA-users

On ti, 16 tammi 2018, Robbie Harwood via FreeIPA-users wrote:

Chris Moody via FreeIPA-users 
writes:


2018-01-15T21:55:24Z INFO Configured /etc/krb5.conf for IPA realm
IPA.XYZ.COM
2018-01-15T21:55:24Z DEBUG Starting external process
2018-01-15T21:55:24Z DEBUG args=keyctl search @s user
ipa_session_cookie:host/sfca-do-1.xyz@ipa.xyz.com
2018-01-15T21:55:24Z DEBUG Process finished, return code=1
2018-01-15T21:55:24Z DEBUG stdout=
2018-01-15T21:55:24Z DEBUG stderr=keyctl_search: Required key not available


I'm not familiar with what IPA's trying to do here, but this looks like
a problem?  Can someone else comment?

No, this is not a problem. We check if a session cookie, stored in a
Kerberos ccache, is available. If not, we don't have a cached cookie, no
big deal, we have to run authentication flow.


I have tried manually setting /etc/krb5.conf to the contents that get>
generated & display during the verbose client-install process (as seen
above), that manually spell out the KDC details, and am able to run a
'kinit admin' just fine from the CLI on the client, so kerberos DOES
function from the client.  It talks to the KDC beautifully and
authenticates just fine... so I'm not sure how the client-install
process is getting confused/lost when trying to find/contact the KDC.


Someone else who knows more than me: how is the install different than a
normal kinit?

Install generates own krb5.conf in /tmp and uses that one to perform a
discovery. Then it configures /etc/krb5.conf according to what was
discovered and how ipa-client-install was called.

It may be that discovery process doesn't work well because DNS lacks SRV
or TXT records, for example. In this case re-running ipa-client-install
with explicit realm/domain info might help. There are more
considerations in ipa-client-install manual page.

--
/ Alexander Bokovoy
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


[Freeipa-users] Re: freeipa-client joins keep failing : Cannot find KDC for realm

2018-01-16 Thread Robbie Harwood via FreeIPA-users
Chris Moody via FreeIPA-users 
writes:

> 2018-01-15T21:55:24Z INFO Configured /etc/krb5.conf for IPA realm
> IPA.XYZ.COM
> 2018-01-15T21:55:24Z DEBUG Starting external process
> 2018-01-15T21:55:24Z DEBUG args=keyctl search @s user
> ipa_session_cookie:host/sfca-do-1.xyz@ipa.xyz.com
> 2018-01-15T21:55:24Z DEBUG Process finished, return code=1
> 2018-01-15T21:55:24Z DEBUG stdout=
> 2018-01-15T21:55:24Z DEBUG stderr=keyctl_search: Required key not available

I'm not familiar with what IPA's trying to do here, but this looks like
a problem?  Can someone else comment?

> I have tried manually setting /etc/krb5.conf to the contents that get>
> generated & display during the verbose client-install process (as seen
> above), that manually spell out the KDC details, and am able to run a
> 'kinit admin' just fine from the CLI on the client, so kerberos DOES
> function from the client.  It talks to the KDC beautifully and
> authenticates just fine... so I'm not sure how the client-install
> process is getting confused/lost when trying to find/contact the KDC.

Someone else who knows more than me: how is the install different than a
normal kinit?

Thanks,
--Robbie


signature.asc
Description: PGP signature
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org