On Sat, 04 Apr 2015, Coy Hile wrote:
Hi all,
What purpose does this package serve? The way I’ve done Kerberos
between Active Directory and AD, the trust was always one way
(outgoing): the MIT realm is authoritative and AD “shadow accounts”
were mapped to ‘real’ principals via the alternateSecurityID attribute.
Looking at what freeipa-server-trust-ad installs, it appears the
dependencies installed are around letting someone a bidirectional trust
(or at least let the AD users be authoritative). If one wants to setup
his trust in the way I described, all he really needs to do in MIT land
is create
krbtgt/AD.REALM@MIT.REALM
in the MIT Realm.
Is there a ‘supported’ way to do something similar with FreeIPA? Time
to break out kadmin.local -x ipa-setup-override-restrictions? Or would
that not drop the principal in the right place in the LDAP tree?
Let me answer this mail as Simo didn't answer a key part of it and I feel
with a growing number of subscribers and people looking at the archives
it might bring a lot of misunderstanding.
FreeIPA implements cross-forest trust to AD in terms of AD protocols.
Part of it is Kerberos cross-realm trust, right, but not only that. In
particular, FreeIPA side uses Samba to implement required NetLogon, LSA,
and SAMR interfaces required by AD to validate the trust. This causes AD
DCs to think that FreeIPA realm is a proper AD forest, not just
'external Kerberos realm'. As result, a proper set of trusted domain
objects is created in AD and can be used by FreeIPA to perform lookups
of AD users and groups and a proper information about internal FreeIPA
realm structure is conveyed to AD DCs, including details of DNS
ownership which are crucial to decide what KDCs are responsible in
handling specific hosts and subdomains.
We are deliberately not supporting external Kerberos trust with Active
Directory because we believe this has very little value in an
enterprise environment without additional means to deliver such topology
details and SID to name and name to SID translation for Kerberos
principals on each Windows client. Instead of focusing on a manual
maintenance of such mappings on Windows side which would have required
us to spend time on implementing software for Windows with obvious
limitations due to need to rewrite half of LSA stack on Windows to
support all features we want (look at pGINA story and how they failed
with it), we chose to concentrate on improving Linux interoperability
based on the protocols Microsoft has to support itself to make sure
their own Windows clients would work.
Right now FreeIPA only supports looking up AD users and groups and is
not being able to provide a fully-compliant service so that AD DCs could
look up FreeIPA users and groups. This results in Windows machines not
being able to resolve SIDs of FreeIPA users and groups to human-friendly
names and therefore inability to assign permissions in Windows user
interfaces in Security tabs to allow or deny certain access rights to
resources on Windows machines. We are working on implementing remaining
components so that it will be possible to use FreeIPA users on Windows
side too.
Even with those components we are not going to implement all features
required to present ourselves as Active Directory so no direct join of
Windows machines to FreeIPA is planned. Instead, we are continuing to
pursue an approach where FreeIPA is seen by AD as another AD forest and
trust relationship is used to provide access to resources in both
forests.
Samba usage in FreeIPA, thus, is limited to being a 'NT4 member server',
using LDAP store of FreeIPA to keep users, groups, and trusted domains'
accounts. Samba's Active Directory Domain Controller mode is not used
but we are working on making sure FreeIPA and Samba AD DC are capable to
trust each other as cross-forest trust and, thus, Samba AD DC would be
used to enroll Windows machines while Linux machines would be enrolled
to FreeIPA. We are at a stage where there is a hope to demonstrate a
working solution during SambaXP conference next month and have all the
bits and pieces merged upstream Samba.
A somewhat detailed overview how FreeIPA trust to AD works is available
in the design section of http://www.freeipa.org/page/V4/One-way_trust --
what is described as 'FreeIPA v3.0 and v3.3' is applicable to v4.1 too,
we plan to complete the changes by v4.2.
--
/ 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
