I think it
will work. You can keep
DNS domain is:
- owned by your organization
- has appropriate SRV records for LDAP and Kerberos of
when enrolling IPA clients -- regardless where
they will be located, --domain <domain> is pointing to the primary IPA
domain. See man page for ipa-client-install for discovery details.
If you want
This is even more interesting as I would love to setup this for
private
use, but really don't want to get another domain for "just" this.
Domains are cheap, especially subdomains of your own existing ones. ;)
Thanks :)
-Chris.
On 17/06/2019 15:36, John Keates via FreeIPA-users wrote:
> Ah, that was good to know, you’re converting a plain LDAP + Kerberos
> setup to IPA with integrated LDAP, integrated Kerberos and integrated DNS.
> What’s important to know is that you cannot really cleanly convert that
> as the Kerberos tabs will have to be updated. With such a change,
> updating the kerberos config files is an easy next step.
>
> Regarding DNS, NAT, KDCProxy, that’s most for if you wanted to do
> kerberos over the internet. Normally, you wouldn’t give an IPA server a
> public IP, so you’d NAT anyway. Natting an additional IP is a small pain
> to add ;-)
> KDCProxy is meant as a kerberos-over-the-web solution where you can use
> kerberos in a somewhat safer way. Regarding the KDC realm: most people
> don’t really care what their ticket principals look like ;-)
>
> If you have existing DNS, and you must re-use it for some reason, that
> is a more problematic scenario. In those cases it’s easier to just use a
> CNAME of additional A record on your existing DNS and point them to the
> new DNS.
> Say your current setup is:
>
>
ldap.company.com <
http://ldap.company.com> for LDAP
>
kerberos.company.com <
http://kerberos.company.com> for Kerberos
>
> You could setup IPA with:
>
>
auth.company.com <
http://auth.company.com> for everything (LDAP, web,
> KDC, KDC Proxy)
>
> And then add a CNAME for
ldap.company.com <
http://ldap.company.com> to
>
auth.company.com <
http://auth.company.com> for LDAP and a CNAME for
>
kerberos.company.com <
http://kerberos.company.com> to auth.company.com
> <
http://auth.company.com> for Kerberos.
> That way, the client-side config wouldn’t have to change domain names.
> The Kerberos realm would have to change so that’s a configuration you
> have to update anyway, no getting past that.
> Configuring hosts for IPA uses the ipa-client-install script anyway, and
> that script would configure everything automatically anyway, so you
> don’t actually have to mess with the domains anyway.
> The domains and manual naming of things is only relevant if you have to
> manually configure everything.
>
> John
>
>
>> On 17 Jun 2019, at 14:59, Christian Reiss via FreeIPA-users
>> <freeipa-users(a)lists.fedorahosted.org
>> <mailto:freeipa-users@lists.fedorahosted.org>> wrote:
>>
>> Hey John,
>>
>> Awesome response :)
>> But I am not setting any dns records by hand. I did it *prior* to
>> FreeIPA. We are using naked Kerberos and ldap as-is. So thats where the
>> DNS RR are coming from.
>>
>> Does "Dont run IPA on a domain thats in use" mean "entire
domain" or
>> "Subdomain is OK"?
>>
>> kdcproxy.. nat.. does not really sound awesome to be honest.
>> Would a setup on
auth.company.com <
http://auth.company.com> (realm,
>> domain, etc) have and
>> disadvantages? I could simply add dns srv records from
company.com
>> <
http://company.com> to
>>
auth.company.com <
http://auth.company.com>?
>>
>> And it's okay I guess if the host keytabs look like
>>
>> host/server.company.com(a)AUTH.COMPANY.COM
>> <mailto:host/server.company.com@AUTH.COMPANY.COM>
>>
>> I am slowly getting there :)
>>
>> -Chris.
>>
>> On 17/06/2019 14:06, John Keates via FreeIPA-users wrote:
>>> In that case, you’re doing it wrong ;-)
>>>
>>> Don’t manually make DNS records, it’s not needed unless you disable the
>>> built in DNS server in IPA. Also, don’t try to run IPA on a domain
>>> that’s in use for something else. Keeping it simple and ’standard’ will
>>> help you a ton here.
>>> For example, if you setup your server like this, all should would
>>> out-of-the-box:
>>>
>>> ipa-server-install —domain=auth.company.com <
http://auth.company.com>
>>> <
http://auth.company.com>
>>> —realm=AUTH.COMPANY.COM <
http://AUTH.COMPANY.COM>
>>> <
http://AUTH.COMPANY.COM> --setup-dns
>>>
>>> (Note: I’d use
ds.company.com <
http://ds.company.com>
>>> <
http://ds.company.com> because auth
>>> suggests it’s just an authentication server, but IPA is a lot more than
>>> dat; then again ds for directory service isn’t a complete picture
>>> either, you’d probably end up with
ipa.company.com
>>> <
http://ipa.company.com>
>>> <
http://ipa.company.com> if you wanted to do it ‘right’)
>>>
>>> For public use, I’d suggest using kdcproxy which is designed for public
>>> exposure. It’s supported in IPA.
>>>
>>> If you wanted to use separate domain names for TCP/IP communication,
>>> that is not connected to what you set in IPA. So if you have IPA setup,
>>> you can always make an extra DNS record called
kerberos.company.com
>>> <
http://kerberos.company.com>
>>> <
http://kerberos.company.com>, point it to an IP, hand then internally
>>> NAT that IP to any IPA server(s) you want.
>>>
>>> John
>>>
>>>> On 17 Jun 2019, at 13:58, Christian Reiss via FreeIPA-users
>>>> <freeipa-users(a)lists.fedorahosted.org
>>>> <mailto:freeipa-users@lists.fedorahosted.org>
>>>> <mailto:freeipa-users@lists.fedorahosted.org>> wrote:
>>>>
>>>> Hey John,
>>>>
>>>> thanks again for a detailed information. I do understand this, but maybe
>>>> I am overthinking it. The current setup (non IPA) is:
>>>>
>>>>
company.com <
http://company.com> <
http://company.com> Domain
name,
>>>> Using kerberos on
kerberos.company.com
<
http://kerberos.company.com>
>>>> <
http://kerberos.company.com>.
>>>> SRV & TXT Records all point to
kerberos.company.com
>>>> <
http://kerberos.company.com>
>>>> <
http://kerberos.company.com>.
>>>>
>>>> All user prinicipals are user(a)COMPANY.COM
<mailto:user@COMPANY.COM>
>>>> <mailto:user@COMPANY.COM>,
>>>> all kerberized
>>>> services/keytabs have a principal of
>>>> host/vm4.company.com(a)COMPANY.COM
>>>> <mailto:host/vm4.company.com@COMPANY.COM>
>>>> <mailto:host/vm4.company.com@COMPANY.COM>
>>>>
>>>> What we are aiming for is: A User requests a TGT via
>>>>
>>>> kinit john(a)COMPANY.COM <mailto:john@COMPANY.COM>
>>>> <mailto:john@COMPANY.COM> (ignoring default
>>>> realms for a bit) and it would
>>>> receive a TGT from either IPA server issues to
>>>>
>>>> john(a)COMPANY.COM <mailto:john@COMPANY.COM>
<mailto:john@COMPANY.COM>
>>>>
>>>> Servers are in the form
>>>>
>>>> host/server.company.com(a)COMPANY.COM
>>>> <mailto:host/server.company.com@COMPANY.COM>
>>>> <mailto:host/server.company.com@COMPANY.COM>
>>>>
>>>> Also, things that use ldap want dc=company,dc=com.
>>>> We will not be using any Windows / AD things. Only UNIX/Linux.
>>>> The Services are used in house as well as from around the world
>>>> (public).
>>>>
>>>> Thanks so much.
>>>> -Christian.
>>>>
>>>>
>>>> On 17/06/2019 13:44, John Keates via FreeIPA-users wrote:
>>>>> What you are trying to do is possible but not recommended. If you
>>>>> make a
>>>>> distinction between what you want your users to ’see’ and what your
>>>>> domain technically should be you can probably resolve it.
>>>>> For IPA, it’s important that the domain for the built in DNS server
is
>>>>> not used. That means: do not use a domain that is in use. Not for
your
>>>>> IPA domain and not for the kerberos realm.
>>>>>
>>>>> So, say you have
company.com <
http://company.com>
<
http://company.com>
>>>>> <
http://company.com> and that is in use and
>>>>> you want to setup IPA. Since it’s in use, you’ll have to start on
level
>>>>> down on a subdomain.
>>>>> That means (per your choice AFAIK) that you have to set it all to
>>>>>
auth.company.com <
http://auth.company.com>
>>>>> <
http://auth.company.com> <
http://auth.company.com>,
>>>>> both the IPA domain and the
>>>>> kerberos realm. The main zone,
company.com
<
http://company.com>
>>>>> <
http://company.com>
>>>>> <
http://company.com> doesn’t
>>>>> actually come into play here.
>>>>>
>>>>> Afterwards, if you want to, you could make NS delegations to your
IPA
>>>>> server(s) from your main zone.
>>>>>
>>>>> If you can’t make this work out, or if DNS is managed by multiple
>>>>> teams/people, it might be much easier to simply register a second
>>>>> domain
>>>>> just for IPA, remove all of its public zones and just use it inside
>>>>> IPA.
>>>>> So if you have
company.com <
http://company.com>
<
http://company.com>
>>>>> <
http://company.com> you could use something
>>>>> like
company.net <
http://company.net>
<
http://company.net>
>>>>> <
http://company.net> if that’s
>>>>> available. Could be
>>>>> confusing for users, so maybe
companyauth.com
>>>>> <
http://companyauth.com> <
http://companyauth.com>
>>>>> <
http://companyauth.com> or company-internal.com
>>>>> <
http://company-internal.com>
>>>>> <
http://company-internal.com>
>>>>> <
http://company-internal.com>.
>>>>>
>>>>> The “domain” part in the server setup doesn’t mean anything
regarding
>>>>> what your users would type to access your web stuff, that can be
>>>>> proxied
>>>>> and renamed as much as you like to anything else.
>>>>>
>>>>> Something else: what is your goal? Is this IPA setup for internal
use,
>>>>> public use, end-users, admin-users, workstations, servers, web
>>>>> applications?
>>>>>
>>>>> John
>>>>>
>>>>>> On 17 Jun 2019, at 11:49, Christian Reiss via FreeIPA-users
>>>>>> <freeipa-users(a)lists.fedorahosted.org
>>>>>> <mailto:freeipa-users@lists.fedorahosted.org>
>>>>>> <mailto:freeipa-users@lists.fedorahosted.org>
>>>>>> <mailto:freeipa-users@lists.fedorahosted.org>> wrote:
>>>>>>
>>>>>> Hey John,
>>>>>>
>>>>>> Thanks for a speedy reply! Sure helped a lot understanding, tho a
pity
>>>>>> that some clients simply require a "a/cname" and do not
look up
>>>>>> any srv,
>>>>>> like pfsense. And your reverse proxy idea is neat.
>>>>>>
>>>>>>
>>>>>> Just one issue, either technical or lack of understanding:
>>>>>>
>>>>>> So I went ahead for the domain
company.com
<
http://company.com>
>>>>>> <
http://company.com>
>>>>>> <
http://company.com>
>>>>>> (exmaple, using real IPs out
>>>>>> there):
>>>>>>
>>>>>>
auth.company.com <
http://auth.company.com>
>>>>>> <
http://auth.company.com> <
http://auth.company.com>
>>>>>> IN NS 10.0.0.1
>>>>>>
>>>>>> and created
>>>>>>
>>>>>>
srv1.auth.company.com <
http://srv1.auth.company.com>
>>>>>> <
http://srv1.auth.company.com>
>>>>>> <
http://srv1.auth.company.com> (10.0.0.1)
>>>>>>
srv2.auth.company.com <
http://srv2.auth.company.com>
>>>>>> <
http://srv2.auth.company.com>
>>>>>> <
http://srv2.auth.company.com> (10.0.0.2)
>>>>>>
>>>>>> During setup of srv1 I set:
>>>>>>
>>>>>> The IPA Master Server will be configured with:
>>>>>> Hostname: srv1.auth.company.com
>>>>>> <
http://srv1.auth.company.com>
<
http://srv1.auth.company.com>
>>>>>> <
http://srv1.auth.company.com>
>>>>>> IP address(es): 10.0.0.1
>>>>>> Domain name: auth.company.com <
http://auth.company.com>
>>>>>> <
http://auth.company.com>
>>>>>> <
http://auth.company.com>
>>>>>> Realm name: COMPANY.COOM
>>>>>>
>>>>>> BIND DNS server will be configured to serve IPA domain with:
>>>>>> Forwarders: 10.0.0.1
>>>>>> Forward policy: first
>>>>>> Reverse zone(s): 0.0.10.in-addr.arpa.
>>>>>>
>>>>>> WARNING: Realm name does not match the domain name.
>>>>>> You will not be able to establish trusts with Active Directory
unless
>>>>>> the realm name of the IPA server matches its domain name.
>>>>>>
>>>>>> So:
>>>>>> Server:
srv1.auth.company.com
<
http://srv1.auth.company.com>
>>>>>> <
http://srv1.auth.company.com>
>>>>>> <
http://srv1.auth.company.com>
>>>>>> Domain:
auth.company.com <
http://auth.company.com>
>>>>>> <
http://auth.company.com>
>>>>>> <
http://auth.company.com>
>>>>>> K5 :
COMPANY.COM <
http://COMPANY.COM>
<
http://COMPANY.COM>
>>>>>> <
http://COMPANY.COM>
>>>>>>
>>>>>> Replica adoption failed because
auth.company.com
>>>>>> <
http://auth.company.com>
>>>>>> <
http://auth.company.com>
>>>>>> <
http://auth.company.com> is not
company.com
<
http://company.com>
>>>>>> <
http://company.com>
>>>>>> <
http://company.com>.
>>>>>>
>>>>>>
>>>>>> 2nd try, this time:
>>>>>>
>>>>>> Server:
srv1.auth.company.com
<
http://srv1.auth.company.com>
>>>>>> <
http://srv1.auth.company.com>
>>>>>> <
http://srv1.auth.company.com>
>>>>>> Domain:
company.com <
http://company.com>
<
http://company.com>
>>>>>> <
http://company.com>
>>>>>> K5 :
COMPANY.COM <
http://COMPANY.COM>
<
http://COMPANY.COM>
>>>>>> <
http://COMPANY.COM>
>>>>>>
>>>>>> Primary failed: ERROR DNS zone
COMPANY.COM
<
http://COMPANY.COM>
>>>>>> <
http://COMPANY.COM>
>>>>>> <
http://COMPANY.COM>.
>>>>>> already exists in DNS and
>>>>>> is handled by server(s):
ns1.ns-serve.net
>>>>>> <
http://ns1.ns-serve.net> <
http://ns1.ns-serve.net>
>>>>>> <
http://ns1.ns-serve.net>.,
>>>>>>
ns2.ns-serve.net <
http://ns2.ns-serve.net>
>>>>>> <
http://ns2.ns-serve.net> <
http://ns2.ns-serve.net>.
>>>>>>
>>>>>> What would be the right approach here?
>>>>>>
>>>>>> Thanks again!
>>>>>> -Chris.
>>>>>>
>>>>>>
>>>>>> On 17/06/2019 10:10, John Keates via FreeIPA-users wrote:
>>>>>>> A HA-aware client would use SRV records to locate the
server(s) and
>>>>>>> then connect every returned instance until a working server
is found.
>>>>>>> And by using locations you can scope the servers you get
back.
>>>>>>>
>>>>>>> Regarding the single URL: while there are many options, we
decided to
>>>>>>> simply register all servers in a load balancer and when you
access
>>>>>>> the URL provided by the loadbalancer you simply get
redirected to any
>>>>>>> working server.
>>>>>>> Some people prefer no URL redirects and try to solve it using
stick
>>>>>>> tables and the likes, but to us that seems like a dirty
solution so
>>>>>>> we ditched it after a PoC phase. It works but we don’t want
it ;-)
>>>>>>>
>>>>>>> If you have a special use case, a separate web app that talks
to IPA
>>>>>>> can be better, that is what we did for non-tech accounts; a
simple
>>>>>>> self-service app that allows you to change your own password
and
>>>>>>> manage MFA.
>>>>>>> For everything else (i.e. SSO, SAML etc.) we often use
something else
>>>>>>> that talks to IPA, like Keycloak, because the IPA WebUI
itself is
>>>>>>> really not going to give a user any useful functionality;
it’s more
>>>>>>> of an operator and admin thing.
>>>>>>>
>>>>>>> John
>>>>>>>
>>>>>>>> On 17 Jun 2019, at 10:02, Christian Reiss via
FreeIPA-users
>>>>>>>> <freeipa-users(a)lists.fedorahosted.org
>>>>>>>> <mailto:freeipa-users@lists.fedorahosted.org>
>>>>>>>> <mailto:freeipa-users@lists.fedorahosted.org>
>>>>>>>> <mailto:freeipa-users@lists.fedorahosted.org>>
wrote:
>>>>>>>>
>>>>>>>> Hey folks,
>>>>>>>>
>>>>>>>> I just recently began planning the deployment of FreeIPA
and have
>>>>>>>> successfully made several test setups. Next step would
be to
>>>>>>>> integrate
>>>>>>>> this in our new datacenter; so we are starting there from
scratch.
>>>>>>>>
>>>>>>>> I understand HA on the server side. What boogles my head
is HA
>>>>>>>> on the
>>>>>>>> *client* side.
>>>>>>>>
>>>>>>>> For example: Our pfsenses use a LDAP lookup against a
single
>>>>>>>> FQDN, and
>>>>>>>> the cert must be valid (against any provided CA).
Exporting the CA
>>>>>>>> from
>>>>>>>> freeIPA and importing that in pfsense is a cake.
>>>>>>>>
>>>>>>>> But what do I point the clients towards? Let's say I
have 4 FreeIPA
>>>>>>>> servers:
>>>>>>>>
>>>>>>>> -
ipa01.auth.dc-01.company.com
<
http://ipa01.auth.dc-01.company.com>
>>>>>>>> <
http://ipa01.auth.dc-01.company.com>
>>>>>>>> <
http://ipa01.auth.dc-01.company.com>
>>>>>>>> -
ipa02.auth.dc-01.company.com
<
http://ipa02.auth.dc-01.company.com>
>>>>>>>> <
http://ipa02.auth.dc-01.company.com>
>>>>>>>> <
http://ipa02.auth.dc-01.company.com>
>>>>>>>> -
ipa03.auth.dc-01.company.com
<
http://ipa03.auth.dc-01.company.com>
>>>>>>>> <
http://ipa03.auth.dc-01.company.com>
>>>>>>>> <
http://ipa03.auth.dc-01.company.com>
>>>>>>>> -
ipa04.auth.dc-01.company.com
<
http://ipa04.auth.dc-01.company.com>
>>>>>>>> <
http://ipa04.auth.dc-01.company.com>
>>>>>>>> <
http://ipa04.auth.dc-01.company.com>
>>>>>>>>
>>>>>>>> Realm
company.com <
http://company.com>
<
http://company.com>
>>>>>>>> <
http://company.com>,
>>>>>>>> Kerberos
COMPANY.COM <
http://COMPANY.COM>
<
http://COMPANY.COM>
>>>>>>>> <
http://COMPANY.COM>. If I point the pfsense
(I'll
>>>>>>>> stick to that as an example) against
>>>>>>>>
ipa01.auth.dc-01.company.com
<
http://ipa01.auth.dc-01.company.com>
>>>>>>>> <
http://ipa01.auth.dc-01.company.com>
>>>>>>>> <
http://ipa01.auth.dc-01.company.com> and
>>>>>>>> this server is offline, then no HA is given. DNS
Delegation might
>>>>>>>> yield
>>>>>>>> *any* of the four servers, including the one offline, so
a 25% fault
>>>>>>>> chance in there.
>>>>>>>>
>>>>>>>> Second question, same area: If I want my users to have
one
>>>>>>>> single url
>>>>>>>> for the FreeIPA webservice, like
auth.company.com
>>>>>>>> <
http://auth.company.com>
>>>>>>>> <
http://auth.company.com>
>>>>>>>> <
http://auth.company.com> that follows the above
>>>>>>>> solution then the self-signed and generated certs do not
have
>>>>>>>> this as
>>>>>>>> altname.
>>>>>>>>
>>>>>>>>
>>>>>>>> So summed up:
>>>>>>>>
>>>>>>>> - How can I make (ldap) clients access the current online
server(s)?
>>>>>>>> - How can I provide access to the webinterace to the
current online
>>>>>>>> server(s)?
>>>>>>>>
>>>>>>>>
>>>>>>>> (Or is this simply by the magic of dns zone delegation
and pure
>>>>>>>> faith
>>>>>>>> that always an online server will be hit?)
>>>>>>>>
>>>>>>>> Thanks for any advice!
>>>>>>>> -Christian.
>>>>>>>>
>>>>>>>> --
>>>>>>>> Christian Reiss - email(a)christian-reiss.de
>>>>>>>> <mailto:email@christian-reiss.de>
>>>>>>>> <mailto:email@christian-reiss.de>
>>>>>>>> <mailto:email@christian-reiss.de> /"\
ASCII Ribbon
>>>>>>>> support(a)alpha-labs.net
>>>>>>>> <mailto:support@alpha-labs.net>
>>>>>>>> <mailto:support@alpha-labs.net>
>>>>>>>> <mailto:support@alpha-labs.net> \ /
Campaign
>>>>>>>> X
against HTML
>>>>>>>> WEB
alpha-labs.net <
http://alpha-labs.net>
>>>>>>>> <
http://alpha-labs.net>
<
http://alpha-labs.net>
>>>>>>>> / \ in eMails
>>>>>>>>
>>>>>>>> GPG Retrieval
https://gpg.christian-reiss.de
>>>>>>>> GPG ID ABCD43C5, 0x44E29126ABCD43C5
>>>>>>>> GPG fingerprint = 9549 F537 2596 86BA 733C A4ED 44E2
9126 ABCD 43C5
>>>>>>>>
>>>>>>>> "It's better to reign in hell than to serve in
heaven.",
>>>>>>>> John Milton,
Paradise lost.
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> FreeIPA-users mailing list --
>>>>>>>> freeipa-users(a)lists.fedorahosted.org
>>>>>>>> <mailto:freeipa-users@lists.fedorahosted.org>
>>>>>>>> <mailto:freeipa-users@lists.fedorahosted.org>
>>>>>>>> <mailto:freeipa-users@lists.fedorahosted.org>
>>>>>>>> To unsubscribe send an email to
>>>>>>>> freeipa-users-leave(a)lists.fedorahosted.org
>>>>>>>>
<mailto:freeipa-users-leave@lists.fedorahosted.org>
>>>>>>>>
<mailto:freeipa-users-leave@lists.fedorahosted.org>
>>>>>>>>
<mailto:freeipa-users-leave@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.fedoraho...
>>>>>>> _______________________________________________
>>>>>>> FreeIPA-users mailing list --
>>>>>>> freeipa-users(a)lists.fedorahosted.org
>>>>>>> <mailto:freeipa-users@lists.fedorahosted.org>
>>>>>>> <mailto:freeipa-users@lists.fedorahosted.org>
>>>>>>> <mailto:freeipa-users@lists.fedorahosted.org>
>>>>>>> To unsubscribe send an email to
>>>>>>> freeipa-users-leave(a)lists.fedorahosted.org
>>>>>>> <mailto:freeipa-users-leave@lists.fedorahosted.org>
>>>>>>> <mailto:freeipa-users-leave@lists.fedorahosted.org>
>>>>>>> <mailto:freeipa-users-leave@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.fedoraho...
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Christian Reiss - email(a)christian-reiss.de
>>>>>> <mailto:email@christian-reiss.de>
>>>>>> <mailto:email@christian-reiss.de>
>>>>>> <mailto:email@christian-reiss.de> /"\ ASCII
Ribbon
>>>>>> support(a)alpha-labs.net
>>>>>> <mailto:support@alpha-labs.net>
<mailto:support@alpha-labs.net>
>>>>>> <mailto:support@alpha-labs.net> \ / Campaign
>>>>>> X against
HTML
>>>>>> WEB
alpha-labs.net <
http://alpha-labs.net>
<
http://alpha-labs.net>
>>>>>> <
http://alpha-labs.net>
>>>>>> / \ in eMails
>>>>>>
>>>>>> GPG Retrieval
https://gpg.christian-reiss.de
>>>>>> GPG ID ABCD43C5, 0x44E29126ABCD43C5
>>>>>> GPG fingerprint = 9549 F537 2596 86BA 733C A4ED 44E2 9126 ABCD
43C5
>>>>>>
>>>>>> "It's better to reign in hell than to serve in
heaven.",
>>>>>> John Milton, Paradise
lost.
>>>>>>
>>>>>> _______________________________________________
>>>>>> FreeIPA-users mailing list --
freeipa-users(a)lists.fedorahosted.org
>>>>>> <mailto:freeipa-users@lists.fedorahosted.org>
>>>>>> <mailto:freeipa-users@lists.fedorahosted.org>
>>>>>> <mailto:freeipa-users@lists.fedorahosted.org>
>>>>>> To unsubscribe send an email to
>>>>>> freeipa-users-leave(a)lists.fedorahosted.org
>>>>>> <mailto:freeipa-users-leave@lists.fedorahosted.org>
>>>>>> <mailto:freeipa-users-leave@lists.fedorahosted.org>
>>>>>> <mailto:freeipa-users-leave@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.fedoraho...
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
>>>>> <mailto:freeipa-users@lists.fedorahosted.org>
>>>>> <mailto:freeipa-users@lists.fedorahosted.org>
>>>>> To unsubscribe send an email to
>>>>> freeipa-users-leave(a)lists.fedorahosted.org
>>>>> <mailto:freeipa-users-leave@lists.fedorahosted.org>
>>>>> <mailto:freeipa-users-leave@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.fedoraho...
>>>>>
>>>>
>>>> --
>>>> Christian Reiss - email(a)christian-reiss.de
>>>> <mailto:email@christian-reiss.de>
>>>> <mailto:email@christian-reiss.de> /"\ ASCII Ribbon
>>>> support(a)alpha-labs.net
<mailto:support@alpha-labs.net>
>>>> <mailto:support@alpha-labs.net> \ / Campaign
>>>> X against HTML
>>>> WEB
alpha-labs.net <
http://alpha-labs.net>
<
http://alpha-labs.net>
>>>> / \ in eMails
>>>>
>>>> GPG Retrieval
https://gpg.christian-reiss.de
>>>> GPG ID ABCD43C5, 0x44E29126ABCD43C5
>>>> GPG fingerprint = 9549 F537 2596 86BA 733C A4ED 44E2 9126 ABCD 43C5
>>>>
>>>> "It's better to reign in hell than to serve in heaven.",
>>>> John Milton, Paradise lost.
>>>>
>>>> _______________________________________________
>>>> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
>>>> <mailto:freeipa-users@lists.fedorahosted.org>
>>>> <mailto:freeipa-users@lists.fedorahosted.org>
>>>> To unsubscribe send an email to
>>>> freeipa-users-leave(a)lists.fedorahosted.org
>>>> <mailto:freeipa-users-leave@lists.fedorahosted.org>
>>>> <mailto:freeipa-users-leave@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.fedoraho...
>>>
>>>
>>> _______________________________________________
>>> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
>>> <mailto:freeipa-users@lists.fedorahosted.org>
>>> To unsubscribe send an email to
>>> freeipa-users-leave(a)lists.fedorahosted.org
>>> <mailto:freeipa-users-leave@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.fedoraho...
>>>
>>
>> --
>> Christian Reiss - email(a)christian-reiss.de
>> <mailto:email@christian-reiss.de> /"\ ASCII Ribbon
>> support(a)alpha-labs.net
>> <mailto:support@alpha-labs.net> \ / Campaign
>> X against HTML
>> WEB
alpha-labs.net <
http://alpha-labs.net>
>> / \ in eMails
>>
>> GPG Retrieval
https://gpg.christian-reiss.de
>> GPG ID ABCD43C5, 0x44E29126ABCD43C5
>> GPG fingerprint = 9549 F537 2596 86BA 733C A4ED 44E2 9126 ABCD 43C5
>>
>> "It's better to reign in hell than to serve in heaven.",
>> John Milton, Paradise lost.
>>
>> _______________________________________________
>> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
>> <mailto:freeipa-users@lists.fedorahosted.org>
>> To unsubscribe send an email to
>> freeipa-users-leave(a)lists.fedorahosted.org
>> <mailto:freeipa-users-leave@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.fedoraho...
>
>
> _______________________________________________
> 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://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.fedoraho...
>
--
Christian Reiss - email(a)christian-reiss.de /"\ ASCII Ribbon
support(a)alpha-labs.net \ / Campaign
X against HTML
WEB
alpha-labs.net / \ in eMails
GPG Retrieval
https://gpg.christian-reiss.de
GPG ID ABCD43C5, 0x44E29126ABCD43C5
GPG fingerprint = 9549 F537 2596 86BA 733C A4ED 44E2 9126 ABCD 43C5
"It's better to reign in hell than to serve in heaven.",
John Milton, Paradise lost.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland