From email.marc at gmail.com Mon Feb 2 04:21:27 2009 From: email.marc at gmail.com (Marc Richards) Date: Sun, 01 Feb 2009 23:21:27 -0500 Subject: [Freeipa-users] Using the Schema Compatibility Plugin with FreeIPA v1 Message-ID: <498674C7.4030708@gmail.com> I notice that you FAQ makes reference to Schema Compatibility Plugin that was developed as part of the NIS compatibility effort (https://fedorahosted.org/slapi-nis/). Can this plugin be used with FreeIPA v1 or is it strictly for v2? I was thinking about using it to create a crude mapping of groups -> netgroups as an interim solution for host based access control on Solaris...until FreeIPA v2 gets released. Basically, I want to create a mapping of the netgroup format defined here: http://directory.fedoraproject.org/wiki/Howto:Netgroups and then configure my Solaris client to restrict access based on netgroups: http://www.sun.com/bigadmin/features/articles/nis_ldap_part2.jsp#Solaris10 (scroll down to section 6). I know it is crude, but it is just an interim hack until v2 comes around and at least I avoid duplicating information. Does it look like it will work? Marc From email.marc at gmail.com Mon Feb 2 04:25:53 2009 From: email.marc at gmail.com (Marc Richards) Date: Sun, 01 Feb 2009 23:25:53 -0500 Subject: [Freeipa-users] Apache Directory Studio Message-ID: <498675D1.5030402@gmail.com> Any body using Apache Directory Studio (http://directory.apache.org/studio/) with FreeIPA? I was thinking about using it for browsing and LDIF editing/import/export, just wondered if anyone had tried it yet. Marc From email.marc at gmail.com Mon Feb 2 07:24:46 2009 From: email.marc at gmail.com (Marc Richards) Date: Mon, 02 Feb 2009 02:24:46 -0500 Subject: [Freeipa-users] Solaris client configuration for FreeIPA 1.2 Message-ID: <49869FBE.9090701@gmail.com> I read on this list that as of v1.2 the native Solaris 10 nss_ldap library can be used. What are the modifications requiered for that to work? I tried installing the freeipa nss_ldap by following the instructions at http://www.freeipa.org/page/ConfiguringSolarisClients, but it looks like the native library is already installed and I am no Solaris expert so I would rather leave the native library in place. I've seen mention of /var/ldap/ldap_client_file in this document (http://freeipa.org/page/ConfiguringUnixClients), but seeing as how it doesn't include any kerberos information, I am assuming it is no longer relevant. Marc From n.gresham at manchester.ac.uk Mon Feb 2 13:18:45 2009 From: n.gresham at manchester.ac.uk (Nick Gresham) Date: Mon, 02 Feb 2009 13:18:45 +0000 Subject: [Freeipa-users] Moving the master server In-Reply-To: <4981E427.4040803@redhat.com> References: <4981DF90.2050109@manchester.ac.uk> <4981E427.4040803@redhat.com> Message-ID: <4986F2B5.1090900@manchester.ac.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rob Crittenden wrote: > Nick Gresham wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi, >> >> I have a couple of machines in a running freeipa-1.2.1 in a >> master/replica set up. However the the master server in this scenario is >> now out of warranty and needs to be retired. >> >> I have another machine readied to assume its role (with a different >> hostname and ip number, however), or preferably, I could promote the >> existing replica to master. >> >> There doesn't seem to be an easy way to accomplish this, short of >> starting again (which is not a practical option for me). >> >> Cany anyone give some advice? Thanks in advance, >> > > The only difference between a replica and the initial IPA install (the > "master") is that the first server owns the self-signed CA. > > You should be able to do this to make your "replica" the master: > > - copy /var/lib/ipa/ca_serialno from master to replica > - import the CA into the replica DS NSS database with: > # cd /etc/dirsrv/slapd-REALM > # pk12util -i /path/to/cacert.p12 -d . > > The password on the PKCS#12 file is on the original server in > /etc/dirsrv/slapd-REALM/pwdfile.txt as is the file cacert.p12 (which you > backed up elsewhere too, right?) > > - Delete the existing replication agreements: > # ipa-replica-manage del master.example.com > > Now you should have 2 identical IPA servers, neither of which know about > each other. Shut down the old master and stand up the new box. Create a > replica file on the newly promoted master and install that on the new > box. You should be back in business. > > Note: I haven't actually tried this but it should do the trick. Backups > are always a good idea. > > rob That worked perfectly! Many thanks [NG] - -- N.J. Gresham FLS/IS AIO Systems Administration and Support University of Manchester Faculty of Life Sciences -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkmG8rAACgkQoqZzfMI0Udm/jACdGzQkzwxdapORbLKgaVUSP53B KxEAn2ehRmuJVE5PJcQ7AiS0DoOLPn6s =To0V -----END PGP SIGNATURE----- From ssorce at redhat.com Mon Feb 2 13:48:09 2009 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 02 Feb 2009 08:48:09 -0500 Subject: [Freeipa-users] Solaris client configuration for FreeIPA 1.2 In-Reply-To: <49869FBE.9090701@gmail.com> References: <49869FBE.9090701@gmail.com> Message-ID: <1233582489.30808.33.camel@localhost.localdomain> On Mon, 2009-02-02 at 02:24 -0500, Marc Richards wrote: > I read on this list that as of v1.2 the native Solaris 10 nss_ldap > library can be used. What are the modifications requiered for that to > work? You need to configure the compatibility plugin which is available and works since version 1.2 See the ipa-compat-manage command. You have to use it to enable the compat plugin on each master that you want to use to serve out compat groups for Solaris. It's a per-server option. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Mon Feb 2 15:23:38 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 02 Feb 2009 10:23:38 -0500 Subject: [Freeipa-users] Moving the master server In-Reply-To: <4986F2B5.1090900@manchester.ac.uk> References: <4981DF90.2050109@manchester.ac.uk> <4981E427.4040803@redhat.com> <4986F2B5.1090900@manchester.ac.uk> Message-ID: <49870FFA.70603@redhat.com> Nick Gresham wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Rob Crittenden wrote: >> Nick Gresham wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> Hi, >>> >>> I have a couple of machines in a running freeipa-1.2.1 in a >>> master/replica set up. However the the master server in this scenario is >>> now out of warranty and needs to be retired. >>> >>> I have another machine readied to assume its role (with a different >>> hostname and ip number, however), or preferably, I could promote the >>> existing replica to master. >>> >>> There doesn't seem to be an easy way to accomplish this, short of >>> starting again (which is not a practical option for me). >>> >>> Cany anyone give some advice? Thanks in advance, >>> >> The only difference between a replica and the initial IPA install (the >> "master") is that the first server owns the self-signed CA. >> >> You should be able to do this to make your "replica" the master: >> >> - copy /var/lib/ipa/ca_serialno from master to replica >> - import the CA into the replica DS NSS database with: >> # cd /etc/dirsrv/slapd-REALM >> # pk12util -i /path/to/cacert.p12 -d . >> >> The password on the PKCS#12 file is on the original server in >> /etc/dirsrv/slapd-REALM/pwdfile.txt as is the file cacert.p12 (which you >> backed up elsewhere too, right?) >> >> - Delete the existing replication agreements: >> # ipa-replica-manage del master.example.com >> >> Now you should have 2 identical IPA servers, neither of which know about >> each other. Shut down the old master and stand up the new box. Create a >> replica file on the newly promoted master and install that on the new >> box. You should be back in business. >> >> Note: I haven't actually tried this but it should do the trick. Backups >> are always a good idea. >> >> rob > > That worked perfectly! Many thanks Great, glad to hear it. We'll see about integrating this into our documentation. thanks for the feedback rob From email.marc at gmail.com Mon Feb 2 15:25:39 2009 From: email.marc at gmail.com (Marc Richards) Date: Mon, 02 Feb 2009 10:25:39 -0500 Subject: [Freeipa-users] Solaris client configuration for FreeIPA 1.2 In-Reply-To: <1233582489.30808.33.camel@localhost.localdomain> References: <49869FBE.9090701@gmail.com> <1233582489.30808.33.camel@localhost.localdomain> Message-ID: <49871073.1060409@gmail.com> On 02/02/2009 8:48 AM, Simo Sorce wrote: > On Mon, 2009-02-02 at 02:24 -0500, Marc Richards wrote: > >> I read on this list that as of v1.2 the native Solaris 10 nss_ldap >> library can be used. What are the modifications requiered for that to >> work? >> > > You need to configure the compatibility plugin which is available and > works since version 1.2 > > See the ipa-compat-manage command. > You have to use it to enable the compat plugin on each master that you > want to use to serve out compat groups for Solaris. > It's a per-server option. > Ok, cool. What about on the client side. How does the configuration differ from the docs? Marc -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Mon Feb 2 15:26:57 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 02 Feb 2009 10:26:57 -0500 Subject: [Freeipa-users] Apache Directory Studio In-Reply-To: <498675D1.5030402@gmail.com> References: <498675D1.5030402@gmail.com> Message-ID: <498710C1.2060808@redhat.com> Marc Richards wrote: > Any body using Apache Directory Studio > (http://directory.apache.org/studio/) with FreeIPA? I was thinking > about using it for browsing and LDIF editing/import/export, just > wondered if anyone had tried it yet. I have tried it but then again I'm a glutton for punishment so tend to stick with ldapmodify and ldapsearch :-) A note of caution though, be careful if you add entries using any non-IPA tools. Be sure to stick with our layout and you will probably be ok. rob From rcritten at redhat.com Mon Feb 2 15:32:00 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 02 Feb 2009 10:32:00 -0500 Subject: [Freeipa-users] Solaris client configuration for FreeIPA 1.2 In-Reply-To: <49869FBE.9090701@gmail.com> References: <49869FBE.9090701@gmail.com> Message-ID: <498711F0.40303@redhat.com> Marc Richards wrote: > I read on this list that as of v1.2 the native Solaris 10 nss_ldap > library can be used. What are the modifications requiered for that to > work? > > I tried installing the freeipa nss_ldap by following the instructions at > http://www.freeipa.org/page/ConfiguringSolarisClients, but it looks like > the native library is already installed and I am no Solaris expert so I > would rather leave the native library in place. I've seen mention of > /var/ldap/ldap_client_file in this document > (http://freeipa.org/page/ConfiguringUnixClients), but seeing as how it > doesn't include any kerberos information, I am assuming it is no longer > relevant. With freeIPA v1.2+ you don't need our nss_ldap any more. The native one will work fine. The issue was the way the native nss_ldap expected groups to work. The compatibility plugin solves this for us. Configuring a native Solaris server should be as simple as: [ on the IPA server ] # ipa-compat-manage enable # service restart dirsrv [ on the Solaris client ] # ldapclient init ipa.example.com When you installed IPA we created a default profile that should configure your client. Note that Solaris is a bit silly when it comes to LDAP. It assumes that if you want to use LDAP for anything you want to use it for EVERYTHING. So you'll need to edit /etc/nsswitch.conf after running ldapclient and fix the hosts and ipnodes. They got set to ldap and should probably be "files dns", depending on your network. rob From email.marc at gmail.com Mon Feb 2 15:41:12 2009 From: email.marc at gmail.com (Marc Richards) Date: Mon, 02 Feb 2009 10:41:12 -0500 Subject: [Freeipa-users] Solaris client configuration for FreeIPA 1.2 In-Reply-To: <498711F0.40303@redhat.com> References: <49869FBE.9090701@gmail.com> <498711F0.40303@redhat.com> Message-ID: <49871418.3030403@gmail.com> On 02/02/2009 10:32 AM, Rob Crittenden wrote: > Marc Richards wrote: >> I read on this list that as of v1.2 the native Solaris 10 nss_ldap >> library can be used. What are the modifications requiered for that >> to work? >> >> I tried installing the freeipa nss_ldap by following the instructions >> at http://www.freeipa.org/page/ConfiguringSolarisClients, but it >> looks like the native library is already installed and I am no >> Solaris expert so I would rather leave the native library in place. >> I've seen mention of /var/ldap/ldap_client_file in this document >> (http://freeipa.org/page/ConfiguringUnixClients), but seeing as how >> it doesn't include any kerberos information, I am assuming it is no >> longer relevant. > > With freeIPA v1.2+ you don't need our nss_ldap any more. The native > one will work fine. The issue was the way the native nss_ldap expected > groups to work. The compatibility plugin solves this for us. > > Configuring a native Solaris server should be as simple as: > > [ on the IPA server ] > # ipa-compat-manage enable > # service restart dirsrv > > [ on the Solaris client ] > # ldapclient init ipa.example.com > > When you installed IPA we created a default profile that should > configure your client. Note that Solaris is a bit silly when it comes > to LDAP. It assumes that if you want to use LDAP for anything you want > to use it for EVERYTHING. So you'll need to edit /etc/nsswitch.conf > after running ldapclient and fix the hosts and ipnodes. They got set > to ldap and should probably be "files dns", depending on your network. Excellent. I'll give that a shot. Marc From nalin at redhat.com Mon Feb 2 15:58:14 2009 From: nalin at redhat.com (Nalin Dahyabhai) Date: Mon, 2 Feb 2009 10:58:14 -0500 Subject: [Freeipa-users] Using the Schema Compatibility Plugin with FreeIPA v1 In-Reply-To: <498674C7.4030708@gmail.com> References: <498674C7.4030708@gmail.com> Message-ID: <20090202155814.GA20297@redhat.com> On Sun, Feb 01, 2009 at 11:21:27PM -0500, Marc Richards wrote: > I notice that you FAQ makes reference to Schema Compatibility Plugin > that was developed as part of the NIS compatibility effort > (https://fedorahosted.org/slapi-nis/). Can this plugin be used with > FreeIPA v1 or is it strictly for v2? It can be used with either, as the plugin doesn't have dependencies on anything other than the directory server. The only thing you need to be sure of is that the section of the tree that's served by the plugin doesn't overlap "real" data, which the plugin isn't likely to handle in any sane way. If I'm remembering it right, in v2, we're using the "cn=compat,$SUFFIX" area for this, so something else under $SUFFIX ("cn=compat-netgroups", for one) should be fine. (You want to keep it under $SUFFIX so that the default ACIs set on the real backend database will be applied and allow you search the compat tree.) > I was thinking about using it to create a crude mapping of groups -> > netgroups as an interim solution for host based access control on > Solaris...until FreeIPA v2 gets released. Basically, I want to create a > mapping of the netgroup format defined here: > http://directory.fedoraproject.org/wiki/Howto:Netgroups and then > configure my Solaris client to restrict access based on netgroups: > http://www.sun.com/bigadmin/features/articles/nis_ldap_part2.jsp#Solaris10 > (scroll down to section 6). > > I know it is crude, but it is just an interim hack until v2 comes around > and at least I avoid duplicating information. Does it look like it will > work? Yes, that should work just fine. Now that you mention it, it might be interesting it to always assign POSIX group IDs to netgroup entries, and let the server-side logic filter out hosts when presenting them as groups of users. It might be unusual, and I haven't worked out what all would be required to make it work without leaning on the compat plugin, but hey. Cheers, Nalin From dpal at redhat.com Wed Feb 4 18:53:33 2009 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 04 Feb 2009 13:53:33 -0500 Subject: [Freeipa-users] Usability Testing Message-ID: <4989E42D.2010209@redhat.com> Hello, Last week the freeIPA development team conducted a series of usability testing sessions. The goal was to see how the user interface proposed for IPA v2 resonates with the administrators. We got a lot of interesting feedback and we will be changing the screens. However we also wanted to hear your opinion about the proposed UI. All the materials we used and feedback we got are now posted on the freeIPA site at: http://www.freeipa.org/page/IPAv2_development_status#User_Interface_Design Thank you for your interest in freeIPA. Any comments or suggestions are welcome! Dmitri From email.marc at gmail.com Thu Feb 5 09:38:33 2009 From: email.marc at gmail.com (Marc Richards) Date: Thu, 05 Feb 2009 04:38:33 -0500 Subject: [Freeipa-users] IPA client support for Solaris in v2 Message-ID: <498AB399.3050102@gmail.com> I know the v2 requirements doc for the IPA client mentions Solaris support, but I am curious as to what level of support is currently being planned/developed. The v2 client design looks quite sophisticated compared to v1, how much of that will actually work on non-linux platforms? Do you plan on implementing the custom pam and nss modules on Solaris? What about the PolicyKit and InfoPipe daemons? DBus integration? I realize this is a non-trivial thing to do on the non-linux platforms (though it would be great if at least the PAM/NSS part worked), I just want to know what to expect since the docs aren't totally clear Marc From d.Thomas at colostate.edu Tue Feb 10 07:55:51 2009 From: d.Thomas at colostate.edu (Thomas,Dave) Date: Tue, 10 Feb 2009 00:55:51 -0700 Subject: [Freeipa-users] New users can't log into Centos client Message-ID: <67A4901921307B49AC55A96647DBDBDD0E017D1567@EVS4.ColoState.EDU> Hi, I've got two FreeIPA (1.2.1) servers running on Fedora 10, with some FreeIPA clients running on CentOS 5.2 and some clients on Fedora 10 (all with FreeIPA 1.2.1) Everything seems to be working fine, except when a new user tries to log in for the first time. If a new user (or someone who had their password reset) tries to ssh into one of the CentOS clients, it (which are the only clients our remote users log into) it says "Permission denied, please try again." If the same user tries to log into one of the Fedora clients or one of the FreeIPA servers, They are asked to change their password as usual. Also, if I su to a new user account, it will let me change the password as normal, even on the CentOS clients, so I'm thinking that there is something that is not configured right in ssh. This same thing also happened when I had Redhat IPA installed on the CentOS clients. On the CentOS Machines, I've installed nss-ldap 261-4 and python-kerberos 1.1-3.1 compiled from the fedora 10 source rpms. Does anyone know what is causing this behavior? It's not a show-stopper, but it would be nice to get this solved. Thanks, Dave From rcritten at redhat.com Tue Feb 10 14:41:43 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 10 Feb 2009 09:41:43 -0500 Subject: [Freeipa-users] New users can't log into Centos client In-Reply-To: <67A4901921307B49AC55A96647DBDBDD0E017D1567@EVS4.ColoState.EDU> References: <67A4901921307B49AC55A96647DBDBDD0E017D1567@EVS4.ColoState.EDU> Message-ID: <49919227.8050509@redhat.com> Thomas,Dave wrote: > Hi, > > I've got two FreeIPA (1.2.1) servers running on Fedora 10, with some FreeIPA clients running on CentOS 5.2 and some clients on Fedora 10 (all with FreeIPA 1.2.1) Everything seems to be working fine, except when a new user tries to log in for the first time. > > If a new user (or someone who had their password reset) tries to ssh into one of the CentOS clients, it (which are the only clients our remote users log into) it says "Permission denied, please try again." If the same user tries to log into one of the Fedora clients or one of the FreeIPA servers, They are asked to change their password as usual. Also, if I su to a new user account, it will let me change the password as normal, even on the CentOS clients, so I'm thinking that there is something that is not configured right in ssh. This same thing also happened when I had Redhat IPA installed on the CentOS clients. > > On the CentOS Machines, I've installed nss-ldap 261-4 and python-kerberos 1.1-3.1 compiled from the fedora 10 source rpms. > > Does anyone know what is causing this behavior? It's not a show-stopper, but it would be nice to get this solved. You need to enable Challenge-Response in sshd: http://freeipa.org/page/AdministratorsGuide#Using_Password_Authentication rob From d.Thomas at colostate.edu Tue Feb 10 16:05:04 2009 From: d.Thomas at colostate.edu (Thomas,Dave) Date: Tue, 10 Feb 2009 09:05:04 -0700 Subject: [Freeipa-users] New users can't log into Centos client In-Reply-To: <49919227.8050509@redhat.com> References: <67A4901921307B49AC55A96647DBDBDD0E017D1567@EVS4.ColoState.EDU>, <49919227.8050509@redhat.com> Message-ID: <67A4901921307B49AC55A96647DBDBDD0E017D1569@EVS4.ColoState.EDU> Thanks, Rob. It's strange, then, that it works on the Fedora 10 clients, because Challenge-Response is disabled in sshd_config on those machines as well... -Dave ________________________________________ From: Rob Crittenden [rcritten at redhat.com] > Thomas,Dave wrote: >> Hi, >> >> I've got two FreeIPA (1.2.1) servers running on Fedora 10, with some FreeIPA clients running on CentOS 5.2 and some clients on Fedora 10 (all with FreeIPA 1.2.1) Everything seems to be working fine, except when a new user tries to log in for the first time. >> >> If a new user (or someone who had their password reset) tries to ssh into one of the CentOS clients, it (which are the only clients our remote users log into) it says "Permission denied, please try again." If the same user tries to log into one of the Fedora clients or one of the FreeIPA servers, They are asked to change their password as usual. Also, if I su to a new user account, it will let me change the password as normal, even on the CentOS clients, so I'm thinking that there is something that is not configured right in ssh. This same thing also happened when I had Redhat IPA installed on the CentOS clients. >> >> On the CentOS Machines, I've installed nss-ldap 261-4 and python-kerberos 1.1-3.1 compiled from the fedora 10 source rpms. >> >> Does anyone know what is causing this behavior? It's not a show-stopper, but it would be nice to get this solved. > >You need to enable Challenge-Response in sshd: > >http://freeipa.org/page/AdministratorsGuide#Using_Password_Authentication > >rob From rcritten at redhat.com Tue Feb 10 21:09:11 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 10 Feb 2009 16:09:11 -0500 Subject: [Freeipa-users] New users can't log into Centos client In-Reply-To: <67A4901921307B49AC55A96647DBDBDD0E017D1569@EVS4.ColoState.EDU> References: <67A4901921307B49AC55A96647DBDBDD0E017D1567@EVS4.ColoState.EDU>, <49919227.8050509@redhat.com> <67A4901921307B49AC55A96647DBDBDD0E017D1569@EVS4.ColoState.EDU> Message-ID: <4991ECF7.9030500@redhat.com> Thomas,Dave wrote: > Thanks, Rob. It's strange, then, that it works on the Fedora 10 clients, because Challenge-Response is disabled in sshd_config on those machines as well... > -Dave Does it fix it though? I wonder if EL5 and Fedora 10 have different defaults. rob From d.Thomas at colostate.edu Tue Feb 10 21:37:38 2009 From: d.Thomas at colostate.edu (Thomas,Dave) Date: Tue, 10 Feb 2009 14:37:38 -0700 Subject: [Freeipa-users] New users can't log into Centos client In-Reply-To: <4991ECF7.9030500@redhat.com> References: <67A4901921307B49AC55A96647DBDBDD0E017D1567@EVS4.ColoState.EDU>, <49919227.8050509@redhat.com> <67A4901921307B49AC55A96647DBDBDD0E017D1569@EVS4.ColoState.EDU>, <4991ECF7.9030500@redhat.com> Message-ID: <67A4901921307B49AC55A96647DBDBDD0E017D1570@EVS4.ColoState.EDU> From: Rob Crittenden [rcritten at redhat.com] >Thomas,Dave wrote: >> Thanks, Rob. It's strange, then, that it works on the Fedora 10 clients, because Challenge-Response is disabled in sshd_config on those machines as well... >> -Dave >Does it fix it though? >I wonder if EL5 and Fedora 10 have different defaults. >rob Yes, it fixes it. Now it works as expected in both Fedora 10 and EL5. Challenge-response is explicitly disabled by default in sshd_config for EL5 and Fedora 10. When it is disabled, EL5 does not allow the initial password change, but Fedora 10 does, although it's behavior is a bit strange: $ ssh USERNAME at ipaserver@example.com USERNAME at ipaserver@example.com's password: Warning: Your password will expire in less than one hour. Warning: password has expired. WARNING: Your password has expired. You must change your password now and login again! Changing password for user USERNAME. Kerberos 5 Password: Warning: Your password will expire in less than one hour. New UNIX password: Retype new UNIX password: passwd: all authentication tokens updated successfully. Connection to ipaserver at example.com closed. When challenge-response is enabled, both EL5 and Fedora 10 behave as expected, (enter old password then enter new password twice.) So I've got it working now (thanks!) but I'm curious about why EL5 and Fedora 10 behave differently when the sshd configuration is the same. -Dave From dpal at redhat.com Thu Feb 19 15:54:59 2009 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 19 Feb 2009 10:54:59 -0500 Subject: [Freeipa-users] IPA client support for Solaris in v2 In-Reply-To: <498AB399.3050102@gmail.com> References: <498AB399.3050102@gmail.com> Message-ID: <499D80D3.6060503@redhat.com> Marc Richards wrote: > I know the v2 requirements doc for the IPA client mentions Solaris > support, but I am curious as to what level of support is currently > being planned/developed. The v2 client design looks quite > sophisticated compared to v1, how much of that will actually work on > non-linux platforms? > > Do you plan on implementing the custom pam and nss modules on Solaris? > What about the PolicyKit and InfoPipe daemons? > DBus integration? > > I realize this is a non-trivial thing to do on the non-linux platforms > (though it would be great if at least the PAM/NSS part worked), I just > want to know what to expect since the docs aren't totally clear > > Marc > We are developing the client in a platform independent fashion on Fedora/Red Hat Enterprise Linux first. We will port it to Solaris and other platforms as the next step after. So the whole set of services (PAM, NSS with caching HBAC etc) will be available on Solaris too but down the road. The client is modular and PolicyKit and InfoPipe integration will not be available on the platforms that do not have these components. The part of DBUS we use is has been ported to multiple platforms so we do not expect any significant issues there. Sorry for delayed response. Thanks Dmitri > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From stefan at ru.is Mon Feb 23 14:25:02 2009 From: stefan at ru.is (Stefan Stefansson) Date: Mon, 23 Feb 2009 14:25:02 +0000 Subject: [Freeipa-users] Attributes on groups Message-ID: <30cfbc570902230625g6b80ee1dl442fb5611a5fce78@mail.gmail.com> Hello. In my situation, I have a number of entities that will be deploying the same set of services. For simplicity, let's call these entities departments although that's not strictly the case in our situation. So each department will deploy a Subversion server, Wiki and possibly some other services. We're planning on having as much delegation of the administration work as possible, by having for example department heads have wiki admin rights and the rights to define SVN permissions for their departments SVN. My question is basically, what is the best way of doing this? What we currently have in a very small proof of concept deployment is creating groups that reflect all the different roles in their names, for example: "cs-wiki-admin" (an administrator for the wiki of the School of Computer Science) "humanobs-wiki-admin" (same as above but only for the humanobs project) "cs-svn-admin" (someone who can administer the whole CS SVN repository) ... etc, you get the point. An example shows how complicated the group names can become: cs-svn-foobar-auditor, could be someone with "auditor" rights on a single project (foobar) inside the CS SVN repository. This can get out of control pretty quickly if/when project owners start wanting to do finer grained access controls. Another problem that I see with this has to do with delegation. How do I specify that anybody in the humanobs-admin group can add users to and define permissions on groups that have a name that starts with the prefix "humanobs-". So, the question is, is it possible to do this more conveniently? Can I create multiple groups called "admin" where each one is somehow distinct from the others by specifying the department/project it applies to somehow? The Humanobs "admin" group would then only be able to control things within the Humanobs project. One could even think of having a "wiki-admin" and a "svn-admin" groups and an "admin" supergroup for each of the projects/departments. I'm hoping for some discussion about this. If anyone has experience with something similar I'd love to hear about it and how it's working out. Discussion of the pros/cons of each method would be great. Best regards, Stefan Freyr. From rcritten at redhat.com Mon Feb 23 15:47:58 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 23 Feb 2009 10:47:58 -0500 Subject: [Freeipa-users] Attributes on groups In-Reply-To: <30cfbc570902230625g6b80ee1dl442fb5611a5fce78@mail.gmail.com> References: <30cfbc570902230625g6b80ee1dl442fb5611a5fce78@mail.gmail.com> Message-ID: <49A2C52E.5080202@redhat.com> Stefan Stefansson wrote: > Hello. > > In my situation, I have a number of entities that will be deploying > the same set of services. For simplicity, let's call these entities > departments although that's not strictly the case in our situation. > > So each department will deploy a Subversion server, Wiki and possibly > some other services. > > We're planning on having as much delegation of the administration work > as possible, by having for example department heads have wiki admin > rights and the rights to define SVN permissions for their departments > SVN. > > My question is basically, what is the best way of doing this? > > What we currently have in a very small proof of concept deployment is > creating groups that reflect all the different roles in their names, > for example: > > "cs-wiki-admin" (an administrator for the wiki of the School of > Computer Science) > "humanobs-wiki-admin" (same as above but only for the humanobs project) > > "cs-svn-admin" (someone who can administer the whole CS SVN repository) > ... etc, you get the point. > > An example shows how complicated the group names can become: > cs-svn-foobar-auditor, could be someone with "auditor" rights on a > single project (foobar) inside the CS SVN repository. > > This can get out of control pretty quickly if/when project owners > start wanting to do finer grained access controls. > > Another problem that I see with this has to do with delegation. How do > I specify that anybody in the humanobs-admin group can add users to > and define permissions on groups that have a name that starts with the > prefix "humanobs-". > > So, the question is, is it possible to do this more conveniently? Can > I create multiple groups called "admin" where each one is somehow > distinct from the others by specifying the department/project it > applies to somehow? The Humanobs "admin" group would then only be able > to control things within the Humanobs project. One could even think of > having a "wiki-admin" and a "svn-admin" groups and an "admin" > supergroup for each of the projects/departments. > > I'm hoping for some discussion about this. If anyone has experience > with something similar I'd love to hear about it and how it's working > out. Discussion of the pros/cons of each method would be great. > > Best regards, Stefan Freyr. Unfortunately IPA doesn't supported this type of fine-grained access control yet but it is something we're planning to add in the next major release. The current delegation just assigns write access for a predefined set of attributes from group A to group B. It doesn't provide control over discrete parts of the tree, support for controlling who can add/remove entries, etc. The new system will provide the ability to delegate entry management (add, delete, etc) but that too will be global. We would need to add the concept of user containers to IPA to be able to delegate this level of user management. Right now all users are written to the same place in the DIT so if you have add access there you can add a user. It sounds what you'd like is to be able to create separate areas in the LDAP tree to separate users, is that right? rob From natxo.asenjo at gmail.com Wed Feb 25 22:37:11 2009 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Wed, 25 Feb 2009 23:37:11 +0100 Subject: [Freeipa-users] new freeipa user Message-ID: <90f6e8270902251437y62c4f3f6le17cb5e859ef1739@mail.gmail.com> hi, After reading a lot of good things about this project I have decided to give it a try. I have set up a virtual environment (all fedora based, it works great with virtual manager). I have two fedora10 virtual machines, on the first one I followed the instructions on http://www.freeipa.org/page/Implementing_FreeIPA_in_a_mixed_Environment_(Windows/Linux)_-_Step_by_step : # yum install ipa-* # yum install bind (no chroot for bind, but it works fine) ; so I have succesfully installed freeipa 1.2.1 and I am iimpressed. Very good documentation, it works as advertised. On the other vm I run # yum install ipa-client and then run ipa-client-install and everything worked! Adding users thru the web interface is a breeze. Great stuff. I have so far only run into a problem and that is the auto creation of home dirs on the firs login. I used the authenthication configuration gui from fedora10 on the ipaclient and checked the option to auto-create homedirs but that doesn't work. There is a selinux error: Feb 25 23:28:47 ipaclient01 setroubleshoot: SELinux is preventing sshd (sshd_t) "write" to ./home (home_root_t). For complete SELinux messages. run sealert -l 2f194ec1-0764-48b0-b66c-d84734105283 apparently the pam_mkhomedir.so is not allowed to work with selinux. Any workarounds? If I login as root and su - to a kerberos user in the ipaclient vm, then it creates the homedir, obviously. I want to use nfs homedirs anyway, so it is not a huge issue. Speaking of which: for nfs homedirs in ldap: do I have to wait for the next release of freeipa? Is it easy to install from sources? I am no coder, but if I can help you testing stuff I will be happy to do it. -- Groeten, J.Asenjo From rcritten at redhat.com Thu Feb 26 03:20:52 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 25 Feb 2009 22:20:52 -0500 Subject: [Freeipa-users] new freeipa user In-Reply-To: <90f6e8270902251437y62c4f3f6le17cb5e859ef1739@mail.gmail.com> References: <90f6e8270902251437y62c4f3f6le17cb5e859ef1739@mail.gmail.com> Message-ID: <49A60A94.8050601@redhat.com> Natxo Asenjo wrote: > hi, > > After reading a lot of good things about this project I have decided > to give it a try. I have set up a virtual environment (all fedora > based, it works great with virtual manager). I have two fedora10 > virtual machines, on the first one I followed the instructions on > http://www.freeipa.org/page/Implementing_FreeIPA_in_a_mixed_Environment_(Windows/Linux)_-_Step_by_step > : > > # yum install ipa-* > # yum install bind > > (no chroot for bind, but it works fine) ; so I have succesfully > installed freeipa 1.2.1 and I am iimpressed. Very good documentation, > it works as advertised. > > On the other vm I run > > # yum install ipa-client > > and then run ipa-client-install and everything worked! Adding users > thru the web interface is a breeze. Great stuff. Great! > I have so far only run into a problem and that is the auto creation of > home dirs on the firs login. I used the authenthication configuration > gui from fedora10 on the ipaclient and checked the option to > auto-create homedirs but that doesn't work. There is a selinux error: > > Feb 25 23:28:47 ipaclient01 setroubleshoot: SELinux is preventing sshd > (sshd_t) "write" to ./home (home_root_t). For complete SELinux > messages. run sealert -l 2f194ec1-0764-48b0-b66c-d84734105283 > apparently the pam_mkhomedir.so is not allowed to work with selinux. > Any workarounds? It would be helpful to see the sealert output for this error. We may be able to include a generic fix in IPA, or pass this by the SELinux guys to see what they think. > If I login as root and su - to a kerberos user in the ipaclient vm, > then it creates the homedir, obviously. I want to use nfs homedirs > anyway, so it is not a huge issue. Speaking of which: for nfs homedirs > in ldap: do I have to wait for the next release of freeipa? Is it easy > to install from sources? I am no coder, but if I can help you testing > stuff I will be happy to do it. > Well there are so many different ways to do it we decided to leave it up to the individual admins to implement it for their environment. For some pam_mkhomedirs is the right answer, for others it is NFS, others may use Samba shares. The mind boggles at the different choices people make. We didn't want to have to bless one method over another. regards rob From natxo.asenjo at gmail.com Thu Feb 26 15:09:01 2009 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Thu, 26 Feb 2009 16:09:01 +0100 Subject: [Freeipa-users] new freeipa user In-Reply-To: <49A60A94.8050601@redhat.com> References: <90f6e8270902251437y62c4f3f6le17cb5e859ef1739@mail.gmail.com> <49A60A94.8050601@redhat.com> Message-ID: <90f6e8270902260709u3d6225f5v64d5fcfc1adb968f@mail.gmail.com> On Thu, Feb 26, 2009 at 4:20 AM, Rob Crittenden wrote: > Natxo Asenjo wrote: >> I have so far only run into a problem and that is the auto creation of >> home dirs on the firs login. I used the authenthication configuration >> gui from fedora10 on the ipaclient and checked the option to >> auto-create homedirs but that doesn't work. There is a selinux error: >> >> Feb 25 23:28:47 ipaclient01 setroubleshoot: SELinux is preventing sshd >> (sshd_t) "write" to ./home (home_root_t). For complete SELinux >> messages. run sealert -l 2f194ec1-0764-48b0-b66c-d84734105283 >> apparently the pam_mkhomedir.so is not allowed to work with selinux. >> Any workarounds? > > It would be helpful to see the sealert output for this error. We may be able > to include a generic fix in IPA, or pass this by the SELinux guys to see > what they think. ok, the output of sealert -l 2f194ec1-0764-48b0-b66c-d84734105283 Summary: SELinux is preventing sshd (sshd_t) "write" to ./home (home_root_t). Detailed Description: SELinux denied access requested by sshd. The current boolean settings do not allow this access. If you have not setup sshd to require this access this may signal an intrusion attempt. If you do intend this access you need to change the booleans on this system to allow the access. Allowing Access: Confined processes can be configured to to run requiring different access, SELinux provides booleans to allow you to turn on/off access as needed. The boolean allow_polyinstantiation is set incorrectly. Boolean Description: Allow login programs to use polyinstantiated directories. Fix Command: # setsebool -P allow_polyinstantiation 1 Additional Information: Source Context system_u:system_r:sshd_t:s0-s0:c0.c1023 Target Context system_u:object_r:home_root_t:s0 Target Objects ./home [ dir ] Source sshd Source Path /usr/sbin/sshd Port Host ipaclient01.virtual.local Source RPM Packages openssh-server-5.1p1-3.fc10 Target RPM Packages filesystem-2.4.19-1.fc10 Policy RPM selinux-policy-3.5.13-45.fc10 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall_boolean Host Name ipaclient01.virtual.local Platform Linux ipaclient01.virtual.local 2.6.27.15-170.2.24.fc10.x86_64 #1 SMP Wed Feb 11 23:14:31 EST 2009 x86_64 x86_64 Alert Count 1 First Seen Wed Feb 25 23:28:47 2009 Last Seen Wed Feb 25 23:28:47 2009 Local ID 2f194ec1-0764-48b0-b66c-d84734105283 Line Numbers Raw Audit Messages node=ipaclient01.virtual.local type=AVC msg=audit(1235600927.386:53): avc: deni ed { write } for pid=3055 comm="sshd" name="home" dev=dm-0 ino=211745 scontext =system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:home_root_t: s0 tclass=dir node=ipaclient01.virtual.local type=SYSCALL msg=audit(1235600927.386:53): arch=c 000003e syscall=83 success=no exit=-13 a0=173bd66 a1=1ed a2=21 a3=6a6e657361632f 65 items=0 ppid=1870 pid=3055 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshd" exe="/usr/sbin/sshd" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) so I run: # setsebool -P allow_polyinstantiation 1 And next time I tried login on the console through gdm: Feb 26 15:41:53 ipaclient01 setroubleshoot: SELinux is preventing gdm-session-wo r (xdm_t) "write" to ./home (home_root_t). For complete SELinux messages. run se alert -l cf03e02d-4bdd-484d-bf6f-d70c553bdab8 running sealert -l cf03e02d-4bdd-484d-bf6f-d70c553bdab8 provides a similar output but one substitutes sshd for gdm als source, obviously. There is another SElinux error in the log: Feb 26 15:46:34 ipaclient01 setroubleshoot: SELinux is preventing gdm-session-wo r (xdm_t) "create" to ./casenjo (home_root_t). For complete SELinux messages. ru n sealert -l a104e0b3-0dc4-4dc7-ba6a-494b7ca070de Summary: SELinux is preventing gdm-session-wor (xdm_t) "create" to ./casenjo (home_root_t). Detailed Description: SELinux denied access requested by gdm-session-wor. It is not expected that this access is required by gdm-session-wor and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: Sometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for ./casenjo, restorecon -v './casenjo' If this does not work, there is currently no automatic way to allow this access. Instead, you can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. Additional Information: Source Context system_u:system_r:xdm_t:s0-s0:c0.c1023 Target Context system_u:object_r:home_root_t:s0 Target Objects ./casenjo [ dir ] Source gdm-session-wor Source Path /usr/libexec/gdm-session-worker Port Host ipaclient01.virtual.local Source RPM Packages gdm-2.24.0-12.fc10 Target RPM Packages Policy RPM selinux-policy-3.5.13-45.fc10 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall_file Host Name ipaclient01.virtual.local Platform Linux ipaclient01.virtual.local 2.6.27.15-170.2.24.fc10.x86_64 #1 SMP Wed Feb 11 23:14:31 EST 2009 x86_64 x86_64 Alert Count 1 First Seen Thu Feb 26 15:46:32 2009 Last Seen Thu Feb 26 15:46:32 2009 Local ID a104e0b3-0dc4-4dc7-ba6a-494b7ca070de Line Numbers Raw Audit Messages node=ipaclient01.virtual.local type=AVC msg=audit(1235659592.554:36): avc: deni ed { create } for pid=4301 comm="gdm-session-wor" name="casenjo" scontext=syst em_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:home_root_t:s0 tcl ass=dir node=ipaclient01.virtual.local type=SYSCALL msg=audit(1235659592.554:36): arch=c 000003e syscall=83 success=no exit=-13 a0=7f577ce13bb6 a1=1ed a2=21 a3=810101010 1010100 items=0 ppid=4174 pid=4301 auid=1100 uid=0 gid=1002 euid=0 suid=0 fsuid= 0 egid=1002 sgid=1002 fsgid=1002 tty=(none) ses=4 comm="gdm-session-wor" exe="/u sr/libexec/gdm-session-worker" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=( null) This time I cannot run restorecon -v './casenjo' because the folder ./casenjo simply does not exist., neither gdm nor sshd could autocreate them. I'd very much rather that selinux stayed enabled, obviously. Hope the output of sealert is helpful to you guys. -- Natxo Asenjo From rcritten at redhat.com Thu Feb 26 18:14:15 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 26 Feb 2009 13:14:15 -0500 Subject: [Freeipa-users] new freeipa user In-Reply-To: <90f6e8270902260709u3d6225f5v64d5fcfc1adb968f@mail.gmail.com> References: <90f6e8270902251437y62c4f3f6le17cb5e859ef1739@mail.gmail.com> <49A60A94.8050601@redhat.com> <90f6e8270902260709u3d6225f5v64d5fcfc1adb968f@mail.gmail.com> Message-ID: <49A6DBF7.9060904@redhat.com> Natxo Asenjo wrote: > On Thu, Feb 26, 2009 at 4:20 AM, Rob Crittenden wrote: >> Natxo Asenjo wrote: > >>> I have so far only run into a problem and that is the auto creation of >>> home dirs on the firs login. I used the authenthication configuration >>> gui from fedora10 on the ipaclient and checked the option to >>> auto-create homedirs but that doesn't work. There is a selinux error: >>> >>> Feb 25 23:28:47 ipaclient01 setroubleshoot: SELinux is preventing sshd >>> (sshd_t) "write" to ./home (home_root_t). For complete SELinux >>> messages. run sealert -l 2f194ec1-0764-48b0-b66c-d84734105283 >>> apparently the pam_mkhomedir.so is not allowed to work with selinux. >>> Any workarounds? >> It would be helpful to see the sealert output for this error. We may be able >> to include a generic fix in IPA, or pass this by the SELinux guys to see >> what they think. > > ok, the output of sealert -l 2f194ec1-0764-48b0-b66c-d84734105283 > > Summary: > > SELinux is preventing sshd (sshd_t) "write" to ./home (home_root_t). I'll check with some SELinux folks to see what they think. Thanks for the detailed report. rob From natxo.asenjo at gmail.com Thu Feb 26 20:05:20 2009 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Thu, 26 Feb 2009 21:05:20 +0100 Subject: [Freeipa-users] organizational units Message-ID: <90f6e8270902261205v6aa6f7f6j7db50534063b11eb@mail.gmail.com> hi, In freeipa 1.2.1 from fedora10, is it possible to create different ou in the directory server in order to organize the directory for different branches, like, ou=europe,dc=example,dc=lcom; ou=asia,dc=example,dc=com etc. Having all users under cn=users,cn=accounts,dc=example,dc=com can be a bit disorganized. Another question: will the webgui have a ldap browser interface? Will the ipa-admintools be able to create objects in different ou/containers in the directory? -- Groeten, J.Asenjo From rcritten at redhat.com Fri Feb 27 17:56:51 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 27 Feb 2009 12:56:51 -0500 Subject: [Freeipa-users] organizational units In-Reply-To: <90f6e8270902261205v6aa6f7f6j7db50534063b11eb@mail.gmail.com> References: <90f6e8270902261205v6aa6f7f6j7db50534063b11eb@mail.gmail.com> Message-ID: <49A82963.20809@redhat.com> Natxo Asenjo wrote: > hi, > > In freeipa 1.2.1 from fedora10, is it possible to create different ou > in the directory server in order to organize the directory for > different branches, like, ou=europe,dc=example,dc=lcom; > ou=asia,dc=example,dc=com etc. Having all users under > cn=users,cn=accounts,dc=example,dc=com can be a bit disorganized. Storing users in one place is on purpose. Trying to separate users by OU, region, etc tends to be difficult because people move a lot, companies reorganize, etc. > Another question: will the webgui have a ldap browser interface? Will > the ipa-admintools be able to create objects in different > ou/containers in the directory? There are no plans for a generic ldap browser. One of the goals is to hide the implementation so we may never provide one. We don't currently support containers. rob From natxo.asenjo at gmail.com Fri Feb 27 18:46:39 2009 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Fri, 27 Feb 2009 19:46:39 +0100 Subject: [Freeipa-users] organizational units In-Reply-To: <49A82963.20809@redhat.com> References: <90f6e8270902261205v6aa6f7f6j7db50534063b11eb@mail.gmail.com> <49A82963.20809@redhat.com> Message-ID: <90f6e8270902271046j4ae6c7e6me191d2a30ab4bdcf@mail.gmail.com> On Fri, Feb 27, 2009 at 6:56 PM, Rob Crittenden wrote: > Natxo Asenjo wrote: >> >> hi, >> >> In freeipa 1.2.1 from fedora10, is it possible to create different ou >> in the directory server in order to organize the directory for >> different branches, like, ou=europe,dc=example,dc=lcom; >> ou=asia,dc=example,dc=com etc. Having all users under >> cn=users,cn=accounts,dc=example,dc=com can be a bit disorganized. > > Storing users in one place is on purpose. Trying to separate users by OU, > region, etc tends to be difficult because people move a lot, companies > reorganize, etc ok, that's an interesting startpoint. So how will policies be implemented then? Excuse my asking, I guess I am a bit used to the AD way of coupling policies to ou's. >> Another question: will the webgui have a ldap browser interface? Will >> the ipa-admintools be able to create objects in different >> ou/containers in the directory? > > There are no plans for a generic ldap browser. One of the goals is to hide > the implementation so we may never provide one. I see. Well, I suppose one can always use any of the available ldap browsers if the need arises.