Re: [Freeipa-devel] [PATCH] 0060 Ensure ipa-adtrust-install is run as admin user
On Wed, 18 Jul 2012, Simo Sorce wrote: On Wed, 2012-07-18 at 16:19 +0300, Alexander Bokovoy wrote: On Wed, 18 Jul 2012, Rob Crittenden wrote: >Alexander Bokovoy wrote: >>On Tue, 17 Jul 2012, Rob Crittenden wrote: >>>Alexander Bokovoy wrote: On Fri, 13 Jul 2012, Alexander Bokovoy wrote: >Hi, > >when adding AD trusts support, we need to ensure we have valid kerberos >ticket of the user from 'admins' group or otherwise appropriate ACIs >will not be granted. > >This patch introduces a check for that. We already check if >ipa-adtrust-install is run by root so this complements existing checks. > >https://fedorahosted.org/freeipa/ticket/2815 After discussing on IRC with Simo and Rob, we came to conclusion that it is possible to switch to LDAPI and autobind feature of dirsrv for authentication and remove requirement for Directory Manager credentials altogether. Updated patch makes use of LDAPI + autobind under root privileges to map automatically to Directory Manager privileges in dirsrv. Additionally it ensures we have Kerberos credentials to fetch keytab with CIFS service key. Service._ldap_mod() is extended to switch to autobind when self.ldapi is set to True and we are running as root. For those interested in why ACIError is mapped to 'outdated Kerberos credentials' error message, this is because we'll get ACIError for 'ipa user-show ' command when authenticated by the Kerberos credentials for in a default ccache only when Kerberos credentials are stale -- either belong to a user that was removed or to a previous IPA install that was wiped before reinstalling. The latter is how I discovered this case. :) >>> >>>I think that this should raise an exception if one tries to use ldapi, >>>doesn't provide the DM password and is not root. Otherwise it won't >>>authenticate at all. >>This is not exactly true. >> >>$ id >>uid=75701(abokovoy) gid=75701(abokovoy) groups=75701(abokovoy) >>context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 >> >>$ ldapsearch -vvv -H ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket '*' >> >/dev/null >>ldap_initialize( ldapi://%2Fvar%2Frun%2Fslapd-IPA-LOCAL.socket/??base ) >>SASL/EXTERNAL authentication started >>ldap_sasl_interactive_bind_s: Inappropriate authentication (48) >> additional info: SASL EXTERNAL bind requires an SSL connection >> >>$ ldapsearch -vvv -Y GSSAPI -H >>ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket '*' >/dev/null >>ldap_initialize( ldapi://%2Fvar%2Frun%2Fslapd-IPA-LOCAL.socket/??base ) >>SASL/GSSAPI authentication started >>SASL username: abokovoy@IPA.LOCAL >>SASL SSF: 56 >>SASL data security layer installed. >>filter: (objectclass=*) >>requesting: * >>So GSSAPI auth works with LDAPI access. I can simply enforce -Y GSSAPI >>when non-root and no dm_password regardless of self.ldapi, this would >>extend previously available logic to following: >> >>- ldapi: use -H ldapi://url instead of -h hostname >>- dm_password: add Directory Manager auth >>- root without dm_password: use autobind >>- non-root without dm_password: use GSSAPI >> >>>In reality, I think all this service code always runs as root, so it >>>may be a moot point, but this code is kinda convoluted. >>Yep. >> > >Sorry, I didn't mean this in general, but this code is going to >result in no auth being used which is going to fail. So rather than >failing with some no auth error we either enforce that Service is >executed as root or raise an exception in this auth code. In other >words, if we know something isn't going to work before we try it, we >should fail with a more friendly error. What the code did before in such case (no DM, non-root, non-ldapi) is to use -Y GSSAPI. So this forces to try GSSAPI auth already. My latest patch (-2) expands this also to (no DM, non-root, ldapi) case. However, one case is not covered yet: no DM, root, non-ldapi. We either can try -Y GSSAPI here as well or raise exception. I'd prefer the former. When in doubt always try GSSAPI please. This gets us back to my patch (-1) because -auth_parms = ["-Y", "GSSAPI"] +auth_params = [] +if not (os.getegid() == 0 and self.ldapi): +auth_parms = ["-Y", "GSSAPI"] covers both (no DM, root, non-ldapi) and (no DM, non-root, non-ldapi) -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0060 Ensure ipa-adtrust-install is run as admin user
On Wed, 2012-07-18 at 16:19 +0300, Alexander Bokovoy wrote: > On Wed, 18 Jul 2012, Rob Crittenden wrote: > >Alexander Bokovoy wrote: > >>On Tue, 17 Jul 2012, Rob Crittenden wrote: > >>>Alexander Bokovoy wrote: > On Fri, 13 Jul 2012, Alexander Bokovoy wrote: > >Hi, > > > >when adding AD trusts support, we need to ensure we have valid kerberos > >ticket of the user from 'admins' group or otherwise appropriate ACIs > >will not be granted. > > > >This patch introduces a check for that. We already check if > >ipa-adtrust-install is run by root so this complements existing checks. > > > >https://fedorahosted.org/freeipa/ticket/2815 > After discussing on IRC with Simo and Rob, we came to conclusion that it > is possible to switch to LDAPI and autobind feature of dirsrv for > authentication and remove requirement for Directory Manager credentials > altogether. > > Updated patch makes use of LDAPI + autobind under root privileges to map > automatically to Directory Manager privileges in dirsrv. Additionally it > ensures we have Kerberos credentials to fetch keytab with CIFS service > key. > > Service._ldap_mod() is extended to switch to autobind when self.ldapi is > set to True and we are running as root. > > For those interested in why ACIError is mapped to 'outdated Kerberos > credentials' error message, this is because we'll get ACIError for 'ipa > user-show ' command when authenticated by the Kerberos credentials > for in a default ccache only when Kerberos credentials are > stale -- > either belong to a user that was removed or to a previous IPA install > that was wiped before reinstalling. The latter is how I discovered > this case. :) > >>> > >>>I think that this should raise an exception if one tries to use ldapi, > >>>doesn't provide the DM password and is not root. Otherwise it won't > >>>authenticate at all. > >>This is not exactly true. > >> > >>$ id > >>uid=75701(abokovoy) gid=75701(abokovoy) groups=75701(abokovoy) > >>context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 > >> > >>$ ldapsearch -vvv -H ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket '*' > >> >/dev/null > >>ldap_initialize( ldapi://%2Fvar%2Frun%2Fslapd-IPA-LOCAL.socket/??base ) > >>SASL/EXTERNAL authentication started > >>ldap_sasl_interactive_bind_s: Inappropriate authentication (48) > >> additional info: SASL EXTERNAL bind requires an SSL connection > >> > >>$ ldapsearch -vvv -Y GSSAPI -H > >>ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket '*' >/dev/null > >>ldap_initialize( ldapi://%2Fvar%2Frun%2Fslapd-IPA-LOCAL.socket/??base ) > >>SASL/GSSAPI authentication started > >>SASL username: abokovoy@IPA.LOCAL > >>SASL SSF: 56 > >>SASL data security layer installed. > >>filter: (objectclass=*) > >>requesting: * > >>So GSSAPI auth works with LDAPI access. I can simply enforce -Y GSSAPI > >>when non-root and no dm_password regardless of self.ldapi, this would > >>extend previously available logic to following: > >> > >>- ldapi: use -H ldapi://url instead of -h hostname > >>- dm_password: add Directory Manager auth > >>- root without dm_password: use autobind > >>- non-root without dm_password: use GSSAPI > >> > >>>In reality, I think all this service code always runs as root, so it > >>>may be a moot point, but this code is kinda convoluted. > >>Yep. > >> > > > >Sorry, I didn't mean this in general, but this code is going to > >result in no auth being used which is going to fail. So rather than > >failing with some no auth error we either enforce that Service is > >executed as root or raise an exception in this auth code. In other > >words, if we know something isn't going to work before we try it, we > >should fail with a more friendly error. > What the code did before in such case (no DM, non-root, non-ldapi) is to > use -Y GSSAPI. So this forces to try GSSAPI auth already. My latest > patch (-2) expands this also to (no DM, non-root, ldapi) case. > > However, one case is not covered yet: no DM, root, non-ldapi. We either > can try -Y GSSAPI here as well or raise exception. I'd prefer the > former. When in doubt always try GSSAPI please. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0060 Ensure ipa-adtrust-install is run as admin user
On Wed, 18 Jul 2012, Rob Crittenden wrote: Alexander Bokovoy wrote: On Tue, 17 Jul 2012, Rob Crittenden wrote: Alexander Bokovoy wrote: On Fri, 13 Jul 2012, Alexander Bokovoy wrote: Hi, when adding AD trusts support, we need to ensure we have valid kerberos ticket of the user from 'admins' group or otherwise appropriate ACIs will not be granted. This patch introduces a check for that. We already check if ipa-adtrust-install is run by root so this complements existing checks. https://fedorahosted.org/freeipa/ticket/2815 After discussing on IRC with Simo and Rob, we came to conclusion that it is possible to switch to LDAPI and autobind feature of dirsrv for authentication and remove requirement for Directory Manager credentials altogether. Updated patch makes use of LDAPI + autobind under root privileges to map automatically to Directory Manager privileges in dirsrv. Additionally it ensures we have Kerberos credentials to fetch keytab with CIFS service key. Service._ldap_mod() is extended to switch to autobind when self.ldapi is set to True and we are running as root. For those interested in why ACIError is mapped to 'outdated Kerberos credentials' error message, this is because we'll get ACIError for 'ipa user-show ' command when authenticated by the Kerberos credentials for in a default ccache only when Kerberos credentials are stale -- either belong to a user that was removed or to a previous IPA install that was wiped before reinstalling. The latter is how I discovered this case. :) I think that this should raise an exception if one tries to use ldapi, doesn't provide the DM password and is not root. Otherwise it won't authenticate at all. This is not exactly true. $ id uid=75701(abokovoy) gid=75701(abokovoy) groups=75701(abokovoy) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 $ ldapsearch -vvv -H ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket '*' >/dev/null ldap_initialize( ldapi://%2Fvar%2Frun%2Fslapd-IPA-LOCAL.socket/??base ) SASL/EXTERNAL authentication started ldap_sasl_interactive_bind_s: Inappropriate authentication (48) additional info: SASL EXTERNAL bind requires an SSL connection $ ldapsearch -vvv -Y GSSAPI -H ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket '*' >/dev/null ldap_initialize( ldapi://%2Fvar%2Frun%2Fslapd-IPA-LOCAL.socket/??base ) SASL/GSSAPI authentication started SASL username: abokovoy@IPA.LOCAL SASL SSF: 56 SASL data security layer installed. filter: (objectclass=*) requesting: * So GSSAPI auth works with LDAPI access. I can simply enforce -Y GSSAPI when non-root and no dm_password regardless of self.ldapi, this would extend previously available logic to following: - ldapi: use -H ldapi://url instead of -h hostname - dm_password: add Directory Manager auth - root without dm_password: use autobind - non-root without dm_password: use GSSAPI In reality, I think all this service code always runs as root, so it may be a moot point, but this code is kinda convoluted. Yep. Sorry, I didn't mean this in general, but this code is going to result in no auth being used which is going to fail. So rather than failing with some no auth error we either enforce that Service is executed as root or raise an exception in this auth code. In other words, if we know something isn't going to work before we try it, we should fail with a more friendly error. What the code did before in such case (no DM, non-root, non-ldapi) is to use -Y GSSAPI. So this forces to try GSSAPI auth already. My latest patch (-2) expands this also to (no DM, non-root, ldapi) case. However, one case is not covered yet: no DM, root, non-ldapi. We either can try -Y GSSAPI here as well or raise exception. I'd prefer the former. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0060 Ensure ipa-adtrust-install is run as admin user
Alexander Bokovoy wrote: On Tue, 17 Jul 2012, Rob Crittenden wrote: Alexander Bokovoy wrote: On Fri, 13 Jul 2012, Alexander Bokovoy wrote: Hi, when adding AD trusts support, we need to ensure we have valid kerberos ticket of the user from 'admins' group or otherwise appropriate ACIs will not be granted. This patch introduces a check for that. We already check if ipa-adtrust-install is run by root so this complements existing checks. https://fedorahosted.org/freeipa/ticket/2815 After discussing on IRC with Simo and Rob, we came to conclusion that it is possible to switch to LDAPI and autobind feature of dirsrv for authentication and remove requirement for Directory Manager credentials altogether. Updated patch makes use of LDAPI + autobind under root privileges to map automatically to Directory Manager privileges in dirsrv. Additionally it ensures we have Kerberos credentials to fetch keytab with CIFS service key. Service._ldap_mod() is extended to switch to autobind when self.ldapi is set to True and we are running as root. For those interested in why ACIError is mapped to 'outdated Kerberos credentials' error message, this is because we'll get ACIError for 'ipa user-show ' command when authenticated by the Kerberos credentials for in a default ccache only when Kerberos credentials are stale -- either belong to a user that was removed or to a previous IPA install that was wiped before reinstalling. The latter is how I discovered this case. :) I think that this should raise an exception if one tries to use ldapi, doesn't provide the DM password and is not root. Otherwise it won't authenticate at all. This is not exactly true. $ id uid=75701(abokovoy) gid=75701(abokovoy) groups=75701(abokovoy) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 $ ldapsearch -vvv -H ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket '*' >/dev/null ldap_initialize( ldapi://%2Fvar%2Frun%2Fslapd-IPA-LOCAL.socket/??base ) SASL/EXTERNAL authentication started ldap_sasl_interactive_bind_s: Inappropriate authentication (48) additional info: SASL EXTERNAL bind requires an SSL connection $ ldapsearch -vvv -Y GSSAPI -H ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket '*' >/dev/null ldap_initialize( ldapi://%2Fvar%2Frun%2Fslapd-IPA-LOCAL.socket/??base ) SASL/GSSAPI authentication started SASL username: abokovoy@IPA.LOCAL SASL SSF: 56 SASL data security layer installed. filter: (objectclass=*) requesting: * So GSSAPI auth works with LDAPI access. I can simply enforce -Y GSSAPI when non-root and no dm_password regardless of self.ldapi, this would extend previously available logic to following: - ldapi: use -H ldapi://url instead of -h hostname - dm_password: add Directory Manager auth - root without dm_password: use autobind - non-root without dm_password: use GSSAPI In reality, I think all this service code always runs as root, so it may be a moot point, but this code is kinda convoluted. Yep. Sorry, I didn't mean this in general, but this code is going to result in no auth being used which is going to fail. So rather than failing with some no auth error we either enforce that Service is executed as root or raise an exception in this auth code. In other words, if we know something isn't going to work before we try it, we should fail with a more friendly error. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0060 Ensure ipa-adtrust-install is run as admin user
On Wed, 18 Jul 2012, Alexander Bokovoy wrote: On Tue, 17 Jul 2012, Rob Crittenden wrote: Alexander Bokovoy wrote: On Fri, 13 Jul 2012, Alexander Bokovoy wrote: Hi, when adding AD trusts support, we need to ensure we have valid kerberos ticket of the user from 'admins' group or otherwise appropriate ACIs will not be granted. This patch introduces a check for that. We already check if ipa-adtrust-install is run by root so this complements existing checks. https://fedorahosted.org/freeipa/ticket/2815 After discussing on IRC with Simo and Rob, we came to conclusion that it is possible to switch to LDAPI and autobind feature of dirsrv for authentication and remove requirement for Directory Manager credentials altogether. Updated patch makes use of LDAPI + autobind under root privileges to map automatically to Directory Manager privileges in dirsrv. Additionally it ensures we have Kerberos credentials to fetch keytab with CIFS service key. Service._ldap_mod() is extended to switch to autobind when self.ldapi is set to True and we are running as root. For those interested in why ACIError is mapped to 'outdated Kerberos credentials' error message, this is because we'll get ACIError for 'ipa user-show ' command when authenticated by the Kerberos credentials for in a default ccache only when Kerberos credentials are stale -- either belong to a user that was removed or to a previous IPA install that was wiped before reinstalling. The latter is how I discovered this case. :) I think that this should raise an exception if one tries to use ldapi, doesn't provide the DM password and is not root. Otherwise it won't authenticate at all. This is not exactly true. $ id uid=75701(abokovoy) gid=75701(abokovoy) groups=75701(abokovoy) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 $ ldapsearch -vvv -H ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket '*' >/dev/null ldap_initialize( ldapi://%2Fvar%2Frun%2Fslapd-IPA-LOCAL.socket/??base ) SASL/EXTERNAL authentication started ldap_sasl_interactive_bind_s: Inappropriate authentication (48) additional info: SASL EXTERNAL bind requires an SSL connection $ ldapsearch -vvv -Y GSSAPI -H ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket '*' >/dev/null ldap_initialize( ldapi://%2Fvar%2Frun%2Fslapd-IPA-LOCAL.socket/??base ) SASL/GSSAPI authentication started SASL username: abokovoy@IPA.LOCAL SASL SSF: 56 SASL data security layer installed. filter: (objectclass=*) requesting: * So GSSAPI auth works with LDAPI access. I can simply enforce -Y GSSAPI when non-root and no dm_password regardless of self.ldapi, this would extend previously available logic to following: - ldapi: use -H ldapi://url instead of -h hostname - dm_password: add Directory Manager auth - root without dm_password: use autobind - non-root without dm_password: use GSSAPI In reality, I think all this service code always runs as root, so it may be a moot point, but this code is kinda convoluted. Yep. Here is updated patch. -- / Alexander Bokovoy >From 81b1e0305ac8ad3516bb7bcaeb13999480e0f14f Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Fri, 13 Jul 2012 18:12:48 +0300 Subject: [PATCH 2/5] Ensure ipa-adtrust-install is run with Kerberos ticket for admin user When setting up AD trusts support, ipa-adtrust-install utility needs to be run as: - root, for performing Samba configuration and using LDAPI/autobind - kinit-ed IPA admin user, to ensure proper ACIs are granted to fetch keytab As result, we can get rid of Directory Manager credentials in ipa-adtrust-install https://fedorahosted.org/freeipa/ticket/2815 --- install/tools/ipa-adtrust-install | 42 +++ install/tools/man/ipa-adtrust-install.1 |3 --- ipaserver/install/adtrustinstance.py| 21 ipaserver/install/service.py| 15 +-- 4 files changed, 55 insertions(+), 26 deletions(-) diff --git a/install/tools/ipa-adtrust-install b/install/tools/ipa-adtrust-install index 6678018e6346d75d5042894cfb833d38079d3f21..f367d5b2b516bd411bce9275ff299eb3ffdf6bf9 100755 --- a/install/tools/ipa-adtrust-install +++ b/install/tools/ipa-adtrust-install @@ -37,8 +37,6 @@ log_file_name = "/var/log/ipaserver-install.log" def parse_options(): parser = IPAOptionParser(version=version.VERSION) -parser.add_option("-p", "--ds-password", dest="dm_password", - sensitive=True, help="directory manager password") parser.add_option("-d", "--debug", dest="debug", action="store_true", default=False, help="print debugging information") parser.add_option("--ip-address", dest="ip_address", @@ -86,6 +84,30 @@ def read_netbios_name(netbios_default): return netbios_name +def ensure_kerberos_admin_rights(api): +try: +ctx = krbV.default_context() +ccache = ctx.default_ccache() +principal = ccache.principal() +api.Backend.ldap2.connect(ccache.na
Re: [Freeipa-devel] [PATCH] 0060 Ensure ipa-adtrust-install is run as admin user
On Tue, 17 Jul 2012, Rob Crittenden wrote: Alexander Bokovoy wrote: On Fri, 13 Jul 2012, Alexander Bokovoy wrote: Hi, when adding AD trusts support, we need to ensure we have valid kerberos ticket of the user from 'admins' group or otherwise appropriate ACIs will not be granted. This patch introduces a check for that. We already check if ipa-adtrust-install is run by root so this complements existing checks. https://fedorahosted.org/freeipa/ticket/2815 After discussing on IRC with Simo and Rob, we came to conclusion that it is possible to switch to LDAPI and autobind feature of dirsrv for authentication and remove requirement for Directory Manager credentials altogether. Updated patch makes use of LDAPI + autobind under root privileges to map automatically to Directory Manager privileges in dirsrv. Additionally it ensures we have Kerberos credentials to fetch keytab with CIFS service key. Service._ldap_mod() is extended to switch to autobind when self.ldapi is set to True and we are running as root. For those interested in why ACIError is mapped to 'outdated Kerberos credentials' error message, this is because we'll get ACIError for 'ipa user-show ' command when authenticated by the Kerberos credentials for in a default ccache only when Kerberos credentials are stale -- either belong to a user that was removed or to a previous IPA install that was wiped before reinstalling. The latter is how I discovered this case. :) I think that this should raise an exception if one tries to use ldapi, doesn't provide the DM password and is not root. Otherwise it won't authenticate at all. This is not exactly true. $ id uid=75701(abokovoy) gid=75701(abokovoy) groups=75701(abokovoy) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 $ ldapsearch -vvv -H ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket '*' >/dev/null ldap_initialize( ldapi://%2Fvar%2Frun%2Fslapd-IPA-LOCAL.socket/??base ) SASL/EXTERNAL authentication started ldap_sasl_interactive_bind_s: Inappropriate authentication (48) additional info: SASL EXTERNAL bind requires an SSL connection $ ldapsearch -vvv -Y GSSAPI -H ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket '*' >/dev/null ldap_initialize( ldapi://%2Fvar%2Frun%2Fslapd-IPA-LOCAL.socket/??base ) SASL/GSSAPI authentication started SASL username: abokovoy@IPA.LOCAL SASL SSF: 56 SASL data security layer installed. filter: (objectclass=*) requesting: * So GSSAPI auth works with LDAPI access. I can simply enforce -Y GSSAPI when non-root and no dm_password regardless of self.ldapi, this would extend previously available logic to following: - ldapi: use -H ldapi://url instead of -h hostname - dm_password: add Directory Manager auth - root without dm_password: use autobind - non-root without dm_password: use GSSAPI In reality, I think all this service code always runs as root, so it may be a moot point, but this code is kinda convoluted. Yep. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0060 Ensure ipa-adtrust-install is run as admin user
Alexander Bokovoy wrote: On Fri, 13 Jul 2012, Alexander Bokovoy wrote: Hi, when adding AD trusts support, we need to ensure we have valid kerberos ticket of the user from 'admins' group or otherwise appropriate ACIs will not be granted. This patch introduces a check for that. We already check if ipa-adtrust-install is run by root so this complements existing checks. https://fedorahosted.org/freeipa/ticket/2815 After discussing on IRC with Simo and Rob, we came to conclusion that it is possible to switch to LDAPI and autobind feature of dirsrv for authentication and remove requirement for Directory Manager credentials altogether. Updated patch makes use of LDAPI + autobind under root privileges to map automatically to Directory Manager privileges in dirsrv. Additionally it ensures we have Kerberos credentials to fetch keytab with CIFS service key. Service._ldap_mod() is extended to switch to autobind when self.ldapi is set to True and we are running as root. For those interested in why ACIError is mapped to 'outdated Kerberos credentials' error message, this is because we'll get ACIError for 'ipa user-show ' command when authenticated by the Kerberos credentials for in a default ccache only when Kerberos credentials are stale -- either belong to a user that was removed or to a previous IPA install that was wiped before reinstalling. The latter is how I discovered this case. :) I think that this should raise an exception if one tries to use ldapi, doesn't provide the DM password and is not root. Otherwise it won't authenticate at all. In reality, I think all this service code always runs as root, so it may be a moot point, but this code is kinda convoluted. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0060 Ensure ipa-adtrust-install is run as admin user
On Fri, 13 Jul 2012, Alexander Bokovoy wrote: Hi, when adding AD trusts support, we need to ensure we have valid kerberos ticket of the user from 'admins' group or otherwise appropriate ACIs will not be granted. This patch introduces a check for that. We already check if ipa-adtrust-install is run by root so this complements existing checks. https://fedorahosted.org/freeipa/ticket/2815 After discussing on IRC with Simo and Rob, we came to conclusion that it is possible to switch to LDAPI and autobind feature of dirsrv for authentication and remove requirement for Directory Manager credentials altogether. Updated patch makes use of LDAPI + autobind under root privileges to map automatically to Directory Manager privileges in dirsrv. Additionally it ensures we have Kerberos credentials to fetch keytab with CIFS service key. Service._ldap_mod() is extended to switch to autobind when self.ldapi is set to True and we are running as root. For those interested in why ACIError is mapped to 'outdated Kerberos credentials' error message, this is because we'll get ACIError for 'ipa user-show ' command when authenticated by the Kerberos credentials for in a default ccache only when Kerberos credentials are stale -- either belong to a user that was removed or to a previous IPA install that was wiped before reinstalling. The latter is how I discovered this case. :) -- / Alexander Bokovoy >From 7e4216272fffe55a8f87c51c418895fe6b4dbd73 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Fri, 13 Jul 2012 18:12:48 +0300 Subject: [PATCH 2/2] Ensure ipa-adtrust-install is run with Kerberos ticket for admin user When setting up AD trusts support, ipa-adtrust-install utility needs to be run as: - root, for performing Samba configuration and using LDAPI/autobind - kinit-ed IPA admin user, to ensure proper ACIs are granted to fetch keytab As result, we can get rid of Directory Manager credentials in ipa-adtrust-install https://fedorahosted.org/freeipa/ticket/2815 --- install/tools/ipa-adtrust-install | 42 +++ install/tools/man/ipa-adtrust-install.1 |3 --- ipaserver/install/adtrustinstance.py| 21 ipaserver/install/service.py| 15 +-- 4 files changed, 55 insertions(+), 26 deletions(-) diff --git a/install/tools/ipa-adtrust-install b/install/tools/ipa-adtrust-install index 6678018e6346d75d5042894cfb833d38079d3f21..f367d5b2b516bd411bce9275ff299eb3ffdf6bf9 100755 --- a/install/tools/ipa-adtrust-install +++ b/install/tools/ipa-adtrust-install @@ -37,8 +37,6 @@ log_file_name = "/var/log/ipaserver-install.log" def parse_options(): parser = IPAOptionParser(version=version.VERSION) -parser.add_option("-p", "--ds-password", dest="dm_password", - sensitive=True, help="directory manager password") parser.add_option("-d", "--debug", dest="debug", action="store_true", default=False, help="print debugging information") parser.add_option("--ip-address", dest="ip_address", @@ -86,6 +84,30 @@ def read_netbios_name(netbios_default): return netbios_name +def ensure_kerberos_admin_rights(api): +try: +ctx = krbV.default_context() +ccache = ctx.default_ccache() +principal = ccache.principal() +api.Backend.ldap2.connect(ccache.name) +user = api.Command.user_show(unicode(principal[0]))['result'] +group = api.Command.group_show(u'admins')['result'] +api.Backend.ldap2.disconnect() +if not (user['uid'][0] in group['member_user'] and +group['cn'][0] in user['memberof_group']): +raise errors.RequirementError(name='admins group membership') +except Exception, e: +error_messages = dict( + ACIError = "Outdated Kerberos credentials. Use kdestroy and kinit to update your ticket", + Krb5Error = "Must have Kerberos credentials to setup AD trusts on server", + RequirementError = "Must have administrative privileges to setup AD trusts on server" +) +name = type(e).__name__ +if name in error_messages: +sys.exit(error_messages[name]) +else: +sys.exit("Unrecognized error during check of admin rights: %s\n%s" % (name, str(e))) + def main(): safe_options, options = parse_options() @@ -128,6 +150,8 @@ def main(): api.bootstrap(**cfg) api.finalize() +ensure_kerberos_admin_rights(api) + if adtrustinstance.ipa_smb_conf_exists(): if not options.unattended: while True: @@ -194,9 +218,8 @@ def main(): if not options.unattended and ( not netbios_name or not options.netbios_name): netbios_name = read_netbios_name(netbios_name) -dm_password = options.dm_password or read_password("Directory Manager", - confirm=False, validate=False) -smb = adtrustinstance.ADTRUSTInstance(fsto
[Freeipa-devel] [PATCH] 0060 Ensure ipa-adtrust-install is run as admin user
Hi, when adding AD trusts support, we need to ensure we have valid kerberos ticket of the user from 'admins' group or otherwise appropriate ACIs will not be granted. This patch introduces a check for that. We already check if ipa-adtrust-install is run by root so this complements existing checks. https://fedorahosted.org/freeipa/ticket/2815 -- / Alexander Bokovoy >From 4a439e86c26f7a640063d4b20beaf35e6a2967c9 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Fri, 13 Jul 2012 18:12:48 +0300 Subject: [PATCH 2/2] Ensure ipa-adtrust-install is run with Kerberos ticket for admin user When setting up AD trusts support, ipa-adtrust-install utility needs to be run as: - root, for performing Samba configuration - kinit-ed IPA admin user, to ensure proper ACIs are granted https://fedorahosted.org/freeipa/ticket/2815 --- install/tools/ipa-adtrust-install | 25 + 1 file changed, 25 insertions(+) diff --git a/install/tools/ipa-adtrust-install b/install/tools/ipa-adtrust-install index 6678018e6346d75d5042894cfb833d38079d3f21..d03657118995022cbf1c34149bc5528a628a71ea 100755 --- a/install/tools/ipa-adtrust-install +++ b/install/tools/ipa-adtrust-install @@ -86,6 +86,29 @@ def read_netbios_name(netbios_default): return netbios_name +def ensure_kerberos_admin_rights(api): +try: +ctx = krbV.default_context() +ccache = ctx.default_ccache() +principal = ccache.principal() +api.Backend.ldap2.connect(ccache.name) +user = api.Command.user_show(unicode(principal[0]))['result'] +group = api.Command.group_show(u'admins')['result'] +api.Backend.ldap2.disconnect() +if not (user['uid'][0] in group['member_user'] and +group['cn'][0] in user['memberof_group']): +raise errors.RequirementError(name='admins group membership') +except Exception, e: +error_messages = dict( + Krb5Error = "Must have Kerberos credentials to setup AD trusts on server", + RequirementError = "Must have administrative privileges to setup AD trusts on server" +) +name = type(e).__name__ +if name in error_messages: +sys.exit(error_messages[name]) +else: +sys.exit("Unrecognized error during check of admin rights: %s" % (str(e))) + def main(): safe_options, options = parse_options() @@ -128,6 +151,8 @@ def main(): api.bootstrap(**cfg) api.finalize() +ensure_kerberos_admin_rights(api) + if adtrustinstance.ipa_smb_conf_exists(): if not options.unattended: while True: -- 1.7.10.4 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel