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 - ipa02.auth.dc-01.company.com - ipa03.auth.dc-01.company.com - ipa04.auth.dc-01.company.com
Realm company.com, Kerberos COMPANY.COM. If I point the pfsense (I'll stick to that as an example) against 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 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.
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 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
- ipa02.auth.dc-01.company.com
- ipa03.auth.dc-01.company.com
- ipa04.auth.dc-01.company.com
Realm company.com, Kerberos COMPANY.COM. If I point the pfsense (I'll stick to that as an example) against 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 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@christian-reiss.de /"\ ASCII Ribbon support@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.
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to 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.fedorahoste...
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 (exmaple, using real IPs out there):
auth.company.com IN NS 10.0.0.1
and created
srv1.auth.company.com (10.0.0.1) 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 IP address(es): 10.0.0.1 Domain name: 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 Domain: auth.company.com K5 : COMPANY.COM
Replica adoption failed because auth.company.com is not company.com.
2nd try, this time:
Server: srv1.auth.company.com Domain: company.com K5 : COMPANY.COM
Primary failed: ERROR DNS zone COMPANY.COM. already exists in DNS and is handled by server(s): ns1.ns-serve.net., 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 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
- ipa02.auth.dc-01.company.com
- ipa03.auth.dc-01.company.com
- ipa04.auth.dc-01.company.com
Realm company.com, Kerberos COMPANY.COM. If I point the pfsense (I'll stick to that as an example) against 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 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@christian-reiss.de /"\ ASCII Ribbon support@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.
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to 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.fedorahoste...
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to 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.fedorahoste...
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/ 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/, both the IPA domain and the kerberos realm. The main zone, 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/ you could use something like company.net http://company.net/ if that’s available. Could be confusing for users, so maybe companyauth.com http://companyauth.com/ or 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 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 (exmaple, using real IPs out there):
auth.company.com IN NS 10.0.0.1
and created
srv1.auth.company.com (10.0.0.1) 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 IP address(es): 10.0.0.1 Domain name: 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 Domain: auth.company.com K5 : COMPANY.COM
Replica adoption failed because auth.company.com is not company.com.
2nd try, this time:
Server: srv1.auth.company.com Domain: company.com K5 : COMPANY.COM
Primary failed: ERROR DNS zone COMPANY.COM. already exists in DNS and is handled by server(s): ns1.ns-serve.net., 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 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
- ipa02.auth.dc-01.company.com
- ipa03.auth.dc-01.company.com
- ipa04.auth.dc-01.company.com
Realm company.com, Kerberos COMPANY.COM. If I point the pfsense (I'll stick to that as an example) against 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 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@christian-reiss.de /"\ ASCII Ribbon support@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.
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to 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.fedorahoste...
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to 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.fedorahoste...
-- Christian Reiss - email@christian-reiss.de /"\ ASCII Ribbon support@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.
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to 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.fedorahoste...
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 Domain name, Using kerberos on kerberos.company.com. SRV & TXT Records all point to kerberos.company.com.
All user prinicipals are user@COMPANY.COM, all kerberized services/keytabs have a principal of host/vm4.company.com@COMPANY.COM
What we are aiming for is: A User requests a TGT via
kinit john@COMPANY.COM (ignoring default realms for a bit) and it would receive a TGT from either IPA server issues to
john@COMPANY.COM
Servers are in the form
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 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, both the IPA domain and the kerberos realm. The main zone, 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 you could use something like company.net http://company.net if that’s available. Could be confusing for users, so maybe companyauth.com http://companyauth.com or 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> 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 (exmaple, using real IPs out there):
auth.company.com http://auth.company.com IN NS 10.0.0.1
and created
srv1.auth.company.com http://srv1.auth.company.com (10.0.0.1) 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 IP address(es): 10.0.0.1 Domain name: 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 Domain: auth.company.com http://auth.company.com K5 : COMPANY.COM http://COMPANY.COM
Replica adoption failed because auth.company.com http://auth.company.com is not company.com http://company.com.
2nd try, this time:
Server: srv1.auth.company.com http://srv1.auth.company.com Domain: company.com http://company.com K5 : COMPANY.COM http://COMPANY.COM
Primary failed: ERROR DNS zone COMPANY.COM http://COMPANY.COM. already exists in DNS and is handled by server(s): ns1.ns-serve.net http://ns1.ns-serve.net., 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> 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
- 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
- ipa04.auth.dc-01.company.com http://ipa04.auth.dc-01.company.com
Realm company.com http://company.com, Kerberos 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 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 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@christian-reiss.de mailto:email@christian-reiss.de /"\ ASCII Ribbon support@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@lists.fedorahosted.org mailto:freeipa-users@lists.fedorahosted.org To unsubscribe send an email to 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.fedorahoste...
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org mailto:freeipa-users@lists.fedorahosted.org To unsubscribe send an email to 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.fedorahoste...
-- Christian Reiss - email@christian-reiss.de mailto:email@christian-reiss.de /"\ ASCII Ribbon support@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@lists.fedorahosted.org mailto:freeipa-users@lists.fedorahosted.org To unsubscribe send an email to 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.fedorahoste...
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to 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.fedorahoste...
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 —realm=AUTH.COMPANY.COM --setup-dns
(Note: I’d use 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/ 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/, 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 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 Domain name, Using kerberos on kerberos.company.com. SRV & TXT Records all point to kerberos.company.com.
All user prinicipals are user@COMPANY.COM, all kerberized services/keytabs have a principal of host/vm4.company.com@COMPANY.COM
What we are aiming for is: A User requests a TGT via
kinit john@COMPANY.COM (ignoring default realms for a bit) and it would receive a TGT from either IPA server issues to
john@COMPANY.COM
Servers are in the form
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 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, both the IPA domain and the kerberos realm. The main zone, 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 you could use something like company.net http://company.net if that’s available. Could be confusing for users, so maybe companyauth.com http://companyauth.com or 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> 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 (exmaple, using real IPs out there):
auth.company.com http://auth.company.com IN NS 10.0.0.1
and created
srv1.auth.company.com http://srv1.auth.company.com (10.0.0.1) 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 IP address(es): 10.0.0.1 Domain name: 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 Domain: auth.company.com http://auth.company.com K5 : COMPANY.COM http://COMPANY.COM
Replica adoption failed because auth.company.com http://auth.company.com is not company.com http://company.com.
2nd try, this time:
Server: srv1.auth.company.com http://srv1.auth.company.com Domain: company.com http://company.com K5 : COMPANY.COM http://COMPANY.COM
Primary failed: ERROR DNS zone COMPANY.COM http://COMPANY.COM. already exists in DNS and is handled by server(s): ns1.ns-serve.net http://ns1.ns-serve.net., 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> 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
- 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
- ipa04.auth.dc-01.company.com http://ipa04.auth.dc-01.company.com
Realm company.com http://company.com, Kerberos 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 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 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@christian-reiss.de mailto:email@christian-reiss.de /"\ ASCII Ribbon support@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@lists.fedorahosted.org mailto:freeipa-users@lists.fedorahosted.org To unsubscribe send an email to 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.fedorahoste...
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org mailto:freeipa-users@lists.fedorahosted.org To unsubscribe send an email to 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.fedorahoste...
-- Christian Reiss - email@christian-reiss.de mailto:email@christian-reiss.de /"\ ASCII Ribbon support@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@lists.fedorahosted.org mailto:freeipa-users@lists.fedorahosted.org To unsubscribe send an email to 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.fedorahoste...
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to 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.fedorahoste...
-- Christian Reiss - email@christian-reiss.de /"\ ASCII Ribbon support@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.
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to 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.fedorahoste...
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 (realm, domain, etc) have and disadvantages? I could simply add dns srv records from company.com to auth.company.com?
And it's okay I guess if the host keytabs look like
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 —realm=AUTH.COMPANY.COM http://AUTH.COMPANY.COM --setup-dns
(Note: I’d use 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 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, 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> 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 Domain name, Using kerberos on kerberos.company.com http://kerberos.company.com. SRV & TXT Records all point to kerberos.company.com http://kerberos.company.com.
All user prinicipals are user@COMPANY.COM mailto:user@COMPANY.COM, all kerberized services/keytabs have a principal of 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@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@COMPANY.COM mailto:john@COMPANY.COM
Servers are in the form
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 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, both the IPA domain and the kerberos realm. The main zone, 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 you could use something like 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 or 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> 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 (exmaple, using real IPs out there):
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 (10.0.0.1) 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 IP address(es): 10.0.0.1 Domain name: 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 Domain: auth.company.com http://auth.company.com http://auth.company.com K5 : COMPANY.COM http://COMPANY.COM http://COMPANY.COM
Replica adoption failed because auth.company.com http://auth.company.com http://auth.company.com is not 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 Domain: company.com http://company.com http://company.com K5 : COMPANY.COM http://COMPANY.COM http://COMPANY.COM
Primary failed: ERROR DNS zone 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., 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> 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
- 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
- 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, Kerberos 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 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 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@christian-reiss.de mailto:email@christian-reiss.de mailto:email@christian-reiss.de /"\ ASCII Ribbon 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 / \ 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-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.fedorahoste...
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-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.fedorahoste...
-- Christian Reiss - email@christian-reiss.de mailto:email@christian-reiss.de mailto:email@christian-reiss.de /"\ ASCII Ribbon 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 / \ 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-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.fedorahoste...
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org mailto:freeipa-users@lists.fedorahosted.org To unsubscribe send an email to 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.fedorahoste...
-- Christian Reiss - email@christian-reiss.de mailto:email@christian-reiss.de /"\ ASCII Ribbon support@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@lists.fedorahosted.org mailto:freeipa-users@lists.fedorahosted.org To unsubscribe send an email to 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.fedorahoste...
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to 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.fedorahoste...
On ma, 17 kesä 2019, Christian Reiss via FreeIPA-users 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 (realm, domain, etc) have and disadvantages? I could simply add dns srv records from company.com to auth.company.com?
And it's okay I guess if the host keytabs look like
host/server.company.com@AUTH.COMPANY.COM
I am slowly getting there :)
See, for example, https://www.redhat.com/archives/freeipa-users/2016-October/msg00350.html
You might also want to read https://vda.li/en/posts/2019/03/24/Kerberos-host-to-realm-translation/
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 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 (realm, domain, etc) have and disadvantages? I could simply add dns srv records from company.com to auth.company.com?
And it's okay I guess if the host keytabs look like
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 —realm=AUTH.COMPANY.COM http://AUTH.COMPANY.COM --setup-dns
(Note: I’d use 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 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, 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> 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 Domain name, Using kerberos on kerberos.company.com http://kerberos.company.com. SRV & TXT Records all point to kerberos.company.com http://kerberos.company.com.
All user prinicipals are user@COMPANY.COM mailto:user@COMPANY.COM, all kerberized services/keytabs have a principal of 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@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@COMPANY.COM mailto:john@COMPANY.COM
Servers are in the form
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 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, both the IPA domain and the kerberos realm. The main zone, 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 you could use something like 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 or 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> 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 (exmaple, using real IPs out there):
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 (10.0.0.1) 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 IP address(es): 10.0.0.1 Domain name: 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 Domain: auth.company.com http://auth.company.com http://auth.company.com K5 : COMPANY.COM http://COMPANY.COM http://COMPANY.COM
Replica adoption failed because auth.company.com http://auth.company.com http://auth.company.com is not 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 Domain: company.com http://company.com http://company.com K5 : COMPANY.COM http://COMPANY.COM http://COMPANY.COM
Primary failed: ERROR DNS zone 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., 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> 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 > - 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 > - 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, > Kerberos 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 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 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@christian-reiss.de > mailto:email@christian-reiss.de > mailto:email@christian-reiss.de /"\ ASCII Ribbon > 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 > / \ 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-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.fedorahoste... _______________________________________________ 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-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.fedorahoste...
-- Christian Reiss - email@christian-reiss.de mailto:email@christian-reiss.de mailto:email@christian-reiss.de /"\ ASCII Ribbon 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 / \ 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-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.fedorahoste...
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org mailto:freeipa-users@lists.fedorahosted.org To unsubscribe send an email to 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.fedorahoste...
-- Christian Reiss - email@christian-reiss.de mailto:email@christian-reiss.de /"\ ASCII Ribbon support@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@lists.fedorahosted.org mailto:freeipa-users@lists.fedorahosted.org To unsubscribe send an email to 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.fedorahoste...
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to 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.fedorahoste...
-- Christian Reiss - email@christian-reiss.de /"\ ASCII Ribbon support@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.
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to 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.fedorahoste...
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.com@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@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@COMPANY.COM mailto:user@COMPANY.COM mailto:user@COMPANY.COM, all kerberized services/keytabs have a principal of host/vm4.company.com@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@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@COMPANY.COM mailto:john@COMPANY.COM mailto:john@COMPANY.COM
Servers are in the form
host/server.company.com@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@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 - email@christian-reiss.de >> mailto:email@christian-reiss.de >> mailto:email@christian-reiss.de >> mailto:email@christian-reiss.de /"\ ASCII Ribbon >> support@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@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@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.fedorahoste... > _______________________________________________ > 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-leave@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.fedorahoste... >
-- Christian Reiss - email@christian-reiss.de mailto:email@christian-reiss.de mailto:email@christian-reiss.de mailto:email@christian-reiss.de /"\ ASCII Ribbon support@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@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@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.fedorahoste...
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-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.fedorahoste...
-- Christian Reiss - email@christian-reiss.de mailto:email@christian-reiss.de mailto:email@christian-reiss.de /"\ ASCII Ribbon 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 / \ 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-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.fedorahoste...
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org mailto:freeipa-users@lists.fedorahosted.org To unsubscribe send an email to 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.fedorahoste...
-- Christian Reiss - email@christian-reiss.de mailto:email@christian-reiss.de /"\ ASCII Ribbon support@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@lists.fedorahosted.org mailto:freeipa-users@lists.fedorahosted.org To unsubscribe send an email to 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.fedorahoste...
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to 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.fedorahoste...
On ma, 17 kesä 2019, Christian Reiss via FreeIPA-users wrote:
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?
I think it will work. You can keep COMPANY.COM realm, just make sure company.com DNS domain is: - owned by your organization - has appropriate SRV records for LDAP and Kerberos of COMPANY.COM, wherever they located - has TXT Kerberos record pointing to COMPANY.COM
Use --domain company.com 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 AUTH.COMPANY.COM as your realm, that would work too, just consider auth.company.com your primary IPA domain.
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@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@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@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@COMPANY.COM mailto:user@COMPANY.COM mailto:user@COMPANY.COM, all kerberized services/keytabs have a principal of host/vm4.company.com@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@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@COMPANY.COM mailto:john@COMPANY.COM mailto:john@COMPANY.COM
Servers are in the form
host/server.company.com@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@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 - email@christian-reiss.de >>> mailto:email@christian-reiss.de >>> mailto:email@christian-reiss.de >>> mailto:email@christian-reiss.de /"\ ASCII Ribbon >>> support@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@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@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.fedorahoste... >> _______________________________________________ >> 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-leave@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.fedorahoste... >> > > -- > Christian Reiss - email@christian-reiss.de > mailto:email@christian-reiss.de > mailto:email@christian-reiss.de > mailto:email@christian-reiss.de /"\ ASCII Ribbon > support@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@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@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.fedorahoste...
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-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.fedorahoste...
-- Christian Reiss - email@christian-reiss.de mailto:email@christian-reiss.de mailto:email@christian-reiss.de /"\ ASCII Ribbon 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 / \ 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-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.fedorahoste...
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org mailto:freeipa-users@lists.fedorahosted.org To unsubscribe send an email to 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.fedorahoste...
-- Christian Reiss - email@christian-reiss.de mailto:email@christian-reiss.de /"\ ASCII Ribbon support@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@lists.fedorahosted.org mailto:freeipa-users@lists.fedorahosted.org To unsubscribe send an email to 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.fedorahoste...
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to 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.fedorahoste...
-- Christian Reiss - email@christian-reiss.de /"\ ASCII Ribbon support@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.
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to 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.fedorahoste...
freeipa-users@lists.fedorahosted.org
-
Alexander Bokovoy -
Christian Reiss -
John Keates