Ahh... okay. Assumption: We can throw all the servers and keytabs overboard and start afresh. No restrictions, everyone can get new credentials.
Assumption: We are free to pick domain or a subdomain under the current domain. Assumption: No AD trust required. Requirement: ldap lookups must provide results for the primary company.com domain. Requirement: IPA must (must as in RFC 2119) be publically available. All office terminals, remote terminals, customers w/o vpn must be able to use the services. Anything against rolling out against auth.company.com (realm & domain), delegating subdomain and doing SRV records pointing to auth.company.com? 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. 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@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....@auth.company.com >> <mailto:host/server.company....@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@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 u...@company.com <mailto:u...@company.com> >>>> <mailto:u...@company.com>, >>>> all kerberized >>>> services/keytabs have a principal of >>>> host/vm4.company....@company.com >>>> <mailto:host/vm4.company....@company.com> >>>> <mailto:host/vm4.company....@company.com> >>>> >>>> What we are aiming for is: A User requests a TGT via >>>> >>>> kinit j...@company.com <mailto:j...@company.com> >>>> <mailto:j...@company.com> (ignoring default >>>> realms for a bit) and it would >>>> receive a TGT from either IPA server issues to >>>> >>>> j...@company.com <mailto:j...@company.com> <mailto:j...@company.com> >>>> >>>> Servers are in the form >>>> >>>> host/server.company....@company.com >>>> <mailto:host/server.company....@company.com> >>>> <mailto:host/server.company....@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@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@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 - em...@christian-reiss.de >>>>>>>> <mailto:em...@christian-reiss.de> >>>>>>>> <mailto:em...@christian-reiss.de> >>>>>>>> <mailto:em...@christian-reiss.de> /"\ ASCII Ribbon >>>>>>>> supp...@alpha-labs.net >>>>>>>> <mailto:supp...@alpha-labs.net> >>>>>>>> <mailto:supp...@alpha-labs.net> >>>>>>>> <mailto:supp...@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@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-le...@lists.fedorahosted.org >>>>>>>> <mailto:freeipa-users-le...@lists.fedorahosted.org> >>>>>>>> <mailto:freeipa-users-le...@lists.fedorahosted.org> >>>>>>>> <mailto: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 >>>>>>> _______________________________________________ >>>>>>> FreeIPA-users mailing list -- >>>>>>> freeipa-users@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-le...@lists.fedorahosted.org >>>>>>> <mailto:freeipa-users-le...@lists.fedorahosted.org> >>>>>>> <mailto:freeipa-users-le...@lists.fedorahosted.org> >>>>>>> <mailto: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 >>>>>>> >>>>>> >>>>>> -- >>>>>> Christian Reiss - em...@christian-reiss.de >>>>>> <mailto:em...@christian-reiss.de> >>>>>> <mailto:em...@christian-reiss.de> >>>>>> <mailto:em...@christian-reiss.de> /"\ ASCII Ribbon >>>>>> supp...@alpha-labs.net >>>>>> <mailto:supp...@alpha-labs.net> <mailto:supp...@alpha-labs.net> >>>>>> <mailto:supp...@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@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-le...@lists.fedorahosted.org >>>>>> <mailto:freeipa-users-le...@lists.fedorahosted.org> >>>>>> <mailto:freeipa-users-le...@lists.fedorahosted.org> >>>>>> <mailto: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 >>>>> >>>>> >>>>> _______________________________________________ >>>>> FreeIPA-users mailing list -- 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-le...@lists.fedorahosted.org >>>>> <mailto:freeipa-users-le...@lists.fedorahosted.org> >>>>> <mailto: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 >>>>> >>>> >>>> -- >>>> Christian Reiss - em...@christian-reiss.de >>>> <mailto:em...@christian-reiss.de> >>>> <mailto:em...@christian-reiss.de> /"\ ASCII Ribbon >>>> supp...@alpha-labs.net <mailto:supp...@alpha-labs.net> >>>> <mailto:supp...@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@lists.fedorahosted.org >>>> <mailto:freeipa-users@lists.fedorahosted.org> >>>> <mailto:freeipa-users@lists.fedorahosted.org> >>>> To unsubscribe send an email to >>>> freeipa-users-le...@lists.fedorahosted.org >>>> <mailto:freeipa-users-le...@lists.fedorahosted.org> >>>> <mailto: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 >>> >>> >>> _______________________________________________ >>> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org >>> <mailto:freeipa-users@lists.fedorahosted.org> >>> To unsubscribe send an email to >>> freeipa-users-le...@lists.fedorahosted.org >>> <mailto: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 >>> >> >> -- >> Christian Reiss - em...@christian-reiss.de >> <mailto:em...@christian-reiss.de> /"\ ASCII Ribbon >> supp...@alpha-labs.net >> <mailto:supp...@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@lists.fedorahosted.org >> <mailto:freeipa-users@lists.fedorahosted.org> >> To unsubscribe send an email to >> freeipa-users-le...@lists.fedorahosted.org >> <mailto: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 > > > _______________________________________________ > 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 > -- Christian Reiss - em...@christian-reiss.de /"\ ASCII Ribbon supp...@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.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ 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
