On Tue, 28 May 2013, Dmitri Pal wrote:
On 05/28/2013 04:29 PM, Alexander Bokovoy wrote:
On Tue, 28 May 2013, Dmitri Pal wrote:
On 05/28/2013 03:48 PM, Alexander Bokovoy wrote:
On Tue, 28 May 2013, Dmitri Pal wrote:
On 05/28/2013 07:50 AM, Alexander Bokovoy wrote:
Hi,
http://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts
= Overview =
Since version 3.0 FreeIPA supports cross-realm trusts with Active
Directory. In order to allow AD users to utilize services on IPA
clients, up to date version of SSSD should be configured at the IPA
client. In case it is not possible to install and configure SSSD >
1.09,
Active Directory users cannot access services on IPA clients.
This feature is designed to bridge the gap and provide minimal
compatibility level that allows to log-in to IPA clients for AD
users.
IPA clients will be able to use any reasonable nss_ldap/pam_ldap/sssd
version.
= Use Cases =
Access to IPA client machine resources for AD users in case IPA
client
cannot utilize up to date version of SSSD with native support for IPA
cross-realm trusts.
= Design=
Since IPA client is configured with the use of older SSSD or
nss_ldap/pam_ldap, all work should be performed at the IPA master.
Primary design decision is to provide a separate LDAP tree,
similar to
compat tree, that has following features:
* information about both IPA and AD users can be queried;
* it ispossible to enumerate members of IPA and AD groups;
* authentication bind to IPA LDAP as AD users should automatically
* trigger obtaining ticket from AD DC; in case TGT is obtained,
* authentication bind should be treated as successful.
From a client perspective, use of the separate LDAP tree is viewed as
traditional nss_ldap/pam_ldap configuration.
Proposed base for the LDAP tree:
'''cn=users,cn=trust-accounts,dc=example,dc=com'''
= Implementation =
# IPA server sets SSSD configuration to 'ipa_server_mode = true' on
install or upgrade
# ipa-adtrust-install configures additional directory server
plugin to
serve trusted domains tree
# Directory server plugin uses getpwnam_r(), getgrnam_r() and
related
calls to obtain information about AD user. For IPA users the
information is fetched directly from the LDAP.
# IPA KDC database driver adds MS-PAC information into ticket
granting
ticket for host/fqdn@REALM principal of IPA master. This is required
to allow SSSD on IPA master to authenticate against AD using
host/fqdn@REALM principal.
For SSSD design see
https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode
= Feature Management =
=== UI ===
The feature is transparent and not exposed in UI
=== CLI ===
The feature is not directly exposed in CLI.
IPA idrange management is expanded to specify idrange type (IPA
local,
AD trust, AD with winsync, IPA trust, ..) to affect the way how AD
users
SIDs are mapped to POSIX IDs.
= Major configuration options and enablement =
sssd.conf will have 'ipa_server_mode = true' set for IPA master.
= Replication =
No effect on replication. Since directory server plugin is only
configured when ipa-adtrust-install is run, IPA masters may opt out
from
serving AD clients.
= Updates and Upgrades =
During upgrade of IPA master, sssd.conf should be updated to set
'ipa_server_mode = true'.
= Dependencies =
Depends on SSSD implementing IPA server mode (sssd 1.10.x)
= External Impact =
https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode
= Backup and Restore =
No external configuration files are affected
= Test Plan =
Testing the feature will require following:
# Configure IPA to serve AD trusts
# Establish trust with AD domain
# Configure a client to use nss_ldap/pam_ldap against AD-compatible
tree
# Attempt to log-in to the client as AD user
= RFE Author =
[[User:Ab|ab]] ([[User talk:Ab|talk]])
Can you please explain how the older SSSD or other UNIX versions would
use Kerberos for authentication?
pam_krb5 should work as it is, as well as older SSSD, since any AD user
attempting to connect using GSSAPI to IPA services will have
cross-realm
TGT issued for us by the trusting AD DC prior to that attempt.
The whole idea was to make sure for old clients these users will look
like normal users, via nss_ldap/SSSD.
We still will need to configure principal mapping in /etc/krb5.conf
like
we do for AD users with trusts.
I thought we would have to issue some patch for client to switch the
clients from using Kerberos for authentication to using LDAP.
No need to. pam_ldap would go through LDAP bind automatically, that's
why the proposal talks about attempting to obtain TGT in place of a
user
instead of proxying such LDAP bind back to AD DC. This would require us
enforcing clear password bind over TLS/SSL but it is simpler to
achieve.
I am missing something. How a simple kinit would work?
Can you please describe the sequence and workflow?
I'm talking about the case when AD user logs in into IPA client using
PuTTY from Windows machine. In such case there is already service ticket
and cross-realm TGT available.
For kinit on IPA client all what is needed is /etc/krb5.conf
configuration that forces to talk to AD DC for principals in AD realm.
It can be done via SRV records in DNS or manually in /etc/krb5.conf.
For example, on the machine I'm writing this email I added manual
routing to my VMs with AD and IPA to /etc/krb5.conf and I'm able to do
following:
# klist
klist: No credentials cache found (ticket cache
DIR::/run/user/0/krb5cc/tkt)
# kinit administra...@ad.lan
Password for administra...@ad.lan: Warning: Your password will expire
in 2 days on Пт. 31 мая 2013 07:29:10
# klist
Ticket cache: DIR::/run/user/0/krb5cc/tktP0IiKO
Default principal: administra...@ad.lan
Valid starting Expires Service principal
28.05.2013 23:24:44 29.05.2013 09:24:44 krbtgt/ad....@ad.lan
renew until 04.06.2013 23:24:44
# kvno HTTP/red.bird.clone@BIRD.CLONE
HTTP/red.bird.clone@BIRD.CLONE: kvno = 2
# klist
Ticket cache: DIR::/run/user/0/krb5cc/tktP0IiKO
Default principal: administra...@ad.lan
Valid starting Expires Service principal
28.05.2013 23:24:44 29.05.2013 09:24:44 krbtgt/ad....@ad.lan
renew until 04.06.2013 23:24:44
28.05.2013 23:25:45 29.05.2013 09:24:44 krbtgt/bird.cl...@ad.lan
renew until 04.06.2013 23:24:44
28.05.2013 23:26:42 29.05.2013 09:24:44 HTTP/red.bird.clone@BIRD.CLONE
renew until 04.06.2013 23:24:44
This is exactly the problem I am try to get to.
Let us take CentOS 6.3 machine and configure SSSD against IPA. It has
absolutely no knowledge about AD. This is the whole point.
But AD users should be able to walk to the console and authenticate. The
flow will be:
User -> SSSD -> kerberos library -> KDC -> ???? -> SSSD on IPA -> AD
But there is no design for such flow. And IMO it is too much.
For this use case LDAP-based authentication has to be configured.
For any remote login we can rely on Kerberos authentication.
For over console login we cannot rely on Kerberos authentication without
explicit help from either KDC or SSSD.
What we can do in our KDB driver is to force KDC to issue KDC referral
for users from trusted domains, rewriting the realm and redirecting to
AD DC. This is how AD DC performs in a forest when a client talks to
non-root DC in request of a ticket for a service in a trusted domain.
However, I think it could be a good target for 3.4.
What you are suggesting here is a sort of "split brain solution" that we
did not recommend in the past are we going to change out assessment of
this approach?
No. What I suggested did not include direct console logins.
So to summarize we are talking about the case:
a) Legacy/UNIX systems are configured to authenticate/joined to IPA and
do not know about AD
b) User from AD walks to the console and uses his name and password
He needs to be authenticated. How?
See above. KDC needs to recognize this user is from a trusted domain (by
the domain's realm) and issue a referral to AD DCs which handle it.
--
/ Alexander Bokovoy
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
