On Tue, 2015-08-25 at 15:19 +0200, Petr Spacek wrote: > On 1.8.2015 21:19, John Stein wrote: > > Hi, > > > > Thanks for the reply. Any Idea when will the GSSAPI-updating bug fix get to > > RHEL 7? > > You can watch the progress here: > https://bugzilla.redhat.com/show_bug.cgi?id=1214827 > > Unfortunately fixing this bug will not be sufficient for your particular > scenario. FreeIPA does not allow ordinary host/ principals used by client > machines (not to be confused with FreeIPA servers) to get tickets for AD > Kerberos realms. > > It effectively means that nsupdate will properly detect the AD realm and > generate correct request but the request will be refused because the client > will not be able to get ticket. > > I.e. you will have to resort to manual PTR record update OR convince > Alexander/Simo that allowing host/ principals from FreeIPA realm to get > tickets for AD realm is not a security issue :-)
There is no security issue per se, host/ principals can get tickets just fine but we do not attach a PAC here, and AD may refuse to operate w/o a MS-PAC. Please open a RFE if this is breaking operations. We'll need to decide how to assign a SID to hosts but that's the only "security" issue that needs to be solved. Simo. > Petr^2 Spacek > > > Thanks again, > > John > > > > On Mon, Jul 27, 2015 at 5:30 PM Alexander Bokovoy <[email protected]> > > 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 > -- Simo Sorce * Red Hat, Inc * New York -- 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
