On 15.1.2014 08:52, Alexander Bokovoy wrote:
On Wed, 15 Jan 2014, Petr Spacek wrote:
On 15.1.2014 06:49, Alexander Bokovoy wrote:
On Tue, 14 Jan 2014, Nordgren, Bryce L -FS wrote:
Both AD integration solutions we have (synchronization and
cross-forest domain trusts) assume having higher level access
privileges at the time integration is set up.
My problem here is that I'm too ignorable. :) There's over 15000 users
in our AD; I'm in Montana, the admins are in DC. Worse, our agency's AD
is being absorbed into the next level up the chain (Forest Service AD
is going to become a part of the overall USDA AD). Then I'm an even
smaller fish, relatively speaking.
I'm unaware of other
mechanisms that would give you the same flexibility and level of
privilege separation between the AD and IPA domains.
?? The current solution using the LDAP interface to AD (and a
metadirectory to merge "external users") provides privilege separation
and the flexibility to add external users. I don't need more; I just
need it to be less clunky. It weakens security, of course, as my AD
password is stored in various plaintext configuration files for each
application needing binding credentials to search for users in AD. I
also have an index to which files contain my password, as it forms a
"password-change-checklist" which I need to run thru every 60 days.
You got me confused on this. You cannot run FreeIPA in such mode because
FreeIPA is not a client-only solution, it is server and client solution.
If you want to stay with an approach where AD is the data source, IPA
server part will not be usable to you and what left is SSSD on the
client side.
SSSD is capable to work as an AD client.
However, if you want all your Linux machines to be enrolled to IPA, they
cannot be enrolled to AD at the same time, this will not work.
Alexander and Jakub, would it be possible to enroll a machine as IPA client
and then manually add AD domain do SSSD configuration?
I guess that this configuration theoretically allows to use one set of users
("external" users) from IPA and also use another set of users ("internal"
users) from AD at the same time. The obvious disadvantage is that you have
to carefully type username@DOMAIN.
This naturally does 'separation' of external and internal users because AD
would know nothing about IPA users and the other way around.
Could it work? I'm just theorizing ... :-)
You can setup SSSD to use multiple sources and you can setup krb5.conf
to serve multiple realms. What you cannot do is to mix and match within
the same DNS namespace over multiple Kerberos realms without being
prepared to things not working now and then.
Suppose you have example.com DNS namespace and four machines:
dc.example.com, win.example.com, lnx.example.com, and ipa.example.com.
They are AD DC, Windows machine, Linux server, and IPA master.
dc.example.com would host Active Directory and own example.com DNS
namespace, including DNS server which hosts example.com zone. Kerberos
realm for AD will be EXAMPLE.COM
ipa.example.com would host IPA master: LDAP server, KDC for IPA realm,
DNS server for example.com with IPA entries. You'd need to define
different Kerberos realm name since you'll need to have different
configurations in krb5.conf on your lnx.example.com. Let's say, it is
IPA-EXAMPLE.COM.
win.example.com is enrolled to AD. It consults dc.example.com for DNS
and Kerberos on logon. It will attempt to get Kerberos tickets to any
service in .example.com through Active Directory domain controller
dc.example.com.
lnx.example.com is enrolled to IPA. You can either manually set up
configuration to point to ipa.example.com everywhere where needed
(through /etc/hosts, /etc/krb5.conf, /etc/sssd/sssd.conf, ...) or point
/etc/resolv.conf to ipa.example.com and assume that split-brain DNS will
work when communicating with win.example.com.
lnx.example.com could be configured to have a second domain in
/etc/sssd/sssd.conf that points to dc.example.com. You need to create a
computer object for lnx.example.com in AD, you need to fetch service
key for host/lnx.example....@example.com from AD, and later
maintain it refresh over time but it is possible.
The very same is needed for IPA side. I think we already had discussion
on this list how to setup SSSD with two different domains pointing to
different Kerberos realms last week but in that case there were
non-overlapping DNS namespaces for both Kerberos realms.
Now, when an SSH client (PuTTY) on win.example.com will want to connect
to lnx.example.com, AD DC on dc.example.com would issue Kerberos ticket
to service host/lnx.example....@example.com based on own AD credentials.
One will be able to login with this ticket to lnx.example.com but
nothing from IPA side will apply here: sudo and HBAC rules don't know
anything about these users and authentication source.
In such situation what I question is the need for IPA deployment at all.
If all users will be coming from AD and they are not visible to IPA and
not using IPA features, why to spend time with FreeIPA at all?
I think that the requirement is to have two distinct sets of users while you
don't have control over one set (AD users) but you have to manage the other
set (IPA users) somehow.
--
Petr^2 Spacek
_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
