Hi, Thanks for the reply. Any Idea when will the GSSAPI-updating bug fix get to RHEL 7?
Thanks again, John On Mon, Jul 27, 2015 at 5:30 PM Alexander Bokovoy <aboko...@redhat.com> wrote: > On Mon, 27 Jul 2015, John Stein wrote: > >Hi, > > > >I consider deploying IPA in my organization.The environment is > disconnected > >from the internet.I have some concerns I'm not sure how to resolve. > > > >The environment consists mostly of windows servers (thousands) and > >workstations (ten thousand) managed by AD (CORP.COM). There is also a > small > >linux environment (up to a thousand servers) that are currently not > >centerally managed (user-wise). > > > >I want to utilize IPA and the AD trust feature to implement SSO. > > > >I'd like to have a sub-domain ran by IPA (LINUX.CORP.COM). > > > >Because the environment is windows dominated, the AD is used as the > >authoritative DNS server for all forward and reverse lookup zones. > > > >The AD trust requires that both the IPA and AD will be authoritative over > >their respective forward and reverse lookup zones. However, the linux and > No. We require that *some entity* is responsible for the zones. If you > put everything in AD DNS, fine, but then you are responsible for manual > update of the zone records and that all specific records are there. > > >windows servers are spread across multiple subnets without any big-scale > >logic, therefore it is not practical to create a reverse lookup zone for > >each subnet in the IPA server as those subnets contain both linux and > >windows machines. > You cannot have machines from IPA and AD domains in the same DNS zone at > the same time. A/AAAA records of those IPA and AD machines must belong > to different DNS zones. > > This is basic requirement of Active Directory deployment -- each AD > domain is responsible for at least one DNS zone and you cannot have > machines from two different AD domains in the same DNS zone. > > >I came up with some solutions: > > > >1) Have only the AD as a DNS server and give up on ipa-client-install and > >automatic client registration. > Totally unrelated to how you handle DNS zones. ipa-client-install does > not require you to allow creation of DNS records. It can sufficiently > work with a configuration where a DNS record for the host is > pre-created. > > >2) DNS synchronization between IPA and AD. > Unrelated and is not recommended. In DNS lexicon only a single entity is > responsible for the single DNS zone. IPA cannot be authoritative at the > same time as AD. (Neither we support IPA being a slave for other DNS > server). > > >3) Have the IPA manage the forward zone (linux.corp.com), and have the > >clients update its own A record automatically upon ipa-client-install, > >while having the AD manage the reverse zones (A or B class subnets) with > me > >creating the PTR records manually. The IPA will be configured as a > >conditional forwarder for linux.corp.com, while the AD will be configured > >as a global forwarder in the IPA server. > That would work. There is a bug in nsupdate tool that prevents you from > GSSAPI-updating PTR records (over AD trust) so going with manual PTR > records would work. > > You need to make sure AD has no policy to periodically remove PTR > records for Linux machines. > > -- > / 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