Re: [Freeipa-devel] [PATCH] 0108 Add support for compatibility tree for trusted domain users
On 07/18/2013 05:45 PM, Alexander Bokovoy wrote:
> On Tue, 16 Jul 2013, Jakub Hrozek wrote:
>>> >>+if self.enable_compat:
>>> >>+self.step("Enabling trusted domains support for older clients
>>> via Schema Compatibility plugin",
>>> >
>>> >
>>> > Nitpick: all the other steps begin with lowercased
>>> > letter. Only this one is uppercased, which makes the
>>> > tool output looks inconsistent:
>>> >[15/21]: adding special DNS service records
>>> >[16/21]: Enabling trusted domains support for older clients via Schema
>>> Compatibility plugin
>>> >[17/21]: restarting Directory Server to take MS PAC and LDAP plugins
>>> changes into account
>>> Thanks. Lowcased it.
>>>
>>> Updated patch is attached.
>>
>> Maybe it would be nice if some native English speaker read the man page
>> change as well. To me it sounds like there are some articles missing. But
>> the code works correctly and sets up the SSSD compat attributes during
>> install when told to.
>>
>> Ack from me, however.
> Thanks.
>
> When this patch will be pushed to master, you will need slapi-nis built
> with my patch in order to actually provide older clients with trusted
> domains' users.
>
> The patch to slapi-nis uncovers dead-lock issue in slapi-nis because its
> operation means SSSD will be contacted as part of serving LDAP query
> over compat tree. SSSD then will want to obtain a TGT using
> host/ipa.server principal to be able to contact AD DC. Our KDC driver will
> modify host entry in the main LDAP tree which will cause post-op
> callback triggered in slapi-nis. At this point the callback will
> encounter that global slapi-nis write lock is already taken by the
> original query and will dead-lock.
>
> However, IPA patch can be applied safely because it only configures
> slapi-nis trees to serve trusted domains' users over compat tree and if
> there is no code in slapi-nis to do so, no dead-lock will be triggered.
Pushed to master.
I left the ticket open as tracker until we also fix the slapi-nis part.
Martin
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0108 Add support for compatibility tree for trusted domain users
On Tue, 16 Jul 2013, Jakub Hrozek wrote:
>>+if self.enable_compat:
>>+self.step("Enabling trusted domains support for older clients via
Schema Compatibility plugin",
>
>
> Nitpick: all the other steps begin with lowercased
> letter. Only this one is uppercased, which makes the
> tool output looks inconsistent:
>[15/21]: adding special DNS service records
>[16/21]: Enabling trusted domains support for older clients via Schema
Compatibility plugin
>[17/21]: restarting Directory Server to take MS PAC and LDAP plugins changes
into account
Thanks. Lowcased it.
Updated patch is attached.
Maybe it would be nice if some native English speaker read the man page
change as well. To me it sounds like there are some articles missing. But
the code works correctly and sets up the SSSD compat attributes during
install when told to.
Ack from me, however.
Thanks.
When this patch will be pushed to master, you will need slapi-nis built
with my patch in order to actually provide older clients with trusted
domains' users.
The patch to slapi-nis uncovers dead-lock issue in slapi-nis because its
operation means SSSD will be contacted as part of serving LDAP query
over compat tree. SSSD then will want to obtain a TGT using
host/ipa.server principal to be able to contact AD DC. Our KDC driver will
modify host entry in the main LDAP tree which will cause post-op
callback triggered in slapi-nis. At this point the callback will
encounter that global slapi-nis write lock is already taken by the
original query and will dead-lock.
However, IPA patch can be applied safely because it only configures
slapi-nis trees to serve trusted domains' users over compat tree and if
there is no code in slapi-nis to do so, no dead-lock will be triggered.
--
/ Alexander Bokovoy
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0108 Add support for compatibility tree for trusted domain users
On Tue, Jul 16, 2013 at 04:22:01PM +0300, Alexander Bokovoy wrote:
> On Tue, 16 Jul 2013, Jakub Hrozek wrote:
> >the patch looks mostly good to me. I only have some small nitpicks:
> >
> >>+++ b/install/tools/man/ipa-adtrust-install.1
> >>@@ -106,6 +106,24 @@ The password of the user with administrative
> >>privileges for this IPA server. Wil
> >> .TP
> >> The credentials of the admin user will be used to obtain Kerberos ticket
> >> before configuring cross-realm trusts support and afterwards, to ensure
> >> that the ticket contains MS-PAC information required to actually add a
> >> trust with Active Directory domain via 'ipa trust-add --type=ad' command.
> >> .TP
> >>+\fB\-\-enable\-compat\fR
> >>+Enables support for trusted domains users for old clients through Schema
> >>Compatibility plugin.
> >>+SSSD supports trusted domains natively starting with version 1.9 platform.
> >>For platforms that
> >
> > The word "platform"
> > looks a little
> > extra here to me.
> Removed. I initially had statement there to talk about Linux and
> non-Linux platforms, this word slipped when I edited platform talk out.
>
> >>+lack SSSD or run older SSSD version one needs to use this option. When
> >>enabled, slapi\-nis package
> >>+needs to be installed and schema\-compat\-plugin will be configured to
> >>provide lookup of
> >>+users and groups from trusted domains via SSSD on IPA server. These users
> >>and groups will be
> >>+available under \fBcn=users,cn=compat,$SUFFIX\fR and
> >>\fBcn=groups,cn=compat,$SUFFIX\fR trees.
> >>+SSSD will normalize names of users and groups to lower case.
> >>+.IP
> >>+In addition to providing these users and groups through the compat tree,
> >>this option enables
> >>+authentication over LDAP for trusted domain users with DN under compat
> >>tree, i.e. using bind DN
> >>+\fBuid=administrator@ad.domain,cn=users,cn=compat,$SUFFIX\fR. This
> >>authentication is related
> >>+to PAM stack using '\fBsystem\-auth\fR' PAM service. If you have disabled
> >>HBAC rule 'allow_all', then
> >>+make sure there is special service called '\fBsystem\-auth\fR' created and
> >>HBAC rule to allow
> >>+access to anyone to this rule on IPA masters is added. Please note that
> >>system-auth PAM service
> >>+is not used directly by any other application, therefore it is safe to
> >>create one specifically
> >>+to support trusted domain users via compatibility path.
> >
> >The last sentence wasn't really clear to me, were you suggesting to
> >create a special PAM service?
> I refactored the statement.
>
> system-auth is a PAM service (/etc/pam.d/system-auth) provided by pam
> RPM package. You don't need to create it as it is created and maintained
> by the system (and authconfig).
>
> What this sentence talks about is that PAM authentication means also
> verifying HBAC rules. If you have disable 'allow_all' HBAC rule, then
> for all PAM services there should be HBAC rule that allows access to it
> if that is required. As in case of trusted AD users they don't exist in
> LDAP, we cannot really refer to them in HBAC rules so we only can have
> an HBAC rule that allows 'all' to access 'system-auth' service on 'ipa
> masters' host group.
>
> system-auth PAM service is not used by any other application directly.
> Instead, their own PAM services include system-auth through PAM stack.
> That's why I selected system-auth -- enabling HBAC rules to access it
> does not compromise any other service because of the way how PAM
> stacking works -- access to an app is granted through PAM service name
> that application runs against. I.e. ssh runs against /etc/pam.d/ssh, so
> HBAC rule would need to be created against 'ssh' service. /etc/pam.d/ssh
> is including system-auth through PAM stack and system-auth is configured
> to use pam_sss but 'system-auth' as service name is never seen or used
> by anyone through PAM API.
>
I know how system-auth works and how PAM services work, but it wasn't
clear to me what you were suggesting in the man page :) Now it's much
clearer, thank you.
> >>+if self.enable_compat:
> >>+self.step("Enabling trusted domains support for older clients
> >>via Schema Compatibility plugin",
> >
> >
> > Nitpick: all the other steps begin with lowercased
> > letter. Only this one is uppercased, which makes the
> > tool output looks inconsistent:
> >[15/21]: adding special DNS service records
> >[16/21]: Enabling trusted domains support for older clients via Schema
> >Compatibility plugin
> >[17/21]: restarting Directory Server to take MS PAC and LDAP plugins changes
> >into account
> Thanks. Lowcased it.
>
> Updated patch is attached.
Maybe it would be ni
Re: [Freeipa-devel] [PATCH] 0108 Add support for compatibility tree for trusted domain users
On Tue, 16 Jul 2013, Jakub Hrozek wrote:
the patch looks mostly good to me. I only have some small nitpicks:
+++ b/install/tools/man/ipa-adtrust-install.1
@@ -106,6 +106,24 @@ The password of the user with administrative privileges
for this IPA server. Wil
.TP
The credentials of the admin user will be used to obtain Kerberos ticket
before configuring cross-realm trusts support and afterwards, to ensure that
the ticket contains MS-PAC information required to actually add a trust with
Active Directory domain via 'ipa trust-add --type=ad' command.
.TP
+\fB\-\-enable\-compat\fR
+Enables support for trusted domains users for old clients through Schema
Compatibility plugin.
+SSSD supports trusted domains natively starting with version 1.9 platform. For
platforms that
The word "platform"
looks a little
extra here to me.
Removed. I initially had statement there to talk about Linux and
non-Linux platforms, this word slipped when I edited platform talk out.
+lack SSSD or run older SSSD version one needs to use this option. When
enabled, slapi\-nis package
+needs to be installed and schema\-compat\-plugin will be configured to provide
lookup of
+users and groups from trusted domains via SSSD on IPA server. These users and
groups will be
+available under \fBcn=users,cn=compat,$SUFFIX\fR and
\fBcn=groups,cn=compat,$SUFFIX\fR trees.
+SSSD will normalize names of users and groups to lower case.
+.IP
+In addition to providing these users and groups through the compat tree, this
option enables
+authentication over LDAP for trusted domain users with DN under compat tree,
i.e. using bind DN
+\fBuid=administrator@ad.domain,cn=users,cn=compat,$SUFFIX\fR. This
authentication is related
+to PAM stack using '\fBsystem\-auth\fR' PAM service. If you have disabled HBAC
rule 'allow_all', then
+make sure there is special service called '\fBsystem\-auth\fR' created and
HBAC rule to allow
+access to anyone to this rule on IPA masters is added. Please note that
system-auth PAM service
+is not used directly by any other application, therefore it is safe to create
one specifically
+to support trusted domain users via compatibility path.
The last sentence wasn't really clear to me, were you suggesting to
create a special PAM service?
I refactored the statement.
system-auth is a PAM service (/etc/pam.d/system-auth) provided by pam
RPM package. You don't need to create it as it is created and maintained
by the system (and authconfig).
What this sentence talks about is that PAM authentication means also
verifying HBAC rules. If you have disable 'allow_all' HBAC rule, then
for all PAM services there should be HBAC rule that allows access to it
if that is required. As in case of trusted AD users they don't exist in
LDAP, we cannot really refer to them in HBAC rules so we only can have
an HBAC rule that allows 'all' to access 'system-auth' service on 'ipa
masters' host group.
system-auth PAM service is not used by any other application directly.
Instead, their own PAM services include system-auth through PAM stack.
That's why I selected system-auth -- enabling HBAC rules to access it
does not compromise any other service because of the way how PAM
stacking works -- access to an app is granted through PAM service name
that application runs against. I.e. ssh runs against /etc/pam.d/ssh, so
HBAC rule would need to be created against 'ssh' service. /etc/pam.d/ssh
is including system-auth through PAM stack and system-auth is configured
to use pam_sss but 'system-auth' as service name is never seen or used
by anyone through PAM API.
+if self.enable_compat:
+self.step("Enabling trusted domains support for older clients via
Schema Compatibility plugin",
Nitpick: all the other steps begin with lowercased
letter. Only this one is uppercased, which makes the
tool output looks inconsistent:
[15/21]: adding special DNS service records
[16/21]: Enabling trusted domains support for older clients via Schema
Compatibility plugin
[17/21]: restarting Directory Server to take MS PAC and LDAP plugins changes
into account
Thanks. Lowcased it.
Updated patch is attached.
--
/ Alexander Bokovoy
>From bbfb7620de54c8b55886f3e7a616096afa9ce58e Mon Sep 17 00:00:00 2001
From: Alexander Bokovoy
Date: Mon, 15 Jul 2013 19:13:50 +0300
Subject: [PATCH] ipa-adtrust-install: configure compatibility tree to serve
trusted domain users
Enables support for trusted domains users for old clients through Schema
Compatibility plugin. SSSD supports trusted domains natively starting with
version 1.9 platform. For platforms that lack SSSD or run older SSSD version
one needs to use this option. When en
Re: [Freeipa-devel] [PATCH] 0108 Add support for compatibility tree for trusted domain users
On Mon, Jul 15, 2013 at 08:14:52PM +0300, Alexander Bokovoy wrote: > Hi! > > Attached patch allows to enable serving trusted domain users and groups > through Schema Compatibilty plugin. > > The patch only does FreeIPA master configuration settings, the real work > is done by the changes to slapi-nis plugin (in a separate email). > > Since ipa-adtrust-install can safely be run multiple times, one can > re-run it on the IPA master to enable serving old clients, by specifying > > ipa-adtrust-install --enable-compat > > or answering 'yes' to the interactive question. > > I have expanded man page for ipa-adtrust-install to cover this option. > > Once enabled, following is possible: > --- > # ldapsearch -Y GSSAPI -b cn=compat,dc=vda,dc=li '(&(cn=domain > adm...@ad.lan)(objectclass=posixgroup))' > SASL/GSSAPI authentication started > SASL username: ad...@vda.li > SASL SSF: 56 > SASL data security layer installed. > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: (&(cn=domain adm...@ad.lan)(objectclass=posixgroup)) > # requesting: ALL > # > > # domain adm...@ad.lan, groups, compat, vda.li > dn: cn=domain adm...@ad.lan,cn=groups,cn=compat,dc=vda,dc=li > objectClass: posixGroup > objectClass: extensibleObject > objectClass: top > gidNumber: 1442800512 > memberUid: uid=administra...@ad.lan,cn=users,cn=compat,dc=vda,dc=li > schema-compat-origin: sssd > ipaNTSecurityIdentifier: S-1-5-21-3502988750-125904550-3683905862-512 > cn: domain adm...@ad.lan > > # search result > search: 4 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 > --- > > and for users: > --- > # ldapsearch -Y GSSAPI -b cn=compat,dc=vda,dc=li > # '(uid=administra...@ad.lan)' > SASL/GSSAPI authentication started > SASL username: ad...@vda.li > SASL SSF: 56 > SASL data security layer installed. > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: (uid=administra...@ad.lan) > # requesting: ALL > # > > # administra...@ad.lan, users, compat, vda.li > dn: uid=administra...@ad.lan,cn=users,cn=compat,dc=vda,dc=li > objectClass: posixAccount > objectClass: extensibleObject > objectClass: top > gecos: Administrator > cn: Administrator > uidNumber: 1442800500 > gidNumber: 1442800500 > homeDirectory: / > schema-compat-origin: sssd > ipaNTSecurityIdentifier: S-1-5-21-3502988750-125904550-3683905862-500 > uid: administra...@ad.lan > > # search result > search: 4 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 > > > Currently PAM authentication is a bit broken due to yet-to-hunt bug in > SSSD or my environment (Jakub was unable to reproduce it) where SSSD > thinks that AD DC is offline during authentication step. > > However, if you don't hit the bug, you can check authentication by doing > following bind and entering a password for your AD administrator: > # ldapsearch -D uid=administra...@ad.lan,cn=users,cn=compat,dc=vda,dc=li \ > -W -x -C -a always -b dc=vda,dc=li '(uid=admin)' > > The bind operation needs to be performed _after_ user lookup. > > All these commands are only examples, I'm currently working on seeing > how to configure pam_ldap/nss_ldap to use compat plugin this way. > -- > / Alexander Bokovoy Hi, the patch looks mostly good to me. I only have some small nitpicks: > +++ b/install/tools/man/ipa-adtrust-install.1 > @@ -106,6 +106,24 @@ The password of the user with administrative privileges > for this IPA server. Wil > .TP > The credentials of the admin user will be used to obtain Kerberos ticket > before configuring cross-realm trusts support and afterwards, to ensure that > the ticket contains MS-PAC information required to actually add a trust with > Active Directory domain via 'ipa trust-add --type=ad' command. > .TP > +\fB\-\-enable\-compat\fR > +Enables support for trusted domains users for old clients through Schema > Compatibility plugin. > +SSSD supports trusted domains natively starting with version 1.9 platform. > For platforms that The word "platform" looks a little extra here to me. > +lack SSSD or run older SSSD version one needs to use this option. When > enabled, slapi\-nis package > +needs to be installed and schema\-compat\-plugin will be configured to > provide lookup of > +users and groups from trusted domains via SSSD on IPA server. These users > and groups will be > +available under \fBcn=users,cn=compat,$SUFFIX\fR and > \fBcn=gr
