Re: [Freeipa-users] Still unclear about relation between IPA DNS domain and company DNS domain.

[Brian Candler]

On 23/12/2016 10:31, Alexander Bokovoy wrote:

ipa-ca used to be a CNAME, you cannot handle CNAME via /etc/hosts.
However, multiple replicas cannot me specified via CNAME, so we had to
fix https://fedorahosted.org/freeipa/ticket/3547. 


Absolutely - I have no problem with ipa-ca being real A record(s) 
pointing to the server itself.


All I'm saying is that at installation time, it already knew the IP 
address of the server - by local hostname resolution, and because 
ipa-server-install  asks you to list the IP addresses of the server 
explicitly.


> The ipa-ca A record is now handled as part of the server upgrade which
> also should be run at the very end of a normal install.

Are you are supposed to manually run "ipa-server-upgrade" even after a 
clean install?


I've just tested that, and yes, one of the steps is:

...
[Add missing CA DNS records]
Updating DNS system records
<< pauses here >>
unable to resolve host name ipatest.foo.example.com. to IP address, 
ipa-ca DNS record will be incomplete

...

So you're right: that would have fixed it *if* I'd created the 
foo.example.com zone first, and added the host to it, which in real life 
I would have done (since other hosts must be able to resolve the IPA 
server's hostname)


I already opened https://fedorahosted.org/freeipa/ticket/6579 which 
suggested using local resolution, e.g. via gethostent(). But feel free 
to close it if you don't think this is needed.


Regards,

Brian.

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Still unclear about relation between IPA DNS domain and company DNS domain.

[Alexander Bokovoy]

On pe, 23 joulu 2016, Brian Candler wrote:

On 23/12/2016 09:47, Brian Candler wrote:

/etc/pki/pki-tomcat/ca/CS.cfg:ca.defaultOcspUri=http://ipa-ca.bar.example.com/ca/ocsp


However the installation process didn't actually create this DNS 
entry, so the ipa-ca hostname is not resolvable.


Aside: I think this was because ipatest.foo.example.com was only in 
/etc/hosts, not in the DNS. Installation message:


ipa : ERRORunable to resolve host name 
ipatest.foo.example.com. to IP address, ipa-ca DNS record will be 
incomplete


But if it had used gethostent() or similar, it would have worked:

# getent hosts ipatest.foo.example.com
100.64.2.3  ipatest.foo.example.com ipatest

ipa-ca used to be a CNAME, you cannot handle CNAME via /etc/hosts.
However, multiple replicas cannot me specified via CNAME, so we had to
fix https://fedorahosted.org/freeipa/ticket/3547.

The ipa-ca A record is now handled as part of the server upgrade which
also should be run at the very end of a normal install.
--
/ Alexander Bokovoy

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Still unclear about relation between IPA DNS domain and company DNS domain.

[Brian Candler]

On 23/12/2016 09:47, Brian Candler wrote:
/etc/pki/pki-tomcat/ca/CS.cfg:ca.defaultOcspUri=http://ipa-ca.bar.example.com/ca/ocsp 



However the installation process didn't actually create this DNS 
entry, so the ipa-ca hostname is not resolvable.


Aside: I think this was because ipatest.foo.example.com was only in 
/etc/hosts, not in the DNS. Installation message:


ipa : ERRORunable to resolve host name 
ipatest.foo.example.com. to IP address, ipa-ca DNS record will be incomplete


But if it had used gethostent() or similar, it would have worked:

# getent hosts ipatest.foo.example.com
100.64.2.3  ipatest.foo.example.com ipatest

Regards,

Brian.

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Still unclear about relation between IPA DNS domain and company DNS domain.

[Brian Candler]

On 22/12/2016 20:53, Martin Basti wrote:


(1) This introduces a concept of an "IPA Primary Domain".  Is that 
just the DNS domain which holds the SRV records which point to the 
realm's kerberos/ldap servers, or does it have any other function? In 
other words, what other effects would there be from choosing a 
different IP Primary Domain?


it holds SRV records, A/ records for CA

LDAP tree is constructed from the domain (cn=accounts,dc=example,dc=com)



No, I don't believe that's true: the LDAP tree is constructed from the 
*realm* not the *domain*.


I just checked this by creating a Centos7 lxd container with hostname 
"ipa.foo.example.com", running the following command:


# ipa-server-install --domain bar.example.com --realm QUX.EXAMPLE.COM 
--setup-dns -p Abcd1234 -a Defg5678


and accepting defaults for everything else. What I get is:

*** an LDAP tree rooted at dc=qux,dc=example,dc=com

=> this proves the LDAP tree is constructed from the --realm, not the 
--domain.


*** the DNS zone "bar.example.com" (in addition to the reverse zone)

The bar.example.com contains both types of DNS mapping: hostname to 
realm and realm to servers.


(1) _kerberos TXT "QUX.EXAMPLE.COM"

i.e. "hosts with hostnames under domain bar.example.com belong to realm 
QUX.EXAMPLE.COM"


(2) _kerberos._tcp SRV 0 100 88 ipatest.foo.example.com.# plus 
_kerberos._ldap etc


=> this shows the SRV records are put under the --domain


*** in krb5.conf a default realm of QUX.EXAMPLE.COM, and the following 
realm to server mapping:


[realms]
 QUX.EXAMPLE.COM = {
  kdc = ipatest.foo.example.com:88
  master_kdc = ipatest.foo.example.com:88
  admin_server = ipatest.foo.example.com:749
  default_domain = bar.example.com
  pkinit_anchors = FILE:/etc/ipa/ca.crt
}

Aha: there is "default_domain" in there! It's a property of the realm! 
Checking the MIT kerberos documentation:


http://web.mit.edu/kerberos/krb5-1.14/doc/admin/conf_files/krb5_conf.html

"default_domain

This tag specifies the domain used to expand hostnames when translating 
Kerberos 4 service principals to Kerberos 5 principals (for example, 
when converting rcmd.hostname to host/hostname.domain)."


So it seems that's only a legacy setting for dealing with kerberos 4 :-(

*** /etc/sssd/sssd.conf

[domain/bar.example.com]
krb5_realm = QUX.EXAMPLE.COM
ipa_domain = bar.example.com

[sssd]
domains = bar.example.com

But in sssd, "A domain is a database containing user information" - from 
sssd.conf(5).  So really it's just a label for a group of settings, 
nothing to do with a DNS domain.


*** CA

grepping through /etc I see some other settings based on the domain, in 
particular the CA hostname is here:


/etc/pki/pki-tomcat/ca/CS.cfg:ca.defaultOcspUri=http://ipa-ca.bar.example.com/ca/ocsp

However the installation process didn't actually create this DNS entry, 
so the ipa-ca hostname is not resolvable.  Since it has the 
bar.example.com master zone, maybe it should add this record?


*** During the installation I get a reasonable warning:

WARNING: Realm name does not match the domain name.
You will not be able to estabilish trusts with Active Directory unless
the realm name of the IPA server matches its domain name.

But I think this also highlights confusion between "the IPA domain" and 
"the server's domain name".


It's clear is that the *realm* is something that's common to all the IPA 
servers.  However it's also clear that each IPA server's *hostname* can 
be in a different *domain*, e.g. they could be


srv1.bar.com
srv2.baz.com

But "the IPA primary domain" (where the SRV records are stored) is an 
attribute of the realm collectively, not of the individual servers.  So 
it might be clearer if it said:


WARNING: Realm name does not match the domain name.
You will not be able to establish trusts with Active Directory unless
the IPA realm matches the IPA primary domain.




Then use bar.example.com, IPA servers can have names outside the IPA 
domain name space.


Different people wants different things, that's why the option is there.



Indeed, but the "--domain" option to ipa-server-install appears to be 
orthogonal to the domain name of the IPA servers themselves. This is a 
primary source of confusion I think.


Regards,

Brian.

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Still unclear about relation between IPA DNS domain and company DNS domain.

[Martin Basti]

On 22.12.2016 17:53, Brian Candler wrote:

On 20/12/2016 08:07, Petr Spacek wrote:
I've tried to clarify things in man pages and on web as well. Please 
have a
look to changes and let us know if it is better or not, and 
preferably what

can be improved and in which way

The modified deployment page is here:
http://www.freeipa.org/page/Deployment_Recommendations

Man page changes and changes in description of installer options are 
here:

https://github.com/freeipa/freeipa/pull/352


Thank you for working on this.

This is getting clearer, but I would like to expand a little more.

(1) This introduces a concept of an "IPA Primary Domain".  Is that 
just the DNS domain which holds the SRV records which point to the 
realm's kerberos/ldap servers, or does it have any other function? In 
other words, what other effects would there be from choosing a 
different IP Primary Domain?


it holds SRV records, A/ records for CA

LDAP tree is constructed from the domain (cn=accounts,dc=example,dc=com)



Let me give a specific example.

- IPA server hostname is ipa.foo.example.com
- I want to create kerberos realm BAR.EXAMPLE.COM

Which IPA primary domain should I choose?

The expected place for SRV records for realm BAR.EXAMPLE.COM would be 
in the DNS under domain bar.example.com.  So I'm thinking that 
"--domain bar.example.com" is the right thing - and can't think why 
you'd ever want to do anything else.





Then use bar.example.com, IPA servers can have names outside the IPA 
domain name space.


Different people wants different things, that's why the option is there.



(2) I'm trying to work out how --domain, --realm, --server and 
systemhostname influence each other, if one or more is not provided.


For ipa-server-install, testing suggests:

* --domain defaults to the domain part of the system hostname
* --realm defaults to the uppercased --domain
* (--server is obviously itself :-)

For ipa-client-install it seems a bit more complex. Based on the 
manpage, I believe the sequence is something like this:


* If --domain is not specified, then it's the domain from the system 
hostname
* If --server is not specified, then it hunts for servers based on the 
--domain (looking in that domain and its parents until suitable SRV 
records are found)
* If --realm is not specified, then it sends a query to the 
--server(s) to ask what realm they are in


But the manpage says you can specify both --server and --domain:

  "Client  machine  can  also be configured without a DNS 
autodiscovery at all. When both
   --server and --domain options are used, client installer will 
use the specified server

   and  domain  directly."


Server and client can be in different DNS domains, that's probably why 
it has separate options.


I know that it is not clear how client determine domain and server, but 
there were more important things to fix, this may be improved in future.





In that case, I can't see what the --domain is used for here, if it's 
only purpose is to locate servers (and you've already told it which 
--server to use)


Thanks,

Brian.



Martin

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Still unclear about relation between IPA DNS domain and company DNS domain.

[Brian Candler]

On 20/12/2016 08:07, Petr Spacek wrote:

I've tried to clarify things in man pages and on web as well. Please have a
look to changes and let us know if it is better or not, and preferably what
can be improved and in which way

The modified deployment page is here:
http://www.freeipa.org/page/Deployment_Recommendations

Man page changes and changes in description of installer options are here:
https://github.com/freeipa/freeipa/pull/352


Thank you for working on this.

This is getting clearer, but I would like to expand a little more.

(1) This introduces a concept of an "IPA Primary Domain".  Is that just 
the DNS domain which holds the SRV records which point to the realm's 
kerberos/ldap servers, or does it have any other function? In other 
words, what other effects would there be from choosing a different IP 
Primary Domain?


Let me give a specific example.

- IPA server hostname is ipa.foo.example.com
- I want to create kerberos realm BAR.EXAMPLE.COM

Which IPA primary domain should I choose?

The expected place for SRV records for realm BAR.EXAMPLE.COM would be in 
the DNS under domain bar.example.com.  So I'm thinking that "--domain 
bar.example.com" is the right thing - and can't think why you'd ever 
want to do anything else.




(2) I'm trying to work out how --domain, --realm, --server and 
systemhostname influence each other, if one or more is not provided.


For ipa-server-install, testing suggests:

* --domain defaults to the domain part of the system hostname
* --realm defaults to the uppercased --domain
* (--server is obviously itself :-)

For ipa-client-install it seems a bit more complex. Based on the 
manpage, I believe the sequence is something like this:


* If --domain is not specified, then it's the domain from the system 
hostname
* If --server is not specified, then it hunts for servers based on the 
--domain (looking in that domain and its parents until suitable SRV 
records are found)
* If --realm is not specified, then it sends a query to the --server(s) 
to ask what realm they are in


But the manpage says you can specify both --server and --domain:

  "Client  machine  can  also be configured without a DNS 
autodiscovery at all. When both
   --server and --domain options are used, client installer will 
use the specified server

   and  domain  directly."

In that case, I can't see what the --domain is used for here, if it's 
only purpose is to locate servers (and you've already told it which 
--server to use)


Thanks,

Brian.

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Still unclear about relation between IPA DNS domain and company DNS domain.

[Petr Spacek]

On 8.12.2016 10:12, Pieter Nagel wrote:
> On Thu, Dec 8, 2016 at 10:59 AM, Alexander Bokovoy 
> wrote:
> 
>> It is really simply: your DNS domain named as your Kerberos realm must
>> be under your control, one way or another, to allow automatic discovery
>> of resources to work.
>>
> 
> Thanks, this explanation makes it crystal clear. This exact phrasing would
> have made the docs much clearer too, IMO.
> 
> Setting the realm to the DNS domain that the FreeIPA internal DNS server
> serves is just one simple out-of-the box way to get DNS domain named as
> your Kerberos realm that is under your control, in other words.

I've tried to clarify things in man pages and on web as well. Please have a
look to changes and let us know if it is better or not, and preferably what
can be improved and in which way

The modified deployment page is here:
http://www.freeipa.org/page/Deployment_Recommendations

Man page changes and changes in description of installer options are here:
https://github.com/freeipa/freeipa/pull/352

-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Still unclear about relation between IPA DNS domain and company DNS domain.

[Alexander Bokovoy]

On pe, 09 joulu 2016, Brian Candler wrote:

On 08/12/2016 08:50, Pieter Nagel wrote:


Concrete scenario, I wonder if this will work:

A greenfields deployment, no other kerberos, no Active Directory. 
Internal DNS to be int.lautus.net  and 
FreeIPA manages that DNS domain and adds internal hosts to it as 
they enroll. Public-facing servers are manually registered in 
lautus.net  DNS which is hosted elsewhere. But 
FreeIPA is installed with realm LAUTUS.NET  so it 
adds _kerberos entries for realm LAUTUS.NET  to 
int.lautus.net , and I manually copy those 
entries to lautus.net , so everone agrees that 
they belong to the same realm.


The reason I want the realm to be LAUTUS.NET  is 
because it makes more sense to me that the internal desktops in the 
subdomain int.lautus.net  to enroll into a 
realm related to the parent DNS domain
I see a red flag with "desktops". Do you mean Windows desktops? Then 
you are talking Active Directory (or the Samba implementation of AD) 
and there are very specific rules for how the hostnames and the realms 
interact.


If you are talking Linux/BSD desktops, then it doesn't matter. 
Personally I would do it the other way round than you propose: let 
machines foo.lautus.net and bar.int.lautus.net use IPA.LAUTUS.NET as 
their kerberos realm, because this gives you the *option* of adding a 
distinct kerberos realm like AD.LAUTUS.NET later.


If you ever introduce Active Directory into your network then you 
don't want it to be either a subdomain or a parent domain of your IPA 
domain, unless you enjoy pain.

This is not a big deal, really. Red Hat customers routinely deploy IPA
as a subdomain or a parent domain to Active Directory deployments.



Changing your IPA realm later is also extremely painful.

Right now there is no a procedure to do so. Partially because realm name
is part of the salt used by Kerberos hashes.

, than it makes sense for the public-facing servers in the parent 
lautus.net  domain enroll into a realm related to 
an internal DNS subdomain.

It's not really a problem. In the DNS you create TXT records:

_kerberos.lautus.net.  TXT  "IPA.LAUTUS.NET"
_kerberos.int.lautus.net  TXT  "IPA.LAUTUS.NET"

and the auto-mapping of hosts to realms just works (in the *nix world 
anyway)

Correct. Windows systems don't request _kerberos TXT record at all.



Personally I would have no problem publishing
_kerberos.lautus.net.  TXT  "IPA.LAUTUS.NET"
in the public DNS. It's up to you whether you put *.ipa.lautus.net and 
*.int.lautus.net in the public DNS.


Or am I making an issue of a cosmetic triviality, and it is not all 
all strange in the kerberos realm to enroll a server into a realm 
related to a DNS subdomain it is not part of?



In my opinion, not at all strange. You have three things:

1. The DNS domain of the host
2. The Kerberos realm that the host is in
3. The DNS domain of the Kerberos realm

2+3 are bound together, but 1 does not need to relate to 2+3 (unless 
you are Microsoft)

Even in Microsoft world there are means to add DNS domains to the same
Active Directory domain (they are called name routing suffixes). They
aren't flexible enough though and you are not advised to create many of
them (to the tune of thousands) because they are checked every time a
Kerberos ticket is issued by the AD DC.

--
/ Alexander Bokovoy

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Still unclear about relation between IPA DNS domain and company DNS domain.

[Brian Candler]

On 08/12/2016 08:50, Pieter Nagel wrote:


Concrete scenario, I wonder if this will work:

A greenfields deployment, no other kerberos, no Active Directory. 
Internal DNS to be int.lautus.net  and FreeIPA 
manages that DNS domain and adds internal hosts to it as they enroll. 
Public-facing servers are manually registered in lautus.net 
 DNS which is hosted elsewhere. But FreeIPA is 
installed with realm LAUTUS.NET  so it adds 
_kerberos entries for realm LAUTUS.NET  to 
int.lautus.net , and I manually copy those 
entries to lautus.net , so everone agrees that they 
belong to the same realm.


The reason I want the realm to be LAUTUS.NET  is 
because it makes more sense to me that the internal desktops in the 
subdomain int.lautus.net  to enroll into a 
realm related to the parent DNS domain
I see a red flag with "desktops". Do you mean Windows desktops? Then you 
are talking Active Directory (or the Samba implementation of AD) and 
there are very specific rules for how the hostnames and the realms interact.


If you are talking Linux/BSD desktops, then it doesn't matter. 
Personally I would do it the other way round than you propose: let 
machines foo.lautus.net and bar.int.lautus.net use IPA.LAUTUS.NET as 
their kerberos realm, because this gives you the *option* of adding a 
distinct kerberos realm like AD.LAUTUS.NET later.


If you ever introduce Active Directory into your network then you don't 
want it to be either a subdomain or a parent domain of your IPA domain, 
unless you enjoy pain.


Changing your IPA realm later is also extremely painful.

, than it makes sense for the public-facing servers in the parent 
lautus.net  domain enroll into a realm related to 
an internal DNS subdomain.

It's not really a problem. In the DNS you create TXT records:

_kerberos.lautus.net.  TXT  "IPA.LAUTUS.NET"
_kerberos.int.lautus.net  TXT  "IPA.LAUTUS.NET"

and the auto-mapping of hosts to realms just works (in the *nix world 
anyway)


Personally I would have no problem publishing
_kerberos.lautus.net.  TXT  "IPA.LAUTUS.NET"
in the public DNS. It's up to you whether you put *.ipa.lautus.net and 
*.int.lautus.net in the public DNS.


Or am I making an issue of a cosmetic triviality, and it is not all 
all strange in the kerberos realm to enroll a server into a realm 
related to a DNS subdomain it is not part of?



In my opinion, not at all strange. You have three things:

1. The DNS domain of the host
2. The Kerberos realm that the host is in
3. The DNS domain of the Kerberos realm

2+3 are bound together, but 1 does not need to relate to 2+3 (unless you 
are Microsoft)


Regards,

Brian.
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Still unclear about relation between IPA DNS domain and company DNS domain.

[Jacob Evans]

Pieter, 
If you are comfortable with duplicating your external records internally, you 
CAN use this domain, however I've always preferred to have internal only and 
external only domains (we actually register domains externally that are 
internal use only). so for example, lautus.net is your external domain, for 
internal you could use a subdomain like ipa.lautus.net or lautus.tech. 

Split DNS isn't wrong, but it never makes things easier. your SRV records would 
only need to be duplicated if your users are @lautus.net and not 
@ipa.lautus.net or @ad.lautus.net. 

I hope this helps, this is all general dns infrastructure, so you could also 
checkout any other resources on building domain/forest infrastructure 
recommendations 

Good Luck, 

Jacob 

From: "Pieter Nagel" <pie...@lautus.net> 
To: "freeipa-users" <freeipa-users@redhat.com> 
Sent: Wednesday, December 7, 2016 8:33:41 AM 
Subject: Re: [Freeipa-users] Still unclear about relation between IPA DNS 
domain and company DNS domain. 

Thanks, that helps a lot. 



Yes and no. What you see with "@ NS ..." is a glue record -- you are 
supposed to have a glue record for IPA domain in the upstream domain, 
this is how domain delegation works in DNS world. 



Except what i saw was the other way around. The FreeIPA server has an NSrecord 
claiming that it is authoritative the parent domain, but its parent domain is 
hosted at dnsmadeeasy: 

~ dig @ [ http://8.8.8.8/ | 8.8.8.8 ] -t NS [ http://lautus.net/ | lautus.net ] 
[ http://lautus.net/ | lautus.net ] . 86399 IN NS [ 
http://ns15.dnsmadeeasy.com/ | ns15.dnsmadeeasy.com ] . 
~ dig @ [ http://8.8.8.8/ | 8.8.8.8 ] -t NS [ http://ipa.lautus.net/ | 
ipa.lautus.net ] 
[ http://ipa.lautus.net/ | ipa.lautus.net ] . 86399 IN NS [ 
http://ipa-hetzner-cpt4-01.lautus.net/ | ipa-hetzner-cpt4-01.lautus.net ] . 

But as far as the FreeIPA DNS is concerned, it is authoritative for everything: 

~ dig @ [ http://ipa-hetzner-cpt4-01.lautus.net/ | 
ipa-hetzner-cpt4-01.lautus.net ] -t NS [ http://lautus.net/ | lautus.net ] 
[ http://lautus.net/ | lautus.net ] . 86400 IN NS [ 
http://ipa-hetzner-cpt4-01.lautus.net/ | ipa-hetzner-cpt4-01.lautus.net ] . 
~ dig @ [ http://ipa-hetzner-cpt4-01.lautus.net/ | 
ipa-hetzner-cpt4-01.lautus.net ] -t NS [ http://ipa.lautus.net/ | 
ipa.lautus.net ] 
[ http://ipa.lautus.net/ | ipa.lautus.net ] . 86400 IN NS [ 
http://ipa-hetzner-cpt4-01.lautus.net/ | ipa-hetzner-cpt4-01.lautus.net ] . 







-- 
Pieter Nagel 
Lautus Solutions (Pty) Ltd 
Building 27, The Woodlands, 20 Woodlands Drive, Woodmead, Gauteng 
0832587540 

-- 
Manage your subscription for the Freeipa-users mailing list: 
https://www.redhat.com/mailman/listinfo/freeipa-users 
Go to http://freeipa.org for more info on the project 
BEGIN:VCARD
VERSION:3.0
FN:Evans\, Jacob
N:Evans;Jacob;;;
ADR;TYPE=home,postal,parcel:;;;Harrisburg;PA;17112;USA
TEL;TYPE=cell,voice:717-417-8324
TEL;TYPE=work,voice:717-417-8344
EMAIL;TYPE=internet:em...@jacobdevans.com
URL;TYPE=work:http://www.jacobdevans.com
URL;TYPE=work:http://linkedin.jacobdevans.com
ORG:Jacob D Evans\, Cloud Consultant
TITLE:Owner
REV:2016-01-20T10:08:50Z
UID:3034ae81-f255-4b3c-aff5-2dc73614bc74:64082
END:VCARD
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Still unclear about relation between IPA DNS domain and company DNS domain.

[Pieter Nagel]

On Thu, Dec 8, 2016 at 10:59 AM, Alexander Bokovoy 
wrote:

> It is really simply: your DNS domain named as your Kerberos realm must
> be under your control, one way or another, to allow automatic discovery
> of resources to work.
>

Thanks, this explanation makes it crystal clear. This exact phrasing would
have made the docs much clearer too, IMO.

Setting the realm to the DNS domain that the FreeIPA internal DNS server
serves is just one simple out-of-the box way to get DNS domain named as
your Kerberos realm that is under your control, in other words.

-- 
Pieter Nagel
Lautus Solutions (Pty) Ltd
Building 27, The Woodlands, 20 Woodlands Drive, Woodmead, Gauteng
0832587540
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Still unclear about relation between IPA DNS domain and company DNS domain.

[Alexander Bokovoy]

On to, 08 joulu 2016, Pieter Nagel wrote:

On Wed, Dec 7, 2016 at 3:57 PM, Brian Candler  wrote:


The Kerberos realm always has a corresponding DNS domain, so realm
IPA.LAUTUS.NET has a corresponding DNS domain "ipa.lautus.net".



This is the crux of what I find unclear. The docs make it sound as if the
DNS domain that corresponds to the Kerberos realm needs to be the exact
same DNS domain that the FreeIPA internal DNS is actively managing. But I
get the impression in this thread that the DNS domain that corresponds to
the Kerberos realm just needs to be a DNS domain that belongs to the
organisation using FreeIPA.

It is really simply: your DNS domain named as your Kerberos realm must
be under your control, one way or another, to allow automatic discovery
of resources to work.

This is how Kerberos automatic service discovery is designed to work.

If you are not using Kerberos automatic discovery; if all your KDC
resources are fixed in krb5.conf on all machines, all your SSSD
configurations on all IPA machines are fixed to point to exact servers
with no fallback to automatic service discovery; if you are not using
trust to Active Directory forests, you can ignore that requirement.

In majority of deployments, however, people are relying on automatic
service discovery for multiple reasons or using trust to AD feature.
These deployments must follow the rules defined by those who invented
automatic service discovery and technologies like Active Directory.

Overall, documentation might be too dense on the details, but it is a
balance between giving the necessary details and giving too many
details.


Concrete scenario, I wonder if this will work:

A greenfields deployment, no other kerberos, no Active Directory. Internal
DNS to be int.lautus.net and FreeIPA manages that DNS domain and adds
internal hosts to it as they enroll. Public-facing servers are manually
registered in lautus.net DNS which is hosted elsewhere. But FreeIPA is
installed with realm LAUTUS.NET so it adds _kerberos entries for realm
LAUTUS.NET to int.lautus.net, and I manually copy those entries to
lautus.net, so everone agrees that they belong to the same realm.

The reason I want the realm to be LAUTUS.NET is because it makes more sense
to me that the internal desktops in the subdomain int.lautus.net to enroll
into a realm related to the parent DNS domain, than it makes sense for the
public-facing servers in the parent lautus.net domain enroll into a realm
related to an internal DNS subdomain. Or am I making an issue of a cosmetic
triviality, and it is not all all strange in the kerberos realm to enroll a
server into a realm related to a DNS subdomain it is not part of?

--
Pieter Nagel
Lautus Solutions (Pty) Ltd
Building 27, The Woodlands, 20 Woodlands Drive, Woodmead, Gauteng
0832587540



--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project



--
/ Alexander Bokovoy

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Still unclear about relation between IPA DNS domain and company DNS domain.

[Pieter Nagel]

On Wed, Dec 7, 2016 at 3:57 PM, Brian Candler  wrote:

> The Kerberos realm always has a corresponding DNS domain, so realm
> IPA.LAUTUS.NET has a corresponding DNS domain "ipa.lautus.net".
>

This is the crux of what I find unclear. The docs make it sound as if the
DNS domain that corresponds to the Kerberos realm needs to be the exact
same DNS domain that the FreeIPA internal DNS is actively managing. But I
get the impression in this thread that the DNS domain that corresponds to
the Kerberos realm just needs to be a DNS domain that belongs to the
organisation using FreeIPA.

Concrete scenario, I wonder if this will work:

A greenfields deployment, no other kerberos, no Active Directory. Internal
DNS to be int.lautus.net and FreeIPA manages that DNS domain and adds
internal hosts to it as they enroll. Public-facing servers are manually
registered in lautus.net DNS which is hosted elsewhere. But FreeIPA is
installed with realm LAUTUS.NET so it adds _kerberos entries for realm
LAUTUS.NET to int.lautus.net, and I manually copy those entries to
lautus.net, so everone agrees that they belong to the same realm.

The reason I want the realm to be LAUTUS.NET is because it makes more sense
to me that the internal desktops in the subdomain int.lautus.net to enroll
into a realm related to the parent DNS domain, than it makes sense for the
public-facing servers in the parent lautus.net domain enroll into a realm
related to an internal DNS subdomain. Or am I making an issue of a cosmetic
triviality, and it is not all all strange in the kerberos realm to enroll a
server into a realm related to a DNS subdomain it is not part of?

-- 
Pieter Nagel
Lautus Solutions (Pty) Ltd
Building 27, The Woodlands, 20 Woodlands Drive, Woodmead, Gauteng
0832587540
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Still unclear about relation between IPA DNS domain and company DNS domain.

[Petr Spacek]

On 7.12.2016 14:57, Brian Candler wrote:
> On 07/12/2016 08:58, freeIPA users list wrote:
>> On ke, 07 joulu 2016, List dedicated to discussions about use, configuration
>> and deployment of the IPA server. wrote:
>>> I know the Quick Start Guide and Deployment Recommendations cover this in
>>> depth, but there are still some ambiguities.
>>>
>>> I'm trying to figure out if a company like us, lautus.net should use a DNS
>>> subdomain like ipa.lautus.net for the IPA domain, or not.
>> It is really depending on your deployment details.
>>
>> If you already have some other Kerberized environment in place and you
>> are not going to replace it by FreeIPA, then you need to make sure that
>> new FreeIPA deployment would not conflict with the existing one.
> Or if you think there's a chance you might want to add another Kerberized
> environment later (e.g. "ad.lautus.net")
> 
>>
>>> should continue to be hosted by DNS servers elsewhere that delegate say,
>>> ipa.lautus.net to FreeIPA.
> The question of whether you host ipa.lautus.net DNS (or indeed lautus.net DNS)
> in FreeIPA is a different issue.
> 
> If you're happy with your existing DNS infrastructure, then you can either
> delegate ipa.lautus.net to your FreeIPA servers (with NS records); or run
> FreeIPA without DNS, and simply import the ipa.lautus.net SRV records directly
> into the lautus.net domain.
> 
> Having FreeIPA host the ipa.lautus.net domain means these SRV records are
> populated automatically, but it's not really that hard to add them to an
> existing DNS service.
> 
> OTOH, if you *don't* already have a good authoritative internal DNS service
> with a UI that you like, then you might want to use FreeIPA for this anyway.
> You can easily create extra zones in FreeIPA.
> 
> I would be a bit wary about putting FreeIPA servers out on the public Internet
> though. For one thing, the default config is an open resolver (which you can
> tighten easily enough). I also have a deep distrust of Java, but maybe that's
> just me.

Speaking of DNS, it is just BIND. Configure it accordingly and you should be 
find.

Please note that FreeIPA DNS is not intended as general-purpose DNS:
http://www.freeipa.org/page/DNS#Initial_Considerations

It is tailored for FreeIPA use-cases and might lack special features.


>>> But on the other hand the same doc is full of examples where a Kerberos
>>> realm like EXAMPLE.COM (instead of IPA.EXAMPLE.COM) is used, i.e example
>>> 2.2. of secion 2.3.4. But the same guide also says that the Kerberos realm
>>> should be the same as the ipa DNS domain, just uppercased. So example 2.2.
>>> implies that example.com is running their DNS domain on FreeIPA, for
>>> everything, not just for IPA SRV and TXT entries.
> The Kerberos realm always has a corresponding DNS domain, so realm
> IPA.LAUTUS.NET has a corresponding DNS domain "ipa.lautus.net".
> 
> But with FreeIPA you can still manage hosts called foo.lautus.net or
> bar.int.lautus.net. At worst you'd have some extra [domain_realm] mappings in
> krb5.conf

Yes. Ideally you will be able to add _kerberos TXT records to relevant DNS
domains so explicit mapping will not be necessary.

I will have a look how we can clarify the guide to make this less confusing...

> 
> (Aside: Active Directory is much more fussy, and basically doesn't work if the
> hosts don't have hostnames within the same DNS domain as their kerberos realm
> - and indeed have reverse DNS as well as forward)
> 
>>
>>> And when ipa-client-install is run on somehost.lautus.net, it also defaults
>>> to LAUTUS.NET for Kerberos domain, as if the default expectation is that
>>> your toplevel company DNS name would be your kerberos domain.
> But you can override that.
> 
>>
>>
>>> And when I install a trial IPA server on host ipa-server-1.lautus.net using
>>> "ipa-server-install --setup-dns --realm IPA.LAUTUS.NET --domain
>>> ipa.lautus.net --forwarder=8.8.8.8", and then look at the DNS Zones  in the
>>> Web UI, I see not only ipa.lautus.net, but also lautus, with record "@ NS
>>> ipa-server-1.lautus.net". In other words the IPA server defaults to
>>> thinking it owns the domain above ipa.lautus.net too. Which goes against
>>> 2.3.1 above.
> Interesting. What does "ipa dnszone-find --pkey-only" show?
> 
> It seems like it's created an authoritative zone both for the server's own
> domain (lautus.net if the server is xxx.lautus.net) as well as the realm's
> domain (ipa.lautus.net)
> 
> I don't know why it's doing that. Now I've checked with another system here:
> the hostname is "ipa-1.int.example.com" and the realm is "ipa.example.com",
> and you're right, it is authoritative for both:
> 
>   Zone name: int.example.com.
>   Zone name: ipa.example.com.
> 
> This isn't what I wanted. The int.example.com domain is hosted externally and
> I didn't want to override it. Right now it's hiding all names in
> int.example.com that it doesn't know about.
> 
> I would expect that it's possible to remove this zone, but I'd need to 

Re: [Freeipa-users] Still unclear about relation between IPA DNS domain and company DNS domain.

[Brian Candler]

On 07/12/2016 08:58, freeIPA users list wrote:
On ke, 07 joulu 2016, List dedicated to discussions about use, 
configuration and deployment of the IPA server. wrote:
I know the Quick Start Guide and Deployment Recommendations cover 
this in

depth, but there are still some ambiguities.

I'm trying to figure out if a company like us, lautus.net should use 
a DNS

subdomain like ipa.lautus.net for the IPA domain, or not.

It is really depending on your deployment details.

If you already have some other Kerberized environment in place and you
are not going to replace it by FreeIPA, then you need to make sure that
new FreeIPA deployment would not conflict with the existing one.
Or if you think there's a chance you might want to add another 
Kerberized environment later (e.g. "ad.lautus.net")





should continue to be hosted by DNS servers elsewhere that delegate say,
ipa.lautus.net to FreeIPA.
The question of whether you host ipa.lautus.net DNS (or indeed 
lautus.net DNS) in FreeIPA is a different issue.


If you're happy with your existing DNS infrastructure, then you can 
either delegate ipa.lautus.net to your FreeIPA servers (with NS 
records); or run FreeIPA without DNS, and simply import the 
ipa.lautus.net SRV records directly into the lautus.net domain.


Having FreeIPA host the ipa.lautus.net domain means these SRV records 
are populated automatically, but it's not really that hard to add them 
to an existing DNS service.


OTOH, if you *don't* already have a good authoritative internal DNS 
service with a UI that you like, then you might want to use FreeIPA for 
this anyway. You can easily create extra zones in FreeIPA.


I would be a bit wary about putting FreeIPA servers out on the public 
Internet though. For one thing, the default config is an open resolver 
(which you can tighten easily enough). I also have a deep distrust of 
Java, but maybe that's just me.






But on the other hand the same doc is full of examples where a Kerberos
realm like EXAMPLE.COM (instead of IPA.EXAMPLE.COM) is used, i.e example
2.2. of secion 2.3.4. But the same guide also says that the Kerberos 
realm
should be the same as the ipa DNS domain, just uppercased. So example 
2.2.

implies that example.com is running their DNS domain on FreeIPA, for
everything, not just for IPA SRV and TXT entries.
The Kerberos realm always has a corresponding DNS domain, so realm 
IPA.LAUTUS.NET has a corresponding DNS domain "ipa.lautus.net".


But with FreeIPA you can still manage hosts called foo.lautus.net or 
bar.int.lautus.net. At worst you'd have some extra [domain_realm] 
mappings in krb5.conf


(Aside: Active Directory is much more fussy, and basically doesn't work 
if the hosts don't have hostnames within the same DNS domain as their 
kerberos realm - and indeed have reverse DNS as well as forward)




And when ipa-client-install is run on somehost.lautus.net, it also 
defaults

to LAUTUS.NET for Kerberos domain, as if the default expectation is that
your toplevel company DNS name would be your kerberos domain.

But you can override that.




And when I install a trial IPA server on host ipa-server-1.lautus.net 
using

"ipa-server-install --setup-dns --realm IPA.LAUTUS.NET --domain
ipa.lautus.net --forwarder=8.8.8.8", and then look at the DNS Zones  
in the
Web UI, I see not only ipa.lautus.net, but also lautus, with record 
"@ NS

ipa-server-1.lautus.net". In other words the IPA server defaults to
thinking it owns the domain above ipa.lautus.net too. Which goes against
2.3.1 above.

Interesting. What does "ipa dnszone-find --pkey-only" show?

It seems like it's created an authoritative zone both for the server's 
own domain (lautus.net if the server is xxx.lautus.net) as well as the 
realm's domain (ipa.lautus.net)


I don't know why it's doing that. Now I've checked with another system 
here: the hostname is "ipa-1.int.example.com" and the realm is 
"ipa.example.com", and you're right, it is authoritative for both:


  Zone name: int.example.com.
  Zone name: ipa.example.com.

This isn't what I wanted. The int.example.com domain is hosted 
externally and I didn't want to override it. Right now it's hiding all 
names in int.example.com that it doesn't know about.


I would expect that it's possible to remove this zone, but I'd need to 
test that doesn't stop other hosts called xxx.int.example.com from joining.



Yes and no. What you see with "@ NS ..." is a glue record -- you are
supposed to have a glue record for IPA domain in the upstream domain,
this is how domain delegation works in DNS world.
Aside: technically that's not a glue record. A glue record is an A or 
 record when the NS record points to a host within the subdomain 
which is being delegated. It is to solve the chicken-and-egg situation 
of how to contact a nameserver for a domain before you've contacted a 
nameserver for the domain.


In your case, if you already have working DNS for lautus.net, then you 
don't want FreeIPA to be authoritative for 

Re: [Freeipa-users] Still unclear about relation between IPA DNS domain and company DNS domain.

[Pieter Nagel]

Thanks, that helps a lot.

Yes and no. What you see with "@ NS ..." is a glue record -- you are
> supposed to have a glue record for IPA domain in the upstream domain,
> this is how domain delegation works in DNS world.


Except what i saw was the other way around. The FreeIPA server has an
NSrecord claiming that it is authoritative the parent domain, but its
parent domain is hosted at dnsmadeeasy:

~ dig @8.8.8.8  -t NS lautus.net
lautus.net. 86399 IN NS ns15.dnsmadeeasy.com.
~ dig @8.8.8.8  -t NS ipa.lautus.net
ipa.lautus.net. 86399 IN NS ipa-hetzner-cpt4-01.lautus.net.

But as far as the FreeIPA DNS is concerned, it is authoritative for
everything:

~ dig @ipa-hetzner-cpt4-01.lautus.net  -t NS lautus.net
lautus.net. 86400 IN NS ipa-hetzner-cpt4-01.lautus.net.
~ dig @ipa-hetzner-cpt4-01.lautus.net  -t NS ipa.lautus.net
ipa.lautus.net. 86400 IN NS ipa-hetzner-cpt4-01.lautus.net.







-- 
Pieter Nagel
Lautus Solutions (Pty) Ltd
Building 27, The Woodlands, 20 Woodlands Drive, Woodmead, Gauteng
0832587540
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Still unclear about relation between IPA DNS domain and company DNS domain.

[freeIPA users list]

On ke, 07 joulu 2016, List dedicated to discussions about use, configuration 
and deployment of the IPA server. wrote:

I know the Quick Start Guide and Deployment Recommendations cover this in
depth, but there are still some ambiguities.

I'm trying to figure out if a company like us, lautus.net should use a DNS
subdomain like ipa.lautus.net for the IPA domain, or not.

It is really depending on your deployment details.

If you already have some other Kerberized environment in place and you
are not going to replace it by FreeIPA, then you need to make sure that
new FreeIPA deployment would not conflict with the existing one.

This is the rule dictated by the way how Kerberos realms are organized
and particularly so for Active Directory deployments as that one has
even more serious limitations towards what can be part of the Active
Directory domain/forest structure.


On the one hand 2.3.1 of the Linux Domain Identity, Authentication, and
Policy Guide says "The integrated DNS server provided by IdM is not
designed to be used as a general-purpose DNS server. It only supports
features related to IdM deployment and maintenance". OK, so lautus.net
should continue to be hosted by DNS servers elsewhere that delegate say,
ipa.lautus.net to FreeIPA.

You definitely can use IPA DNS server for the purpose of hosting your
primary DNS servers if all features provided by IPA DNS server cover
your needs. As I said, it really depends on your specific deployment
considerations. The guide is trying to hint that all things that ISC
BIND supports aren't necessarily will be working in the IPA version --
like a split-horizon feature -- so it is not a general-purpose DNS
server in that sense.


But on the other hand the same doc is full of examples where a Kerberos
realm like EXAMPLE.COM (instead of IPA.EXAMPLE.COM) is used, i.e example
2.2. of secion 2.3.4. But the same guide also says that the Kerberos realm
should be the same as the ipa DNS domain, just uppercased. So example 2.2.
implies that example.com is running their DNS domain on FreeIPA, for
everything, not just for IPA SRV and TXT entries.

It assumes for the most of configurations that you are setting up
FreeIPA as the only Kerberos environment, thus talking about
EXAMPLE.COM.


And when ipa-client-install is run on somehost.lautus.net, it also defaults
to LAUTUS.NET for Kerberos domain, as if the default expectation is that
your toplevel company DNS name would be your kerberos domain.

Yes, as with *any* decent Kerberos implementation.


And when I install a trial IPA server on host ipa-server-1.lautus.net using
"ipa-server-install --setup-dns --realm IPA.LAUTUS.NET --domain
ipa.lautus.net --forwarder=8.8.8.8", and then look at the DNS Zones  in the
Web UI, I see not only ipa.lautus.net, but also lautus, with record "@ NS
ipa-server-1.lautus.net". In other words the IPA server defaults to
thinking it owns the domain above ipa.lautus.net too. Which goes against
2.3.1 above.

Yes and no. What you see with "@ NS ..." is a glue record -- you are
supposed to have a glue record for IPA domain in the upstream domain,
this is how domain delegation works in DNS world.


The docs say I should manually add SRV records to a parent DNS domain like
lautus.net if IPA does not manage that with integrated DNS. But then what's
the point of the integrated DNS, if the docs say the integrated DNS is not
supposed to be used as a general-purpose DNS server? In that case,
everybody is always gonna need to manually add SRV records every time they
add a IPA replication peer anyway, unless they run their company DNS on the
integrated DNS server, which the docs seem to discourage?

See above.

--
/ Alexander Bokovoy

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] Still unclear about relation between IPA DNS domain and company DNS domain.

[List dedicated to discussions about use, configuration and deployment of the IPA server.]

I know the Quick Start Guide and Deployment Recommendations cover this in
depth, but there are still some ambiguities.

I'm trying to figure out if a company like us, lautus.net should use a DNS
subdomain like ipa.lautus.net for the IPA domain, or not.

On the one hand 2.3.1 of the Linux Domain Identity, Authentication, and
Policy Guide says "The integrated DNS server provided by IdM is not
designed to be used as a general-purpose DNS server. It only supports
features related to IdM deployment and maintenance". OK, so lautus.net
should continue to be hosted by DNS servers elsewhere that delegate say,
ipa.lautus.net to FreeIPA.

But on the other hand the same doc is full of examples where a Kerberos
realm like EXAMPLE.COM (instead of IPA.EXAMPLE.COM) is used, i.e example
2.2. of secion 2.3.4. But the same guide also says that the Kerberos realm
should be the same as the ipa DNS domain, just uppercased. So example 2.2.
implies that example.com is running their DNS domain on FreeIPA, for
everything, not just for IPA SRV and TXT entries.

And when ipa-client-install is run on somehost.lautus.net, it also defaults
to LAUTUS.NET for Kerberos domain, as if the default expectation is that
your toplevel company DNS name would be your kerberos domain.

And when I install a trial IPA server on host ipa-server-1.lautus.net using
"ipa-server-install --setup-dns --realm IPA.LAUTUS.NET --domain
ipa.lautus.net --forwarder=8.8.8.8", and then look at the DNS Zones  in the
Web UI, I see not only ipa.lautus.net, but also lautus, with record "@ NS
ipa-server-1.lautus.net". In other words the IPA server defaults to
thinking it owns the domain above ipa.lautus.net too. Which goes against
2.3.1 above.

The docs say I should manually add SRV records to a parent DNS domain like
lautus.net if IPA does not manage that with integrated DNS. But then what's
the point of the integrated DNS, if the docs say the integrated DNS is not
supposed to be used as a general-purpose DNS server? In that case,
everybody is always gonna need to manually add SRV records every time they
add a IPA replication peer anyway, unless they run their company DNS on the
integrated DNS server, which the docs seem to discourage?

-- 
Pieter Nagel
Lautus Solutions (Pty) Ltd
Building 27, The Woodlands, 20 Woodlands Drive, Woodmead, Gauteng
0832587540
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project