Hello,
I wonder if your problems with SSL are really caused by problems with reverse
name resolution ... I think that SSL libraries usually don't care about PTR
records. Which SSL libraries do you use? Do you use server's IP address in
certificate subject field?
Regarding the DNS:
First of all, I would recommend to replace conditional forwarder on Windows
side by normal DNS delegation from Windows to FreeIPA: Create NS+A record on
Windows side, do not configure any forwarding from Windows to FreeIPA.
Conditional forwarding usually creates more problems than it solves.
Regarding the reverse zone:
As you said, the correct approach is to have only one authoritative source for
reverse zone - i.e. serve reverse zone only from Windows OR FreeIPA.
Do I understand correctly that you want to allow Windows & non-Windows clients
to update own records in the same reverse zone?
It could be a tricky ... What are your security requirements?
Do you require Kerberos authentication for each update?
Do you have a FreeIPA-Windows trust in place?
Obviously, the simplest thing is to not require update signing :-)
Now seriously: BIND9 could allow you to specify that authenticated clients
from REALM1 and REALM2 can do any update to PTR records in particular reverse
zone, but it could be tricky to configure. (See match type 'wildcard'
mentioned at
ftp://ftp.isc.org/isc/bind9/9.9.3-P1/doc/arm/Bv9ARM.ch06.html#dynamic_update_policies.)
If you need more granular control over each update then match type 'external'
with your own ACL-daemon could be the way to go.
I have no idea how DNS updates from trusted realms are processed on Windows
side, it is possible that you can configure Windows to trust updates from
FreeIPA realm (if there is a trust between Windows and FreeIPA).
Please let us know if you need any further assistance.
Petr^2 Spacek
On 9.8.2013 15:29, Armstrong, Kenneth Lawrence wrote:
Hi all.
We have IdM set up in a test environment as a subdomain of our Windows domain
(so, linux.example.com) with integrated DNS on the IdM server and forwarders
going to the AD servers on example.com. We have on the Windows DNS server the
IdM server set up as a conditional forwarder for linux.example.com and an A
record in its DNS for the IdM server.
However, on example.com, we have other subdomains that need to be able to
communicate with the linux.example.com domain, such as tier1.example.com,
tier2.example.com, etc.
What we are trying to figure out is the whole PTR reverse zone bit, mainly due
to the fact that the linux.example.com and the example.com reside on the same
subnets (and unfortunately, this is a very large network and we can't change
that).
For instance, say we have a system at test1.tier2.example.com that needs to
make an SSL connection to another system on testA.linux.example.com. The SSL
handshake will fail since the PTR record will resolve to a different domain
than what the client is expecting, again due to the fact that the reverse zone
is on the same subnet. The reverse zone on the Windows DNS server would only
contain PTR records for all of the domains except linux.example.com, and the
IdM server would only contain PTR records for just the linux.example.com
systems.
So, obviously, we would not want the IdM server to have a reverse zone, and
have it rely on the reverse zone on the Windows DNS server. Other than
manually entering PTR records for all Linux systems under linux.example.com to
the reverse zone file on the Windows DNS server, is there another way that we
can properly accomplish this? Would replicating the reverse zone file from the
Windows server to the IdM server take care of that?
Thanks.
-Kenny
--
Petr^2 Spacek
_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
