From freeipa at noboost.org Thu Dec 1 05:31:06 2011 From: freeipa at noboost.org (Craig T) Date: Thu, 1 Dec 2011 16:31:06 +1100 Subject: [Freeipa-users] Solaris 10 as IPA Client? Message-ID: <20111201053106.GA25969@noboost.org> Hi, Anyone had any success using Solaris 10 as a IPA client (using ipa-server-2.1.1-4.el6.x86_64)? Does anyone have any more detailed documentation on the topic? I find that Section "3.3.1. Configuring Solaris 10" from the Identitiy Management Guide very light. #Solaris 10 (Newest Edition) Oracle Solaris 10 8/11 s10x_u10wos_17b X86 Copyright (c) 1983, 2011, Oracle and/or its affiliates. All rights reserved. Assembled 23 August 2011 bash-3.2# ldapclient -v init chtvm-389.teratext.saic.com.au Arguments parsed: defaultServerList: chtvm-389.teratext.saic.com.au Handling init option About to configure machine by downloading a profile No profile specified. Using "default" Proxy DN: NULL Proxy password: NULL Authentication method: 0 No proxyDN/proxyPassword required Shadow Update is not enabled, no adminDN/adminPassword is required. About to modify this machines configuration by writing the files Stopping network services Stopping sendmail stop: sleep 100000 microseconds stop: network/smtp:sendmail... success Stopping nscd stop: sleep 100000 microseconds stop: sleep 200000 microseconds stop: system/name-service-cache:default... success Stopping autofs stop: sleep 100000 microseconds stop: sleep 200000 microseconds stop: sleep 400000 microseconds stop: sleep 800000 microseconds stop: sleep 1600000 microseconds stop: sleep 3200000 microseconds stop: system/filesystem/autofs:default... success ldap not running nisd not running nis(yp) not running file_backup: stat(/etc/nsswitch.conf)=0 file_backup: (/etc/nsswitch.conf -> /var/ldap/restore/nsswitch.conf) file_backup: stat(/etc/defaultdomain)=0 file_backup: (/etc/defaultdomain -> /var/ldap/restore/defaultdomain) file_backup: stat(/var/nis/NIS_COLD_START)=-1 file_backup: No /var/nis/NIS_COLD_START file. file_backup: nis domain is "teratext.saic.com.au" file_backup: stat(/var/yp/binding/teratext.saic.com.au)=-1 file_backup: No /var/yp/binding/teratext.saic.com.au directory. file_backup: stat(/var/ldap/ldap_client_file)=-1 file_backup: No /var/ldap/ldap_client_file file. Starting network services start: /usr/bin/domainname teratext.saic.com.au... success start: sleep 100000 microseconds start: sleep 200000 microseconds start: sleep 400000 microseconds start: sleep 800000 microseconds start: sleep 1600000 microseconds start: sleep 3200000 microseconds start: sleep 6400000 microseconds start: sleep 12800000 microseconds start: sleep 25600000 microseconds start: sleep 51200000 microseconds >>> start: sleep 17700000 microseconds <<<< >>> start: network/ldap/client:default... timed out <<<< >>> start: network/ldap/client:default... offline to disable <<<< >>> stop: sleep 100000 microseconds <<<< stop: sleep 200000 microseconds stop: sleep 400000 microseconds stop: sleep 800000 microseconds stop: sleep 1600000 microseconds stop: sleep 3200000 microseconds stop: sleep 6400000 microseconds stop: sleep 12800000 microseconds stop: sleep 25600000 microseconds stop: sleep 8900000 microseconds stop: network/ldap/client:default... timed out start: sleep 100000 microseconds start: system/filesystem/autofs:default... success start: sleep 100000 microseconds start: system/name-service-cache:default... success start: sleep 100000 microseconds start: sleep 200000 microseconds start: network/smtp:sendmail... success >>> restart: sleep 100000 microseconds <<<< >>> restart: milestone/name-services:default... success <<<< >>> Error resetting system. <<<< >>> Recovering old system settings. <<<< >>> Stopping network services <<<< Stopping sendmail stop: sleep 100000 microseconds stop: network/smtp:sendmail... success Stopping nscd stop: sleep 100000 microseconds stop: sleep 200000 microseconds stop: system/name-service-cache:default... success Stopping autofs stop: sleep 100000 microseconds stop: sleep 200000 microseconds stop: sleep 400000 microseconds stop: sleep 800000 microseconds stop: sleep 1600000 microseconds stop: sleep 3200000 microseconds stop: system/filesystem/autofs:default... success Stopping ldap stop: sleep 100000 microseconds stop: sleep 200000 microseconds stop: sleep 400000 microseconds stop: sleep 800000 microseconds stop: sleep 1600000 microseconds stop: sleep 3200000 microseconds stop: sleep 6400000 microseconds stop: sleep 12800000 microseconds stop: sleep 25600000 microseconds stop: sleep 8900000 microseconds stop: network/ldap/client:default... timed out Stopping ldap failed with (7) Error (1) while stopping services during reset recover: stat(/var/ldap/restore/defaultdomain)=0 recover: open(/var/ldap/restore/defaultdomain) recover: read(/var/ldap/restore/defaultdomain) recover: old domainname "teratext.saic.com.au" recover: stat(/var/ldap/restore/ldap_client_file)=-1 recover: stat(/var/ldap/restore/ldap_client_cred)=-1 recover: stat(/var/ldap/restore/NIS_COLD_START)=-1 recover: stat(/var/ldap/restore/teratext.saic.com.au)=-1 recover: stat(/var/ldap/restore/nsswitch.conf)=0 recover: file_move(/var/ldap/restore/nsswitch.conf, /etc/nsswitch.conf)=0 recover: stat(/var/ldap/restore/defaultdomain)=0 recover: file_move(/var/ldap/restore/defaultdomain, /etc/defaultdomain)=0 Starting network services start: /usr/bin/domainname teratext.saic.com.au... success start: sleep 100000 microseconds start: system/filesystem/autofs:default... success start: sleep 100000 microseconds start: sleep 200000 microseconds start: sleep 400000 microseconds start: system/name-service-cache:default... success start: sleep 100000 microseconds start: network/smtp:sendmail... success restart: sleep 100000 microseconds restart: sleep 200000 microseconds restart: milestone/name-services:default... success Regards, Craig From sigbjorn at nixtra.com Thu Dec 1 10:09:36 2011 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Thu, 1 Dec 2011 11:09:36 +0100 (CET) Subject: [Freeipa-users] Solaris 10 as IPA Client? In-Reply-To: <20111201053106.GA25969@noboost.org> References: <20111201053106.GA25969@noboost.org> Message-ID: <36385.62.148.39.180.1322734176.squirrel@www.nixtra.com> Hi, I use Solaris 10 as clients, several different updates. They all work fine. I have replaced the default DUAConfigProfile though, to include netgroups and automount support, and use SSL authenticated connctions, but the default should work well for basic user and group. Even though it uses unencrypted, unauthenticated connections to the LDAP server. :) Please note that you really need to change /etc/nsswitch.ldap before running the ldapclient script, as this is being copied into /etc/nsswitch.conf by the ldapclient script. The default nsswitch.ldap sets hosts to look from ldap, and removes dns. This does not work with IPA as it relies on DNS for name lookups, and the hosts tables does not exist in IPA's LDAP server. This prevents the ldap client from starting. I've configured my nsswitch.ldap to only look up passwd, group, automount, netgroup and ethers for now. Remember to configure the kerberos client afterwards. AES256 (which is the first KRB encryption type in IPA) was not included in Solaris 10 until Update 8 from what I've read. On these machines I have created keytabs using only AES128 and below for the keytab, and limiting enctypes in krb5.conf using default_tkt_enctypes and default_tgs_enctypes to AES128 and downwards. Regards, Siggi On Thu, December 1, 2011 06:31, Craig T wrote: > Hi, > > > Anyone had any success using Solaris 10 as a IPA client (using ipa-server-2.1.1-4.el6.x86_64)? > Does anyone have any more detailed documentation on the topic? I find that Section "3.3.1. > Configuring Solaris 10" from the Identitiy Management Guide very light. > > > > #Solaris 10 (Newest Edition) > Oracle Solaris 10 8/11 s10x_u10wos_17b X86 > Copyright (c) 1983, 2011, Oracle and/or its affiliates. All rights reserved. > Assembled 23 August 2011 > > > > bash-3.2# ldapclient -v init chtvm-389.teratext.saic.com.au Arguments parsed: > defaultServerList: chtvm-389.teratext.saic.com.au > Handling init option > About to configure machine by downloading a profile > No profile specified. Using "default" > Proxy DN: NULL > Proxy password: NULL > Authentication method: 0 > No proxyDN/proxyPassword required > Shadow Update is not enabled, no adminDN/adminPassword is required. > About to modify this machines configuration by writing the files > Stopping network services > Stopping sendmail > stop: sleep 100000 microseconds > stop: network/smtp:sendmail... success > Stopping nscd > stop: sleep 100000 microseconds > stop: sleep 200000 microseconds > stop: system/name-service-cache:default... success > Stopping autofs > stop: sleep 100000 microseconds > stop: sleep 200000 microseconds > stop: sleep 400000 microseconds > stop: sleep 800000 microseconds > stop: sleep 1600000 microseconds > stop: sleep 3200000 microseconds > stop: system/filesystem/autofs:default... success > ldap not running nisd not running nis(yp) not running file_backup: stat(/etc/nsswitch.conf)=0 > file_backup: (/etc/nsswitch.conf -> /var/ldap/restore/nsswitch.conf) > file_backup: stat(/etc/defaultdomain)=0 > file_backup: (/etc/defaultdomain -> /var/ldap/restore/defaultdomain) > file_backup: stat(/var/nis/NIS_COLD_START)=-1 > file_backup: No /var/nis/NIS_COLD_START file. > file_backup: nis domain is "teratext.saic.com.au" > file_backup: stat(/var/yp/binding/teratext.saic.com.au)=-1 > file_backup: No /var/yp/binding/teratext.saic.com.au directory. > file_backup: stat(/var/ldap/ldap_client_file)=-1 > file_backup: No /var/ldap/ldap_client_file file. > Starting network services > start: /usr/bin/domainname teratext.saic.com.au... success > start: sleep 100000 microseconds > start: sleep 200000 microseconds > start: sleep 400000 microseconds > start: sleep 800000 microseconds > start: sleep 1600000 microseconds > start: sleep 3200000 microseconds > start: sleep 6400000 microseconds > start: sleep 12800000 microseconds > start: sleep 25600000 microseconds > start: sleep 51200000 microseconds > >>>> start: sleep 17700000 microseconds <<<< >>>> start: network/ldap/client:default... timed out <<<< >>>> start: network/ldap/client:default... offline to disable <<<< >>>> stop: sleep 100000 microseconds <<<< >>>> > stop: sleep 200000 microseconds > stop: sleep 400000 microseconds > stop: sleep 800000 microseconds > stop: sleep 1600000 microseconds > stop: sleep 3200000 microseconds > stop: sleep 6400000 microseconds > stop: sleep 12800000 microseconds > stop: sleep 25600000 microseconds > stop: sleep 8900000 microseconds > stop: network/ldap/client:default... timed out > start: sleep 100000 microseconds > start: system/filesystem/autofs:default... success > start: sleep 100000 microseconds > start: system/name-service-cache:default... success > start: sleep 100000 microseconds > start: sleep 200000 microseconds > start: network/smtp:sendmail... success > >>>> restart: sleep 100000 microseconds <<<< >>>> restart: milestone/name-services:default... success <<<< >>>> Error resetting system. <<<< >>>> Recovering old system settings. <<<< >>>> Stopping network services <<<< >>>> > Stopping sendmail > stop: sleep 100000 microseconds > stop: network/smtp:sendmail... success > Stopping nscd > stop: sleep 100000 microseconds > stop: sleep 200000 microseconds > stop: system/name-service-cache:default... success > Stopping autofs > stop: sleep 100000 microseconds > stop: sleep 200000 microseconds > stop: sleep 400000 microseconds > stop: sleep 800000 microseconds > stop: sleep 1600000 microseconds > stop: sleep 3200000 microseconds > stop: system/filesystem/autofs:default... success > Stopping ldap > stop: sleep 100000 microseconds > stop: sleep 200000 microseconds > stop: sleep 400000 microseconds > stop: sleep 800000 microseconds > stop: sleep 1600000 microseconds > stop: sleep 3200000 microseconds > stop: sleep 6400000 microseconds > stop: sleep 12800000 microseconds > stop: sleep 25600000 microseconds > stop: sleep 8900000 microseconds > stop: network/ldap/client:default... timed out > Stopping ldap failed with (7) > Error (1) while stopping services during reset > recover: stat(/var/ldap/restore/defaultdomain)=0 > recover: open(/var/ldap/restore/defaultdomain) > recover: read(/var/ldap/restore/defaultdomain) > recover: old domainname "teratext.saic.com.au" > recover: stat(/var/ldap/restore/ldap_client_file)=-1 > recover: stat(/var/ldap/restore/ldap_client_cred)=-1 > recover: stat(/var/ldap/restore/NIS_COLD_START)=-1 > recover: stat(/var/ldap/restore/teratext.saic.com.au)=-1 > recover: stat(/var/ldap/restore/nsswitch.conf)=0 > recover: file_move(/var/ldap/restore/nsswitch.conf, /etc/nsswitch.conf)=0 > recover: stat(/var/ldap/restore/defaultdomain)=0 > recover: file_move(/var/ldap/restore/defaultdomain, /etc/defaultdomain)=0 > Starting network services > start: /usr/bin/domainname teratext.saic.com.au... success > start: sleep 100000 microseconds > start: system/filesystem/autofs:default... success > start: sleep 100000 microseconds > start: sleep 200000 microseconds > start: sleep 400000 microseconds > start: system/name-service-cache:default... success > start: sleep 100000 microseconds > start: network/smtp:sendmail... success > restart: sleep 100000 microseconds > restart: sleep 200000 microseconds > restart: milestone/name-services:default... success > > > > > Regards, > > > Craig > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > From jhrozek at redhat.com Thu Dec 1 12:46:41 2011 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 1 Dec 2011 13:46:41 +0100 Subject: [Freeipa-users] Limiting group/user visibility In-Reply-To: <4ED61116.1020206@iki.fi> References: <4ED61116.1020206@iki.fi> Message-ID: <20111201124641.GF7875@zeppelin.brq.redhat.com> On Wed, Nov 30, 2011 at 01:18:46PM +0200, Lassi P?l?nen wrote: > Hi, > > I'm looking for implementing FreeIPA in an environment where there are > multiple customers in multiple organizations and a single organization > that manages the users, sets the access rights etc. > > We don't have a centralized system currently so I will be starting from > the scratch in that sense. The first concern I've had so far is that we > don't want different customers to be able to find information about each > other. Currently in my test setup any user can find out every user in a > group if they know the group name and all the groups for each user if > they know the username. In some cases this might reveal information the > customer is not willing to share. > > So are there ways to limit that e.g certain hosts/hostgroups or > users/usergroups see some defined subset of the directory? Or are there > some other suggested approaches? As the current setup relies on local > authentication, users naturally are able to find users/groups only on > servers they are able to log in and that is the level of confidentiality > we are looking for if possible > > > -Lassi P?l?nen > > If you insist on a single instance for multiple organizations, then I agree with Stephen Ingram that the correct way would be to setup ACIs. You could also abuse the ldap_user_search_filter and ldap_group_search_filter parameters to limit NSS lookups performed by SSSD. However, nothing would prevent clients from looking at the directory structure with ldapsearch or using the IPA UI. From sgallagh at redhat.com Thu Dec 1 13:12:31 2011 From: sgallagh at redhat.com (Stephen Gallagher) Date: Thu, 01 Dec 2011 08:12:31 -0500 Subject: [Freeipa-users] Limiting group/user visibility In-Reply-To: <20111201124641.GF7875@zeppelin.brq.redhat.com> References: <4ED61116.1020206@iki.fi> <20111201124641.GF7875@zeppelin.brq.redhat.com> Message-ID: <1322745151.2474.3.camel@sgallagh520.sgallagh.bos.redhat.com> On Thu, 2011-12-01 at 13:46 +0100, Jakub Hrozek wrote: > On Wed, Nov 30, 2011 at 01:18:46PM +0200, Lassi P?l?nen wrote: > > Hi, > > > > I'm looking for implementing FreeIPA in an environment where there are > > multiple customers in multiple organizations and a single organization > > that manages the users, sets the access rights etc. > > > > We don't have a centralized system currently so I will be starting from > > the scratch in that sense. The first concern I've had so far is that we > > don't want different customers to be able to find information about each > > other. Currently in my test setup any user can find out every user in a > > group if they know the group name and all the groups for each user if > > they know the username. In some cases this might reveal information the > > customer is not willing to share. > > > > So are there ways to limit that e.g certain hosts/hostgroups or > > users/usergroups see some defined subset of the directory? Or are there > > some other suggested approaches? As the current setup relies on local > > authentication, users naturally are able to find users/groups only on > > servers they are able to log in and that is the level of confidentiality > > we are looking for if possible > > > > > > -Lassi P?l?nen > > > > > > If you insist on a single instance for multiple organizations, then I > agree with Stephen Ingram that the correct way would be to setup ACIs. > > You could also abuse the ldap_user_search_filter and ldap_group_search_filter > parameters to limit NSS lookups performed by SSSD. However, nothing > would prevent clients from looking at the directory structure with > ldapsearch or using the IPA UI. Please note that the *search_filter options aren't fully functional yet. We're improving them substantially for the 1.7.0 release of SSSD. But Jakub is right: if you manipulate the ACIs of your user entries, then you can restrict which client machines can see those entries. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From lassi.polonen at iki.fi Thu Dec 1 17:01:52 2011 From: lassi.polonen at iki.fi (=?ISO-8859-1?Q?Lassi_P=F6l=F6nen?=) Date: Thu, 01 Dec 2011 19:01:52 +0200 Subject: [Freeipa-users] Limiting group/user visibility In-Reply-To: <1322745151.2474.3.camel@sgallagh520.sgallagh.bos.redhat.com> References: <4ED61116.1020206@iki.fi> <20111201124641.GF7875@zeppelin.brq.redhat.com> <1322745151.2474.3.camel@sgallagh520.sgallagh.bos.redhat.com> Message-ID: <4ED7B300.8000109@iki.fi> On 1.12.2011 15:12, Stephen Gallagher wrote: > On Thu, 2011-12-01 at 13:46 +0100, Jakub Hrozek wrote: >> On Wed, Nov 30, 2011 at 01:18:46PM +0200, Lassi P?l?nen wrote: >>> Hi, >>> >>> I'm looking for implementing FreeIPA in an environment where there are >>> multiple customers in multiple organizations and a single organization >>> that manages the users, sets the access rights etc. >>> >>> We don't have a centralized system currently so I will be starting from >>> the scratch in that sense. The first concern I've had so far is that we >>> don't want different customers to be able to find information about each >>> other. Currently in my test setup any user can find out every user in a >>> group if they know the group name and all the groups for each user if >>> they know the username. In some cases this might reveal information the >>> customer is not willing to share. >>> >>> So are there ways to limit that e.g certain hosts/hostgroups or >>> users/usergroups see some defined subset of the directory? Or are there >>> some other suggested approaches? As the current setup relies on local >>> authentication, users naturally are able to find users/groups only on >>> servers they are able to log in and that is the level of confidentiality >>> we are looking for if possible >>> >>> >>> -Lassi P?l?nen >>> >>> >> If you insist on a single instance for multiple organizations, then I >> agree with Stephen Ingram that the correct way would be to setup ACIs. >> >> You could also abuse the ldap_user_search_filter and ldap_group_search_filter >> parameters to limit NSS lookups performed by SSSD. However, nothing >> would prevent clients from looking at the directory structure with >> ldapsearch or using the IPA UI. > Please note that the *search_filter options aren't fully functional yet. > We're improving them substantially for the 1.7.0 release of SSSD. > > But Jakub is right: if you manipulate the ACIs of your user entries, > then you can restrict which client machines can see those entries. Ok, thanks for the replies. ACIs sound like pretty much the only feasible solution and still less things to maintain than completely dedicated setups. Will look in to 389's documentation for more. From agajania at cs.newpaltz.edu Fri Dec 2 00:02:35 2011 From: agajania at cs.newpaltz.edu (Aram J. Agajanian) Date: Thu, 1 Dec 2011 19:02:35 -0500 Subject: [Freeipa-users] winsync: only synchronize existing user accounts? In-Reply-To: <20111130162158.11c50615@frogn.cs.newpaltz.edu> References: <20111130162158.11c50615@frogn.cs.newpaltz.edu> Message-ID: <20111201190235.107f5568@frogn.cs.newpaltz.edu> On Wed, 30 Nov 2011 16:21:58 -0500 "Aram J. Agajanian" wrote: > > Is is possible to configure an AD synchronization with IPA but only > for existing IPA accounts? > If it's not possible to do this, then I'm considering an alternative plan for authentication. I would have RHEVM authenticate with the campus AD. The Linux workstations would authenticate with a 389 LDAP server which is configured for pass-through authentication to the AD server. I can learn more about IPA and perhaps deploy it over the summer. -- Aram J. Agajanian Computer Science/UNIX Support Academic Computing State University of New York at New Paltz From jo at mediaparadise.net Fri Dec 2 01:07:43 2011 From: jo at mediaparadise.net (Johannes von Bargen) Date: Fri, 02 Dec 2011 02:07:43 +0100 Subject: [Freeipa-users] Using the freeipa 389 ds installation for own stuff Message-ID: <4ED824DF.6000800@mediaparadise.net> Hi! The documentation strongly emphasises that the difference between freeipa and the pre 389 directory server (https://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/introduction.html#comparing). Does it lead to problems if I use the directiory server which is the backend for freeipa for other stuff, like postfix/dovecot users? Greetings, jo -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Fri Dec 2 03:11:02 2011 From: simo at redhat.com (Simo Sorce) Date: Thu, 01 Dec 2011 22:11:02 -0500 Subject: [Freeipa-users] Using the freeipa 389 ds installation for own stuff In-Reply-To: <4ED824DF.6000800@mediaparadise.net> References: <4ED824DF.6000800@mediaparadise.net> Message-ID: <1322795462.22044.72.camel@willson.li.ssimo.org> On Fri, 2011-12-02 at 02:07 +0100, Johannes von Bargen wrote: > Hi! > > The documentation strongly emphasises that the difference between > freeipa and the pre 389 directory server > (https://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/introduction.html#comparing). > Does it lead to problems if I use the directiory server which is the > backend for freeipa for other stuff, like postfix/dovecot users? No it shouldn't as long as user/group creation is done through IPa you shouldn't have issues. You may need to write some customization if you need to add mandatory attributes at user object creation but this has been previously documented in this list. We also have documents on how to extend the FreeIPA framework with new modules in case you wish to create native management interfaces in FreeIPA to manage the objects you need. In order to better future-proof I also suggest you place custom objects in a clearly named subtree (like cn=yourorgname) under the base suffix so that you do not risk conflicts when we add new features in IPA in the future. Simo. -- Simo Sorce * Red Hat, Inc * New York From lassi.polonen at iki.fi Fri Dec 2 06:49:05 2011 From: lassi.polonen at iki.fi (=?ISO-8859-1?Q?Lassi_P=F6l=F6nen?=) Date: Fri, 02 Dec 2011 08:49:05 +0200 Subject: [Freeipa-users] Limiting group/user visibility In-Reply-To: <4ED7B300.8000109@iki.fi> References: <4ED61116.1020206@iki.fi> <20111201124641.GF7875@zeppelin.brq.redhat.com> <1322745151.2474.3.camel@sgallagh520.sgallagh.bos.redhat.com> <4ED7B300.8000109@iki.fi> Message-ID: <4ED874E1.4020802@iki.fi> On 2011-12-01 19:01, Lassi P?l?nen wrote: > On 1.12.2011 15:12, Stephen Gallagher wrote: >> On Thu, 2011-12-01 at 13:46 +0100, Jakub Hrozek wrote: >>> On Wed, Nov 30, 2011 at 01:18:46PM +0200, Lassi P?l?nen wrote: >>>> Hi, >>>> >>>> I'm looking for implementing FreeIPA in an environment where there are >>>> multiple customers in multiple organizations and a single organization >>>> that manages the users, sets the access rights etc. >>>> >>>> We don't have a centralized system currently so I will be starting >>>> from >>>> the scratch in that sense. The first concern I've had so far is >>>> that we >>>> don't want different customers to be able to find information about >>>> each >>>> other. Currently in my test setup any user can find out every user >>>> in a >>>> group if they know the group name and all the groups for each user if >>>> they know the username. In some cases this might reveal information >>>> the >>>> customer is not willing to share. >>>> >>>> So are there ways to limit that e.g certain hosts/hostgroups or >>>> users/usergroups see some defined subset of the directory? Or are >>>> there >>>> some other suggested approaches? As the current setup relies on local >>>> authentication, users naturally are able to find users/groups only on >>>> servers they are able to log in and that is the level of >>>> confidentiality >>>> we are looking for if possible >>>> >>>> >>>> -Lassi P?l?nen >>>> >>>> >>> If you insist on a single instance for multiple organizations, then I >>> agree with Stephen Ingram that the correct way would be to setup ACIs. >>> >>> You could also abuse the ldap_user_search_filter and >>> ldap_group_search_filter >>> parameters to limit NSS lookups performed by SSSD. However, nothing >>> would prevent clients from looking at the directory structure with >>> ldapsearch or using the IPA UI. >> Please note that the *search_filter options aren't fully functional yet. >> We're improving them substantially for the 1.7.0 release of SSSD. >> >> But Jakub is right: if you manipulate the ACIs of your user entries, >> then you can restrict which client machines can see those entries. > > Ok, thanks for the replies. ACIs sound like pretty much the only > feasible solution and still less things to maintain than completely > dedicated setups. Will look in to 389's documentation for more. > Replying to myself.. Actually I would think my goal would be pretty typical setup for managed hosting companies like us as we are the ones who manage all the accounts and servers for our customer organizations. We grant customer access to servers we host and we should have our own accounts on every server as well. Running multiple domains in this case means we would need to replicate our admin accounts to every domain (not sure if there's even a feasible solution to do that) and also manage customer accounts on multiple FreeIPA installations. Running a single domain would make it easier to provide a single account for customers for services that are common to every customer, e.g ticketing system, wikis and so on. It's just that they shouldn't be able to know about each other. Anyway, looking at macro ACIs, it at least looks like it's possible to accomplish with a few pretty simple rules. From root at nachtmaus.us Fri Dec 2 14:01:07 2011 From: root at nachtmaus.us (david t. klein) Date: Fri, 2 Dec 2011 08:01:07 -0600 Subject: [Freeipa-users] Limiting group/user visibility In-Reply-To: <4ED874E1.4020802@iki.fi> References: <4ED61116.1020206@iki.fi> <20111201124641.GF7875@zeppelin.brq.redhat.com> <1322745151.2474.3.camel@sgallagh520.sgallagh.bos.redhat.com> <4ED7B300.8000109@iki.fi> <4ED874E1.4020802@iki.fi> Message-ID: <064901ccb0fa$d7d736a0$8785a3e0$@us> I think, rather than replicating your admin accounts, have a separate admin realm, and then have all customer realms trust your admin realm, and use those credentials. -DTK -- david t. klein Cisco Certified Network Associate (CSCO11281885) Linux Professional Institute Certification (LPI000165615) Redhat Certified Engineer (805009745938860) Quis custodiet ipsos custodes? -----Original Message----- From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Lassi P?l?nen Sent: Friday, December 02, 2011 12:49 AM To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Limiting group/user visibility On 2011-12-01 19:01, Lassi P?l?nen wrote: > On 1.12.2011 15:12, Stephen Gallagher wrote: >> On Thu, 2011-12-01 at 13:46 +0100, Jakub Hrozek wrote: >>> On Wed, Nov 30, 2011 at 01:18:46PM +0200, Lassi P?l?nen wrote: >>>> Hi, >>>> >>>> I'm looking for implementing FreeIPA in an environment where there are >>>> multiple customers in multiple organizations and a single organization >>>> that manages the users, sets the access rights etc. >>>> >>>> We don't have a centralized system currently so I will be starting >>>> from >>>> the scratch in that sense. The first concern I've had so far is >>>> that we >>>> don't want different customers to be able to find information about >>>> each >>>> other. Currently in my test setup any user can find out every user >>>> in a >>>> group if they know the group name and all the groups for each user if >>>> they know the username. In some cases this might reveal information >>>> the >>>> customer is not willing to share. >>>> >>>> So are there ways to limit that e.g certain hosts/hostgroups or >>>> users/usergroups see some defined subset of the directory? Or are >>>> there >>>> some other suggested approaches? As the current setup relies on local >>>> authentication, users naturally are able to find users/groups only on >>>> servers they are able to log in and that is the level of >>>> confidentiality >>>> we are looking for if possible >>>> >>>> >>>> -Lassi P?l?nen >>>> >>>> >>> If you insist on a single instance for multiple organizations, then I >>> agree with Stephen Ingram that the correct way would be to setup ACIs. >>> >>> You could also abuse the ldap_user_search_filter and >>> ldap_group_search_filter >>> parameters to limit NSS lookups performed by SSSD. However, nothing >>> would prevent clients from looking at the directory structure with >>> ldapsearch or using the IPA UI. >> Please note that the *search_filter options aren't fully functional yet. >> We're improving them substantially for the 1.7.0 release of SSSD. >> >> But Jakub is right: if you manipulate the ACIs of your user entries, >> then you can restrict which client machines can see those entries. > > Ok, thanks for the replies. ACIs sound like pretty much the only > feasible solution and still less things to maintain than completely > dedicated setups. Will look in to 389's documentation for more. > Replying to myself.. Actually I would think my goal would be pretty typical setup for managed hosting companies like us as we are the ones who manage all the accounts and servers for our customer organizations. We grant customer access to servers we host and we should have our own accounts on every server as well. Running multiple domains in this case means we would need to replicate our admin accounts to every domain (not sure if there's even a feasible solution to do that) and also manage customer accounts on multiple FreeIPA installations. Running a single domain would make it easier to provide a single account for customers for services that are common to every customer, e.g ticketing system, wikis and so on. It's just that they shouldn't be able to know about each other. Anyway, looking at macro ACIs, it at least looks like it's possible to accomplish with a few pretty simple rules. _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users From sgallagh at redhat.com Fri Dec 2 14:15:32 2011 From: sgallagh at redhat.com (Stephen Gallagher) Date: Fri, 02 Dec 2011 09:15:32 -0500 Subject: [Freeipa-users] IMPORTANT: Your input requested: SSSD LDAP Provider vs Winbind Message-ID: <1322835332.2194.19.camel@sgallagh520.sgallagh.bos.redhat.com> When we originally designed SSSD, we looked at it as a solution for dealing with LDAP and Kerberos identity and authentication for Linux and UNIX clients. With our initial approach, we decided to include only marginal support for Microsoft's Active Directory as a source of user information (only supporting it when it is enabled for use with posixAccount and posixGroup object classes). Our original assumption was that for complicated deployments relying on Active Directory, users would prefer to continue using Winbind. It has a very long history and is specifically designed around managing the peculiarities of Microsoft's LDAP implementation. Of late, it has become apparent that many users are opting to "jump ship" from winbind to SSSD for use with Active Directory. This has been shown by a sharp uptick in community bug reports with Active Directory servers. Up until now, our plans around Active Directory have circulated around including a "Winbind Provider" into SSSD, similar to the LDAP provider but making use of the original winbind features found in the Samba project. However, it's beginning to seem like users are expressing an interest to move AWAY from that solution. This may result in a change in our strategy going forward. I'm looking for users to describe to us the reasons why they're choosing SSSD (in its current incarnation) over winbind. What I'm trying to sort out is whether there are specific *issues* with winbind that SSSD is solving for users. In other words, I'm trying to determine whether our decision to write and support a winbind provider backend is misplaced. It may be that if SSSD's LDAP provider is offering a significant advantage over winbind, we will consider dropping (or deferring) our efforts to integrate winbind and instead put that effort into adding Active Directory-specific features into the LDAP provider. For example, we might reprioritize bugs https://fedorahosted.org/sssd/ticket/995 and https://fedorahosted.org/sssd/ticket/996 So please, share with us your stories for why you prefer SSSD over winbind and help us choose our direction for SSSD's future. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From ondrejv at s3group.cz Fri Dec 2 14:36:26 2011 From: ondrejv at s3group.cz (Ondrej Valousek) Date: Fri, 02 Dec 2011 15:36:26 +0100 Subject: [Freeipa-users] IMPORTANT: Your input requested: SSSD LDAP Provider vs Winbind In-Reply-To: <1322835332.2194.19.camel@sgallagh520.sgallagh.bos.redhat.com> References: <1322835332.2194.19.camel@sgallagh520.sgallagh.bos.redhat.com> Message-ID: <4ED8E26A.40200@s3group.cz> My story is here: https://bugzilla.redhat.com/show_bug.cgi?id=652609 And it seems to go nowhere. So, in quick - I still believe winbind is a piece of crap really (Simo forgives) for the reasons outlined above in the link. For the same reasons I believe you, SSSD engineers, are wasting your time with the winbind plugin. If configured properly, sssd can do a much better job. Now I do not know how much AD differs from the IPA domain from the SSSD prospective - so I do not know how much extra work is needed to be able to properly cope with AD, but I still believe some of the code can be later re-used for pure IPA domains (see the AD sites in DNS for example). So in short again, I think SSSD should continue to concentrate its main effort in the IPA integration because we (Linux community) currently do not have anything else to match Active Directory - and if we get an SSSD-AD integration as a side-effect, well, a nice bonus! :-) Ondrej On 12/02/2011 03:15 PM, Stephen Gallagher wrote: > When we originally designed SSSD, we looked at it as a solution for > dealing with LDAP and Kerberos identity and authentication for Linux and > UNIX clients. With our initial approach, we decided to include only > marginal support for Microsoft's Active Directory as a source of user > information (only supporting it when it is enabled for use with > posixAccount and posixGroup object classes). > > Our original assumption was that for complicated deployments relying on > Active Directory, users would prefer to continue using Winbind. It has a > very long history and is specifically designed around managing the > peculiarities of Microsoft's LDAP implementation. > > Of late, it has become apparent that many users are opting to "jump > ship" from winbind to SSSD for use with Active Directory. This has been > shown by a sharp uptick in community bug reports with Active Directory > servers. > > Up until now, our plans around Active Directory have circulated around > including a "Winbind Provider" into SSSD, similar to the LDAP provider > but making use of the original winbind features found in the Samba > project. However, it's beginning to seem like users are expressing an > interest to move AWAY from that solution. > > This may result in a change in our strategy going forward. I'm looking > for users to describe to us the reasons why they're choosing SSSD (in > its current incarnation) over winbind. What I'm trying to sort out is > whether there are specific *issues* with winbind that SSSD is solving > for users. In other words, I'm trying to determine whether our decision > to write and support a winbind provider backend is misplaced. > > It may be that if SSSD's LDAP provider is offering a significant > advantage over winbind, we will consider dropping (or deferring) our > efforts to integrate winbind and instead put that effort into adding > Active Directory-specific features into the LDAP provider. For example, > we might reprioritize bugs https://fedorahosted.org/sssd/ticket/995 and > https://fedorahosted.org/sssd/ticket/996 > > So please, share with us your stories for why you prefer SSSD over > winbind and help us choose our direction for SSSD's future. > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications at s3group.com. Thank You. Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ondrejv at s3group.cz Fri Dec 2 14:59:19 2011 From: ondrejv at s3group.cz (Ondrej Valousek) Date: Fri, 02 Dec 2011 15:59:19 +0100 Subject: [Freeipa-users] IMPORTANT: Your input requested: SSSD LDAP Provider vs Winbind In-Reply-To: <4ED8E26A.40200@s3group.cz> References: <1322835332.2194.19.camel@sgallagh520.sgallagh.bos.redhat.com> <4ED8E26A.40200@s3group.cz> Message-ID: <4ED8E7C7.7070508@s3group.cz> Small update so I am not only throwing dirt on winbind: Winbind has still its use if you can not use / do not have RFC2307 attributes in AD. So simply, if you want to use RFC2307 attributes, sssd is here for you. If not, go for winbind. But yet I would not bother about winbind plugin for sssd as it does not make too much sense - that's why we have Glibc and its /etc/nsswitch.conf! My 5 cents. Ondrej On 12/02/2011 03:36 PM, Ondrej Valousek wrote: > My story is here: > > https://bugzilla.redhat.com/show_bug.cgi?id=652609 > > And it seems to go nowhere. So, in quick - I still believe winbind is a piece of crap really (Simo forgives) for the reasons outlined > above in the link. > For the same reasons I believe you, SSSD engineers, are wasting your time with the winbind plugin. > If configured properly, sssd can do a much better job. > > Now I do not know how much AD differs from the IPA domain from the SSSD prospective - so I do not know how much extra work is needed to be > able to properly cope with AD, but I still believe some of the code can be later re-used for pure IPA domains (see the AD sites in DNS for > example). > > So in short again, I think SSSD should continue to concentrate its main effort in the IPA integration because we (Linux community) > currently do not have anything else to match Active Directory - and if we get an SSSD-AD integration as a side-effect, well, a nice bonus! > :-) > > Ondrej > > > > > On 12/02/2011 03:15 PM, Stephen Gallagher wrote: >> When we originally designed SSSD, we looked at it as a solution for >> dealing with LDAP and Kerberos identity and authentication for Linux and >> UNIX clients. With our initial approach, we decided to include only >> marginal support for Microsoft's Active Directory as a source of user >> information (only supporting it when it is enabled for use with >> posixAccount and posixGroup object classes). >> >> Our original assumption was that for complicated deployments relying on >> Active Directory, users would prefer to continue using Winbind. It has a >> very long history and is specifically designed around managing the >> peculiarities of Microsoft's LDAP implementation. >> >> Of late, it has become apparent that many users are opting to "jump >> ship" from winbind to SSSD for use with Active Directory. This has been >> shown by a sharp uptick in community bug reports with Active Directory >> servers. >> >> Up until now, our plans around Active Directory have circulated around >> including a "Winbind Provider" into SSSD, similar to the LDAP provider >> but making use of the original winbind features found in the Samba >> project. However, it's beginning to seem like users are expressing an >> interest to move AWAY from that solution. >> >> This may result in a change in our strategy going forward. I'm looking >> for users to describe to us the reasons why they're choosing SSSD (in >> its current incarnation) over winbind. What I'm trying to sort out is >> whether there are specific *issues* with winbind that SSSD is solving >> for users. In other words, I'm trying to determine whether our decision >> to write and support a winbind provider backend is misplaced. >> >> It may be that if SSSD's LDAP provider is offering a significant >> advantage over winbind, we will consider dropping (or deferring) our >> efforts to integrate winbind and instead put that effort into adding >> Active Directory-specific features into the LDAP provider. For example, >> we might reprioritize bugshttps://fedorahosted.org/sssd/ticket/995 and >> https://fedorahosted.org/sssd/ticket/996 >> >> So please, share with us your stories for why you prefer SSSD over >> winbind and help us choose our direction for SSSD's future. >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > -------------------------------------------------------------------------------------------------------------------------------------------- > The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended > recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part > thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from > your computer system(s). Please direct any additional queries to: communications at s3group.com. Thank You. Silicon and Software Systems > Limited (S3 Group). Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18 > -------------------------------------------------------------------------------------------------------------------------------------------- > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications at s3group.com. Thank You. Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgallagh at redhat.com Fri Dec 2 15:06:43 2011 From: sgallagh at redhat.com (Stephen Gallagher) Date: Fri, 02 Dec 2011 10:06:43 -0500 Subject: [Freeipa-users] IMPORTANT: Your input requested: SSSD LDAP Provider vs Winbind In-Reply-To: <4ED8E7C7.7070508@s3group.cz> References: <1322835332.2194.19.camel@sgallagh520.sgallagh.bos.redhat.com> <4ED8E26A.40200@s3group.cz> <4ED8E7C7.7070508@s3group.cz> Message-ID: <1322838403.2194.21.camel@sgallagh520.sgallagh.bos.redhat.com> On Fri, 2011-12-02 at 15:59 +0100, Ondrej Valousek wrote: > Small update so I am not only throwing dirt on winbind: > > Winbind has still its use if you can not use / do not have RFC2307 > attributes in AD. > So simply, if you want to use RFC2307 attributes, sssd is here for > you. If not, go for winbind. But yet I would not bother about winbind > plugin for sssd as it does not make too much sense - that's why we > have Glibc and its /etc/nsswitch.conf! Well, just to make one point, there are a few advantages to the winbind backend over pure winbind: 1) SSSD caching instead of nscd 2) Support for multiple AD domains without trust 3) One-to-one mapping of identity domain to authentication domain (so you're not exposing your password to multiple authentication domains until you find the right one, as with traditional PAM). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From ondrejv at s3group.cz Fri Dec 2 15:26:41 2011 From: ondrejv at s3group.cz (Ondrej Valousek) Date: Fri, 02 Dec 2011 16:26:41 +0100 Subject: [Freeipa-users] IMPORTANT: Your input requested: SSSD LDAP Provider vs Winbind In-Reply-To: <1322838403.2194.21.camel@sgallagh520.sgallagh.bos.redhat.com> References: <1322835332.2194.19.camel@sgallagh520.sgallagh.bos.redhat.com> <4ED8E26A.40200@s3group.cz> <4ED8E7C7.7070508@s3group.cz> <1322838403.2194.21.camel@sgallagh520.sgallagh.bos.redhat.com> Message-ID: <4ED8EE31.4030209@s3group.cz> On 12/02/2011 04:06 PM, Stephen Gallagher wrote: > 1) SSSD caching instead of nscd Winbind has its own cache. We do not want to implement the yet another one causing confusion, do we? > 2) Support for multiple AD domains without trust If needed, winbind itself should provide this functionality. > 3) One-to-one mapping of identity domain to authentication domain (so > you're not exposing your password to multiple authentication domains > until you find the right one, as with traditional PAM). Yes, That's true, but honestly, who is using it, is it worth the effort? I am not saying no, of course, everything has its own special use. What I think that we need is the *simplicity*. We need to have a clear and simple rules where to go if windows/ipa/... backend is needed. Most system admins see sssd as a cleverer libnss_ldap.so provider - and that is how it should stay, I believe.... Ondrej The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications at s3group.com. Thank You. Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18 -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Fri Dec 2 15:41:46 2011 From: simo at redhat.com (Simo Sorce) Date: Fri, 02 Dec 2011 10:41:46 -0500 Subject: [Freeipa-users] Limiting group/user visibility In-Reply-To: <064901ccb0fa$d7d736a0$8785a3e0$@us> References: <4ED61116.1020206@iki.fi> <20111201124641.GF7875@zeppelin.brq.redhat.com> <1322745151.2474.3.camel@sgallagh520.sgallagh.bos.redhat.com> <4ED7B300.8000109@iki.fi> <4ED874E1.4020802@iki.fi> <064901ccb0fa$d7d736a0$8785a3e0$@us> Message-ID: <1322840506.6745.25.camel@willson.li.ssimo.org> On Fri, 2011-12-02 at 08:01 -0600, david t. klein wrote: > I think, rather than replicating your admin accounts, have a separate admin > realm, and then have all customer realms trust your admin realm, and use > those credentials. In future this will be an easier way. But right now trust relationships won't allow you to use a single admin account to actually manage multiple freeipa realms. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Fri Dec 2 15:50:49 2011 From: simo at redhat.com (Simo Sorce) Date: Fri, 02 Dec 2011 10:50:49 -0500 Subject: [Freeipa-users] IMPORTANT: Your input requested: SSSD LDAP Provider vs Winbind In-Reply-To: <1322838403.2194.21.camel@sgallagh520.sgallagh.bos.redhat.com> References: <1322835332.2194.19.camel@sgallagh520.sgallagh.bos.redhat.com> <4ED8E26A.40200@s3group.cz> <4ED8E7C7.7070508@s3group.cz> <1322838403.2194.21.camel@sgallagh520.sgallagh.bos.redhat.com> Message-ID: <1322841049.6745.33.camel@willson.li.ssimo.org> On Fri, 2011-12-02 at 10:06 -0500, Stephen Gallagher wrote: > On Fri, 2011-12-02 at 15:59 +0100, Ondrej Valousek wrote: > > Small update so I am not only throwing dirt on winbind: > > > > Winbind has still its use if you can not use / do not have RFC2307 > > attributes in AD. > > So simply, if you want to use RFC2307 attributes, sssd is here for > > you. If not, go for winbind. But yet I would not bother about winbind > > plugin for sssd as it does not make too much sense - that's why we > > have Glibc and its /etc/nsswitch.conf! > > Well, just to make one point, there are a few advantages to the winbind > backend over pure winbind: > > 1) SSSD caching instead of nscd Winbindd has its own caching and nscd use is not recommend with Winbindd either. > 2) Support for multiple AD domains without trust But complete lack of support of multiple trusted domains which is extremely common on Windows networks. > 3) One-to-one mapping of identity domain to authentication domain (so > you're not exposing your password to multiple authentication domains > until you find the right one, as with traditional PAM). Well this is interesting only if you have multiple unrelated identity domains to care about, I wouldn't count this as something better/worse than what Winbindd provides, Winbindd is clearly built for a single Ad domain which is the norm and the point is already captured in 2. 4) Winbindd can use MS-RPC to handle legacy NT/Samba3 domains and NTLM authentication. SSSD has no support for any of that nor Site discovery ala Windows way etc ... I do not want to say one is better than the other, they are different. When I architected SSSD I was full aware of both Winbind limitations and good features. The point is that AD domain support was not a goal for SSSD and so it was not built to support multiple trusted domain through one provider or Windows like domains. This is changing to some degree so SSSD may grow that ability. I am neutral to whether we should integrate winbindd through a plugin or re-implement its functionality, I can see positive and negative aspects in both approaches and I really do not have a strong preference at this stage. Simo. -- Simo Sorce * Red Hat, Inc * New York From lassi.polonen at iki.fi Sat Dec 3 10:52:42 2011 From: lassi.polonen at iki.fi (=?UTF-8?B?TGFzc2kgUMO2bMO2bmVu?=) Date: Sat, 03 Dec 2011 12:52:42 +0200 Subject: [Freeipa-users] Limiting group/user visibility In-Reply-To: <1322840506.6745.25.camel@willson.li.ssimo.org> References: <4ED61116.1020206@iki.fi> <20111201124641.GF7875@zeppelin.brq.redhat.com> <1322745151.2474.3.camel@sgallagh520.sgallagh.bos.redhat.com> <4ED7B300.8000109@iki.fi> <4ED874E1.4020802@iki.fi> <064901ccb0fa$d7d736a0$8785a3e0$@us> <1322840506.6745.25.camel@willson.li.ssimo.org> Message-ID: <4ED9FF7A.2080502@iki.fi> On 2.12.2011 17:41, Simo Sorce wrote: > On Fri, 2011-12-02 at 08:01 -0600, david t. klein wrote: >> I think, rather than replicating your admin accounts, have a separate admin >> realm, and then have all customer realms trust your admin realm, and use >> those credentials. > In future this will be an easier way. > But right now trust relationships won't allow you to use a single admin > account to actually manage multiple freeipa realms. > > Simo. From my point of view the fact that a single instance is only able to run a single realm is even a bigger issue. But I think we can accomplish what we need with pretty simple ACIs since the need for limiting the visibility isn't too complex and follows the same pattern with every customer. -Lassi From jo at mediaparadise.net Sat Dec 3 16:07:54 2011 From: jo at mediaparadise.net (Johannes von Bargen) Date: Sat, 03 Dec 2011 17:07:54 +0100 Subject: [Freeipa-users] Using the freeipa 389 ds installation for own stuff In-Reply-To: <1322795462.22044.72.camel@willson.li.ssimo.org> References: <4ED824DF.6000800@mediaparadise.net> <1322795462.22044.72.camel@willson.li.ssimo.org> Message-ID: <4EDA495A.3010406@mediaparadise.net> Am 02.12.11 04:11, schrieb Simo Sorce: > On Fri, 2011-12-02 at 02:07 +0100, Johannes von Bargen wrote: >> Hi! >> >> The documentation strongly emphasises that the difference between >> freeipa and the pre 389 directory server >> (https://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/introduction.html#comparing). >> Does it lead to problems if I use the directiory server which is the >> backend for freeipa for other stuff, like postfix/dovecot users? > No it shouldn't as long as user/group creation is done through IPa you > shouldn't have issues. > > You may need to write some customization if you need to add mandatory > attributes at user object creation but this has been previously > documented in this list. > > We also have documents on how to extend the FreeIPA framework with new > modules in case you wish to create native management interfaces in > FreeIPA to manage the objects you need. > > In order to better future-proof I also suggest you place custom objects > in a clearly named subtree (like cn=yourorgname) under the base suffix > so that you do not risk conflicts when we add new features in IPA in the > future. > > Simo. > Thank you! From dpal at redhat.com Sat Dec 3 18:32:58 2011 From: dpal at redhat.com (Dmitri Pal) Date: Sat, 03 Dec 2011 13:32:58 -0500 Subject: [Freeipa-users] Replica and CA mess In-Reply-To: <4ED3D19F.6040409@nixtra.com> References: <4ED278FE.2010705@nixtra.com> <4ED39A07.1090006@redhat.com> <4ED3D19F.6040409@nixtra.com> Message-ID: <4EDA6B5A.1060807@redhat.com> On 11/28/2011 01:23 PM, Sigbjorn Lie wrote: > HTTP Server: port 443(https) (443): OK > > All ports except 389 fails when the master is IPv6 enabled, but the > replica is only IPv4 enabled. > > Directory Service: Unsecure port (389): OK > Directory Service: Secure port (636): FAILED > Kerberos KDC: TCP (88): FAILED > Kerberos KDC: UDP (88): FAILED > Kerberos Kpasswd: TCP (464): FAILED > Kerberos Kpasswd: UDP (464): FAILED > HTTP Server: port 80 (80): FAILED > HTTP Server: port 443(https) (443): FAILED > > Switching to IPv4 only addresses in resolv.conf resolves the issue. > > Do we have a bug/ticket open on this? > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Sat Dec 3 18:44:59 2011 From: dpal at redhat.com (Dmitri Pal) Date: Sat, 03 Dec 2011 13:44:59 -0500 Subject: [Freeipa-users] Some feature requests In-Reply-To: <833D8E48405E064EBC54C84EC6B36E404C428565@STAWINCOX10MBX4.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E404C4284ED@STAWINCOX10MBX4.staff.vuw.ac.nz>, <4ED3FDD3.6090809@redhat.com> <833D8E48405E064EBC54C84EC6B36E404C428565@STAWINCOX10MBX4.staff.vuw.ac.nz> Message-ID: <4EDA6E2B.1020607@redhat.com> On 11/28/2011 04:36 PM, Steven Jones wrote: > I cant see anything in the glster admin guide on connecting it to a IPA setup... > We will be working with them but it will take some time. Would be nice to have RFEs for those components filed. As for kickstart any ipa-client invocation requires and authentication. You either need to do it manually or in some way add OTP to the kickstart file. At best OTP should be one per machine but you can reuse it for a group of machines. This seems to be a problem that can only be solved by the individual admin depending on the constraints of his environment. I do not think this has a generic solution. > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > ________________________________________ > From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Adam Young [ayoung at redhat.com] > Sent: Tuesday, 29 November 2011 10:32 a.m. > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Some feature requests > > On 11/28/2011 04:16 PM, Steven Jones wrote: >> Hi, >> >> a) Auto setup in RH satellite to allow auto joining to freeIPA from a baremetal kickstart. > That is a Satellite, not FreeIPA, request. > >> b) Setup/config (info etc) to allow a gluster system to join to IPA. > What would a gluster system require that we do not already provide? > >> Since these are all RH...shouldn't be too hard. >> >> ;] >> >> regards >> >> Steven Jones >> >> Technical Specialist - Linux RHCE >> >> Victoria University, Wellington, NZ >> >> 0064 4 463 6272 >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Sat Dec 3 18:50:20 2011 From: dpal at redhat.com (Dmitri Pal) Date: Sat, 03 Dec 2011 13:50:20 -0500 Subject: [Freeipa-users] winsync: only synchronize existing user accounts? In-Reply-To: <20111201190235.107f5568@frogn.cs.newpaltz.edu> References: <20111130162158.11c50615@frogn.cs.newpaltz.edu> <20111201190235.107f5568@frogn.cs.newpaltz.edu> Message-ID: <4EDA6F6C.4070305@redhat.com> On 12/01/2011 07:02 PM, Aram J. Agajanian wrote: > On Wed, 30 Nov 2011 16:21:58 -0500 > "Aram J. Agajanian" wrote: > >> Is is possible to configure an AD synchronization with IPA but only >> for existing IPA accounts? >> > If it's not possible to do this, then I'm considering an alternative > plan for authentication. I would have RHEVM authenticate with the > campus AD. The Linux workstations would authenticate with a 389 LDAP > server which is configured for pass-through authentication to the AD > server. > > I can learn more about IPA and perhaps deploy it over the summer. > > It does it by sub-trees. So if the users that need to be synchronized can be put into a subtree then you can do it. -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Sat Dec 3 18:52:39 2011 From: dpal at redhat.com (Dmitri Pal) Date: Sat, 03 Dec 2011 13:52:39 -0500 Subject: [Freeipa-users] Solaris 10 as IPA Client? In-Reply-To: <36385.62.148.39.180.1322734176.squirrel@www.nixtra.com> References: <20111201053106.GA25969@noboost.org> <36385.62.148.39.180.1322734176.squirrel@www.nixtra.com> Message-ID: <4EDA6FF7.8050400@redhat.com> On 12/01/2011 05:09 AM, Sigbjorn Lie wrote: > Hi, > > I use Solaris 10 as clients, several different updates. They all work fine. I have replaced the > default DUAConfigProfile though, to include netgroups and automount support, and use SSL > authenticated connctions, but the default should work well for basic user and group. Even though > it uses unencrypted, unauthenticated connections to the LDAP server. :) > > Please note that you really need to change /etc/nsswitch.ldap before running the ldapclient > script, as this is being copied into /etc/nsswitch.conf by the ldapclient script. The default > nsswitch.ldap sets hosts to look from ldap, and removes dns. This does not work with IPA as it > relies on DNS for name lookups, and the hosts tables does not exist in IPA's LDAP server. This > prevents the ldap client from starting. > > I've configured my nsswitch.ldap to only look up passwd, group, automount, netgroup and ethers for > now. > > Remember to configure the kerberos client afterwards. AES256 (which is the first KRB encryption > type in IPA) was not included in Solaris 10 until Update 8 from what I've read. On these machines > I have created keytabs using only AES128 and below for the keytab, and limiting enctypes in > krb5.conf using default_tkt_enctypes and default_tgs_enctypes to AES128 and downwards. > > Also Solaris assumes 2307 schema AFAIR and IPA is 2307bis. So you need to enable compat tree on ipa side and point your Solaris nss_ldap to the compat tree. > Regards, > Siggi > > > > > > > On Thu, December 1, 2011 06:31, Craig T wrote: >> Hi, >> >> >> Anyone had any success using Solaris 10 as a IPA client (using ipa-server-2.1.1-4.el6.x86_64)? >> Does anyone have any more detailed documentation on the topic? I find that Section "3.3.1. >> Configuring Solaris 10" from the Identitiy Management Guide very light. >> >> >> >> #Solaris 10 (Newest Edition) >> Oracle Solaris 10 8/11 s10x_u10wos_17b X86 >> Copyright (c) 1983, 2011, Oracle and/or its affiliates. All rights reserved. >> Assembled 23 August 2011 >> >> >> >> bash-3.2# ldapclient -v init chtvm-389.teratext.saic.com.au Arguments parsed: >> defaultServerList: chtvm-389.teratext.saic.com.au >> Handling init option >> About to configure machine by downloading a profile >> No profile specified. Using "default" >> Proxy DN: NULL >> Proxy password: NULL >> Authentication method: 0 >> No proxyDN/proxyPassword required >> Shadow Update is not enabled, no adminDN/adminPassword is required. >> About to modify this machines configuration by writing the files >> Stopping network services >> Stopping sendmail >> stop: sleep 100000 microseconds >> stop: network/smtp:sendmail... success >> Stopping nscd >> stop: sleep 100000 microseconds >> stop: sleep 200000 microseconds >> stop: system/name-service-cache:default... success >> Stopping autofs >> stop: sleep 100000 microseconds >> stop: sleep 200000 microseconds >> stop: sleep 400000 microseconds >> stop: sleep 800000 microseconds >> stop: sleep 1600000 microseconds >> stop: sleep 3200000 microseconds >> stop: system/filesystem/autofs:default... success >> ldap not running nisd not running nis(yp) not running file_backup: stat(/etc/nsswitch.conf)=0 >> file_backup: (/etc/nsswitch.conf -> /var/ldap/restore/nsswitch.conf) >> file_backup: stat(/etc/defaultdomain)=0 >> file_backup: (/etc/defaultdomain -> /var/ldap/restore/defaultdomain) >> file_backup: stat(/var/nis/NIS_COLD_START)=-1 >> file_backup: No /var/nis/NIS_COLD_START file. >> file_backup: nis domain is "teratext.saic.com.au" >> file_backup: stat(/var/yp/binding/teratext.saic.com.au)=-1 >> file_backup: No /var/yp/binding/teratext.saic.com.au directory. >> file_backup: stat(/var/ldap/ldap_client_file)=-1 >> file_backup: No /var/ldap/ldap_client_file file. >> Starting network services >> start: /usr/bin/domainname teratext.saic.com.au... success >> start: sleep 100000 microseconds >> start: sleep 200000 microseconds >> start: sleep 400000 microseconds >> start: sleep 800000 microseconds >> start: sleep 1600000 microseconds >> start: sleep 3200000 microseconds >> start: sleep 6400000 microseconds >> start: sleep 12800000 microseconds >> start: sleep 25600000 microseconds >> start: sleep 51200000 microseconds >> >>>>> start: sleep 17700000 microseconds <<<< >>>>> start: network/ldap/client:default... timed out <<<< >>>>> start: network/ldap/client:default... offline to disable <<<< >>>>> stop: sleep 100000 microseconds <<<< >>>>> >> stop: sleep 200000 microseconds >> stop: sleep 400000 microseconds >> stop: sleep 800000 microseconds >> stop: sleep 1600000 microseconds >> stop: sleep 3200000 microseconds >> stop: sleep 6400000 microseconds >> stop: sleep 12800000 microseconds >> stop: sleep 25600000 microseconds >> stop: sleep 8900000 microseconds >> stop: network/ldap/client:default... timed out >> start: sleep 100000 microseconds >> start: system/filesystem/autofs:default... success >> start: sleep 100000 microseconds >> start: system/name-service-cache:default... success >> start: sleep 100000 microseconds >> start: sleep 200000 microseconds >> start: network/smtp:sendmail... success >> >>>>> restart: sleep 100000 microseconds <<<< >>>>> restart: milestone/name-services:default... success <<<< >>>>> Error resetting system. <<<< >>>>> Recovering old system settings. <<<< >>>>> Stopping network services <<<< >>>>> >> Stopping sendmail >> stop: sleep 100000 microseconds >> stop: network/smtp:sendmail... success >> Stopping nscd >> stop: sleep 100000 microseconds >> stop: sleep 200000 microseconds >> stop: system/name-service-cache:default... success >> Stopping autofs >> stop: sleep 100000 microseconds >> stop: sleep 200000 microseconds >> stop: sleep 400000 microseconds >> stop: sleep 800000 microseconds >> stop: sleep 1600000 microseconds >> stop: sleep 3200000 microseconds >> stop: system/filesystem/autofs:default... success >> Stopping ldap >> stop: sleep 100000 microseconds >> stop: sleep 200000 microseconds >> stop: sleep 400000 microseconds >> stop: sleep 800000 microseconds >> stop: sleep 1600000 microseconds >> stop: sleep 3200000 microseconds >> stop: sleep 6400000 microseconds >> stop: sleep 12800000 microseconds >> stop: sleep 25600000 microseconds >> stop: sleep 8900000 microseconds >> stop: network/ldap/client:default... timed out >> Stopping ldap failed with (7) >> Error (1) while stopping services during reset >> recover: stat(/var/ldap/restore/defaultdomain)=0 >> recover: open(/var/ldap/restore/defaultdomain) >> recover: read(/var/ldap/restore/defaultdomain) >> recover: old domainname "teratext.saic.com.au" >> recover: stat(/var/ldap/restore/ldap_client_file)=-1 >> recover: stat(/var/ldap/restore/ldap_client_cred)=-1 >> recover: stat(/var/ldap/restore/NIS_COLD_START)=-1 >> recover: stat(/var/ldap/restore/teratext.saic.com.au)=-1 >> recover: stat(/var/ldap/restore/nsswitch.conf)=0 >> recover: file_move(/var/ldap/restore/nsswitch.conf, /etc/nsswitch.conf)=0 >> recover: stat(/var/ldap/restore/defaultdomain)=0 >> recover: file_move(/var/ldap/restore/defaultdomain, /etc/defaultdomain)=0 >> Starting network services >> start: /usr/bin/domainname teratext.saic.com.au... success >> start: sleep 100000 microseconds >> start: system/filesystem/autofs:default... success >> start: sleep 100000 microseconds >> start: sleep 200000 microseconds >> start: sleep 400000 microseconds >> start: system/name-service-cache:default... success >> start: sleep 100000 microseconds >> start: network/smtp:sendmail... success >> restart: sleep 100000 microseconds >> restart: sleep 200000 microseconds >> restart: milestone/name-services:default... success >> >> >> >> >> Regards, >> >> >> Craig >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Sat Dec 3 18:56:25 2011 From: dpal at redhat.com (Dmitri Pal) Date: Sat, 03 Dec 2011 13:56:25 -0500 Subject: [Freeipa-users] manual client join In-Reply-To: <4ED69937.80003@redhat.com> References: <4ED68C4A.2090500@redhat.com> <4ED69937.80003@redhat.com> Message-ID: <4EDA70D9.3080200@redhat.com> On 11/30/2011 03:59 PM, Rob Crittenden wrote: > Stephen Ingram wrote: >> Rob- >> >> On Wed, Nov 30, 2011 at 12:04 PM, Rob >> Crittenden wrote: >>> Retrieve the CA certificate for the FreeIPA CA. >>> >>> # wget -O /etc/ipa/ca.crt http://ipa.example.com/ipa/config/ca.crt >>> >>> Create a separate Kerberos configuration to test the provided >>> credentials. >>> This enables a Kerberos connection to the FreeIPA XML-RPC server, >>> necessary >>> to join the FreeIPA client to the FreeIPA domain. This Kerberos >>> configuration is ultimately discarded. >>> >>> - Basically just copy a working krb5.conf to /etc/krb5.conf and set >>> up sssd >>> or nss_ldap as documented. >>> >>> # kinit admin >>> # ipa-join -s ipa.example.com -b dc=example,dc=com >>> >>> Or if using a one-time password you can skip the kinit and do >>> >>> # ipa-join -s ipa.example.com -b dc=example,dc=com -w Secret123 >>> >>> ipa-join lets IPA know a host is enrolled and retrieves a host >>> principal and >>> stores it into /etc/krb5.keytab. >>> >>> Enable certmonger, retrieve an SSL server certificate, and install the >>> certificate in /etc/pki/nssdb. >>> >>> # service messagebus start >>> # service certmonger start >>> # certutil -A -d /etc/pki/nssdb -n 'IPA CA' -t CT,C,C -a -i >>> /etc/ipa/ca.crt >>> # ipa-getcert request -d /etc/pki/nssdb -n 'IPA Machine Certificate - >>> client.example.com' -N 'cn=client.example.com,O=EXAMPLE.COM; -K >>> host/client.example.com at EXAMPLE.COM >>> >>> Disable the nscd daemon. >>> >>> # service nscd stop >>> # chkconfig nscd off >> >> Thanks, but aren't some of these steps assuming that ipa-client has >> been installed on the system? For instance, instead of "# ipa-join -s >> ipa.example.com -b dc=example,dc=com -w Secret123", can't I instead >> use kadmin to retrieve the keytab and then securely copy it over to >> the client system? And, in the case of the ca.crt, if there if IPA >> itself is not installed, the ca would not go to /etc/ipa/ca.crt, no? I >> realize that I will lose functionality by not having ipa-client, but >> just trying to build a case for supporting legacy systems that I would >> never want to take the time to adapt ipa-client for. >> >> Steve > > The only part assuming that is ipa-join itself. IPA does not support > the direct use of kadmin or kadmin.local. On a supported platform > you'd run: > > # ipa-getkeytab -s ipa.example.com -k /tmp/remote.keytab -p > host/remote.example.com > > Then ship /tmp/remote.keytab to the machine and either use ktutil to > combine it with /etc/krb5.keytab or replace krb5.keytab with it (and > fix owner and permissions, and potentially SELinux context). > > certmonger gets its IPA configuration from /etc/ipa/default.conf. If > you don't want or have certmonger then you can skip the CA bit > altogether. Otherwise you'll need to copy in a working config. > Should any part of this be documented? > rob > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From Steven.Jones at vuw.ac.nz Sun Dec 4 19:35:19 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Sun, 4 Dec 2011 19:35:19 +0000 Subject: [Freeipa-users] Some feature requests In-Reply-To: <4EDA6E2B.1020607@redhat.com> References: <833D8E48405E064EBC54C84EC6B36E404C4284ED@STAWINCOX10MBX4.staff.vuw.ac.nz>, <4ED3FDD3.6090809@redhat.com> <833D8E48405E064EBC54C84EC6B36E404C428565@STAWINCOX10MBX4.staff.vuw.ac.nz>, <4EDA6E2B.1020607@redhat.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E404C44AB68@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, RFE? request for engineering? via RHN support portal? I will also raise these with my RH solution architect..... I noticed that you have a freeipa nfs howto/engineering proof of concept, more of those would be good. What I am finding is its very hard (actually impossible) to figure out how to get 3rd party hardware to talk LDAP into IPA. It seems the hardware talks one way or multiple ways and IPA answers differently, the result is they dont communicate. So far I have failed with Sun's Solar SAN, and Bluecoat's proxy server.....the info just seems lacking....or maybe a dictionary from IPA to LDAP or into "steven's speak" is needed I certainly dont find it simple to understand. ;] I will be attempting a new Bluearc this week......which is centos 4.8 apparently.... ;/ I also find that the vendors only speak AD, they are all MS trained.....they are totally clueless when I mention LDAP and especially IPA....."Ive never done a Linux/LDAP connection, I will have to ask engineering" is the common answer......seems in NZ and even in APAC that is a common, I usually dont get an answer....... Satellite - OTP, it would be per machine.....each machine is recorded individually in RH Sat so you know what is vulnerable and what patches there are..........I kind of envisioned another tab in the kickstart file generator where you would put in the info....maybe it isnt that easy.......but integrating their products is what many vendors are slick at.....or make a huge mess of, depending on the vendor........ ;] regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Dmitri Pal [dpal at redhat.com] Sent: Sunday, 4 December 2011 7:44 a.m. To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Some feature requests On 11/28/2011 04:36 PM, Steven Jones wrote: > I cant see anything in the glster admin guide on connecting it to a IPA setup... > We will be working with them but it will take some time. Would be nice to have RFEs for those components filed. As for kickstart any ipa-client invocation requires and authentication. You either need to do it manually or in some way add OTP to the kickstart file. At best OTP should be one per machine but you can reuse it for a group of machines. This seems to be a problem that can only be solved by the individual admin depending on the constraints of his environment. I do not think this has a generic solution. > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > ________________________________________ > From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Adam Young [ayoung at redhat.com] > Sent: Tuesday, 29 November 2011 10:32 a.m. > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Some feature requests > > On 11/28/2011 04:16 PM, Steven Jones wrote: >> Hi, >> >> a) Auto setup in RH satellite to allow auto joining to freeIPA from a baremetal kickstart. > That is a Satellite, not FreeIPA, request. > >> b) Setup/config (info etc) to allow a gluster system to join to IPA. > What would a gluster system require that we do not already provide? > >> Since these are all RH...shouldn't be too hard. >> >> ;] >> >> regards >> >> Steven Jones >> >> Technical Specialist - Linux RHCE >> >> Victoria University, Wellington, NZ >> >> 0064 4 463 6272 >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users From Steven.Jones at vuw.ac.nz Sun Dec 4 19:39:17 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Sun, 4 Dec 2011 19:39:17 +0000 Subject: [Freeipa-users] Solaris 10 as IPA Client? In-Reply-To: <4EDA6FF7.8050400@redhat.com> References: <20111201053106.GA25969@noboost.org> <36385.62.148.39.180.1322734176.squirrel@www.nixtra.com>, <4EDA6FF7.8050400@redhat.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E404C44AB7A@STAWINCOX10MBX1.staff.vuw.ac.nz> 8><----------- Also Solaris assumes 2307 schema AFAIR and IPA is 2307bis. So you need to enable compat tree on ipa side and point your Solaris nss_ldap to the compat tree. 8><---------- We have a Sun solar storage SAN.....uses Solaris I cant get it to work....maybe that's what I need to do to get them to talk....how to I enable "compat tree"? Also would other hardware vendors be similar? Im trying to get a bluecoat proxy server to talk to IPA and it cant.... regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From Steven.Jones at vuw.ac.nz Sun Dec 4 19:50:42 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Sun, 4 Dec 2011 19:50:42 +0000 Subject: [Freeipa-users] IMPORTANT: Your input requested: SSSD LDAP Provider vs Winbind In-Reply-To: <1322841049.6745.33.camel@willson.li.ssimo.org> References: <1322835332.2194.19.camel@sgallagh520.sgallagh.bos.redhat.com> <4ED8E26A.40200@s3group.cz> <4ED8E7C7.7070508@s3group.cz> <1322838403.2194.21.camel@sgallagh520.sgallagh.bos.redhat.com>, <1322841049.6745.33.camel@willson.li.ssimo.org> Message-ID: <833D8E48405E064EBC54C84EC6B36E404C44ABA0@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, Oh I dont know about that...... We have at least 4 AD domains controlled by "me" (central IT) and at least 3 ADs on the edge, as schools want to "do their own thing".......then there is at least one Mac LDAP and one OpenLDAP...and that's the ones I know of..... So my job is to glue this all together and make it work with all the disparate hardware..........securely and seemlessly...........oh joy I must have been a VERY bad person in my last life.... ;] 8><------ Winbindd is clearly built for a single Ad domain which is the norm and the point is already captured in 2. 8><--------- regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 From dpal at redhat.com Mon Dec 5 00:00:10 2011 From: dpal at redhat.com (Dmitri Pal) Date: Sun, 04 Dec 2011 19:00:10 -0500 Subject: [Freeipa-users] Some feature requests In-Reply-To: <833D8E48405E064EBC54C84EC6B36E404C44AB68@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E404C4284ED@STAWINCOX10MBX4.staff.vuw.ac.nz>, <4ED3FDD3.6090809@redhat.com> <833D8E48405E064EBC54C84EC6B36E404C428565@STAWINCOX10MBX4.staff.vuw.ac.nz>, <4EDA6E2B.1020607@redhat.com> <833D8E48405E064EBC54C84EC6B36E404C44AB68@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <4EDC098A.3010804@redhat.com> On 12/04/2011 02:35 PM, Steven Jones wrote: > Hi, > > RFE? request for engineering? via RHN support portal? Request for enhancement = RFE > I will also raise these with my RH solution architect..... > > I noticed that you have a freeipa nfs howto/engineering proof of concept, more of those would be good. What I am finding is its very hard (actually impossible) to figure out how to get 3rd party hardware to talk LDAP into IPA. It seems the hardware talks one way or multiple ways and IPA answers differently, the result is they dont communicate. So far I have failed with Sun's Solar SAN, and Bluecoat's proxy server.....the info just seems lacking....or maybe a dictionary from IPA to LDAP or into "steven's speak" is needed I certainly dont find it simple to understand. We do not know what this hardware wants or expects. We do not even know what kind of lookups it does. Is it nss_ldap? If so and underlying OS is Solaris you need to turn on the IPA compat tree and point the device to that tree. Via compat tree you can expose the information inside FreeIPA tree in any shape you want so if the device wants something special you would be able to satisfy its tastes as long as the data already is some place in the main tree. If it is not then it is a different issue. > ;] > > I will be attempting a new Bluearc this week......which is centos 4.8 apparently.... > > ;/ > > I also find that the vendors only speak AD, they are all MS trained.....they are totally clueless when I mention LDAP and especially IPA....."Ive never done a Linux/LDAP connection, I will have to ask engineering" is the common answer......seems in NZ and even in APAC that is a common, I usually dont get an answer....... If it is AD specific it might not use LDAP. Do you know that these devices actually use LDAP? > Satellite - OTP, it would be per machine.....each machine is recorded individually in RH Sat so you know what is vulnerable and what patches there are..........I kind of envisioned another tab in the kickstart file generator where you would put in the info....maybe it isnt that easy.......but integrating their products is what many vendors are slick at.....or make a huge mess of, depending on the vendor........ RFE would be helpful. > ;] > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > ________________________________________ > From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Dmitri Pal [dpal at redhat.com] > Sent: Sunday, 4 December 2011 7:44 a.m. > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Some feature requests > > On 11/28/2011 04:36 PM, Steven Jones wrote: >> I cant see anything in the glster admin guide on connecting it to a IPA setup... >> > We will be working with them but it will take some time. > Would be nice to have RFEs for those components filed. > > > As for kickstart any ipa-client invocation requires and authentication. > You either need to do it manually or in some way add OTP to the > kickstart file. > At best OTP should be one per machine but you can reuse it for a group > of machines. > This seems to be a problem that can only be solved by the individual > admin depending on the constraints of his environment. > I do not think this has a generic solution. > >> regards >> >> Steven Jones >> >> Technical Specialist - Linux RHCE >> >> Victoria University, Wellington, NZ >> >> 0064 4 463 6272 >> >> ________________________________________ >> From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Adam Young [ayoung at redhat.com] >> Sent: Tuesday, 29 November 2011 10:32 a.m. >> To: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] Some feature requests >> >> On 11/28/2011 04:16 PM, Steven Jones wrote: >>> Hi, >>> >>> a) Auto setup in RH satellite to allow auto joining to freeIPA from a baremetal kickstart. >> That is a Satellite, not FreeIPA, request. >> >>> b) Setup/config (info etc) to allow a gluster system to join to IPA. >> What would a gluster system require that we do not already provide? >> >>> Since these are all RH...shouldn't be too hard. >>> >>> ;] >>> >>> regards >>> >>> Steven Jones >>> >>> Technical Specialist - Linux RHCE >>> >>> Victoria University, Wellington, NZ >>> >>> 0064 4 463 6272 >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IPA project, > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Mon Dec 5 00:05:27 2011 From: dpal at redhat.com (Dmitri Pal) Date: Sun, 04 Dec 2011 19:05:27 -0500 Subject: [Freeipa-users] Solaris 10 as IPA Client? In-Reply-To: <833D8E48405E064EBC54C84EC6B36E404C44AB7A@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <20111201053106.GA25969@noboost.org> <36385.62.148.39.180.1322734176.squirrel@www.nixtra.com>, <4EDA6FF7.8050400@redhat.com> <833D8E48405E064EBC54C84EC6B36E404C44AB7A@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <4EDC0AC7.2070606@redhat.com> On 12/04/2011 02:39 PM, Steven Jones wrote: > 8><----------- > > Also Solaris assumes 2307 schema AFAIR and IPA is 2307bis. > So you need to enable compat tree on ipa side and point your Solaris > nss_ldap to the compat tree. > > 8><---------- > > We have a Sun solar storage SAN.....uses Solaris I cant get it to work....maybe that's what I need to do to get them to talk....how to I enable "compat tree"? # ipa-compat-manage enable I checked the docs. I was surprised we do not mention that Solaris is 2307. I will rise a bug. > Also would other hardware vendors be similar? Im trying to get a bluecoat proxy server to talk to IPA and it cant.... > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > ________________________________________ > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From Steven.Jones at vuw.ac.nz Mon Dec 5 00:14:16 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Mon, 5 Dec 2011 00:14:16 +0000 Subject: [Freeipa-users] Some feature requests In-Reply-To: <4EDC098A.3010804@redhat.com> References: <833D8E48405E064EBC54C84EC6B36E404C4284ED@STAWINCOX10MBX4.staff.vuw.ac.nz>, <4ED3FDD3.6090809@redhat.com> <833D8E48405E064EBC54C84EC6B36E404C428565@STAWINCOX10MBX4.staff.vuw.ac.nz>, <4EDA6E2B.1020607@redhat.com> <833D8E48405E064EBC54C84EC6B36E404C44AB68@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4EDC098A.3010804@redhat.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E404C44CE68@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, The Sun SAN and the Bluecoat have multiple authentication sections, looks like they will query both til they get an answer. ie a specific AD tab and then a generic LDAP tab can also be configured. Bluearc can only do one type per EVS (virtual storage server) it seems so we have to designate either AD or LDAP per EVS but we can have 64 EVS's so its how we split them up. I will do RFE's once RHEL6.2 is GA and ive sucked the Bluearc's architect's brain dry....... :D regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Dmitri Pal [dpal at redhat.com] Sent: Monday, 5 December 2011 1:00 p.m. To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Some feature requests On 12/04/2011 02:35 PM, Steven Jones wrote: > Hi, > > RFE? request for engineering? via RHN support portal? Request for enhancement = RFE > I will also raise these with my RH solution architect..... > > I noticed that you have a freeipa nfs howto/engineering proof of concept, more of those would be good. What I am finding is its very hard (actually impossible) to figure out how to get 3rd party hardware to talk LDAP into IPA. It seems the hardware talks one way or multiple ways and IPA answers differently, the result is they dont communicate. So far I have failed with Sun's Solar SAN, and Bluecoat's proxy server.....the info just seems lacking....or maybe a dictionary from IPA to LDAP or into "steven's speak" is needed I certainly dont find it simple to understand. We do not know what this hardware wants or expects. We do not even know what kind of lookups it does. Is it nss_ldap? If so and underlying OS is Solaris you need to turn on the IPA compat tree and point the device to that tree. Via compat tree you can expose the information inside FreeIPA tree in any shape you want so if the device wants something special you would be able to satisfy its tastes as long as the data already is some place in the main tree. If it is not then it is a different issue. > ;] > > I will be attempting a new Bluearc this week......which is centos 4.8 apparently.... > > ;/ > > I also find that the vendors only speak AD, they are all MS trained.....they are totally clueless when I mention LDAP and especially IPA....."Ive never done a Linux/LDAP connection, I will have to ask engineering" is the common answer......seems in NZ and even in APAC that is a common, I usually dont get an answer....... If it is AD specific it might not use LDAP. Do you know that these devices actually use LDAP? > Satellite - OTP, it would be per machine.....each machine is recorded individually in RH Sat so you know what is vulnerable and what patches there are..........I kind of envisioned another tab in the kickstart file generator where you would put in the info....maybe it isnt that easy.......but integrating their products is what many vendors are slick at.....or make a huge mess of, depending on the vendor........ RFE would be helpful. > ;] > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > ________________________________________ > From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Dmitri Pal [dpal at redhat.com] > Sent: Sunday, 4 December 2011 7:44 a.m. > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Some feature requests > > On 11/28/2011 04:36 PM, Steven Jones wrote: >> I cant see anything in the glster admin guide on connecting it to a IPA setup... >> > We will be working with them but it will take some time. > Would be nice to have RFEs for those components filed. > > > As for kickstart any ipa-client invocation requires and authentication. > You either need to do it manually or in some way add OTP to the > kickstart file. > At best OTP should be one per machine but you can reuse it for a group > of machines. > This seems to be a problem that can only be solved by the individual > admin depending on the constraints of his environment. > I do not think this has a generic solution. > >> regards >> >> Steven Jones >> >> Technical Specialist - Linux RHCE >> >> Victoria University, Wellington, NZ >> >> 0064 4 463 6272 >> >> ________________________________________ >> From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Adam Young [ayoung at redhat.com] >> Sent: Tuesday, 29 November 2011 10:32 a.m. >> To: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] Some feature requests >> >> On 11/28/2011 04:16 PM, Steven Jones wrote: >>> Hi, >>> >>> a) Auto setup in RH satellite to allow auto joining to freeIPA from a baremetal kickstart. >> That is a Satellite, not FreeIPA, request. >> >>> b) Setup/config (info etc) to allow a gluster system to join to IPA. >> What would a gluster system require that we do not already provide? >> >>> Since these are all RH...shouldn't be too hard. >>> >>> ;] >>> >>> regards >>> >>> Steven Jones >>> >>> Technical Specialist - Linux RHCE >>> >>> Victoria University, Wellington, NZ >>> >>> 0064 4 463 6272 >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IPA project, > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users From Steven.Jones at vuw.ac.nz Mon Dec 5 00:15:47 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Mon, 5 Dec 2011 00:15:47 +0000 Subject: [Freeipa-users] Solaris 10 as IPA Client? In-Reply-To: <4EDC0AC7.2070606@redhat.com> References: <20111201053106.GA25969@noboost.org> <36385.62.148.39.180.1322734176.squirrel@www.nixtra.com>, <4EDA6FF7.8050400@redhat.com> <833D8E48405E064EBC54C84EC6B36E404C44AB7A@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4EDC0AC7.2070606@redhat.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E404C44CE78@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, Maybe you do, I just didnt see it.....I will ask what the bluecoat and bluearc do. regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Dmitri Pal [dpal at redhat.com] Sent: Monday, 5 December 2011 1:05 p.m. To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Solaris 10 as IPA Client? On 12/04/2011 02:39 PM, Steven Jones wrote: > 8><----------- > > Also Solaris assumes 2307 schema AFAIR and IPA is 2307bis. > So you need to enable compat tree on ipa side and point your Solaris > nss_ldap to the compat tree. > > 8><---------- > > We have a Sun solar storage SAN.....uses Solaris I cant get it to work....maybe that's what I need to do to get them to talk....how to I enable "compat tree"? # ipa-compat-manage enable I checked the docs. I was surprised we do not mention that Solaris is 2307. I will rise a bug. > Also would other hardware vendors be similar? Im trying to get a bluecoat proxy server to talk to IPA and it cant.... > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > ________________________________________ > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users From sigbjorn at nixtra.com Mon Dec 5 10:51:46 2011 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Mon, 5 Dec 2011 11:51:46 +0100 (CET) Subject: [Freeipa-users] Solaris 10 as IPA Client? In-Reply-To: <833D8E48405E064EBC54C84EC6B36E404C44CE78@STAWINCOX10MBX1.staff.vuw.ac .nz> References: <20111201053106.GA25969@noboost.org> <36385.62.148.39.180.1322734176.squirrel@www.nixtra.com>, <4EDA6FF7.8050400@redhat.com> <833D8E48405E064EBC54C84EC6B36E404C44AB7A@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4EDC0AC7.2070606@redhat.com> <833D8E48405E064EBC54C84EC6B36E404C44CE78@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <34292.213.225.75.97.1323082306.squirrel@www.nixtra.com> Hi, I found various appliances to require some specifications in terms of a LDAP filter to what to look for. E.g. for looking up a user in IPA will be (&(objectclass=person)(uid=username)). For AD the similar search can be specified such as (&(sAMAccountName=l0290061)(objectclass=person))'. If you have an option to choose LDAP or AD, the AD option would probably have a similar LDAP filter already set, while the LDAP option allows you to create your own filter that suites your LDAP server. Also making sure you have specified the correct base DN, and making sure that the appliance will search all sub CN's or OU's if required. With IPA: cn=users,cn=accounts, works for my Solaris clients. Making sure you bind with a user account if you have disabled anonymous access to your LDAP server. These are the most common issues I've come across for configuring appliances to use LDAP. Regards, Siggi On Mon, December 5, 2011 01:15, Steven Jones wrote: > Hi, > > > Maybe you do, I just didnt see it.....I will ask what the bluecoat and bluearc do. > > > regards > > Steven Jones > > > Technical Specialist - Linux RHCE > > > Victoria University, Wellington, NZ > > > 0064 4 463 6272 > > > ________________________________________ > From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Dmitri Pal > [dpal at redhat.com] > Sent: Monday, 5 December 2011 1:05 p.m. > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Solaris 10 as IPA Client? > > > On 12/04/2011 02:39 PM, Steven Jones wrote: > >> 8><----------- >> >> >> Also Solaris assumes 2307 schema AFAIR and IPA is 2307bis. >> So you need to enable compat tree on ipa side and point your Solaris >> nss_ldap to the compat tree. >> >> 8><---------- >> >> >> We have a Sun solar storage SAN.....uses Solaris I cant get it to work....maybe that's what I >> need to do to get them to talk....how to I enable "compat tree"? > > > # ipa-compat-manage enable > > > > I checked the docs. I was surprised we do not mention that Solaris is 2307. > I will rise a bug. > > > > >> Also would other hardware vendors be similar? Im trying to get a bluecoat proxy server to talk >> to IPA and it cant.... >> >> regards >> >> Steven Jones >> >> >> Technical Specialist - Linux RHCE >> >> >> Victoria University, Wellington, NZ >> >> >> 0064 4 463 6272 >> >> >> ________________________________________ >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> >> > > > -- > Thank you, > Dmitri Pal > > > Sr. Engineering Manager IPA project, > Red Hat Inc. > > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > From rcritten at redhat.com Mon Dec 5 14:40:57 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 05 Dec 2011 09:40:57 -0500 Subject: [Freeipa-users] Solaris 10 as IPA Client? In-Reply-To: <833D8E48405E064EBC54C84EC6B36E404C44AB7A@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <20111201053106.GA25969@noboost.org> <36385.62.148.39.180.1322734176.squirrel@www.nixtra.com>, <4EDA6FF7.8050400@redhat.com> <833D8E48405E064EBC54C84EC6B36E404C44AB7A@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <4EDCD7F9.5060304@redhat.com> Steven Jones wrote: > > 8><----------- > > Also Solaris assumes 2307 schema AFAIR and IPA is 2307bis. > So you need to enable compat tree on ipa side and point your Solaris > nss_ldap to the compat tree. > > 8><---------- > > We have a Sun solar storage SAN.....uses Solaris I cant get it to work....maybe that's what I need to do to get them to talk....how to I enable "compat tree"? > > Also would other hardware vendors be similar? Im trying to get a bluecoat proxy server to talk to IPA and it cant.... compat is enabled by default, to double check run: ipa-compat-manage status For authentication typically all you need is the basedn of users (cn=users,cn=accounts,dc=example,dc=com). For SSL you can get a copy of the CA cert from http://ipa.example.com/ipa/config/ca.crt. The 389-ds access logs can be found in /var/log/dirsrv/slapd-YOURINSTANCE/access. These are buffered for up to 30 seconds. The error log by default tends to only log catastrophic problems. You can enable server debugging, details are in the FAQ in the 389-ds wiki. rob From Steven.Jones at vuw.ac.nz Mon Dec 5 19:42:28 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Mon, 5 Dec 2011 19:42:28 +0000 Subject: [Freeipa-users] Solaris 10 as IPA Client? In-Reply-To: <4EDCD7F9.5060304@redhat.com> References: <20111201053106.GA25969@noboost.org> <36385.62.148.39.180.1322734176.squirrel@www.nixtra.com>, <4EDA6FF7.8050400@redhat.com> <833D8E48405E064EBC54C84EC6B36E404C44AB7A@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4EDCD7F9.5060304@redhat.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E404C4592F6@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, If I wanted a specific internet access group where the IPA group is "internet-users" What would the baseDN be? I have been using dc=unix,dc=vuw,dc=ac,dc=nz but I have tried a few combos, none worked....also I need to bind to the IPA? or will anonymous work? I cant search the tree as anonymous inside the bluecoat gui so I cant pick the group I want....which would make life easy. This goes back to my request to see the dc= stuff inside the gui.....the gui "speaks" one way and everything else "speaks" differently, a translation is needed. So really you have succeeded in making the gui very easy to use, sure but not with other products. If I have to bind with a user so I can pick the group I want in the bluecoat gui I assume I need to create a user for that? with limited permissions? regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: Rob Crittenden [rcritten at redhat.com] Sent: Tuesday, 6 December 2011 3:40 a.m. To: Steven Jones Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Solaris 10 as IPA Client? Steven Jones wrote: > > 8><----------- > > Also Solaris assumes 2307 schema AFAIR and IPA is 2307bis. > So you need to enable compat tree on ipa side and point your Solaris > nss_ldap to the compat tree. > > 8><---------- > > We have a Sun solar storage SAN.....uses Solaris I cant get it to work....maybe that's what I need to do to get them to talk....how to I enable "compat tree"? > > Also would other hardware vendors be similar? Im trying to get a bluecoat proxy server to talk to IPA and it cant.... compat is enabled by default, to double check run: ipa-compat-manage status For authentication typically all you need is the basedn of users (cn=users,cn=accounts,dc=example,dc=com). For SSL you can get a copy of the CA cert from http://ipa.example.com/ipa/config/ca.crt. The 389-ds access logs can be found in /var/log/dirsrv/slapd-YOURINSTANCE/access. These are buffered for up to 30 seconds. The error log by default tends to only log catastrophic problems. You can enable server debugging, details are in the FAQ in the 389-ds wiki. rob From sbingram at gmail.com Mon Dec 5 20:24:05 2011 From: sbingram at gmail.com (Stephen Ingram) Date: Mon, 5 Dec 2011 12:24:05 -0800 Subject: [Freeipa-users] Fwd: manual client join In-Reply-To: References: <4ED68C4A.2090500@redhat.com> <4ED69937.80003@redhat.com> Message-ID: On Wed, Nov 30, 2011 at 12:59 PM, Rob Crittenden wrote: > > The only part assuming that is ipa-join itself. IPA does not support the > direct use of kadmin or kadmin.local. On a supported platform you'd run: > > # ipa-getkeytab -s ipa.example.com -k /tmp/remote.keytab -p > host/remote.example.com > > Then ship /tmp/remote.keytab to the machine and either use ktutil to combine > it with /etc/krb5.keytab or replace krb5.keytab with it (and fix owner and > permissions, and potentially SELinux context). OK, got it. I can use the FreeIPA system itself to grab these for host and services and then new remote machine will have all principals it requires to work within FreeIPA realm. > certmonger gets its IPA configuration from /etc/ipa/default.conf. If you > don't want or have certmonger then you can skip the CA bit altogether. > Otherwise you'll need to copy in a working config. OK, this requires certmonger. If I still want FreeIPA-signed cert (say I need to talk SSL to FreeIPA directory for mail server config purposes e.g. check existence of email address) without certmonger, I can use certmonger on FreeIPA server or UI to sign csr generated using nss on remote system and then transport cert to remote system and manually install for apache, ldap client, etc., right? I'm not trying to supplant FreeIPA here. Obviously the best (and almost effortless) solution is to have freeipa-client and certmonger on system, however, if I'm stuck with an older version of Redhat or some other OS that just doesn't conveniently support FreeIPA, I just want to be able to get a cert and necessary principals to be able to easily work within FreeIPA realm. I also sort of like to know how everything works in more detail just in case something breaks and I have to make manual adjustments. Steve From sigbjorn at nixtra.com Mon Dec 5 20:40:50 2011 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Mon, 05 Dec 2011 21:40:50 +0100 Subject: [Freeipa-users] Solaris 10 as IPA Client? In-Reply-To: <833D8E48405E064EBC54C84EC6B36E404C4592F6@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <20111201053106.GA25969@noboost.org> <36385.62.148.39.180.1322734176.squirrel@www.nixtra.com>, <4EDA6FF7.8050400@redhat.com> <833D8E48405E064EBC54C84EC6B36E404C44AB7A@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4EDCD7F9.5060304@redhat.com> <833D8E48405E064EBC54C84EC6B36E404C4592F6@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <4EDD2C52.70209@nixtra.com> Use Base DN: dc=unix,dc=vuw,dc=ac,dc=nz. Make sure you've configured bluecoat to do search sub, and not search one. You should really speak to Bluecoat support about how to configure your appliance. IPA merely provides a LDAP server. There is loads of different ways applications is configured to use LDAP. Some appliances wants just a true/false, such as using a LDAP search, if a result is found the search is true, if a result is not found the search is considered false. Such as: '(&(objectclass=person)(memberOf=cn=internet-access,cn=groups,cn=accounts,dc=test,dc=com)(uid=username))' will return a record if the requested user is a member of the group, and return nothing if the user is not a member of the group. I just used a similar configuration for Squid. Other appliances want to be pointed at a group or a set of groups, where the appliance contains the required logic for searching for users within the group or groups. If you do this, you need to configure the objectclasses and attributes it's looking for, as this varies between different LDAP servers. This is usually configurable within the appliance. Run "ldapsearch -Y GSSAPI -b dc=unix,dc=vuw,dc=ac,dc=nz cn=internet-access" on your IPA server to see what object classes and attributes is associated with your internet-access group. This should give you some hints for how to configure your appliances. What you need is some knowledge of LDAP, and to work with your vendors to figure out how they should be configured to work with IPA. BTW, for a proxy appliance I believe you want Kerberos authentication to provide single sign on, and use LDAP merely to do the authorization. Regards, Siggi On 12/05/2011 08:42 PM, Steven Jones wrote: > Hi, > > If I wanted a specific internet access group where the IPA group is "internet-users" > > What would the baseDN be? > > I have been using dc=unix,dc=vuw,dc=ac,dc=nz but I have tried a few combos, none worked....also I need to bind to the IPA? or will anonymous work? I cant search the tree as anonymous inside the bluecoat gui so I cant pick the group I want....which would make life easy. > > This goes back to my request to see the dc= stuff inside the gui.....the gui "speaks" one way and everything else "speaks" differently, a translation is needed. So really you have succeeded in making the gui very easy to use, sure but not with other products. > > If I have to bind with a user so I can pick the group I want in the bluecoat gui I assume I need to create a user for that? with limited permissions? > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > ________________________________________ > From: Rob Crittenden [rcritten at redhat.com] > Sent: Tuesday, 6 December 2011 3:40 a.m. > To: Steven Jones > Cc:freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Solaris 10 as IPA Client? > > Steven Jones wrote: >> 8><----------- >> >> Also Solaris assumes 2307 schema AFAIR and IPA is 2307bis. >> So you need to enable compat tree on ipa side and point your Solaris >> nss_ldap to the compat tree. >> >> 8><---------- >> >> We have a Sun solar storage SAN.....uses Solaris I cant get it to work....maybe that's what I need to do to get them to talk....how to I enable "compat tree"? >> >> Also would other hardware vendors be similar? Im trying to get a bluecoat proxy server to talk to IPA and it cant.... > compat is enabled by default, to double check run: ipa-compat-manage status > > For authentication typically all you need is the basedn of users > (cn=users,cn=accounts,dc=example,dc=com). For SSL you can get a copy of > the CA cert fromhttp://ipa.example.com/ipa/config/ca.crt. > > The 389-ds access logs can be found in > /var/log/dirsrv/slapd-YOURINSTANCE/access. These are buffered for up to > 30 seconds. The error log by default tends to only log catastrophic > problems. You can enable server debugging, details are in the FAQ in the > 389-ds wiki. > > rob > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From rcritten at redhat.com Mon Dec 5 20:49:39 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 05 Dec 2011 15:49:39 -0500 Subject: [Freeipa-users] Fwd: manual client join In-Reply-To: References: <4ED68C4A.2090500@redhat.com> <4ED69937.80003@redhat.com> Message-ID: <4EDD2E63.8010005@redhat.com> Stephen Ingram wrote: > On Wed, Nov 30, 2011 at 12:59 PM, Rob Crittenden wrote: >> >> The only part assuming that is ipa-join itself. IPA does not support the >> direct use of kadmin or kadmin.local. On a supported platform you'd run: >> >> # ipa-getkeytab -s ipa.example.com -k /tmp/remote.keytab -p >> host/remote.example.com >> >> Then ship /tmp/remote.keytab to the machine and either use ktutil to combine >> it with /etc/krb5.keytab or replace krb5.keytab with it (and fix owner and >> permissions, and potentially SELinux context). > > OK, got it. I can use the FreeIPA system itself to grab these for host > and services and then new remote machine will have all principals it > requires to work within FreeIPA realm. Yup. > >> certmonger gets its IPA configuration from /etc/ipa/default.conf. If you >> don't want or have certmonger then you can skip the CA bit altogether. >> Otherwise you'll need to copy in a working config. > > OK, this requires certmonger. If I still want FreeIPA-signed cert (say > I need to talk SSL to FreeIPA directory for mail server config > purposes e.g. check existence of email address) without certmonger, I > can use certmonger on FreeIPA server or UI to sign csr generated using > nss on remote system and then transport cert to remote system and > manually install for apache, ldap client, etc., right? You don't need certmonger to have SSL certs, it just makes it easier to request and manage them (because of the auto-renewal features). To do it manually just do something like this to get a cert for a web server. IPA server here is really any machine with admintools package installed. remote system: generate CSR using openssl or certutil, save as PEM file, ship to IPA host. With NSS I do: certutil -R -s "CN=remote.example.com,O=EXAMPLE.COM" -d /path/to/database/dir -a > example.csr Be sure that the CN value is the FQDN of your server. IPA server: # ipa cert-request --prinicipal HTTP/remote.example.com /path/to/csr.pem # ipa service-show --out=/tmp/service.crt HTTP/remote.example.com Your cert will be in /tmp/service.crt and PEM formatted for easy use. The output of cert-request is just a base64 blob. > I'm not trying to supplant FreeIPA here. Obviously the best (and > almost effortless) solution is to have freeipa-client and certmonger > on system, however, if I'm stuck with an older version of Redhat or > some other OS that just doesn't conveniently support FreeIPA, I just > want to be able to get a cert and necessary principals to be able to > easily work within FreeIPA realm. I also sort of like to know how > everything works in more detail just in case something breaks and I > have to make manual adjustments. This may be handy to augment the IPA documentation too if you want to donate back your findings :-) cheers rob From Steven.Jones at vuw.ac.nz Mon Dec 5 21:05:40 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Mon, 5 Dec 2011 21:05:40 +0000 Subject: [Freeipa-users] Solaris 10 as IPA Client? In-Reply-To: <4EDD2C52.70209@nixtra.com> References: <20111201053106.GA25969@noboost.org> <36385.62.148.39.180.1322734176.squirrel@www.nixtra.com>, <4EDA6FF7.8050400@redhat.com> <833D8E48405E064EBC54C84EC6B36E404C44AB7A@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4EDCD7F9.5060304@redhat.com> <833D8E48405E064EBC54C84EC6B36E404C4592F6@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4EDD2C52.70209@nixtra.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E404C45C560@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi 8><-------- What you need is some knowledge of LDAP, and to work with your vendors to figure out how they should be configured to work with IPA. 8><------- Funny but I thought a goal of IPA was to make this easier....so you dont need such depth of knowledge..... Like I keep saying its a translation process so you can start to understand it.....Im having huge problems with it... which is a worry because if I have problems the other admins are probably going to fail. I have tried to self-educate myself but Im not getting far at it. "Vendors" in NZ just import in a box, its a function of our small population, few have any depth of knowledge....a few have happily admitted to me that if we buy the hardware they will get some training....until then they are as clueless as we are. 8><------- BTW, for a proxy appliance I believe you want Kerberos authentication to provide single sign on, and use LDAP merely to do the authorization. 8><------ I suspected that but, no where in Bluecoat can I see anything to do kerberos to a kerberos server, so i suspect it wont work as single sign on, so I maybe wasting my time. regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 From simo at redhat.com Mon Dec 5 21:14:38 2011 From: simo at redhat.com (Simo Sorce) Date: Mon, 05 Dec 2011 16:14:38 -0500 Subject: [Freeipa-users] Solaris 10 as IPA Client? In-Reply-To: <833D8E48405E064EBC54C84EC6B36E404C45C560@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <20111201053106.GA25969@noboost.org> <36385.62.148.39.180.1322734176.squirrel@www.nixtra.com> , <4EDA6FF7.8050400@redhat.com> <833D8E48405E064EBC54C84EC6B36E404C44AB7A@STAWINCOX10MBX1.staff.vuw.ac.nz> , <4EDCD7F9.5060304@redhat.com> <833D8E48405E064EBC54C84EC6B36E404C4592F6@STAWINCOX10MBX1.staff.vuw.ac.nz> , <4EDD2C52.70209@nixtra.com> <833D8E48405E064EBC54C84EC6B36E404C45C560@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <1323119678.16141.24.camel@willson.li.ssimo.org> On Mon, 2011-12-05 at 21:05 +0000, Steven Jones wrote: > Funny but I thought a goal of IPA was to make this easier....so you > dont need such depth of knowledge..... That is our goal, but we can only do so much when 3rd parties are involved. Your best bet is to see our instructions for non-ipa clients. Those instruction may not apply 1:1 to whatever configuration methods all 3rd parties may have, but should set you in the right direction. Simo. -- Simo Sorce * Red Hat, Inc * New York From Steven.Jones at vuw.ac.nz Mon Dec 5 21:17:21 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Mon, 5 Dec 2011 21:17:21 +0000 Subject: [Freeipa-users] Solaris 10 as IPA Client? In-Reply-To: <1323119678.16141.24.camel@willson.li.ssimo.org> References: <20111201053106.GA25969@noboost.org> <36385.62.148.39.180.1322734176.squirrel@www.nixtra.com> , <4EDA6FF7.8050400@redhat.com> <833D8E48405E064EBC54C84EC6B36E404C44AB7A@STAWINCOX10MBX1.staff.vuw.ac.nz> , <4EDCD7F9.5060304@redhat.com> <833D8E48405E064EBC54C84EC6B36E404C4592F6@STAWINCOX10MBX1.staff.vuw.ac.nz> , <4EDD2C52.70209@nixtra.com> <833D8E48405E064EBC54C84EC6B36E404C45C560@STAWINCOX10MBX1.staff.vuw.ac.nz>, <1323119678.16141.24.camel@willson.li.ssimo.org> Message-ID: <833D8E48405E064EBC54C84EC6B36E404C45C5A7@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, Oh I know you can only do so much....... :/ regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: Simo Sorce [simo at redhat.com] Sent: Tuesday, 6 December 2011 10:14 a.m. To: Steven Jones Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Solaris 10 as IPA Client? On Mon, 2011-12-05 at 21:05 +0000, Steven Jones wrote: > Funny but I thought a goal of IPA was to make this easier....so you > dont need such depth of knowledge..... That is our goal, but we can only do so much when 3rd parties are involved. Your best bet is to see our instructions for non-ipa clients. Those instruction may not apply 1:1 to whatever configuration methods all 3rd parties may have, but should set you in the right direction. Simo. -- Simo Sorce * Red Hat, Inc * New York From natxo.asenjo at gmail.com Mon Dec 5 22:34:47 2011 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Mon, 5 Dec 2011 23:34:47 +0100 Subject: [Freeipa-users] Solaris 10 as IPA Client? In-Reply-To: <833D8E48405E064EBC54C84EC6B36E404C45C560@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <20111201053106.GA25969@noboost.org> <36385.62.148.39.180.1322734176.squirrel@www.nixtra.com> <4EDA6FF7.8050400@redhat.com> <833D8E48405E064EBC54C84EC6B36E404C44AB7A@STAWINCOX10MBX1.staff.vuw.ac.nz> <4EDCD7F9.5060304@redhat.com> <833D8E48405E064EBC54C84EC6B36E404C4592F6@STAWINCOX10MBX1.staff.vuw.ac.nz> <4EDD2C52.70209@nixtra.com> <833D8E48405E064EBC54C84EC6B36E404C45C560@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: On Mon, Dec 5, 2011 at 10:05 PM, Steven Jones wrote: > Hi > > 8><-------- > > What you need is some knowledge of LDAP, and to work with your vendors > to figure out how they should be configured to work with IPA. > > 8><------- > Funny but I thought a goal of IPA was to make this easier....so you dont need such depth of knowledge..... > Like I keep saying its a translation process so you can start to understand it.....Im having huge problems with it... > which is a worry because if I have problems the other admins are probably going to fail. ?I have tried to self-educate myself but Im not getting far at it. I disagree with you here. Understanding ldap is quite essential stuff for deploying a directory based identity management system. I mean, if you just want to provision users and authenticate them to computer systems in an IPA realm, that's it, you need nothing more than the tools ipa give you. However, life is usually more complicated and people want to use other applications to do stuff. And those applications have ldap bindings, so you need to know how to use them. This is by the way no different as to how to do it with AD. I routinely configure applications to query our AD for user info/authentication/authorization, so I need to specify ldap bases, common names (cn) to bind, etc, .., as well. No difference here as to what you are experiencing. In my experience most vendors have technical info on how to configure and ldap connection to their applications/appliances. You name Bluecoat, and if I google 'bluecoat ldap' the first hit I get is a nice pdf with exactly the info you need (provided this is about the bluecoat.com company). I strongly suggest that you get a good grasp on ldap if you need to manage any directory based service, be it AD, IPA or whatever. > "Vendors" in NZ just import in a box, its a function of our small population, few have any depth of knowledge....a few have happily admitted to me that if we buy the hardware they will get some training....until then they are as clueless as we are. Wow. Are you talking to technical staff or to sales people there? -- natxo From sigbjorn at nixtra.com Mon Dec 5 22:42:45 2011 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Mon, 05 Dec 2011 23:42:45 +0100 Subject: [Freeipa-users] Solaris 10 as IPA Client? In-Reply-To: <833D8E48405E064EBC54C84EC6B36E404C45C560@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <20111201053106.GA25969@noboost.org> <36385.62.148.39.180.1322734176.squirrel@www.nixtra.com>, <4EDA6FF7.8050400@redhat.com> <833D8E48405E064EBC54C84EC6B36E404C44AB7A@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4EDCD7F9.5060304@redhat.com> <833D8E48405E064EBC54C84EC6B36E404C4592F6@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4EDD2C52.70209@nixtra.com> <833D8E48405E064EBC54C84EC6B36E404C45C560@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <4EDD48E5.8090804@nixtra.com> On 12/05/2011 10:05 PM, Steven Jones wrote: > What you need is some knowledge of LDAP, and to work with your vendors > to figure out how they should be configured to work with IPA. > > 8><------- > Funny but I thought a goal of IPA was to make this easier....so you dont need such depth of knowledge..... > Like I keep saying its a translation process so you can start to understand it.....Im having huge problems with it... > which is a worry because if I have problems the other admins are probably going to fail. I have tried to self-educate myself but Im not getting far at it. > And IPA still does make it easier, for the management of the server side. As far as client side goes, 3rd party vendors has had many years to adopt an Active Directory LDAP profile, containing a certain configuration of objectclasses and attributes to look for. In some years, perhaps 3rd party vendors will be making an IPA LDAP profile or 1:1 instructions for configuring their LDAP clients to more easily work with IPA LDAP. > "Vendors" in NZ just import in a box, its a function of our small population, few have any depth of knowledge....a few have happily admitted to me that if we buy the hardware they will get some training....until then they are as clueless as we are. The vendor will most likely have knowledge doc portal and central support outside NZ to help you? From rcritten at redhat.com Tue Dec 6 19:26:19 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 06 Dec 2011 14:26:19 -0500 Subject: [Freeipa-users] Announcing FreeIPA 2.1.4 Message-ID: <4EDE6C5B.6070808@redhat.com> The FreeIPA team is proud to announce version 2.1.4. It can be downloaded from http://www.freeipa.org/Downloads and should appear in the Fedora 15 and 16 updates-testing soon (still waiting for bohdi to push the builds). A rawhide (F-17) build is also available. == Highlights in 2.1.4 == This is a security release, users are strongly advised to upgrade. Specifically, it addresses CVE-2011-3636. A Cross-Site Request Forgery (CSRF) flaw was found in FreeIPA due to a lack of checking the Referer Header in the server (it is not set in the CLI utilities). If a remote attacker could trick a user, who was logged into the FreeIPA management interface, into visiting a specially-crafted URL, the attacker could perform FreeIPA configuration changes with the privileges of the logged in user. Some bugs have been addressed too, the highlights are: * Certificates in the UI are now displayed in PEM format * systemd support in Fedora 16 * Change the way the Kerberos random salt is calculated to improve interoperability with Windows * Fix nis netgroups, users and groups were not appearing * Better handling of Kerberos realm to domain mapping == Upgrading == === Server === To upgrade a 2.0.0, 2.0.1 or 2.1.0 server do the following: # yum update freeipa-server --enablerepo=updates-testing This will pull in updated freeIPA, 389-ds, dogtag, libcurl and xmlrpc-c packages (and perhaps some others). A script will be executed in the rpm postinstall phase to update the IPA LDAP server with any required changes. There is a bug reported against 389-ds, https://bugzilla.redhat.com/show_bug.cgi?id=730387, related to read-write locks. The NSPR RW lock implementation does not safely allow re-entrant use of reader locks. This is a timing issue so it is difficult to predict. During testing one user experienced this and the upgrade hung. To break the hang kill the ns-slapd process for your realm, wait for the yum transaction to complete, then restart 389-ds and manually run the update process: # service dirsrv start # ipa-ldap-updater --update === Client === The ipa-client-install tool in the ipa-client package is just a configuration tool. There should be no need to re-run this on every client already enrolled. == Detailed Changelog for 2.1.3 == Alexander Bokovoy (4): * hbactest fails while you have svcgroup in hbacrule * Add support for systemd environments and use it to support Fedora 16 * Spin for connection success also when socket is not (yet) available * Quote multiple workers option Endi S. Dewata (1): * Added current password field. Evgeny Sinelnikov (1): * ipa_kpasswd: Update selinux policies for ldap and urandom John Dennis (1): * Unable to Download Certificate with Browser Martin Kosek (8): * Fix client krb5 domain mapping and DNS * Fix ipa-managed-entries password option long form * Fix ipa-server-install answer cache * Fix ipa-replica-conncheck port labels * Fix ipa-managed-entries bind procedure * Let PublicError accept Gettext objects * Enable automember for upgraded servers * Make ipa-server-install clean after itself Ondrej Hamada (1): * Client install root privileges check Rob Crittenden (4): * Fix problems in help system * Fix nis netgroup config entry so users appear in netgroup triple. * Don't allow default objectclass list to be empty. * Require an HTTP Referer header in the server. Send one in ipa tools. (CVE-2011-3636) Simo Sorce (1): * Modify random salt creation for interoperability From simo at redhat.com Tue Dec 6 21:09:46 2011 From: simo at redhat.com (Simo Sorce) Date: Tue, 06 Dec 2011 16:09:46 -0500 Subject: [Freeipa-users] Announcing FreeIPA 2.1.4 In-Reply-To: <4EDE6C5B.6070808@redhat.com> References: <4EDE6C5B.6070808@redhat.com> Message-ID: <1323205786.16141.100.camel@willson.li.ssimo.org> Thanks Rob for all the great work! I want to add just one warning that may escape users attention. Due to the need to address the CSRF attack, our command line tools (including ipa-client-install) will not work on newer servers until you upgrade those clients. The reason is that the old tools never sent the Referer header. The newer tools should work w/o any issue against an old server. Unfortunately although CSRF attacks are a concern only when using the Web UI, we had to break compatibility because a browser could be subverted to use the xml-rpc interface used by the CLI tools, and we couldn't leave that hole open even though this means we are breaking backwards compatibility. So if you need to have a gradual upgrade you should start from clients (and install images) before upgrading the server. Keep in mind though that the flaw will not be fixed until you upgrade the server. So, although the flaw is not really critical (IMO), you should not delay upgrades too long in production environments and be careful on administrative clients where you use admin credentials. HTH, Simo. On Tue, 2011-12-06 at 14:26 -0500, Rob Crittenden wrote: > The FreeIPA team is proud to announce version 2.1.4. > > It can be downloaded from http://www.freeipa.org/Downloads and should > appear in the Fedora 15 and 16 updates-testing soon (still waiting for > bohdi to push the builds). A rawhide (F-17) build is also available. > > == Highlights in 2.1.4 == > > This is a security release, users are strongly advised to upgrade. > > Specifically, it addresses CVE-2011-3636. A Cross-Site Request Forgery > (CSRF) flaw was found in FreeIPA due to a lack of checking the Referer > Header in the server (it is not set in the CLI utilities). If a remote > attacker could trick a user, who was logged into the FreeIPA management > interface, into visiting a specially-crafted URL, the attacker could > perform FreeIPA configuration changes with the privileges of the logged > in user. > > Some bugs have been addressed too, the highlights are: > > * Certificates in the UI are now displayed in PEM format > * systemd support in Fedora 16 > * Change the way the Kerberos random salt is calculated to improve > interoperability with Windows > * Fix nis netgroups, users and groups were not appearing > * Better handling of Kerberos realm to domain mapping > > == Upgrading == > > === Server === > > To upgrade a 2.0.0, 2.0.1 or 2.1.0 server do the following: > # yum update freeipa-server --enablerepo=updates-testing > > This will pull in updated freeIPA, 389-ds, dogtag, libcurl and xmlrpc-c > packages (and perhaps some others). A script will be executed in the rpm > postinstall phase to update the IPA LDAP server with any required changes. > > There is a bug reported against 389-ds, > https://bugzilla.redhat.com/show_bug.cgi?id=730387, related to > read-write locks. The NSPR RW lock implementation does not safely allow > re-entrant use of reader > locks. This is a timing issue so it is difficult to predict. During > testing one user experienced this and the upgrade hung. To break the > hang kill the ns-slapd process for your realm, wait for the yum > transaction to complete, then restart 389-ds and manually run the update > process: > > # service dirsrv start > # ipa-ldap-updater --update > > === Client === > > The ipa-client-install tool in the ipa-client package is just a > configuration tool. There should be no need to re-run this on every > client already enrolled. > > == Detailed Changelog for 2.1.3 == > > Alexander Bokovoy (4): > * hbactest fails while you have svcgroup in hbacrule > * Add support for systemd environments and use it to support Fedora 16 > * Spin for connection success also when socket is not (yet) available > * Quote multiple workers option > > Endi S. Dewata (1): > * Added current password field. > > Evgeny Sinelnikov (1): > * ipa_kpasswd: Update selinux policies for ldap and urandom > > John Dennis (1): > * Unable to Download Certificate with Browser > > Martin Kosek (8): > * Fix client krb5 domain mapping and DNS > * Fix ipa-managed-entries password option long form > * Fix ipa-server-install answer cache > * Fix ipa-replica-conncheck port labels > * Fix ipa-managed-entries bind procedure > * Let PublicError accept Gettext objects > * Enable automember for upgraded servers > * Make ipa-server-install clean after itself > > Ondrej Hamada (1): > * Client install root privileges check > > Rob Crittenden (4): > * Fix problems in help system > * Fix nis netgroup config entry so users appear in netgroup triple. > * Don't allow default objectclass list to be empty. > * Require an HTTP Referer header in the server. Send one in ipa tools. > (CVE-2011-3636) > > Simo Sorce (1): > * Modify random salt creation for interoperability > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Simo Sorce * Red Hat, Inc * New York From JR.Aquino at citrix.com Tue Dec 6 21:17:57 2011 From: JR.Aquino at citrix.com (JR Aquino) Date: Tue, 6 Dec 2011 21:17:57 +0000 Subject: [Freeipa-users] [Freeipa-devel] Announcing FreeIPA 2.1.4 In-Reply-To: <1323205786.16141.100.camel@willson.li.ssimo.org> References: <4EDE6C5B.6070808@redhat.com> <1323205786.16141.100.camel@willson.li.ssimo.org> Message-ID: On Dec 6, 2011, at 1:09 PM, Simo Sorce wrote: > Thanks Rob for all the great work! > > > I want to add just one warning that may escape users attention. > > Due to the need to address the CSRF attack, our command line tools > (including ipa-client-install) will not work on newer servers until you > upgrade those clients. The reason is that the old tools never sent the > Referer header. How do you upgrade your clients if they are RHEL and the Server is Fedora? > > The newer tools should work w/o any issue against an old server. > > Unfortunately although CSRF attacks are a concern only when using the > Web UI, we had to break compatibility because a browser could be > subverted to use the xml-rpc interface used by the CLI tools, and we > couldn't leave that hole open even though this means we are breaking > backwards compatibility. > > So if you need to have a gradual upgrade you should start from clients > (and install images) before upgrading the server. > > Keep in mind though that the flaw will not be fixed until you upgrade > the server. So, although the flaw is not really critical (IMO), you > should not delay upgrades too long in production environments and be > careful on administrative clients where you use admin credentials. > > HTH, > Simo. From Steven.Jones at vuw.ac.nz Tue Dec 6 21:56:44 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Tue, 6 Dec 2011 21:56:44 +0000 Subject: [Freeipa-users] Announcing FreeIPA 2.1.4 - rhel6.2 ia ga Message-ID: <833D8E48405E064EBC54C84EC6B36E404C467304@STAWINCOX10MBX1.staff.vuw.ac.nz> rhel6.2 is GA as well. regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 From lassi.polonen at iki.fi Wed Dec 7 14:52:11 2011 From: lassi.polonen at iki.fi (=?ISO-8859-1?Q?Lassi_P=F6l=F6nen?=) Date: Wed, 07 Dec 2011 16:52:11 +0200 Subject: [Freeipa-users] Limiting group/user visibility In-Reply-To: <4ED7B300.8000109@iki.fi> References: <4ED61116.1020206@iki.fi> <20111201124641.GF7875@zeppelin.brq.redhat.com> <1322745151.2474.3.camel@sgallagh520.sgallagh.bos.redhat.com> <4ED7B300.8000109@iki.fi> Message-ID: <4EDF7D9B.7090802@iki.fi> On 2011-12-01 19:01, Lassi P?l?nen wrote: > On 1.12.2011 15:12, Stephen Gallagher wrote: >> On Thu, 2011-12-01 at 13:46 +0100, Jakub Hrozek wrote: >>> On Wed, Nov 30, 2011 at 01:18:46PM +0200, Lassi P?l?nen wrote: >>>> Hi, >>>> >>>> I'm looking for implementing FreeIPA in an environment where there are >>>> multiple customers in multiple organizations and a single organization >>>> that manages the users, sets the access rights etc. >>>> >>>> We don't have a centralized system currently so I will be starting >>>> from >>>> the scratch in that sense. The first concern I've had so far is >>>> that we >>>> don't want different customers to be able to find information about >>>> each >>>> other. Currently in my test setup any user can find out every user >>>> in a >>>> group if they know the group name and all the groups for each user if >>>> they know the username. In some cases this might reveal information >>>> the >>>> customer is not willing to share. >>>> >>>> So are there ways to limit that e.g certain hosts/hostgroups or >>>> users/usergroups see some defined subset of the directory? Or are >>>> there >>>> some other suggested approaches? As the current setup relies on local >>>> authentication, users naturally are able to find users/groups only on >>>> servers they are able to log in and that is the level of >>>> confidentiality >>>> we are looking for if possible >>>> >>>> >>>> -Lassi P?l?nen >>>> >>>> >>> If you insist on a single instance for multiple organizations, then I >>> agree with Stephen Ingram that the correct way would be to setup ACIs. >>> >>> You could also abuse the ldap_user_search_filter and >>> ldap_group_search_filter >>> parameters to limit NSS lookups performed by SSSD. However, nothing >>> would prevent clients from looking at the directory structure with >>> ldapsearch or using the IPA UI. >> Please note that the *search_filter options aren't fully functional yet. >> We're improving them substantially for the 1.7.0 release of SSSD. >> >> But Jakub is right: if you manipulate the ACIs of your user entries, >> then you can restrict which client machines can see those entries. > > Ok, thanks for the replies. ACIs sound like pretty much the only > feasible solution and still less things to maintain than completely > dedicated setups. Will look in to 389's documentation for more. > > I think I found at least one solution, that probably isn't the most elegant one. On the other hand I don't think with the current limitations of FreeIPA it is even possible to do much better. Any comments/suggestions are of course welcome. My first approach was to remove the default aci: (targetattr != "userPassword || krbPrincipalKey || sambaLMPassword || sambaNTPassword || passwordHistory || krbMKey || userPKCS12")(version 3.0; acl "Enable Anonymous access"; allow (read, search, compare) userdn = "ldap:///anyone";) and add needed permissions to specified user groups. But it appeared that there are other things that rely on this aci and as a result e.g "ipa user-find foo" stopped working as well (executed from the FreeIPA server with admin session). I figured it might be a bit too painful to try to find out all the needed aci rules if the default one is removed. So I came in to conclusion I just create a role for each customer, e.g "Customer1" and assign that role to all customer's user groups and hosts (too bad it isn't possible to assign a role to a hostgroup) . This requires an aci to be created for each customer though: aci: (target = "ldap:///uid=*,cn=users,cn=accounts,dc=test")(targetfilter="(!(memberOf=cn=Customer1,cn=roles,cn=accounts,dc=test))")(targetattr = "*")(version 3.0;acl "permission:View only Customer1";deny(all) groupdn = "ldap:///cn=Customer1,cn=roles,cn=accounts,dc=test";) Well, actually not just one aci, but probably one for groups and so on, but with the same idea. The actual amount of required ACIs is still unclear since I just started testing this out, but even though there were 10 ACIs per customer I find it easier to manage than the amount of FreeIPA installations it would take to run an own domain for each. With this setup, customer's users and hosts shouldn't see data outside of their role. 389-ds's aci macros seem to have a limitation that if ($dn) is used in targetfilter, there has to be ($dn) in target as well. But since the user tree is flat, it doesn't seem to be possible to take the advantage of macro ACIs even though there's a obvious pattern in the way I'd like things to work. It is easily scripted though. I think the elegant solution would require FreeIPA to support multiple domains or configurable directory structure. I've seen some discussion about the latter and I do understand why many people are not fans of it. From dpal at redhat.com Wed Dec 7 19:28:05 2011 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 07 Dec 2011 14:28:05 -0500 Subject: [Freeipa-users] Limiting group/user visibility In-Reply-To: <4EDF7D9B.7090802@iki.fi> References: <4ED61116.1020206@iki.fi> <20111201124641.GF7875@zeppelin.brq.redhat.com> <1322745151.2474.3.camel@sgallagh520.sgallagh.bos.redhat.com> <4ED7B300.8000109@iki.fi> <4EDF7D9B.7090802@iki.fi> Message-ID: <4EDFBE45.6060404@redhat.com> > I think I found at least one solution, that probably isn't the most > elegant one. On the other hand I don't think with the current > limitations of FreeIPA it is even possible to do much better. Any > comments/suggestions are of course welcome. > > My first approach was to remove the default aci: > (targetattr != "userPassword || krbPrincipalKey || sambaLMPassword || > sambaNTPassword || passwordHistory || krbMKey || userPKCS12")(version > 3.0; acl "Enable Anonymous access"; allow (read, search, compare) userdn > = "ldap:///anyone";) > > and add needed permissions to specified user groups. But it appeared > that there are other things that rely on this aci and as a result e.g > "ipa user-find foo" stopped working as well (executed from the FreeIPA > server with admin session). I figured it might be a bit too painful to > try to find out all the needed aci rules if the default one is removed. > > So I came in to conclusion I just create a role for each customer, e.g > "Customer1" and assign that role to all customer's user groups and hosts > (too bad it isn't possible to assign a role to a hostgroup) . This > requires an aci to be created for each customer though: > > aci: (target = > "ldap:///uid=*,cn=users,cn=accounts,dc=test")(targetfilter="(!(memberOf=cn=Customer1,cn=roles,cn=accounts,dc=test))")(targetattr > = "*")(version 3.0;acl "permission:View only Customer1";deny(all) > groupdn = "ldap:///cn=Customer1,cn=roles,cn=accounts,dc=test";) > > Well, actually not just one aci, but probably one for groups and so on, > but with the same idea. The actual amount of required ACIs is still > unclear since I just started testing this out, but even though there > were 10 ACIs per customer I find it easier to manage than the amount of > FreeIPA installations it would take to run an own domain for each. > > With this setup, customer's users and hosts shouldn't see data outside > of their role. 389-ds's aci macros seem to have a limitation that if > ($dn) is used in targetfilter, there has to be ($dn) in target as well. > But since the user tree is flat, it doesn't seem to be possible to take > the advantage of macro ACIs even though there's a obvious pattern in the > way I'd like things to work. It is easily scripted though. > > I think the elegant solution would require FreeIPA to support multiple > domains or configurable directory structure. I've seen some discussion > about the latter and I do understand why many people are not fans of it. > > Seems like the right direction to me. Would you mind creating a wiki page that would outline the solution when it is ready. It seems that other people would benefit from your experience. Also it would be great to understand how we can make the process of configuring ACIs simpler for someone. There is definitely a room for improvement so if you can file a trac ticket or BZ (or several) with your enhancement recommendations would be great. -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From Steven.Jones at vuw.ac.nz Wed Dec 7 19:30:18 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Wed, 7 Dec 2011 19:30:18 +0000 Subject: [Freeipa-users] IPA to HNAS (Bluearc) Message-ID: <833D8E48405E064EBC54C84EC6B36E404C469B76@STAWINCOX10MBX1.staff.vuw.ac.nz> So far seems to be going well but 2307 not 2307bis..... regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 From gregswift at gmail.com Wed Dec 7 20:10:07 2011 From: gregswift at gmail.com (Greg Swift) Date: Wed, 7 Dec 2011 14:10:07 -0600 Subject: [Freeipa-users] changing domain name Message-ID: I'm having a debate with our hostmaster. His general complaint is that systems like AD and FreeIPA should not be so closely tied to the domain name because some standard such as his group distributes include a hostname that may change every few years (moving datacenters etc). Since I am not deep in AD for FreeIPA (i just lurk the list and play with FreeIPA whenever I get a chance, which isn't as often as I'd like), does anyone have any solid points about this to help educate me so I can understand better, and thus hopefully get him to understand why its necessary? -greg -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Wed Dec 7 20:22:12 2011 From: simo at redhat.com (Simo Sorce) Date: Wed, 07 Dec 2011 15:22:12 -0500 Subject: [Freeipa-users] changing domain name In-Reply-To: References: Message-ID: <1323289332.16138.39.camel@willson.li.ssimo.org> On Wed, 2011-12-07 at 14:10 -0600, Greg Swift wrote: > I'm having a debate with our hostmaster. His general complaint is > that systems like AD and FreeIPA should not be so closely tied to the > domain name because some standard such as his group distributes > include a hostname that may change every few years (moving datacenters > etc). > > Since I am not deep in AD for FreeIPA (i just lurk the list and play > with FreeIPA whenever I get a chance, which isn't as often as I'd > like), does anyone have any solid points about this to help educate me > so I can understand better, and thus hopefully get him to understand > why its necessary? Choose a name that is no particularly tied to your datacenter and can be moved with the AD/FreeIPA install. Keep in mind that unlike AD, FreeIPA allows your clients to use whatever hostname they want. This comes with some manual work on your krb5.conf files across the domain, but it is doable. Simo. -- Simo Sorce * Red Hat, Inc * New York From natxo.asenjo at gmail.com Wed Dec 7 22:00:19 2011 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Wed, 7 Dec 2011 23:00:19 +0100 Subject: [Freeipa-users] dns delegated zone issue Message-ID: hi, for 'historical' reasons, I have a working dns zone in my lan, say example.com. In this zone, I have delegated an ipa.example.com zone for ipa. I have setup freeipa (homelab, SL 6.1 with version ipa-server-2.0.0-23.el6.i686) and it works, I have a server and a client (kdc.ipa.example.com and ipaclient01.ipa.example.com). >From a laptop (not member of the ipa realm) I kinit to this realm $ klist Ticket cache: FILE:/tmp/krb5cc_500 Default principal: user at IPA.EXAMPLE.COM Valid starting Expires Service principal 12/07/11 22:24:17 12/08/11 22:24:17 krbtgt/IPA.EXAMPLE.COM at IPA.EXAMPLE.COM renew until 12/14/11 22:24:17 12/07/11 22:24:43 12/08/11 22:24:17 HTTP/kdc.ipa.example.com.nx at IPA.EXAMPLE.COM renew until 12/14/11 22:24:17 12/07/11 22:27:28 12/08/11 22:24:17 host/kdc.ipa.example.com.nx at IPA.EXAMPLE.COM renew until 12/14/11 22:24:17 As you see, I could go on the web ui and login from ssh. When logging in the ipaclient01, I get prompted to enter a password and the error is clear when getting verbose output from slogin: $ slogin -v user at ipaclient01 ....... debug1: Next authentication method: gssapi-with-mic debug1: Unspecified GSS failure. Minor code may provide more information Server krbtgt/EXAMPLE.COM at IPA.EXAMPLE.COM not found in Kerberos database debug1: Unspecified GSS failure. Minor code may provide more information Server krbtgt/EXAMPLE.COM at IPA.EXAMPLE.COM not found in Kerberos database If I login using a fqdn instead of the simple one, then it works. The funny thing is, I can use the simple dns name to login the kdc server. Why? I use both the example.com as the ipa.example.com in the laptop's search field in /etc/resolv.conf, by the way. Another question: why is it not possible to add simple hostnames as a service principal? TIA, great stuff so far :-) -- Groeten, natxo From Steven.Jones at vuw.ac.nz Wed Dec 7 22:45:35 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Wed, 7 Dec 2011 22:45:35 +0000 Subject: [Freeipa-users] Solaris 10 as IPA Client? In-Reply-To: References: <20111201053106.GA25969@noboost.org> <36385.62.148.39.180.1322734176.squirrel@www.nixtra.com> <4EDA6FF7.8050400@redhat.com> <833D8E48405E064EBC54C84EC6B36E404C44AB7A@STAWINCOX10MBX1.staff.vuw.ac.nz> <4EDCD7F9.5060304@redhat.com> <833D8E48405E064EBC54C84EC6B36E404C4592F6@STAWINCOX10MBX1.staff.vuw.ac.nz> <4EDD2C52.70209@nixtra.com> <833D8E48405E064EBC54C84EC6B36E404C45C560@STAWINCOX10MBX1.staff.vuw.ac.nz>, Message-ID: <833D8E48405E064EBC54C84EC6B36E404C46AD23@STAWINCOX10MBX1.staff.vuw.ac.nz> 8><------- > "Vendors" in NZ just import in a box, its a function of our small population, few have any depth of knowledge....a few have happily admitted to me that if we buy the hardware they will get some training....until then they are as clueless as we are. Wow. Are you talking to technical staff or to sales people there? -- natxo 8><-------- hehe.... Its usually sales ppl, very few tehcies.....typical sales of a few "boxes" per year....you dont have many techies on that quantity.....for instance with BlueArc/Hitachi they have imported a techy/architect over from OZ for a week to set this up....this is one of the first setups in NZ, there may not be another for many months..... This is normal for NZ. Anything we do even until recently with RedHat...(no architects or any Red Hat employees on the ground here) is they fly over from OZ....So we used to see RH architect 2 times a year if we were lucky....now we have some senior level ppl in Auckland.... :D So I finally have a RH senior to talk to here.......in MS heaven that's cool. (everything here is Microsoft). NZ is so small.....we have 5000 employees that makes us something like in the top 20 biggest organisation in NZ......... But if you think thats bad, I also deal with some pacific islands they get their hardware from NZ.....and they are poor.....Im talking to a friend in one island and the biggest 3 organisations there use freenas for a SAN/NAS.... regards From lassi.polonen at iki.fi Wed Dec 7 23:07:15 2011 From: lassi.polonen at iki.fi (=?ISO-8859-1?Q?Lassi_P=F6l=F6nen?=) Date: Thu, 08 Dec 2011 01:07:15 +0200 Subject: [Freeipa-users] Limiting group/user visibility In-Reply-To: <4EDFBE45.6060404@redhat.com> References: <4ED61116.1020206@iki.fi> <20111201124641.GF7875@zeppelin.brq.redhat.com> <1322745151.2474.3.camel@sgallagh520.sgallagh.bos.redhat.com> <4ED7B300.8000109@iki.fi> <4EDF7D9B.7090802@iki.fi> <4EDFBE45.6060404@redhat.com> Message-ID: <4EDFF1A3.9050600@iki.fi> On 7.12.2011 21:28, Dmitri Pal wrote: >> I think I found at least one solution, that probably isn't the most >> elegant one. On the other hand I don't think with the current >> limitations of FreeIPA it is even possible to do much better. Any >> comments/suggestions are of course welcome. >> >> My first approach was to remove the default aci: >> (targetattr != "userPassword || krbPrincipalKey || sambaLMPassword || >> sambaNTPassword || passwordHistory || krbMKey || userPKCS12")(version >> 3.0; acl "Enable Anonymous access"; allow (read, search, compare) userdn >> = "ldap:///anyone";) >> >> and add needed permissions to specified user groups. But it appeared >> that there are other things that rely on this aci and as a result e.g >> "ipa user-find foo" stopped working as well (executed from the FreeIPA >> server with admin session). I figured it might be a bit too painful to >> try to find out all the needed aci rules if the default one is removed. >> >> So I came in to conclusion I just create a role for each customer, e.g >> "Customer1" and assign that role to all customer's user groups and hosts >> (too bad it isn't possible to assign a role to a hostgroup) . This >> requires an aci to be created for each customer though: >> >> aci: (target = >> "ldap:///uid=*,cn=users,cn=accounts,dc=test")(targetfilter="(!(memberOf=cn=Customer1,cn=roles,cn=accounts,dc=test))")(targetattr >> = "*")(version 3.0;acl "permission:View only Customer1";deny(all) >> groupdn = "ldap:///cn=Customer1,cn=roles,cn=accounts,dc=test";) >> >> Well, actually not just one aci, but probably one for groups and so on, >> but with the same idea. The actual amount of required ACIs is still >> unclear since I just started testing this out, but even though there >> were 10 ACIs per customer I find it easier to manage than the amount of >> FreeIPA installations it would take to run an own domain for each. >> >> With this setup, customer's users and hosts shouldn't see data outside >> of their role. 389-ds's aci macros seem to have a limitation that if >> ($dn) is used in targetfilter, there has to be ($dn) in target as well. >> But since the user tree is flat, it doesn't seem to be possible to take >> the advantage of macro ACIs even though there's a obvious pattern in the >> way I'd like things to work. It is easily scripted though. >> >> I think the elegant solution would require FreeIPA to support multiple >> domains or configurable directory structure. I've seen some discussion >> about the latter and I do understand why many people are not fans of it. >> >> > Seems like the right direction to me. > Would you mind creating a wiki page that would outline the solution when > it is ready. > It seems that other people would benefit from your experience. > > Also it would be great to understand how we can make the process of > configuring ACIs simpler for someone. > There is definitely a room for improvement so if you can file a trac > ticket or BZ (or several) with your enhancement recommendations would be > great. Sure thing, once I figure out all the bits and pieces. My use case doesn't cover e.g mounts but will try to look into all the aspects. Currently the possible caveats are still unknown as well. From gregswift at gmail.com Thu Dec 8 02:19:19 2011 From: gregswift at gmail.com (Greg Swift) Date: Wed, 7 Dec 2011 20:19:19 -0600 Subject: [Freeipa-users] changing domain name In-Reply-To: <1323289332.16138.39.camel@willson.li.ssimo.org> References: <1323289332.16138.39.camel@willson.li.ssimo.org> Message-ID: On Wed, Dec 7, 2011 at 14:22, Simo Sorce wrote: > On Wed, 2011-12-07 at 14:10 -0600, Greg Swift wrote: > > I'm having a debate with our hostmaster. His general complaint is > > that systems like AD and FreeIPA should not be so closely tied to the > > domain name because some standard such as his group distributes > > include a hostname that may change every few years (moving datacenters > > etc). > > > > Since I am not deep in AD for FreeIPA (i just lurk the list and play > > with FreeIPA whenever I get a chance, which isn't as often as I'd > > like), does anyone have any solid points about this to help educate me > > so I can understand better, and thus hopefully get him to understand > > why its necessary? > > Choose a name that is no particularly tied to your datacenter and can be > moved with the AD/FreeIPA install. > > Keep in mind that unlike AD, FreeIPA allows your clients to use whatever > hostname they want. This comes with some manual work on your krb5.conf > files across the domain, but it is doable. Hmm I realized you could disconnect the domain name from the DOMAIN, but thought it was generally considered a bad practice and complicated matters. If FreeIPA is that much more flexible thats exciting, sadly for others in our org, they have lots of AD though. Thanks for the response -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Thu Dec 8 15:36:26 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 08 Dec 2011 10:36:26 -0500 Subject: [Freeipa-users] Limiting group/user visibility In-Reply-To: <4EDFF1A3.9050600@iki.fi> References: <4ED61116.1020206@iki.fi> <20111201124641.GF7875@zeppelin.brq.redhat.com> <1322745151.2474.3.camel@sgallagh520.sgallagh.bos.redhat.com> <4ED7B300.8000109@iki.fi> <4EDF7D9B.7090802@iki.fi> <4EDFBE45.6060404@redhat.com> <4EDFF1A3.9050600@iki.fi> Message-ID: <4EE0D97A.50800@redhat.com> Lassi P?l?nen wrote: > On 7.12.2011 21:28, Dmitri Pal wrote: >>> I think I found at least one solution, that probably isn't the most >>> elegant one. On the other hand I don't think with the current >>> limitations of FreeIPA it is even possible to do much better. Any >>> comments/suggestions are of course welcome. >>> >>> My first approach was to remove the default aci: >>> (targetattr != "userPassword || krbPrincipalKey || sambaLMPassword || >>> sambaNTPassword || passwordHistory || krbMKey || userPKCS12")(version >>> 3.0; acl "Enable Anonymous access"; allow (read, search, compare) userdn >>> = "ldap:///anyone";) >>> >>> and add needed permissions to specified user groups. But it appeared >>> that there are other things that rely on this aci and as a result e.g >>> "ipa user-find foo" stopped working as well (executed from the FreeIPA >>> server with admin session). I figured it might be a bit too painful to >>> try to find out all the needed aci rules if the default one is removed. >>> >>> So I came in to conclusion I just create a role for each customer, e.g >>> "Customer1" and assign that role to all customer's user groups and hosts >>> (too bad it isn't possible to assign a role to a hostgroup) . This >>> requires an aci to be created for each customer though: >>> >>> aci: (target = >>> "ldap:///uid=*,cn=users,cn=accounts,dc=test")(targetfilter="(!(memberOf=cn=Customer1,cn=roles,cn=accounts,dc=test))")(targetattr >>> >>> = "*")(version 3.0;acl "permission:View only Customer1";deny(all) >>> groupdn = "ldap:///cn=Customer1,cn=roles,cn=accounts,dc=test";) >>> >>> Well, actually not just one aci, but probably one for groups and so on, >>> but with the same idea. The actual amount of required ACIs is still >>> unclear since I just started testing this out, but even though there >>> were 10 ACIs per customer I find it easier to manage than the amount of >>> FreeIPA installations it would take to run an own domain for each. >>> >>> With this setup, customer's users and hosts shouldn't see data outside >>> of their role. 389-ds's aci macros seem to have a limitation that if >>> ($dn) is used in targetfilter, there has to be ($dn) in target as well. >>> But since the user tree is flat, it doesn't seem to be possible to take >>> the advantage of macro ACIs even though there's a obvious pattern in the >>> way I'd like things to work. It is easily scripted though. >>> >>> I think the elegant solution would require FreeIPA to support multiple >>> domains or configurable directory structure. I've seen some discussion >>> about the latter and I do understand why many people are not fans of it. >>> >>> >> Seems like the right direction to me. >> Would you mind creating a wiki page that would outline the solution when >> it is ready. >> It seems that other people would benefit from your experience. >> >> Also it would be great to understand how we can make the process of >> configuring ACIs simpler for someone. >> There is definitely a room for improvement so if you can file a trac >> ticket or BZ (or several) with your enhancement recommendations would be >> great. > > Sure thing, once I figure out all the bits and pieces. My use case > doesn't cover e.g mounts but will try to look into all the aspects. > Currently the possible caveats are still unknown as well. Unless you need per-object acis you can probably simplify the filter to cover the entire DIT by dropping the target and using just the targetfilter. I'd recommend verifying that data doesn't leak via schema compat if you have that enabled. rob From danieljamesscott at gmail.com Thu Dec 8 17:55:49 2011 From: danieljamesscott at gmail.com (Dan Scott) Date: Thu, 8 Dec 2011 12:55:49 -0500 Subject: [Freeipa-users] CA replication Message-ID: Hi, I just tried to add a CA replica to my IPA replica (Both Fedora 15) using: ipa-ca-install replica-info-ohm.gpg It proceeds to configure the directory server for the CA, but fails when 'configuring certificate server': Configuring certificate server: Estimated time 3 minutes 30 seconds [1/11]: creating certificate server user [2/11]: creating pki-ca instance [3/11]: configuring certificate server instance root : CRITICAL failed to configure ca instance Command '/usr/bin/perl /usr/bin/pkisilent 'ConfigureCA' '-cs_hostname' 'ohm.example.com' '-cs_port' '9445' '-client_certdb_dir' '/tmp/tmp-Mbw1ut' '-client_certdb_pwd' XXXXXXXX '-preop_pin' 'XXXXXXXXX' '-domain_name' 'IPA' '-admin_user' 'admin' '-admin_email' 'root at localhost' '-admin_password' XXXXXXXX '-agent_name' 'ipa-ca-agent' '-agent_key_size' '2048' '-agent_key_type' 'rsa' '-agent_cert_subject' 'CN=ipa-ca-agent,O=EXAMPLE.COM' '-ldap_host' 'ohm.example.com' '-ldap_port' '7389' '-bind_dn' 'cn=Directory Manager' '-bind_password' XXXXXXXX '-base_dn' 'o=ipaca' '-db_name' 'ipaca' '-key_size' '2048' '-key_type' 'rsa' '-key_algorithm' 'SHA256withRSA' '-save_p12' 'true' '-backup_pwd' XXXXXXXX '-subsystem_name' 'pki-cad' '-token_name' 'internal' '-ca_subsystem_cert_subject_name' 'CN=CA Subsystem,O=EXAMPLE.COM' '-ca_ocsp_cert_subject_name' 'CN=OCSP Subsystem,O=EXAMPLE.COM' '-ca_server_cert_subject_name' 'CN=ohm.example.com,O=EXAMPLE.COM' '-ca_audit_signing_cert_subject_name' 'CN=CA Audit,O=EXAMPLE.COM' '-ca_sign_cert_subject_name' 'CN=Certificate Authority,O=EXAMPLE.COM' '-external' 'false' '-clone' 'true' '-clone_p12_file' 'ca.p12' '-clone_p12_password' XXXXXXXX '-sd_hostname' 'curie.example.com' '-sd_admin_port' '443' '-sd_admin_name' 'admin' '-sd_admin_password' XXXXXXXX '-clone_start_tls' 'true' '-clone_uri' 'https://curie.example.com:443'' returned non-zero exit status 255 creation of replica failed: Configuration of CA failed Some errors from /var/log/ipareplica-ca-install.log Error in DomainPanel(): updateStatus value is null ERROR: ConfigureCA: DomainPanel() failure ERROR: unable to create CA File "/usr/sbin/ipa-ca-install", line 156, in main() File "/usr/sbin/ipa-ca-install", line 141, in main (CA, cs) = cainstance.install_replica_ca(config, postinstall=True) File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 1136, in install_replica_ca subject_base=config.subject_base) File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 537, in configure_instance self.start_creation("Configuring certificate server", 210) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 248, in start_creation method() File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 680, in __configure_instance raise RuntimeError('Configuration of CA failed') Anyone have any ideas? Thanks, Dan From rcritten at redhat.com Thu Dec 8 18:29:56 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 08 Dec 2011 13:29:56 -0500 Subject: [Freeipa-users] CA replication In-Reply-To: References: Message-ID: <4EE10224.9020104@redhat.com> Dan Scott wrote: > Hi, > > I just tried to add a CA replica to my IPA replica (Both Fedora 15) using: > > ipa-ca-install replica-info-ohm.gpg > > It proceeds to configure the directory server for the CA, but fails > when 'configuring certificate server': > > Configuring certificate server: Estimated time 3 minutes 30 seconds > [1/11]: creating certificate server user > [2/11]: creating pki-ca instance > [3/11]: configuring certificate server instance > root : CRITICAL failed to configure ca instance Command > '/usr/bin/perl /usr/bin/pkisilent 'ConfigureCA' '-cs_hostname' > 'ohm.example.com' '-cs_port' '9445' '-client_certdb_dir' > '/tmp/tmp-Mbw1ut' '-client_certdb_pwd' XXXXXXXX '-preop_pin' > 'XXXXXXXXX' '-domain_name' 'IPA' '-admin_user' 'admin' '-admin_email' > 'root at localhost' '-admin_password' XXXXXXXX '-agent_name' > 'ipa-ca-agent' '-agent_key_size' '2048' '-agent_key_type' 'rsa' > '-agent_cert_subject' 'CN=ipa-ca-agent,O=EXAMPLE.COM' '-ldap_host' > 'ohm.example.com' '-ldap_port' '7389' '-bind_dn' 'cn=Directory > Manager' '-bind_password' XXXXXXXX '-base_dn' 'o=ipaca' '-db_name' > 'ipaca' '-key_size' '2048' '-key_type' 'rsa' '-key_algorithm' > 'SHA256withRSA' '-save_p12' 'true' '-backup_pwd' XXXXXXXX > '-subsystem_name' 'pki-cad' '-token_name' 'internal' > '-ca_subsystem_cert_subject_name' 'CN=CA Subsystem,O=EXAMPLE.COM' > '-ca_ocsp_cert_subject_name' 'CN=OCSP Subsystem,O=EXAMPLE.COM' > '-ca_server_cert_subject_name' 'CN=ohm.example.com,O=EXAMPLE.COM' > '-ca_audit_signing_cert_subject_name' 'CN=CA Audit,O=EXAMPLE.COM' > '-ca_sign_cert_subject_name' 'CN=Certificate Authority,O=EXAMPLE.COM' > '-external' 'false' '-clone' 'true' '-clone_p12_file' 'ca.p12' > '-clone_p12_password' XXXXXXXX '-sd_hostname' 'curie.example.com' > '-sd_admin_port' '443' '-sd_admin_name' 'admin' '-sd_admin_password' > XXXXXXXX '-clone_start_tls' 'true' '-clone_uri' > 'https://curie.example.com:443'' returned non-zero exit status 255 > creation of replica failed: Configuration of CA failed > > Some errors from /var/log/ipareplica-ca-install.log > > Error in DomainPanel(): updateStatus value is null > ERROR: ConfigureCA: DomainPanel() failure > ERROR: unable to create CA > > File "/usr/sbin/ipa-ca-install", line 156, in > main() > > File "/usr/sbin/ipa-ca-install", line 141, in main > (CA, cs) = cainstance.install_replica_ca(config, postinstall=True) > > File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", > line 1136, in install_replica_ca > subject_base=config.subject_base) > > File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", > line 537, in configure_instance > self.start_creation("Configuring certificate server", 210) > > File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", > line 248, in start_creation > method() > > File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", > line 680, in __configure_instance > raise RuntimeError('Configuration of CA failed') > > Anyone have any ideas? /var/log/pki-ca/debug probably has more details. This might also be ticket https://fedorahosted.org/freeipa/ticket/2148 rob From Steven.Jones at vuw.ac.nz Thu Dec 8 20:49:06 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Thu, 8 Dec 2011 20:49:06 +0000 Subject: [Freeipa-users] admin Message-ID: <833D8E48405E064EBC54C84EC6B36E404C470437@STAWINCOX10MBX1.staff.vuw.ac.nz> Is this user blocked from logging into a IPA client? regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 From rcritten at redhat.com Thu Dec 8 21:00:36 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 08 Dec 2011 16:00:36 -0500 Subject: [Freeipa-users] admin In-Reply-To: <833D8E48405E064EBC54C84EC6B36E404C470437@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E404C470437@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <4EE12574.4090508@redhat.com> Steven Jones wrote: > Is this user blocked from logging into a IPA client? No, it is more or less a normal user. rob From jhrozek at redhat.com Thu Dec 8 21:00:49 2011 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 8 Dec 2011 22:00:49 +0100 Subject: [Freeipa-users] admin In-Reply-To: <833D8E48405E064EBC54C84EC6B36E404C470437@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E404C470437@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <20111208210049.GC6363@hendrix.redhat.com> On Thu, Dec 08, 2011 at 08:49:06PM +0000, Steven Jones wrote: > Is this user blocked from logging into a IPA client? > > It is not blocked, I often use admin as a test dummy for SSSD testing. From Steven.Jones at vuw.ac.nz Thu Dec 8 21:20:41 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Thu, 8 Dec 2011 21:20:41 +0000 Subject: [Freeipa-users] admin In-Reply-To: <20111208210049.GC6363@hendrix.redhat.com> References: <833D8E48405E064EBC54C84EC6B36E404C470437@STAWINCOX10MBX1.staff.vuw.ac.nz>, <20111208210049.GC6363@hendrix.redhat.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E404C470532@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, yeah Im having issues with IPA....groups dont work and new HBAC rules dont either. Hopefully its because its 6.2beta.....but I cant update my sat server from RH so I cant patch it.....im getting 1.2kbps ... :/ regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Jakub Hrozek [jhrozek at redhat.com] Sent: Friday, 9 December 2011 10:00 a.m. To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] admin On Thu, Dec 08, 2011 at 08:49:06PM +0000, Steven Jones wrote: > Is this user blocked from logging into a IPA client? > > It is not blocked, I often use admin as a test dummy for SSSD testing. _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users From g17jimmy at gmail.com Thu Dec 8 21:31:43 2011 From: g17jimmy at gmail.com (Jimmy) Date: Thu, 8 Dec 2011 16:31:43 -0500 Subject: [Freeipa-users] synchronizing with AD In-Reply-To: <4EBD99B7.2090300@redhat.com> References: <4EBD86A7.1040309@redhat.com> <4EBD9432.2060701@redhat.com> <4EBD99B7.2090300@redhat.com> Message-ID: I had a few weeks away from this configuration and finally getting back to it. I'm uncertain of the correct path forward. I don't seem to be able to find the documentation on how to install the cert into the Passsync NSS database. I have been following this document: http://freeipa.org/docs/1.2/Installation_Deployment_Guide/en-US/html/chap-Installation_and_Deployment_Guide-Setting_up_Synchronization_Between_IPA_and_Active_Directory.html We are attempting to replicate users from an AD instance to FreeIPA, Thanks- Jimmy On Fri, Nov 11, 2011 at 4:55 PM, Rob Crittenden wrote: > Rich Megginson wrote: > >> On 11/11/2011 02:23 PM, Jimmy wrote: >> >>> I do have the AD SSL cert installed, but from how I read it, I need to >>> install the cert from the FreeIPA DS into Windows AD certificate store. >>> >> Perhaps for something else, but for windows sync/passsync, you do not >> need to install the cert from the FreeIPA DS into Windows AD certificate >> store. >> > > Right, you just need to install it in the Passsync NSS databsae. > > rob > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sigbjorn at nixtra.com Thu Dec 8 21:37:47 2011 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Thu, 08 Dec 2011 22:37:47 +0100 Subject: [Freeipa-users] synchronizing with AD In-Reply-To: References: <4EBD86A7.1040309@redhat.com> <4EBD9432.2060701@redhat.com> <4EBD99B7.2090300@redhat.com> Message-ID: <4EE12E2B.3050106@nixtra.com> Hi Jimmy, I believe this is the documentation for the old IPA 1 version. You'll find the updated guide at the link below. I used this guide for configuring IPA <-> AD sync. http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/index.html Regards, Siggi On 12/08/2011 10:31 PM, Jimmy wrote: > I had a few weeks away from this configuration and finally getting > back to it. I'm uncertain of the correct path forward. I don't seem to > be able to find the documentation on how to install the cert into the > Passsync NSS database. I have been following this document: > > http://freeipa.org/docs/1.2/Installation_Deployment_Guide/en-US/html/chap-Installation_and_Deployment_Guide-Setting_up_Synchronization_Between_IPA_and_Active_Directory.html > > We are attempting to replicate users from an AD instance to FreeIPA, > Thanks- Jimmy > > On Fri, Nov 11, 2011 at 4:55 PM, Rob Crittenden > wrote: > > Rich Megginson wrote: > > On 11/11/2011 02:23 PM, Jimmy wrote: > > I do have the AD SSL cert installed, but from how I read > it, I need to > install the cert from the FreeIPA DS into Windows AD > certificate store. > > Perhaps for something else, but for windows sync/passsync, you > do not > need to install the cert from the FreeIPA DS into Windows AD > certificate > store. > > > Right, you just need to install it in the Passsync NSS databsae. > > rob > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Thu Dec 8 21:44:53 2011 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 08 Dec 2011 14:44:53 -0700 Subject: [Freeipa-users] synchronizing with AD In-Reply-To: References: <4EBD86A7.1040309@redhat.com> <4EBD9432.2060701@redhat.com> <4EBD99B7.2090300@redhat.com> Message-ID: <4EE12FD5.2010901@redhat.com> On 12/08/2011 02:31 PM, Jimmy wrote: > I had a few weeks away from this configuration and finally getting > back to it. I'm uncertain of the correct path forward. I don't seem to > be able to find the documentation on how to install the cert into the > Passsync NSS database. I have been following this document: > > http://freeipa.org/docs/1.2/Installation_Deployment_Guide/en-US/html/chap-Installation_and_Deployment_Guide-Setting_up_Synchronization_Between_IPA_and_Active_Directory.html > > We are attempting to replicate users from an AD instance to FreeIPA, > Thanks- Jimmy There's this: Refer to the Fedora Directory Server Administration Guide for more information on the Windows Sync utility. Not only should it not be called "Fedora Directory Server" but the link is out of date - should point to the latest doc here http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html-single/Administration_Guide/index.html#Windows_Sync-About_Windows_Sync For information specifically about setting up passsync on Windows, see http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html-single/Administration_Guide/index.html#Configuring_Windows_Sync-Install_the_Password_Sync_Service > > On Fri, Nov 11, 2011 at 4:55 PM, Rob Crittenden > wrote: > > Rich Megginson wrote: > > On 11/11/2011 02:23 PM, Jimmy wrote: > > I do have the AD SSL cert installed, but from how I read > it, I need to > install the cert from the FreeIPA DS into Windows AD > certificate store. > > Perhaps for something else, but for windows sync/passsync, you > do not > need to install the cert from the FreeIPA DS into Windows AD > certificate > store. > > > Right, you just need to install it in the Passsync NSS databsae. > > rob > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danieljamesscott at gmail.com Thu Dec 8 22:28:25 2011 From: danieljamesscott at gmail.com (Dan Scott) Date: Thu, 8 Dec 2011 17:28:25 -0500 Subject: [Freeipa-users] CA replication In-Reply-To: <4EE10224.9020104@redhat.com> References: <4EE10224.9020104@redhat.com> Message-ID: Hi, On Thu, Dec 8, 2011 at 13:29, Rob Crittenden wrote: > Dan Scott wrote: >> >> Hi, >> >> I just tried to add a CA replica to my IPA replica (Both Fedora 15) using: >> >> ipa-ca-install replica-info-ohm.gpg >> >> It proceeds to configure the directory server for the CA, but fails >> when 'configuring certificate server': >> >> Configuring certificate server: Estimated time 3 minutes 30 seconds >> ? [1/11]: creating certificate server user >> ? [2/11]: creating pki-ca instance >> ? [3/11]: configuring certificate server instance >> root ? ? ? ?: CRITICAL failed to configure ca instance Command >> '/usr/bin/perl /usr/bin/pkisilent 'ConfigureCA' '-cs_hostname' >> 'ohm.example.com' '-cs_port' '9445' '-client_certdb_dir' >> '/tmp/tmp-Mbw1ut' '-client_certdb_pwd' XXXXXXXX '-preop_pin' >> 'XXXXXXXXX' '-domain_name' 'IPA' '-admin_user' 'admin' '-admin_email' >> 'root at localhost' '-admin_password' XXXXXXXX '-agent_name' >> 'ipa-ca-agent' '-agent_key_size' '2048' '-agent_key_type' 'rsa' >> '-agent_cert_subject' 'CN=ipa-ca-agent,O=EXAMPLE.COM' '-ldap_host' >> 'ohm.example.com' '-ldap_port' '7389' '-bind_dn' 'cn=Directory >> Manager' '-bind_password' XXXXXXXX '-base_dn' 'o=ipaca' '-db_name' >> 'ipaca' '-key_size' '2048' '-key_type' 'rsa' '-key_algorithm' >> 'SHA256withRSA' '-save_p12' 'true' '-backup_pwd' XXXXXXXX >> '-subsystem_name' 'pki-cad' '-token_name' 'internal' >> '-ca_subsystem_cert_subject_name' 'CN=CA Subsystem,O=EXAMPLE.COM' >> '-ca_ocsp_cert_subject_name' 'CN=OCSP Subsystem,O=EXAMPLE.COM' >> '-ca_server_cert_subject_name' 'CN=ohm.example.com,O=EXAMPLE.COM' >> '-ca_audit_signing_cert_subject_name' 'CN=CA Audit,O=EXAMPLE.COM' >> '-ca_sign_cert_subject_name' 'CN=Certificate Authority,O=EXAMPLE.COM' >> '-external' 'false' '-clone' 'true' '-clone_p12_file' 'ca.p12' >> '-clone_p12_password' XXXXXXXX '-sd_hostname' 'curie.example.com' >> '-sd_admin_port' '443' '-sd_admin_name' 'admin' '-sd_admin_password' >> XXXXXXXX '-clone_start_tls' 'true' '-clone_uri' >> 'https://curie.example.com:443'' returned non-zero exit status 255 >> creation of replica failed: Configuration of CA failed >> >> Some errors from /var/log/ipareplica-ca-install.log >> >> Error in DomainPanel(): updateStatus value is null >> ERROR: ConfigureCA: DomainPanel() failure >> ERROR: unable to create CA >> >> ? File "/usr/sbin/ipa-ca-install", line 156, in >> ? ? main() >> >> ? File "/usr/sbin/ipa-ca-install", line 141, in main >> ? ? (CA, cs) = cainstance.install_replica_ca(config, postinstall=True) >> >> ? File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", >> line 1136, in install_replica_ca >> ? ? subject_base=config.subject_base) >> >> ? File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", >> line 537, in configure_instance >> ? ? self.start_creation("Configuring certificate server", 210) >> >> ? File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >> line 248, in start_creation >> ? ? method() >> >> ? File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", >> line 680, in __configure_instance >> ? ? raise RuntimeError('Configuration of CA failed') >> >> Anyone have any ideas? > > > /var/log/pki-ca/debug probably has more details. This file contains the following errors: [08/Dec/2011:12:24:40][http-9445-2]: SecurityDomainPanel: validating SSL Admin HTTPS . . . [08/Dec/2011:12:24:40][http-9445-2]: WizardPanelBase pingCS: started [08/Dec/2011:12:24:40][http-9445-2]: WizardPanelBase: pingCS: parser failedorg.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 50; White spaces are required between publicId and systemId. [08/Dec/2011:12:24:40][http-9445-2]: SecurityDomainPanel: pingAdminCS no successful response for SSL Admin HTTPS [08/Dec/2011:12:24:40][http-9445-2]: WizardPanelBase getCertChainUsingSecureAdminPort start [08/Dec/2011:12:24:40][http-9445-2]: WizardPanelBase::getCertChainUsingSecureAdminPort() - Exception=org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 50; White spaces are required between publicId and systemId. [08/Dec/2011:12:24:40][http-9445-2]: WizardPanelBase: getCertChainUsingSecureAdminPort: java.io.IOException: org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 50; White spaces are required between publicId and systemId. [08/Dec/2011:12:24:40][http-9445-2]: WizardPanelBase pingCS: started [08/Dec/2011:12:24:40][http-9445-1]: CMSServlet:service() uri = /ca/admin/ca/getStatus [08/Dec/2011:12:24:40][http-9445-1]: CMSServlet: caGetStatus start to service. [08/Dec/2011:12:24:40][http-9445-1]: CMSServlet: curDate=Thu Dec 08 12:24:40 EST 2011 id=caGetStatus time=32 [08/Dec/2011:12:24:40][http-9445-2]: WizardPanelBase pingCS: got XML parsed [08/Dec/2011:12:24:40][http-9445-2]: WizardPanelBase pingCS: state=0 [08/Dec/2011:12:24:40][http-9445-2]: panel no=3 [08/Dec/2011:12:24:40][http-9445-2]: panel name=securitydomain [08/Dec/2011:12:24:40][http-9445-2]: total number of panels=19 [08/Dec/2011:12:24:40][http-9445-2]: WizardServlet: found xml [08/Dec/2011:12:24:40][http-9445-2]: Error: unknown type org.apache.catalina.connector.ResponseFacade [08/Dec/2011:12:24:40][http-9445-2]: Error: unknown type org.apache.catalina.connector.RequestFacade > This might also be ticket https://fedorahosted.org/freeipa/ticket/2148 The script passes the port-check, so it doesn't look like it's the issue mentioned. Is there a workaround for this issue? Thanks, Dan From Steven.Jones at vuw.ac.nz Fri Dec 9 00:11:13 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Fri, 9 Dec 2011 00:11:13 +0000 Subject: [Freeipa-users] converting users to ldap command line Message-ID: <833D8E48405E064EBC54C84EC6B36E404C4718A0@STAWINCOX10MBX1.staff.vuw.ac.nz> I Created a user storage-admin I have a domain unux.vuw.ac.nz in terms of ou's and dc's what would that look like? regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 From simo at redhat.com Fri Dec 9 00:19:39 2011 From: simo at redhat.com (Simo Sorce) Date: Thu, 08 Dec 2011 19:19:39 -0500 Subject: [Freeipa-users] converting users to ldap command line In-Reply-To: <833D8E48405E064EBC54C84EC6B36E404C4718A0@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E404C4718A0@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <1323389979.4413.13.camel@willson.li.ssimo.org> On Fri, 2011-12-09 at 00:11 +0000, Steven Jones wrote: > I Created a user > > storage-admin > > I have a domain unux.vuw.ac.nz > > in terms of ou's and dc's what would that look like? If you are asking what the DN of the user is then that would be: uid=storage-admin,cn=users,cn=accounts,dc=unux,dc=vuw,dc=ac,dc=nz If you have not done it yet, I suggest you use an LDAP browser like Apache Directory Studio so you can see what the DIT looks like at any time. I recommend not using it to change values or create new entries for ipa objects unless you are intimately familiar with the ipa framework code though. Simo. -- Simo Sorce * Red Hat, Inc * New York From Steven.Jones at vuw.ac.nz Fri Dec 9 00:49:48 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Fri, 9 Dec 2011 00:49:48 +0000 Subject: [Freeipa-users] converting users to ldap command line In-Reply-To: <1323389979.4413.13.camel@willson.li.ssimo.org> References: <833D8E48405E064EBC54C84EC6B36E404C4718A0@STAWINCOX10MBX1.staff.vuw.ac.nz>, <1323389979.4413.13.camel@willson.li.ssimo.org> Message-ID: <833D8E48405E064EBC54C84EC6B36E404C4728E0@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, Thanks, yes DN... Now I have this first sample I might be OK.... but I will take a look at that ADS... regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: Simo Sorce [simo at redhat.com] Sent: Friday, 9 December 2011 1:19 p.m. To: Steven Jones Cc: freeipa-users Subject: Re: [Freeipa-users] converting users to ldap command line On Fri, 2011-12-09 at 00:11 +0000, Steven Jones wrote: > I Created a user > > storage-admin > > I have a domain unux.vuw.ac.nz > > in terms of ou's and dc's what would that look like? If you are asking what the DN of the user is then that would be: uid=storage-admin,cn=users,cn=accounts,dc=unux,dc=vuw,dc=ac,dc=nz If you have not done it yet, I suggest you use an LDAP browser like Apache Directory Studio so you can see what the DIT looks like at any time. I recommend not using it to change values or create new entries for ipa objects unless you are intimately familiar with the ipa framework code though. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Fri Dec 9 00:55:20 2011 From: simo at redhat.com (Simo Sorce) Date: Thu, 08 Dec 2011 19:55:20 -0500 Subject: [Freeipa-users] dns delegated zone issue In-Reply-To: References: Message-ID: <1323392120.4413.24.camel@willson.li.ssimo.org> On Wed, 2011-12-07 at 23:00 +0100, Natxo Asenjo wrote: > hi, > > for 'historical' reasons, I have a working dns zone in my lan, say > example.com. In this zone, I have delegated an ipa.example.com zone > for ipa. > > I have setup freeipa (homelab, SL 6.1 with version > ipa-server-2.0.0-23.el6.i686) and it works, I have a server and a > client (kdc.ipa.example.com and ipaclient01.ipa.example.com). > > >From a laptop (not member of the ipa realm) I kinit to this realm > > > $ klist > Ticket cache: FILE:/tmp/krb5cc_500 > Default principal: user at IPA.EXAMPLE.COM > > Valid starting Expires Service principal > 12/07/11 22:24:17 12/08/11 22:24:17 krbtgt/IPA.EXAMPLE.COM at IPA.EXAMPLE.COM > renew until 12/14/11 22:24:17 > 12/07/11 22:24:43 12/08/11 22:24:17 > HTTP/kdc.ipa.example.com.nx at IPA.EXAMPLE.COM > renew until 12/14/11 22:24:17 > 12/07/11 22:27:28 12/08/11 22:24:17 > host/kdc.ipa.example.com.nx at IPA.EXAMPLE.COM > renew until 12/14/11 22:24:17 > > As you see, I could go on the web ui and login from ssh. > > When logging in the ipaclient01, I get prompted to enter a password > and the error is clear when getting verbose output from slogin: > > $ slogin -v user at ipaclient01 > ....... > debug1: Next authentication method: gssapi-with-mic > debug1: Unspecified GSS failure. Minor code may provide more information > Server krbtgt/EXAMPLE.COM at IPA.EXAMPLE.COM not found in Kerberos database > > debug1: Unspecified GSS failure. Minor code may provide more information > Server krbtgt/EXAMPLE.COM at IPA.EXAMPLE.COM not found in Kerberos database > > If I login using a fqdn instead of the simple one, then it works. The > funny thing is, I can use the simple dns name to login the kdc server. > Why? Not sure why it work on your kdc, perhaps you have entries in /etc/hosts that resolves it first. > I use both the example.com as the ipa.example.com in the laptop's > search field in /etc/resolv.conf, by the way. This is the issue. Your client is trying to use the name ipaclient01.example.com and seeing it is not in the ipa.example.com your krb libs are trying to search for a trsuted realm named 'EXAMPLE.COM' whic does not exist of course. Using the fqdn there is no ambiguity and therefore your krb libs know what is the full name an the principal they should look for. > Another question: why is it not possible to add simple hostnames as a > service principal? In theory you could, and turning off canonicalization completely you would be able to get a ticket. But in general a FQDN name is needed to connect to another host if you do not have a specific search domain. A simple host name would be ambiguous, how do you know which ticket to fetch if you have both www.example.com and www.ipa.example.com and want to do kerb auth against one or the other server? Clearly the HTTP/www at IPA.EXAMPLE.COM principal can only be used by one of them while a FQDN instead makes it pretty unambiguous in all cases. Also a FQDN is sometimes used because there are historically protocols where the name of the server is not know directly, but only through a PTR record which is resolved into a FQDN name. Simo. -- Simo Sorce * Red Hat, Inc * New York From Steven.Jones at vuw.ac.nz Fri Dec 9 02:15:18 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Fri, 9 Dec 2011 02:15:18 +0000 Subject: [Freeipa-users] using kerberos Message-ID: <833D8E48405E064EBC54C84EC6B36E404C472922@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi >From the HNAS manual.... 8><----- Kerberos Configuration Configuring the NAS server requires three steps: 1. Create the principal and key of the service (the EVS) on the KDC (Key Distribution Center). 2. Export a keytab file from the KDC. We recommend using MIT Kerberos version 5. 3. Import the keytab file into the NAS server. 4. Set the Kerberos realm for the NAS server. 8><----- How is 1) and 2) performed on the IPA server? regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 From sbose at redhat.com Fri Dec 9 08:17:34 2011 From: sbose at redhat.com (Sumit Bose) Date: Fri, 9 Dec 2011 09:17:34 +0100 Subject: [Freeipa-users] using kerberos In-Reply-To: <833D8E48405E064EBC54C84EC6B36E404C472922@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E404C472922@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <20111209081734.GL2262@localhost.localdomain> On Fri, Dec 09, 2011 at 02:15:18AM +0000, Steven Jones wrote: > Hi > > >From the HNAS manual.... > > 8><----- > Kerberos Configuration > Configuring the NAS server requires three steps: > 1. Create the principal and key of the service (the EVS) on the KDC (Key > Distribution Center). > 2. Export a keytab file from the KDC. We recommend using MIT Kerberos > version 5. > 3. Import the keytab file into the NAS server. > 4. Set the Kerberos realm for the NAS server. > 8><----- > > How is 1) and 2) performed on the IPA server? I think you are looking for: ipa service-add cifs/my.nas.test ipa-getkeytab -s my.ipa.server -p cifs/my.nas.test -k /tmp/nas.keytab I'm guessing here that you want to use cifs on the NAS box. You might want to change this if you use other methods to access the NAS box. HTH bye, Sumit > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From natxo.asenjo at gmail.com Fri Dec 9 08:44:32 2011 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Fri, 9 Dec 2011 09:44:32 +0100 Subject: [Freeipa-users] dns delegated zone issue In-Reply-To: <1323392120.4413.24.camel@willson.li.ssimo.org> References: <1323392120.4413.24.camel@willson.li.ssimo.org> Message-ID: On Fri, Dec 9, 2011 at 1:55 AM, Simo Sorce wrote: >> If I login using a fqdn instead of the simple one, then it works. The >> funny thing is, I can use the simple dns name to login the kdc server. >> Why? > > Not sure why it work on your kdc, perhaps you have entries in /etc/hosts that resolves it first. spot on, adding that entry in the ipaclient01 host allows simple name logins to the the host. >> I use both the example.com as the ipa.example.com in the laptop's >> search field in /etc/resolv.conf, by the way. > > This is the issue. Your client is trying to use the name > ipaclient01.example.com and seeing it is not in the ipa.example.com your > krb libs are trying to search for a trsuted realm named 'EXAMPLE.COM' > whic does not exist of course. > > Using the fqdn there is no ambiguity and therefore your krb libs know > what is the full name an the principal they should look for. ok. I guess I have to think about the order I want the clients have search their default dns domains and realms. I mean, for members of the ipa realm it appears to make more sense to get the ipa realm dns as first search option and the parent domain as second search option. I should also use the kdc dns server as default name server for those clients and have the example.com as forwareder in the kdc. I changed the dhcp server range and the kdc name server picked up the change and modified the A rr for the ipaclient01 (impressive, dyndns without any configuration of the dchp server), but the example.com ns still had a cached resolution op the ipaclient01 A rr that pointed to the old range. >> Another question: why is it not possible to add simple hostnames as a >> service principal? > > In theory you could, and turning off canonicalization completely you > would be able to get a ticket. But in general a FQDN name is needed to > connect to another host if you do not have a specific search domain. > > A simple host name would be ambiguous, how do you know which ticket to > fetch if you have both www.example.com and www.ipa.example.com and want > to do kerb auth against one or the other server? Clearly the > HTTP/www at IPA.EXAMPLE.COM principal can only be used by one of them while > a FQDN instead makes it pretty unambiguous in all cases. > > Also a FQDN is sometimes used because there are historically protocols > where the name of the server is not know directly, but only through a > PTR record which is resolved into a FQDN name. Thanks for your explanation. The reason I was asking this is because I have seen that in AD those simple spn attributes are automatically added to computers that join the AD domain. So maybe IPA could do the same if we have explicitely set the ipa dns domain as first search domain. I'll look into this later. Thanks! -- natxo From lassi.polonen at iki.fi Fri Dec 9 12:51:46 2011 From: lassi.polonen at iki.fi (=?ISO-8859-1?Q?Lassi_P=F6l=F6nen?=) Date: Fri, 09 Dec 2011 14:51:46 +0200 Subject: [Freeipa-users] Limiting group/user visibility In-Reply-To: <4EE0D97A.50800@redhat.com> References: <4ED61116.1020206@iki.fi> <20111201124641.GF7875@zeppelin.brq.redhat.com> <1322745151.2474.3.camel@sgallagh520.sgallagh.bos.redhat.com> <4ED7B300.8000109@iki.fi> <4EDF7D9B.7090802@iki.fi> <4EDFBE45.6060404@redhat.com> <4EDFF1A3.9050600@iki.fi> <4EE0D97A.50800@redhat.com> Message-ID: <4EE20462.90304@iki.fi> On 2011-12-08 17:36, Rob Crittenden wrote: > Lassi P?l?nen wrote: >> On 7.12.2011 21:28, Dmitri Pal wrote: >>>> So I came in to conclusion I just create a role for each customer, e.g >>>> "Customer1" and assign that role to all customer's user groups and >>>> hosts >>>> (too bad it isn't possible to assign a role to a hostgroup) . This >>>> requires an aci to be created for each customer though: >>>> Actually it seems to be possible to assign roles to host groups as well. Just not from Identity -> Host groups. IPA Server -> RBAC -> Roles has the option though. > Unless you need per-object acis you can probably simplify the filter > to cover the entire DIT by dropping the target and using just the > targetfilter. > > I'd recommend verifying that data doesn't leak via schema compat if > you have that enabled. > > rob Looks like dropping the target prevents a user from logging in, so apparently there's some entries that need to be accessible other than those labeled with memberOf . One additional thing came in to my mind: user private groups probably need to be accessible as well. At least by default there doesn't seem to be a way to assign the same role for those as well. From rcritten at redhat.com Fri Dec 9 14:24:58 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 09 Dec 2011 09:24:58 -0500 Subject: [Freeipa-users] CA replication In-Reply-To: References: <4EE10224.9020104@redhat.com> Message-ID: <4EE21A3A.2040008@redhat.com> Dan Scott wrote: > Hi, > > On Thu, Dec 8, 2011 at 13:29, Rob Crittenden wrote: >> Dan Scott wrote: >>> >>> Hi, >>> >>> I just tried to add a CA replica to my IPA replica (Both Fedora 15) using: >>> >>> ipa-ca-install replica-info-ohm.gpg >>> >>> It proceeds to configure the directory server for the CA, but fails >>> when 'configuring certificate server': >>> >>> Configuring certificate server: Estimated time 3 minutes 30 seconds >>> [1/11]: creating certificate server user >>> [2/11]: creating pki-ca instance >>> [3/11]: configuring certificate server instance >>> root : CRITICAL failed to configure ca instance Command >>> '/usr/bin/perl /usr/bin/pkisilent 'ConfigureCA' '-cs_hostname' >>> 'ohm.example.com' '-cs_port' '9445' '-client_certdb_dir' >>> '/tmp/tmp-Mbw1ut' '-client_certdb_pwd' XXXXXXXX '-preop_pin' >>> 'XXXXXXXXX' '-domain_name' 'IPA' '-admin_user' 'admin' '-admin_email' >>> 'root at localhost' '-admin_password' XXXXXXXX '-agent_name' >>> 'ipa-ca-agent' '-agent_key_size' '2048' '-agent_key_type' 'rsa' >>> '-agent_cert_subject' 'CN=ipa-ca-agent,O=EXAMPLE.COM' '-ldap_host' >>> 'ohm.example.com' '-ldap_port' '7389' '-bind_dn' 'cn=Directory >>> Manager' '-bind_password' XXXXXXXX '-base_dn' 'o=ipaca' '-db_name' >>> 'ipaca' '-key_size' '2048' '-key_type' 'rsa' '-key_algorithm' >>> 'SHA256withRSA' '-save_p12' 'true' '-backup_pwd' XXXXXXXX >>> '-subsystem_name' 'pki-cad' '-token_name' 'internal' >>> '-ca_subsystem_cert_subject_name' 'CN=CA Subsystem,O=EXAMPLE.COM' >>> '-ca_ocsp_cert_subject_name' 'CN=OCSP Subsystem,O=EXAMPLE.COM' >>> '-ca_server_cert_subject_name' 'CN=ohm.example.com,O=EXAMPLE.COM' >>> '-ca_audit_signing_cert_subject_name' 'CN=CA Audit,O=EXAMPLE.COM' >>> '-ca_sign_cert_subject_name' 'CN=Certificate Authority,O=EXAMPLE.COM' >>> '-external' 'false' '-clone' 'true' '-clone_p12_file' 'ca.p12' >>> '-clone_p12_password' XXXXXXXX '-sd_hostname' 'curie.example.com' >>> '-sd_admin_port' '443' '-sd_admin_name' 'admin' '-sd_admin_password' >>> XXXXXXXX '-clone_start_tls' 'true' '-clone_uri' >>> 'https://curie.example.com:443'' returned non-zero exit status 255 >>> creation of replica failed: Configuration of CA failed >>> >>> Some errors from /var/log/ipareplica-ca-install.log >>> >>> Error in DomainPanel(): updateStatus value is null >>> ERROR: ConfigureCA: DomainPanel() failure >>> ERROR: unable to create CA >>> >>> File "/usr/sbin/ipa-ca-install", line 156, in >>> main() >>> >>> File "/usr/sbin/ipa-ca-install", line 141, in main >>> (CA, cs) = cainstance.install_replica_ca(config, postinstall=True) >>> >>> File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", >>> line 1136, in install_replica_ca >>> subject_base=config.subject_base) >>> >>> File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", >>> line 537, in configure_instance >>> self.start_creation("Configuring certificate server", 210) >>> >>> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >>> line 248, in start_creation >>> method() >>> >>> File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", >>> line 680, in __configure_instance >>> raise RuntimeError('Configuration of CA failed') >>> >>> Anyone have any ideas? >> >> >> /var/log/pki-ca/debug probably has more details. > > This file contains the following errors: > > [08/Dec/2011:12:24:40][http-9445-2]: SecurityDomainPanel: validating > SSL Admin HTTPS . . . > [08/Dec/2011:12:24:40][http-9445-2]: WizardPanelBase pingCS: started > [08/Dec/2011:12:24:40][http-9445-2]: WizardPanelBase: pingCS: parser > failedorg.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 50; > White spaces are required between publicId and systemId. > [08/Dec/2011:12:24:40][http-9445-2]: SecurityDomainPanel: pingAdminCS > no successful response for SSL Admin HTTPS > [08/Dec/2011:12:24:40][http-9445-2]: WizardPanelBase > getCertChainUsingSecureAdminPort start > [08/Dec/2011:12:24:40][http-9445-2]: > WizardPanelBase::getCertChainUsingSecureAdminPort() - > Exception=org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: > 50; White spaces are required between publicId and systemId. > [08/Dec/2011:12:24:40][http-9445-2]: WizardPanelBase: > getCertChainUsingSecureAdminPort: java.io.IOException: > org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 50; White > spaces are required between publicId and systemId. > [08/Dec/2011:12:24:40][http-9445-2]: WizardPanelBase pingCS: started > [08/Dec/2011:12:24:40][http-9445-1]: CMSServlet:service() uri = > /ca/admin/ca/getStatus > [08/Dec/2011:12:24:40][http-9445-1]: CMSServlet: caGetStatus start to service. > [08/Dec/2011:12:24:40][http-9445-1]: CMSServlet: curDate=Thu Dec 08 > 12:24:40 EST 2011 id=caGetStatus time=32 > [08/Dec/2011:12:24:40][http-9445-2]: WizardPanelBase pingCS: got XML parsed > [08/Dec/2011:12:24:40][http-9445-2]: WizardPanelBase pingCS: state=0 > [08/Dec/2011:12:24:40][http-9445-2]: panel no=3 > [08/Dec/2011:12:24:40][http-9445-2]: panel name=securitydomain > [08/Dec/2011:12:24:40][http-9445-2]: total number of panels=19 > [08/Dec/2011:12:24:40][http-9445-2]: WizardServlet: found xml > [08/Dec/2011:12:24:40][http-9445-2]: Error: unknown type > org.apache.catalina.connector.ResponseFacade > [08/Dec/2011:12:24:40][http-9445-2]: Error: unknown type > org.apache.catalina.connector.RequestFacade I'll point the dogtag guys at this to see if they notice anything. >> This might also be ticket https://fedorahosted.org/freeipa/ticket/2148 > > The script passes the port-check, so it doesn't look like it's the > issue mentioned. Is there a workaround for this issue? This is different from port-check. Dogtag stores the security domain information in its LDAP database. When creating a replica (or clone, in dogtag lingo) it compares the ports being requested with what is stored in the security domain and will reject if they don't match. Look for invalid clone_uri in the debug log to see if this is the problem. rob From danieljamesscott at gmail.com Fri Dec 9 15:16:41 2011 From: danieljamesscott at gmail.com (Dan Scott) Date: Fri, 9 Dec 2011 10:16:41 -0500 Subject: [Freeipa-users] CA replication In-Reply-To: <4EE21A3A.2040008@redhat.com> References: <4EE10224.9020104@redhat.com> <4EE21A3A.2040008@redhat.com> Message-ID: Hi, On Fri, Dec 9, 2011 at 09:24, Rob Crittenden wrote: > Dan Scott wrote: >> >> Hi, >> >> On Thu, Dec 8, 2011 at 13:29, Rob Crittenden ?wrote: >>> >>> Dan Scott wrote: >>>> >>>> >>>> Hi, >>>> >>>> I just tried to add a CA replica to my IPA replica (Both Fedora 15) >>>> using: >>>> >>>> ipa-ca-install replica-info-ohm.gpg >>>> >>>> It proceeds to configure the directory server for the CA, but fails >>>> when 'configuring certificate server': >>>> >>>> Configuring certificate server: Estimated time 3 minutes 30 seconds >>>> ? [1/11]: creating certificate server user >>>> ? [2/11]: creating pki-ca instance >>>> ? [3/11]: configuring certificate server instance >>>> root ? ? ? ?: CRITICAL failed to configure ca instance Command >>>> '/usr/bin/perl /usr/bin/pkisilent 'ConfigureCA' '-cs_hostname' >>>> 'ohm.example.com' '-cs_port' '9445' '-client_certdb_dir' >>>> '/tmp/tmp-Mbw1ut' '-client_certdb_pwd' XXXXXXXX '-preop_pin' >>>> 'XXXXXXXXX' '-domain_name' 'IPA' '-admin_user' 'admin' '-admin_email' >>>> 'root at localhost' '-admin_password' XXXXXXXX '-agent_name' >>>> 'ipa-ca-agent' '-agent_key_size' '2048' '-agent_key_type' 'rsa' >>>> '-agent_cert_subject' 'CN=ipa-ca-agent,O=EXAMPLE.COM' '-ldap_host' >>>> 'ohm.example.com' '-ldap_port' '7389' '-bind_dn' 'cn=Directory >>>> Manager' '-bind_password' XXXXXXXX '-base_dn' 'o=ipaca' '-db_name' >>>> 'ipaca' '-key_size' '2048' '-key_type' 'rsa' '-key_algorithm' >>>> 'SHA256withRSA' '-save_p12' 'true' '-backup_pwd' XXXXXXXX >>>> '-subsystem_name' 'pki-cad' '-token_name' 'internal' >>>> '-ca_subsystem_cert_subject_name' 'CN=CA Subsystem,O=EXAMPLE.COM' >>>> '-ca_ocsp_cert_subject_name' 'CN=OCSP Subsystem,O=EXAMPLE.COM' >>>> '-ca_server_cert_subject_name' 'CN=ohm.example.com,O=EXAMPLE.COM' >>>> '-ca_audit_signing_cert_subject_name' 'CN=CA Audit,O=EXAMPLE.COM' >>>> '-ca_sign_cert_subject_name' 'CN=Certificate Authority,O=EXAMPLE.COM' >>>> '-external' 'false' '-clone' 'true' '-clone_p12_file' 'ca.p12' >>>> '-clone_p12_password' XXXXXXXX '-sd_hostname' 'curie.example.com' >>>> '-sd_admin_port' '443' '-sd_admin_name' 'admin' '-sd_admin_password' >>>> XXXXXXXX '-clone_start_tls' 'true' '-clone_uri' >>>> 'https://curie.example.com:443'' returned non-zero exit status 255 >>>> creation of replica failed: Configuration of CA failed >>>> >>>> Some errors from /var/log/ipareplica-ca-install.log >>>> >>>> Error in DomainPanel(): updateStatus value is null >>>> ERROR: ConfigureCA: DomainPanel() failure >>>> ERROR: unable to create CA >>>> >>>> ? File "/usr/sbin/ipa-ca-install", line 156, in >>>> ? ? main() >>>> >>>> ? File "/usr/sbin/ipa-ca-install", line 141, in main >>>> ? ? (CA, cs) = cainstance.install_replica_ca(config, postinstall=True) >>>> >>>> ? File >>>> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", >>>> line 1136, in install_replica_ca >>>> ? ? subject_base=config.subject_base) >>>> >>>> ? File >>>> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", >>>> line 537, in configure_instance >>>> ? ? self.start_creation("Configuring certificate server", 210) >>>> >>>> ? File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >>>> line 248, in start_creation >>>> ? ? method() >>>> >>>> ? File >>>> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", >>>> line 680, in __configure_instance >>>> ? ? raise RuntimeError('Configuration of CA failed') >>>> >>>> Anyone have any ideas? >>> >>> >>> >>> /var/log/pki-ca/debug probably has more details. >> >> >> This file contains the following errors: >> >> [08/Dec/2011:12:24:40][http-9445-2]: SecurityDomainPanel: validating >> SSL Admin HTTPS . . . >> [08/Dec/2011:12:24:40][http-9445-2]: WizardPanelBase pingCS: started >> [08/Dec/2011:12:24:40][http-9445-2]: WizardPanelBase: pingCS: parser >> failedorg.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 50; >> White spaces are required between publicId and systemId. >> [08/Dec/2011:12:24:40][http-9445-2]: SecurityDomainPanel: pingAdminCS >> no successful response for SSL Admin HTTPS >> [08/Dec/2011:12:24:40][http-9445-2]: WizardPanelBase >> getCertChainUsingSecureAdminPort start >> [08/Dec/2011:12:24:40][http-9445-2]: >> WizardPanelBase::getCertChainUsingSecureAdminPort() - >> Exception=org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: >> 50; White spaces are required between publicId and systemId. >> [08/Dec/2011:12:24:40][http-9445-2]: WizardPanelBase: >> getCertChainUsingSecureAdminPort: java.io.IOException: >> org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 50; White >> spaces are required between publicId and systemId. >> [08/Dec/2011:12:24:40][http-9445-2]: WizardPanelBase pingCS: started >> [08/Dec/2011:12:24:40][http-9445-1]: CMSServlet:service() uri = >> /ca/admin/ca/getStatus >> [08/Dec/2011:12:24:40][http-9445-1]: CMSServlet: caGetStatus start to >> service. >> [08/Dec/2011:12:24:40][http-9445-1]: CMSServlet: curDate=Thu Dec 08 >> 12:24:40 EST 2011 id=caGetStatus time=32 >> [08/Dec/2011:12:24:40][http-9445-2]: WizardPanelBase pingCS: got XML >> parsed >> [08/Dec/2011:12:24:40][http-9445-2]: WizardPanelBase pingCS: state=0 >> [08/Dec/2011:12:24:40][http-9445-2]: panel no=3 >> [08/Dec/2011:12:24:40][http-9445-2]: panel name=securitydomain >> [08/Dec/2011:12:24:40][http-9445-2]: total number of panels=19 >> [08/Dec/2011:12:24:40][http-9445-2]: WizardServlet: found xml >> [08/Dec/2011:12:24:40][http-9445-2]: Error: unknown type >> org.apache.catalina.connector.ResponseFacade >> [08/Dec/2011:12:24:40][http-9445-2]: Error: unknown type >> org.apache.catalina.connector.RequestFacade > > > I'll point the dogtag guys at this to see if they notice anything. > > >>> This might also be ticket https://fedorahosted.org/freeipa/ticket/2148 >> >> >> The script passes the port-check, so it doesn't look like it's the >> issue mentioned. Is there a workaround for this issue? > > > This is different from port-check. Dogtag stores the security domain > information in its LDAP database. When creating a replica (or clone, in > dogtag lingo) it compares the ports being requested with what is stored in > the security domain and will reject if they don't match. Look for invalid > clone_uri in the debug log to see if this is the problem. There's no mention of clone_uri anywhere in the debug log. Dan From rcritten at redhat.com Fri Dec 9 16:09:35 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 09 Dec 2011 11:09:35 -0500 Subject: [Freeipa-users] CA replication In-Reply-To: References: <4EE10224.9020104@redhat.com> <4EE21A3A.2040008@redhat.com> Message-ID: <4EE232BF.5010608@redhat.com> Dan Scott wrote: > Hi, > > On Fri, Dec 9, 2011 at 09:24, Rob Crittenden wrote: >> Dan Scott wrote: >>> >>> Hi, >>> >>> On Thu, Dec 8, 2011 at 13:29, Rob Crittenden wrote: >>>> >>>> Dan Scott wrote: >>>>> >>>>> >>>>> Hi, >>>>> >>>>> I just tried to add a CA replica to my IPA replica (Both Fedora 15) >>>>> using: >>>>> >>>>> ipa-ca-install replica-info-ohm.gpg >>>>> >>>>> It proceeds to configure the directory server for the CA, but fails >>>>> when 'configuring certificate server': >>>>> >>>>> Configuring certificate server: Estimated time 3 minutes 30 seconds >>>>> [1/11]: creating certificate server user >>>>> [2/11]: creating pki-ca instance >>>>> [3/11]: configuring certificate server instance >>>>> root : CRITICAL failed to configure ca instance Command >>>>> '/usr/bin/perl /usr/bin/pkisilent 'ConfigureCA' '-cs_hostname' >>>>> 'ohm.example.com' '-cs_port' '9445' '-client_certdb_dir' >>>>> '/tmp/tmp-Mbw1ut' '-client_certdb_pwd' XXXXXXXX '-preop_pin' >>>>> 'XXXXXXXXX' '-domain_name' 'IPA' '-admin_user' 'admin' '-admin_email' >>>>> 'root at localhost' '-admin_password' XXXXXXXX '-agent_name' >>>>> 'ipa-ca-agent' '-agent_key_size' '2048' '-agent_key_type' 'rsa' >>>>> '-agent_cert_subject' 'CN=ipa-ca-agent,O=EXAMPLE.COM' '-ldap_host' >>>>> 'ohm.example.com' '-ldap_port' '7389' '-bind_dn' 'cn=Directory >>>>> Manager' '-bind_password' XXXXXXXX '-base_dn' 'o=ipaca' '-db_name' >>>>> 'ipaca' '-key_size' '2048' '-key_type' 'rsa' '-key_algorithm' >>>>> 'SHA256withRSA' '-save_p12' 'true' '-backup_pwd' XXXXXXXX >>>>> '-subsystem_name' 'pki-cad' '-token_name' 'internal' >>>>> '-ca_subsystem_cert_subject_name' 'CN=CA Subsystem,O=EXAMPLE.COM' >>>>> '-ca_ocsp_cert_subject_name' 'CN=OCSP Subsystem,O=EXAMPLE.COM' >>>>> '-ca_server_cert_subject_name' 'CN=ohm.example.com,O=EXAMPLE.COM' >>>>> '-ca_audit_signing_cert_subject_name' 'CN=CA Audit,O=EXAMPLE.COM' >>>>> '-ca_sign_cert_subject_name' 'CN=Certificate Authority,O=EXAMPLE.COM' >>>>> '-external' 'false' '-clone' 'true' '-clone_p12_file' 'ca.p12' >>>>> '-clone_p12_password' XXXXXXXX '-sd_hostname' 'curie.example.com' >>>>> '-sd_admin_port' '443' '-sd_admin_name' 'admin' '-sd_admin_password' >>>>> XXXXXXXX '-clone_start_tls' 'true' '-clone_uri' >>>>> 'https://curie.example.com:443'' returned non-zero exit status 255 >>>>> creation of replica failed: Configuration of CA failed >>>>> >>>>> Some errors from /var/log/ipareplica-ca-install.log >>>>> >>>>> Error in DomainPanel(): updateStatus value is null >>>>> ERROR: ConfigureCA: DomainPanel() failure >>>>> ERROR: unable to create CA >>>>> >>>>> File "/usr/sbin/ipa-ca-install", line 156, in >>>>> main() >>>>> >>>>> File "/usr/sbin/ipa-ca-install", line 141, in main >>>>> (CA, cs) = cainstance.install_replica_ca(config, postinstall=True) >>>>> >>>>> File >>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", >>>>> line 1136, in install_replica_ca >>>>> subject_base=config.subject_base) >>>>> >>>>> File >>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", >>>>> line 537, in configure_instance >>>>> self.start_creation("Configuring certificate server", 210) >>>>> >>>>> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >>>>> line 248, in start_creation >>>>> method() >>>>> >>>>> File >>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", >>>>> line 680, in __configure_instance >>>>> raise RuntimeError('Configuration of CA failed') >>>>> >>>>> Anyone have any ideas? >>>> >>>> >>>> >>>> /var/log/pki-ca/debug probably has more details. >>> >>> >>> This file contains the following errors: >>> >>> [08/Dec/2011:12:24:40][http-9445-2]: SecurityDomainPanel: validating >>> SSL Admin HTTPS . . . >>> [08/Dec/2011:12:24:40][http-9445-2]: WizardPanelBase pingCS: started >>> [08/Dec/2011:12:24:40][http-9445-2]: WizardPanelBase: pingCS: parser >>> failedorg.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 50; >>> White spaces are required between publicId and systemId. >>> [08/Dec/2011:12:24:40][http-9445-2]: SecurityDomainPanel: pingAdminCS >>> no successful response for SSL Admin HTTPS >>> [08/Dec/2011:12:24:40][http-9445-2]: WizardPanelBase >>> getCertChainUsingSecureAdminPort start >>> [08/Dec/2011:12:24:40][http-9445-2]: >>> WizardPanelBase::getCertChainUsingSecureAdminPort() - >>> Exception=org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: >>> 50; White spaces are required between publicId and systemId. >>> [08/Dec/2011:12:24:40][http-9445-2]: WizardPanelBase: >>> getCertChainUsingSecureAdminPort: java.io.IOException: >>> org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 50; White >>> spaces are required between publicId and systemId. >>> [08/Dec/2011:12:24:40][http-9445-2]: WizardPanelBase pingCS: started >>> [08/Dec/2011:12:24:40][http-9445-1]: CMSServlet:service() uri = >>> /ca/admin/ca/getStatus >>> [08/Dec/2011:12:24:40][http-9445-1]: CMSServlet: caGetStatus start to >>> service. >>> [08/Dec/2011:12:24:40][http-9445-1]: CMSServlet: curDate=Thu Dec 08 >>> 12:24:40 EST 2011 id=caGetStatus time=32 >>> [08/Dec/2011:12:24:40][http-9445-2]: WizardPanelBase pingCS: got XML >>> parsed >>> [08/Dec/2011:12:24:40][http-9445-2]: WizardPanelBase pingCS: state=0 >>> [08/Dec/2011:12:24:40][http-9445-2]: panel no=3 >>> [08/Dec/2011:12:24:40][http-9445-2]: panel name=securitydomain >>> [08/Dec/2011:12:24:40][http-9445-2]: total number of panels=19 >>> [08/Dec/2011:12:24:40][http-9445-2]: WizardServlet: found xml >>> [08/Dec/2011:12:24:40][http-9445-2]: Error: unknown type >>> org.apache.catalina.connector.ResponseFacade >>> [08/Dec/2011:12:24:40][http-9445-2]: Error: unknown type >>> org.apache.catalina.connector.RequestFacade >> >> >> I'll point the dogtag guys at this to see if they notice anything. >> >> >>>> This might also be ticket https://fedorahosted.org/freeipa/ticket/2148 >>> >>> >>> The script passes the port-check, so it doesn't look like it's the >>> issue mentioned. Is there a workaround for this issue? >> >> >> This is different from port-check. Dogtag stores the security domain >> information in its LDAP database. When creating a replica (or clone, in >> dogtag lingo) it compares the ports being requested with what is stored in >> the security domain and will reject if they don't match. Look for invalid >> clone_uri in the debug log to see if this is the problem. > > There's no mention of clone_uri anywhere in the debug log. > > Dan Ok, can you provide the contents of the security domain? This will be printed out in the debug log. Or you can send me the debug log out of band. rob From sigbjorn at nixtra.com Sat Dec 10 17:56:13 2011 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Sat, 10 Dec 2011 18:56:13 +0100 Subject: [Freeipa-users] Replica and CA mess In-Reply-To: <4EDA6B5A.1060807@redhat.com> References: <4ED278FE.2010705@nixtra.com> <4ED39A07.1090006@redhat.com> <4ED3D19F.6040409@nixtra.com> <4EDA6B5A.1060807@redhat.com> Message-ID: <4EE39D3D.7020207@nixtra.com> On 12/03/2011 07:32 PM, Dmitri Pal wrote: > On 11/28/2011 01:23 PM, Sigbjorn Lie wrote: >> HTTP Server: port 443(https) (443): OK >> >> All ports except 389 fails when the master is IPv6 enabled, but the >> replica is only IPv4 enabled. >> >> Directory Service: Unsecure port (389): OK >> Directory Service: Secure port (636): FAILED >> Kerberos KDC: TCP (88): FAILED >> Kerberos KDC: UDP (88): FAILED >> Kerberos Kpasswd: TCP (464): FAILED >> Kerberos Kpasswd: UDP (464): FAILED >> HTTP Server: port 80 (80): FAILED >> HTTP Server: port 443(https) (443): FAILED >> >> Switching to IPv4 only addresses in resolv.conf resolves the issue. >> >> > Do we have a bug/ticket open on this? > From the lack of response, I guess no. I've opened a new request in bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=766162 From Steven.Jones at vuw.ac.nz Sun Dec 11 18:59:22 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Sun, 11 Dec 2011 18:59:22 +0000 Subject: [Freeipa-users] using kerberos In-Reply-To: <20111209081734.GL2262@localhost.localdomain> References: <833D8E48405E064EBC54C84EC6B36E404C472922@STAWINCOX10MBX1.staff.vuw.ac.nz>, <20111209081734.GL2262@localhost.localdomain> Message-ID: <833D8E48405E064EBC54C84EC6B36E404C473DCD@STAWINCOX10MBX1.staff.vuw.ac.nz> No, NFSv4 but CIFS howto might well prove useful. regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: Sumit Bose [sbose at redhat.com] Sent: Friday, 9 December 2011 9:17 p.m. To: Steven Jones Cc: freeipa-users Subject: Re: [Freeipa-users] using kerberos On Fri, Dec 09, 2011 at 02:15:18AM +0000, Steven Jones wrote: > Hi > > >From the HNAS manual.... > > 8><----- > Kerberos Configuration > Configuring the NAS server requires three steps: > 1. Create the principal and key of the service (the EVS) on the KDC (Key > Distribution Center). > 2. Export a keytab file from the KDC. We recommend using MIT Kerberos > version 5. > 3. Import the keytab file into the NAS server. > 4. Set the Kerberos realm for the NAS server. > 8><----- > > How is 1) and 2) performed on the IPA server? I think you are looking for: ipa service-add cifs/my.nas.test ipa-getkeytab -s my.ipa.server -p cifs/my.nas.test -k /tmp/nas.keytab I'm guessing here that you want to use cifs on the NAS box. You might want to change this if you use other methods to access the NAS box. HTH bye, Sumit > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From sigbjorn at nixtra.com Sun Dec 11 20:20:34 2011 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Sun, 11 Dec 2011 21:20:34 +0100 Subject: [Freeipa-users] sssd in Ubuntu Message-ID: <4EE51092.6040603@nixtra.com> Hi, Anyone attempting to use the sssd currently available in the Ubuntu package tree (1.5.13), need to also remember to install the packages: "libsasl2-modules-gssapi-mit" and "libsasl2-modules-ldap" for SSSD to work with IPA as a provider. These packages are not set up as dependencies for the sssd package. Bug filed with Ubuntu: https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/902902 Regards, Siggi From sigbjorn at nixtra.com Sun Dec 11 22:49:46 2011 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Sun, 11 Dec 2011 23:49:46 +0100 Subject: [Freeipa-users] sssd in Ubuntu In-Reply-To: <4EE51092.6040603@nixtra.com> References: <4EE51092.6040603@nixtra.com> Message-ID: <4EE5338A.60009@nixtra.com> On the other hand, even though looking up users, groups and netgroups seem fine, I cannot log in. Neither at the console, su, or ssh. Was there an issue with HBAC rules in SSSD 1.5.13 ? Dec 11 21:13:32 mint12 su[6769]: pam_sss(su:account): Access denied for user test: 6 (Permission denied) Rgds, Siggi On 12/11/2011 09:20 PM, Sigbjorn Lie wrote: > Hi, > > Anyone attempting to use the sssd currently available in the Ubuntu > package tree (1.5.13), need to also remember to install the packages: > "libsasl2-modules-gssapi-mit" and "libsasl2-modules-ldap" for SSSD to > work with IPA as a provider. > > These packages are not set up as dependencies for the sssd package. > > Bug filed with Ubuntu: > https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/902902 > > > Regards, > Siggi > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From freeipa at noboost.org Mon Dec 12 06:07:52 2011 From: freeipa at noboost.org (Craig T) Date: Mon, 12 Dec 2011 17:07:52 +1100 Subject: [Freeipa-users] NetApp Filer with IPA? Message-ID: <20111212060752.GA11447@noboost.org> Hi, Has anyone tried configuring a NetApp Fas 270 filer to work with IPA? I had it working perfectly via LDAP auth with 389 Directory Server (No IPA config) earlier, however I'm new to IPA and I'm not sure about the importance of being part of the "IPA REALM" for a device that will just use LDAP auth? cya Craig From jhrozek at redhat.com Mon Dec 12 09:52:50 2011 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 12 Dec 2011 10:52:50 +0100 Subject: [Freeipa-users] sssd in Ubuntu In-Reply-To: <4EE5338A.60009@nixtra.com> References: <4EE51092.6040603@nixtra.com> <4EE5338A.60009@nixtra.com> Message-ID: <20111212095250.GA5447@zeppelin.brq.redhat.com> On Sun, Dec 11, 2011 at 11:49:46PM +0100, Sigbjorn Lie wrote: > On the other hand, even though looking up users, groups and > netgroups seem fine, I cannot log in. Neither at the console, su, or > ssh. Was there an issue with HBAC rules in SSSD 1.5.13 ? > > Dec 11 21:13:32 mint12 su[6769]: pam_sss(su:account): Access denied > for user test: 6 (Permission denied) > > > > Rgds, > Siggi > Yes, there was a number of HBAC-related fixes since 1.5.13. The following commits touched files in src/providers/ipa/ipa_hbac*.[ch]: * Add a missing break (9077c3ebec92454d8ed949491c4ca89ed6cdf75a) * Do not access memory out of bounds (a2a954c4186aaa9e9dd027aebb986062fc5670e7) * HBAC: fix typos preventing proper hostgroup evaluation (28a9f96c3f9e6aa30fb1cbbbb33fe2ee2b1d7ef6) * HBAC: Do not save member/memberOf links (d14a28835223c0578b0a28a8c74d11777c50bcb9) * HBAC: Use originalMember for identifying servicegroups (d74b59b13208fa9508baaf5a1a5172fecad321ae) * HBAC: Use originalMember for identifying hostgroups (7c77e790204f82bce88dd6ecd237c941a9389349) Obviously, the Ubuntu package might have backported some of these into their 1.5.13 distribution package. The list was taken from upstream 1.5 branch. From sigbjorn at nixtra.com Mon Dec 12 10:55:30 2011 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Mon, 12 Dec 2011 11:55:30 +0100 (CET) Subject: [Freeipa-users] NetApp Filer with IPA? In-Reply-To: <20111212060752.GA11447@noboost.org> References: <20111212060752.GA11447@noboost.org> Message-ID: <29471.213.225.75.97.1323687330.squirrel@www.nixtra.com> Hi, I've used OnTAP 7.3.3 with IPA. Using LDAP lookups for users/groups and netgroups so far, using autenticated connections to the IPA LDAP server. Have not been able to get LDAPS working yet. I still have kerberos for NFSv4 left to configure. I used the following OnTAP config: options ldap.base dc=test,dc=local options ldap.base.group cn=groups,cn=compat,dc=test,dc=local options ldap.base.netgroup cn=ng,cn=compat,dc=test,dc=local options ldap.base.passwd cn=users,cn=accounts,dc=test,dc=local options ldap.servers ipa01.test.local options ldap.name uid=s-netapp,cn=users,cn=accounts,dc=test,dc=local options ldap.passwd passwordforbinduser options ldap.minimum_bind_level simple options ldap.usermap.attribute.unixaccount uid options ldap.servers ipa01.test.local options ldap.port 389 options ldap.ssl.enable off options ldap.usermap.attribute.unixaccount uid options ldap.usermap.attribute.windowsaccount ntUserDomainId options ldap.enable on Regards, Siggi On Mon, December 12, 2011 07:07, Craig T wrote: > Hi, > > > Has anyone tried configuring a NetApp Fas 270 filer to work with IPA? > I had it working perfectly via LDAP auth with 389 Directory Server (No IPA config) earlier, > however I'm new to IPA and I'm not sure about the importance of being part of the "IPA REALM" for > a device that will just use LDAP auth? > > cya > > Craig > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > From simo at redhat.com Mon Dec 12 14:31:11 2011 From: simo at redhat.com (Simo Sorce) Date: Mon, 12 Dec 2011 09:31:11 -0500 Subject: [Freeipa-users] NetApp Filer with IPA? In-Reply-To: <29471.213.225.75.97.1323687330.squirrel@www.nixtra.com> References: <20111212060752.GA11447@noboost.org> <29471.213.225.75.97.1323687330.squirrel@www.nixtra.com> Message-ID: <1323700271.4413.53.camel@willson.li.ssimo.org> On Mon, 2011-12-12 at 11:55 +0100, Sigbjorn Lie wrote: > options ldap.name uid=s-netapp,cn=users,cn=accounts,dc=test,dc=local > options ldap.passwd passwordforbinduser If you need a special user you can avoid polluting the normal user space by creating a user under cn=sysaccounts,cn=etc,suffix.. It is a simple object, you can look at one user already there called uid=kdc, it is basically just an objectclass and a userPassword. We have no UI to create these users though, you'll have to create them manually, and they are not seen as regular users by any client, they are useuful exclusively to bind to ldap with a plaintext password. Simo. -- Simo Sorce * Red Hat, Inc * New York From sigbjorn at nixtra.com Mon Dec 12 15:13:06 2011 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Mon, 12 Dec 2011 16:13:06 +0100 (CET) Subject: [Freeipa-users] NetApp Filer with IPA? In-Reply-To: <1323700271.4413.53.camel@willson.li.ssimo.org> References: <20111212060752.GA11447@noboost.org> <29471.213.225.75.97.1323687330.squirrel@www.nixtra.com> <1323700271.4413.53.camel@willson.li.ssimo.org> Message-ID: <33127.213.225.75.97.1323702786.squirrel@www.nixtra.com> On Mon, December 12, 2011 15:31, Simo Sorce wrote: > On Mon, 2011-12-12 at 11:55 +0100, Sigbjorn Lie wrote: > >> options ldap.name uid=s-netapp,cn=users,cn=accounts,dc=test,dc=local options ldap.passwd >> passwordforbinduser > > If you need a special user you can avoid polluting the normal user space > by creating a user under cn=sysaccounts,cn=etc,suffix.. > > It is a simple object, you can look at one user already there called > uid=kdc, it is basically just an objectclass and a userPassword. > > We have no UI to create these users though, you'll have to create them > manually, and they are not seen as regular users by any client, they are useuful exclusively to > bind to ldap with a plaintext password. Excellent! I suppose these are excempt from password policies? So their password will never expire...? Regards, Siggi From simo at redhat.com Mon Dec 12 15:18:59 2011 From: simo at redhat.com (Simo Sorce) Date: Mon, 12 Dec 2011 10:18:59 -0500 Subject: [Freeipa-users] NetApp Filer with IPA? In-Reply-To: <33127.213.225.75.97.1323702786.squirrel@www.nixtra.com> References: <20111212060752.GA11447@noboost.org> <29471.213.225.75.97.1323687330.squirrel@www.nixtra.com> <1323700271.4413.53.camel@willson.li.ssimo.org> <33127.213.225.75.97.1323702786.squirrel@www.nixtra.com> Message-ID: <1323703139.4413.63.camel@willson.li.ssimo.org> On Mon, 2011-12-12 at 16:13 +0100, Sigbjorn Lie wrote: > On Mon, December 12, 2011 15:31, Simo Sorce wrote: > > On Mon, 2011-12-12 at 11:55 +0100, Sigbjorn Lie wrote: > > > >> options ldap.name uid=s-netapp,cn=users,cn=accounts,dc=test,dc=local options ldap.passwd > >> passwordforbinduser > > > > If you need a special user you can avoid polluting the normal user space > > by creating a user under cn=sysaccounts,cn=etc,suffix.. > > > > It is a simple object, you can look at one user already there called > > uid=kdc, it is basically just an objectclass and a userPassword. > > > > We have no UI to create these users though, you'll have to create them > > manually, and they are not seen as regular users by any client, they are useuful exclusively to > > bind to ldap with a plaintext password. > > Excellent! > > I suppose these are excempt from password policies? So their password will never expire...? Yes the password policy applies only to kerberized entities. One of the reasons to use this. Simo. -- Simo Sorce * Red Hat, Inc * New York From ondrejv at s3group.cz Mon Dec 12 16:30:26 2011 From: ondrejv at s3group.cz (Ondrej Valousek) Date: Mon, 12 Dec 2011 17:30:26 +0100 Subject: [Freeipa-users] NetApp Filer with IPA? In-Reply-To: <29471.213.225.75.97.1323687330.squirrel@www.nixtra.com> References: <20111212060752.GA11447@noboost.org> <29471.213.225.75.97.1323687330.squirrel@www.nixtra.com> Message-ID: <4EE62C22.8010603@s3group.cz> I wonder if the following simplified setup I am using with AD: ldap.ADdomain mydomain.com ldap.enable on ldap.nssmap.attribute.uniqueMember Member ldap.nssmap.objectClass.groupOfUniqueNames Group ldap.nssmap.objectClass.posixAccount User ldap.nssmap.objectClass.posixGroup Group ldap.rfc2307bis.enable on would also work with IPA domains. I understand this would require NetApp to somehow join the IPA domain creating normal computer account, but I like the fact that I do not have to specify ldap server manually - NetApp finds it via DNS. Given the fact that IPA NS structure is pretty much similar to AD, it should just work, but I haven't tried yet.... Other bonus would be the possibility of using Kerberized NFSv4 w/ Netapp. Ondrej On 12/12/2011 11:55 AM, Sigbjorn Lie wrote: > Hi, > > I've used OnTAP 7.3.3 with IPA. Using LDAP lookups for users/groups and netgroups so far, using > autenticated connections to the IPA LDAP server. Have not been able to get LDAPS working yet. > > I still have kerberos for NFSv4 left to configure. > > I used the following OnTAP config: > > options ldap.base dc=test,dc=local > options ldap.base.group cn=groups,cn=compat,dc=test,dc=local > options ldap.base.netgroup cn=ng,cn=compat,dc=test,dc=local > options ldap.base.passwd cn=users,cn=accounts,dc=test,dc=local > options ldap.servers ipa01.test.local > options ldap.name uid=s-netapp,cn=users,cn=accounts,dc=test,dc=local > options ldap.passwd passwordforbinduser > options ldap.minimum_bind_level simple > options ldap.usermap.attribute.unixaccount uid > options ldap.servers ipa01.test.local > options ldap.port 389 > options ldap.ssl.enable off > options ldap.usermap.attribute.unixaccount uid > options ldap.usermap.attribute.windowsaccount ntUserDomainId > options ldap.enable on > > > Regards, > Siggi > > > > > On Mon, December 12, 2011 07:07, Craig T wrote: >> Hi, >> >> >> Has anyone tried configuring a NetApp Fas 270 filer to work with IPA? >> I had it working perfectly via LDAP auth with 389 Directory Server (No IPA config) earlier, >> however I'm new to IPA and I'm not sure about the importance of being part of the "IPA REALM" for >> a device that will just use LDAP auth? >> >> cya >> >> Craig >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications at s3group.com. Thank You. Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sigbjorn at nixtra.com Mon Dec 12 18:34:09 2011 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Mon, 12 Dec 2011 19:34:09 +0100 Subject: [Freeipa-users] NetApp Filer with IPA? In-Reply-To: <1323703139.4413.63.camel@willson.li.ssimo.org> References: <20111212060752.GA11447@noboost.org> <29471.213.225.75.97.1323687330.squirrel@www.nixtra.com> <1323700271.4413.53.camel@willson.li.ssimo.org> <33127.213.225.75.97.1323702786.squirrel@www.nixtra.com> <1323703139.4413.63.camel@willson.li.ssimo.org> Message-ID: <4EE64921.4010401@nixtra.com> On 12/12/2011 04:18 PM, Simo Sorce wrote: > On Mon, 2011-12-12 at 16:13 +0100, Sigbjorn Lie wrote: >> On Mon, December 12, 2011 15:31, Simo Sorce wrote: >>> On Mon, 2011-12-12 at 11:55 +0100, Sigbjorn Lie wrote: >>> >>>> options ldap.name uid=s-netapp,cn=users,cn=accounts,dc=test,dc=local options ldap.passwd >>>> passwordforbinduser >>> If you need a special user you can avoid polluting the normal user space >>> by creating a user under cn=sysaccounts,cn=etc,suffix.. >>> >>> It is a simple object, you can look at one user already there called >>> uid=kdc, it is basically just an objectclass and a userPassword. >>> >>> We have no UI to create these users though, you'll have to create them >>> manually, and they are not seen as regular users by any client, they are useuful exclusively to >>> bind to ldap with a plaintext password. >> Excellent! >> >> I suppose these are excempt from password policies? So their password will never expire...? > Yes the password policy applies only to kerberized entities. > > One of the reasons to use this. > Cool. How much access does these accounts have? Do they have write access anywhere? Rgds, Siggi From rcritten at redhat.com Mon Dec 12 18:52:21 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 12 Dec 2011 13:52:21 -0500 Subject: [Freeipa-users] Replica and CA mess In-Reply-To: <4EE39D3D.7020207@nixtra.com> References: <4ED278FE.2010705@nixtra.com> <4ED39A07.1090006@redhat.com> <4ED3D19F.6040409@nixtra.com> <4EDA6B5A.1060807@redhat.com> <4EE39D3D.7020207@nixtra.com> Message-ID: <4EE64D65.6030008@redhat.com> Sigbjorn Lie wrote: > On 12/03/2011 07:32 PM, Dmitri Pal wrote: >> On 11/28/2011 01:23 PM, Sigbjorn Lie wrote: >>> HTTP Server: port 443(https) (443): OK >>> >>> All ports except 389 fails when the master is IPv6 enabled, but the >>> replica is only IPv4 enabled. >>> >>> Directory Service: Unsecure port (389): OK >>> Directory Service: Secure port (636): FAILED >>> Kerberos KDC: TCP (88): FAILED >>> Kerberos KDC: UDP (88): FAILED >>> Kerberos Kpasswd: TCP (464): FAILED >>> Kerberos Kpasswd: UDP (464): FAILED >>> HTTP Server: port 80 (80): FAILED >>> HTTP Server: port 443(https) (443): FAILED >>> >>> Switching to IPv4 only addresses in resolv.conf resolves the issue. >>> >>> >> Do we have a bug/ticket open on this? >> > > From the lack of response, I guess no. I've opened a new request in > bugzilla: > https://bugzilla.redhat.com/show_bug.cgi?id=766162 Sorry about that, we'll take a look. rob From simo at redhat.com Mon Dec 12 19:02:25 2011 From: simo at redhat.com (Simo Sorce) Date: Mon, 12 Dec 2011 14:02:25 -0500 Subject: [Freeipa-users] NetApp Filer with IPA? In-Reply-To: <4EE64921.4010401@nixtra.com> References: <20111212060752.GA11447@noboost.org> <29471.213.225.75.97.1323687330.squirrel@www.nixtra.com> <1323700271.4413.53.camel@willson.li.ssimo.org> <33127.213.225.75.97.1323702786.squirrel@www.nixtra.com> <1323703139.4413.63.camel@willson.li.ssimo.org> <4EE64921.4010401@nixtra.com> Message-ID: <1323716545.4413.78.camel@willson.li.ssimo.org> On Mon, 2011-12-12 at 19:34 +0100, Sigbjorn Lie wrote: > On 12/12/2011 04:18 PM, Simo Sorce wrote: > > On Mon, 2011-12-12 at 16:13 +0100, Sigbjorn Lie wrote: > >> On Mon, December 12, 2011 15:31, Simo Sorce wrote: > >>> On Mon, 2011-12-12 at 11:55 +0100, Sigbjorn Lie wrote: > >>> > >>>> options ldap.name uid=s-netapp,cn=users,cn=accounts,dc=test,dc=local options ldap.passwd > >>>> passwordforbinduser > >>> If you need a special user you can avoid polluting the normal user space > >>> by creating a user under cn=sysaccounts,cn=etc,suffix.. > >>> > >>> It is a simple object, you can look at one user already there called > >>> uid=kdc, it is basically just an objectclass and a userPassword. > >>> > >>> We have no UI to create these users though, you'll have to create them > >>> manually, and they are not seen as regular users by any client, they are useuful exclusively to > >>> bind to ldap with a plaintext password. > >> Excellent! > >> > >> I suppose these are excempt from password policies? So their password will never expire...? > > Yes the password policy applies only to kerberized entities. > > > > One of the reasons to use this. > > > > Cool. How much access does these accounts have? Do they have write > access anywhere? By default they are powerless, they only have read access. Simo. -- Simo Sorce * Red Hat, Inc * New York From ian at crystal.harvard.edu Tue Dec 13 18:49:30 2011 From: ian at crystal.harvard.edu (Ian Levesque) Date: Tue, 13 Dec 2011 13:49:30 -0500 Subject: [Freeipa-users] "User Administrator" role member doesn't see "User Groups" under identity tab Message-ID: <013112DA-2630-43F5-BAED-FACE055C7ACD@crystal.harvard.edu> Hello, I'm running version 2.0.0-23 under Scientific 6.1. I've noticed that users in the "User Administrator" role, don't have access via the web UI to actually manage groups. The only link under "Identity" is "Users". CLI management works as expected. Is this a known bug with the relatively old version of FreeIPA I'm running? $ ipa role-show "User Administrator" Role name: User Administrator Description: Responsible for creating Users and Groups Member users: levesque Privileges: user administrators, group administrators $ ipa privilege-show "group administrators" Privilege name: Group Administrators Description: Group Administrators Permissions: add groups, remove groups, modify groups, modify group membership Granting privilege to roles: User Administrator Best, Ian From rcritten at redhat.com Tue Dec 13 19:09:05 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 13 Dec 2011 14:09:05 -0500 Subject: [Freeipa-users] "User Administrator" role member doesn't see "User Groups" under identity tab In-Reply-To: <013112DA-2630-43F5-BAED-FACE055C7ACD@crystal.harvard.edu> References: <013112DA-2630-43F5-BAED-FACE055C7ACD@crystal.harvard.edu> Message-ID: <4EE7A2D1.9080500@redhat.com> Ian Levesque wrote: > Hello, > > I'm running version 2.0.0-23 under Scientific 6.1. I've noticed that users in the "User Administrator" role, don't have access via the web UI to actually manage groups. The only link under "Identity" is "Users". CLI management works as expected. Is this a known bug with the relatively old version of FreeIPA I'm running? > > $ ipa role-show "User Administrator" > Role name: User Administrator > Description: Responsible for creating Users and Groups > Member users: levesque > Privileges: user administrators, group administrators > > $ ipa privilege-show "group administrators" > Privilege name: Group Administrators > Description: Group Administrators > Permissions: add groups, remove groups, modify groups, modify group membership > Granting privilege to roles: User Administrator > > Best, > Ian A similar issue was fixed in 2.1.3 but it affected all UI screens IIRC (e.g. non-admins never saw anything extra). rob From sigbjorn at nixtra.com Tue Dec 13 21:20:38 2011 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Tue, 13 Dec 2011 22:20:38 +0100 Subject: [Freeipa-users] ipa-client-install & autofs & nfs4-krb Message-ID: <4EE7C1A6.8030504@nixtra.com> Hi, Has there been considered to extend the ipa-client-install script to configure the automounter for LDAP, and to configure the nfs client for nfs4 with krb5? Regards, Siggi From sigbjorn at nixtra.com Tue Dec 13 21:21:48 2011 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Tue, 13 Dec 2011 22:21:48 +0100 Subject: [Freeipa-users] NetApp Filer with IPA? In-Reply-To: <1323716545.4413.78.camel@willson.li.ssimo.org> References: <20111212060752.GA11447@noboost.org> <29471.213.225.75.97.1323687330.squirrel@www.nixtra.com> <1323700271.4413.53.camel@willson.li.ssimo.org> <33127.213.225.75.97.1323702786.squirrel@www.nixtra.com> <1323703139.4413.63.camel@willson.li.ssimo.org> <4EE64921.4010401@nixtra.com> <1323716545.4413.78.camel@willson.li.ssimo.org> Message-ID: <4EE7C1EC.3070902@nixtra.com> On 12/12/2011 08:02 PM, Simo Sorce wrote: > On Mon, 2011-12-12 at 19:34 +0100, Sigbjorn Lie wrote: >> On 12/12/2011 04:18 PM, Simo Sorce wrote: >>> On Mon, 2011-12-12 at 16:13 +0100, Sigbjorn Lie wrote: >>>> On Mon, December 12, 2011 15:31, Simo Sorce wrote: >>>>> On Mon, 2011-12-12 at 11:55 +0100, Sigbjorn Lie wrote: >>>>> >>>>>> options ldap.name uid=s-netapp,cn=users,cn=accounts,dc=test,dc=local options ldap.passwd >>>>>> passwordforbinduser >>>>> If you need a special user you can avoid polluting the normal user space >>>>> by creating a user under cn=sysaccounts,cn=etc,suffix.. >>>>> >>>>> It is a simple object, you can look at one user already there called >>>>> uid=kdc, it is basically just an objectclass and a userPassword. >>>>> >>>>> We have no UI to create these users though, you'll have to create them >>>>> manually, and they are not seen as regular users by any client, they are useuful exclusively to >>>>> bind to ldap with a plaintext password. >>>> Excellent! >>>> >>>> I suppose these are excempt from password policies? So their password will never expire...? >>> Yes the password policy applies only to kerberized entities. >>> >>> One of the reasons to use this. >>> >> Cool. How much access does these accounts have? Do they have write >> access anywhere? > By default they are powerless, they only have read access. > > Just tried this with a Solaris client, works like a charm. Thank you. From rcritten at redhat.com Tue Dec 13 21:45:18 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 13 Dec 2011 16:45:18 -0500 Subject: [Freeipa-users] ipa-client-install & autofs & nfs4-krb In-Reply-To: <4EE7C1A6.8030504@nixtra.com> References: <4EE7C1A6.8030504@nixtra.com> Message-ID: <4EE7C76E.20708@redhat.com> Sigbjorn Lie wrote: > Hi, > > Has there been considered to extend the ipa-client-install script to > configure the automounter for LDAP, and to configure the nfs client for > nfs4 with krb5? Yes for autofs, https://fedorahosted.org/freeipa/ticket/1429, though it is currently deferred for lack of time. We don't have a ticket to configure nfs in ipa-client-install. If you'd like this please open a ticket with your requirements. regards rob From sigbjorn at nixtra.com Tue Dec 13 21:50:50 2011 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Tue, 13 Dec 2011 22:50:50 +0100 Subject: [Freeipa-users] Netgroups and users Message-ID: <4EE7C8BA.8090302@nixtra.com> Hi, When adding users or user groups to a netgroup, the format of the netgrouptriple ends up as following: nisNetgroupTriple: (-,username,ix.test.com) The extra "-" prevents me from using IPA's netgroups for tcp wrappers using /etc/hosts.allow and /etc/hosts.deny for user access control. Making the same test with a NIS server, creating the same entry without the "-", works for user access control. Looking at 389-ds' wiki, the "-" should not be there: http://directory.fedoraproject.org/wiki/Howto:Netgroups Is this a configurable setting? Or should I open a ticket? Regards, Siggi From dpal at redhat.com Tue Dec 13 22:01:09 2011 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 13 Dec 2011 17:01:09 -0500 Subject: [Freeipa-users] Netgroups and users In-Reply-To: <4EE7C8BA.8090302@nixtra.com> References: <4EE7C8BA.8090302@nixtra.com> Message-ID: <4EE7CB25.2090002@redhat.com> On 12/13/2011 04:50 PM, Sigbjorn Lie wrote: > Hi, > > When adding users or user groups to a netgroup, the format of the > netgrouptriple ends up as following: > > nisNetgroupTriple: (-,username,ix.test.com) > > The extra "-" prevents me from using IPA's netgroups for tcp wrappers > using /etc/hosts.allow and /etc/hosts.deny for user access control. > > Making the same test with a NIS server, creating the same entry > without the "-", works for user access control. > > Looking at 389-ds' wiki, the "-" should not be there: > http://directory.fedoraproject.org/wiki/Howto:Netgroups > > Is this a configurable setting? Or should I open a ticket? > > > Regards, > Siggi > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users Are you using DS or IPA? IPA uses internal schema for netgroups to take advantage of some of the associations and exposes 2307bis schema for netgroups via compat plugin. Are you pointing clients at compat tree? Are you trying to add the entries manually and not using the provided interfaces? -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From sigbjorn at nixtra.com Tue Dec 13 22:03:00 2011 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Tue, 13 Dec 2011 23:03:00 +0100 Subject: [Freeipa-users] Netgroups and users In-Reply-To: <4EE7C8BA.8090302@nixtra.com> References: <4EE7C8BA.8090302@nixtra.com> Message-ID: <4EE7CB94.8020308@nixtra.com> On 12/13/2011 10:50 PM, Sigbjorn Lie wrote: > Hi, > > When adding users or user groups to a netgroup, the format of the > netgrouptriple ends up as following: > > nisNetgroupTriple: (-,username,ix.test.com) > > The extra "-" prevents me from using IPA's netgroups for tcp wrappers > using /etc/hosts.allow and /etc/hosts.deny for user access control. > > Making the same test with a NIS server, creating the same entry > without the "-", works for user access control. > > Looking at 389-ds' wiki, the "-" should not be there: > http://directory.fedoraproject.org/wiki/Howto:Netgroups > > Is this a configurable setting? Or should I open a ticket? > > To answer myself, yes this is configurable. There is an attribute under "cn=ng,cn=Schema Compatibility,cn=plugins,cn=config", named "schema-compat-entry-attribute". Changing this attribute from: nisNetgroupTriple=(%link("%ifeq(\"hostCategory\",\"all\",\"\",\"%collect(\\\"%{externalHost}\\\",\\\"%deref(\\\\\\\"memberHost\\\\\\\",\\\\\\\"fqdn\\\\\\\")\\\",\\\"%deref_r(\\\\\\\"member\\\\\\\",\\\\\\\"fqdn\\\\\\\")\\\",\\\"%deref_r(\\\\\\\"memberHost\\\\\\\",\\\\\\\"member\\\\\\\",\\\\\\\"fqdn\\\\\\\")\\\")\")","-",",","%ifeq(\"userCategory\",\"all\",\"\",\"%collect(\\\"%deref(\\\\\\\"memberUser\\\\\\\",\\\\\\\"uid\\\\\\\")\\\",\\\"%deref_r(\\\\\\\"member\\\\\\\",\\\\\\\"uid\\\\\\\")\\\",\\\"%deref_r(\\\\\\\"memberUser\\\\\\\",\\\\\\\"member\\\\\\\",\\\\\\\"uid\\\\\\\")\\\")\")","-"),%{nisDomainName:-}) To: nisNetgroupTriple=(%link("%ifeq(\"hostCategory\",\"all\",\"\",\"%collect(\\\"%{externalHost}\\\",\\\"%deref(\\\\\\\"memberHost\\\\\\\",\\\\\\\"fqdn\\\\\\\")\\\",\\\"%deref_r(\\\\\\\"member\\\\\\\",\\\\\\\"fqdn\\\\\\\")\\\",\\\"%deref_r(\\\\\\\"memberHost\\\\\\\",\\\\\\\"member\\\\\\\",\\\\\\\"fqdn\\\\\\\")\\\")\")","",",","%ifeq(\"userCategory\",\"all\",\"\",\"%collect(\\\"%deref(\\\\\\\"memberUser\\\\\\\",\\\\\\\"uid\\\\\\\")\\\",\\\"%deref_r(\\\\\\\"member\\\\\\\",\\\\\\\"uid\\\\\\\")\\\",\\\"%deref_r(\\\\\\\"memberUser\\\\\\\",\\\\\\\"member\\\\\\\",\\\\\\\"uid\\\\\\\")\\\")\")","-"),%{nisDomainName:-}) Make the netgroup return correctly, and user-based hosts.allow and hosts.deny works just fine! The entires now look like: nisNetgroupTriple: (,username,ix.test.com) This allows me to use the same user group for access to services at Red Hat servers using SSSD/HBAC, and services at Solaris servers using tcp wrappers. SSH in Solaris comes with TCP wrappers built in, so no extra configuration is required. :) Ticket opened: https://bugzilla.redhat.com/show_bug.cgi?id=767372 From sigbjorn at nixtra.com Tue Dec 13 22:15:48 2011 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Tue, 13 Dec 2011 23:15:48 +0100 Subject: [Freeipa-users] Netgroups and users In-Reply-To: <4EE7CB25.2090002@redhat.com> References: <4EE7C8BA.8090302@nixtra.com> <4EE7CB25.2090002@redhat.com> Message-ID: <4EE7CE94.5080402@nixtra.com> On 12/13/2011 11:01 PM, Dmitri Pal wrote: > On 12/13/2011 04:50 PM, Sigbjorn Lie wrote: >> Hi, >> >> When adding users or user groups to a netgroup, the format of the >> netgrouptriple ends up as following: >> >> nisNetgroupTriple: (-,username,ix.test.com) >> >> The extra "-" prevents me from using IPA's netgroups for tcp wrappers >> using /etc/hosts.allow and /etc/hosts.deny for user access control. >> >> Making the same test with a NIS server, creating the same entry >> without the "-", works for user access control. >> >> Looking at 389-ds' wiki, the "-" should not be there: >> http://directory.fedoraproject.org/wiki/Howto:Netgroups >> >> Is this a configurable setting? Or should I open a ticket? >> >> >> Regards, >> Siggi >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > Are you using DS or IPA? IPA :) > IPA uses internal schema for netgroups to take advantage of some of the > associations and exposes 2307bis schema for netgroups via compat plugin. > Are you pointing clients at compat tree? Yes. The netgroups are exposed, they just had an added "-" in the host field. > Are you trying to add the > entries manually and not using the provided interfaces? No, the entries we're added using the provided interface. From sigbjorn at nixtra.com Tue Dec 13 22:32:18 2011 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Tue, 13 Dec 2011 23:32:18 +0100 Subject: [Freeipa-users] ipa-client-install & autofs & nfs4-krb In-Reply-To: <4EE7C76E.20708@redhat.com> References: <4EE7C1A6.8030504@nixtra.com> <4EE7C76E.20708@redhat.com> Message-ID: <4EE7D272.3050709@nixtra.com> On 12/13/2011 10:45 PM, Rob Crittenden wrote: > Sigbjorn Lie wrote: >> Hi, >> >> Has there been considered to extend the ipa-client-install script to >> configure the automounter for LDAP, and to configure the nfs client for >> nfs4 with krb5? > > Yes for autofs, https://fedorahosted.org/freeipa/ticket/1429, though > it is currently deferred for lack of time. > > We don't have a ticket to configure nfs in ipa-client-install. If > you'd like this please open a ticket with your requirements. > > Ok. That ticket specifies exactly the autofs ldap configuration I was looking for. :) I have opened a request for the nfs4+krb5 implementation in the ipa-client-install script. I took the configuration from the top of my head, it might need a few final adjustments. https://bugzilla.redhat.com/show_bug.cgi?id=767379 Regards, Siggi From simo at redhat.com Tue Dec 13 22:50:43 2011 From: simo at redhat.com (Simo Sorce) Date: Tue, 13 Dec 2011 17:50:43 -0500 Subject: [Freeipa-users] Netgroups and users In-Reply-To: <4EE7CE94.5080402@nixtra.com> References: <4EE7C8BA.8090302@nixtra.com> <4EE7CB25.2090002@redhat.com> <4EE7CE94.5080402@nixtra.com> Message-ID: <1323816643.4413.174.camel@willson.li.ssimo.org> On Tue, 2011-12-13 at 23:15 +0100, Sigbjorn Lie wrote: > > IPA uses internal schema for netgroups to take advantage of some of the > > associations and exposes 2307bis schema for netgroups via compat plugin. > > Are you pointing clients at compat tree? > Yes. The netgroups are exposed, they just had an added "-" in the host > field. If it breaks tcpwrappers, please open a ticket against freeipa to have a default matching the one you use now. Unless there are side effects we can switch to that default. Simo. -- Simo Sorce * Red Hat, Inc * New York From rmercer at harris.com Wed Dec 14 16:04:03 2011 From: rmercer at harris.com (Mercer, Rodney) Date: Wed, 14 Dec 2011 16:04:03 +0000 Subject: [Freeipa-users] FreeIPA_demonstration_tools CA creation error. Message-ID: <512A3AF8DAE8454D95C05141F746ECE136BE37C2@MLBMXUS21.cs.myharris.net> I've been attempting to install the virtual machine setup from http://freeipa.org/page/FreeIPA_demonstration_tools I install on fresh Fedora 15 x86_64 host, and I am able to complete the first two steps. When I run the last script, ./ipa-demo.sh I get from the ipa-demo-.log ---- CRITICAL:root:failed to configure ca instance ---- and later in the log: ---- Warning: skipping DNS resolution of host master.example.com The IPA Master Server will be configured with Hostname: master.example.com IP address: 192.168.122.32 Domain name: example.com ---- and ---- Configuring certificate server: Estimated time 3 minutes 30 seconds [1/17]: creating certificate server user [2/17]: creating pki-ca instance [3/17]: configuring certificate server instance Unexpected error - see ipaserver-install.log for details: Configuration of CA failed Server installation failed! Domain f15-ipa-server destroyed Domain f15-ipa-server has been undefined ---- I see the dhcp address changing for master.example.com each time the script is run. Is there a requirement for making the dhcp address consistent for master.example.com and having the address in /etc/hosts so that it can reverse resolve via dnsmasq? Or does the DNS resolution of ip to host have any bearing on the certificate creation as I suspect? -- Rodney Mercer Systems Administrator From sigbjorn at nixtra.com Wed Dec 14 17:16:30 2011 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Wed, 14 Dec 2011 18:16:30 +0100 Subject: [Freeipa-users] Netgroups and users In-Reply-To: <1323816643.4413.174.camel@willson.li.ssimo.org> References: <4EE7C8BA.8090302@nixtra.com> <4EE7CB25.2090002@redhat.com> <4EE7CE94.5080402@nixtra.com> <1323816643.4413.174.camel@willson.li.ssimo.org> Message-ID: <4EE8D9EE.4030900@nixtra.com> On 12/13/2011 11:50 PM, Simo Sorce wrote: > On Tue, 2011-12-13 at 23:15 +0100, Sigbjorn Lie wrote: > >>> IPA uses internal schema for netgroups to take advantage of some of the >>> associations and exposes 2307bis schema for netgroups via compat plugin. >>> Are you pointing clients at compat tree? >> Yes. The netgroups are exposed, they just had an added "-" in the host >> field. > If it breaks tcpwrappers, please open a ticket against freeipa to have a > default matching the one you use now. > Unless there are side effects we can switch to that default. > > Simo. > Hi I opened the request below. https://bugzilla.redhat.com/show_bug.cgi?id=767372 Thanks. Regards, Siggi From dpal at redhat.com Wed Dec 14 17:58:41 2011 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 14 Dec 2011 12:58:41 -0500 Subject: [Freeipa-users] FreeIPA_demonstration_tools CA creation error. In-Reply-To: <512A3AF8DAE8454D95C05141F746ECE136BE37C2@MLBMXUS21.cs.myharris.net> References: <512A3AF8DAE8454D95C05141F746ECE136BE37C2@MLBMXUS21.cs.myharris.net> Message-ID: <4EE8E3D1.7080801@redhat.com> On 12/14/2011 11:04 AM, Mercer, Rodney wrote: > I've been attempting to install the virtual machine setup from > http://freeipa.org/page/FreeIPA_demonstration_tools > > I install on fresh Fedora 15 x86_64 host, and I am able to complete the first two steps. > > When I run the last script, > ./ipa-demo.sh > I get from the ipa-demo-.log > ---- > CRITICAL:root:failed to configure ca instance > ---- > and later in the log: > ---- > Warning: skipping DNS resolution of host master.example.com > The IPA Master Server will be configured with > Hostname: master.example.com > IP address: 192.168.122.32 > Domain name: example.com > ---- > and > ---- > Configuring certificate server: Estimated time 3 minutes 30 seconds > [1/17]: creating certificate server user > [2/17]: creating pki-ca instance > [3/17]: configuring certificate server instance > Unexpected error - see ipaserver-install.log for details: > Configuration of CA failed > Server installation failed! > Domain f15-ipa-server destroyed > > Domain f15-ipa-server has been undefined > ---- > > I see the dhcp address changing for master.example.com each time the script is run. > Is there a requirement for making the dhcp address consistent for master.example.com > and having the address in /etc/hosts so that it can reverse resolve via dnsmasq? > > Or does the DNS resolution of ip to host have any bearing on the certificate creation as I suspect? > > Consistent name resolution is a requirement for IPA. Ondrej, can you please take a closer look and see if this is something with the demo scripts or IPA itself? -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From mkosek at redhat.com Wed Dec 14 21:41:57 2011 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 14 Dec 2011 22:41:57 +0100 Subject: [Freeipa-users] Optionistic approach for new DNS API Message-ID: <1323898917.17355.47.camel@priserak> Hello all, we just had a good discussion with Rob and Endi about different approach to the new DNS API. Current DNS API proposal (patches 174-176) introduced new API based on different commands, e.g. for MX RR type: ipa dnsrecord-mx-add ZONE NAME --preference=0 --exchanger=server1.example.com. ipa dnsrecord-mx-mod ZONE NAME "0 server1.example.com." --preference=1 ipa dnsrecord-mx-show ZONE NAME As a side effect, this would introduce many new commands (dnsrecord-mx-add/mod/show, dnsrecord-loc-add/mod/show, ...) which may of course be confusing. Endi proposed an different approach to use rather per-type options instead of commands, which I think is really interesting to think about. I will summarize how the API may look like. Changes to DNS module commands: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - no new DNS command would be implemented, we would just enhance current dns record commands: * dnsrecord-add, dnsrecord-mod, dnsrecord-del and dnsrecord-find - all changes must be compatible with 2.x clients, changes to output shall be triggered by 3.x option Command Structure: ~~~~~~~~~~~~~~~~~~ - we would introduce --type option which would trigger the command to use the new structured DNS options, i.e.: ipa dnsrecord-add ZONE NAME --type=mx --preference=0 --exchanger=server1.example.com. or ipa dnsrecord-mod ZONE NAME VALUE? --type=mx --preference=0 or ipa dnsrecord-del ZONE NAME --type=mx --preference=0 --exchanger=server1.example.com. - SHOW and FIND commands do not need this new --type parameter Command Output: ~~~~~~~~~~~~~~~ - we would introduce a new --structured option which would switch command output to "structured way" and present rather parsed DNS records instead of raw DNS values (this is also needed for 2.x compatibility). For JSON output we may get: { idnsname: 'foo', records: [ { type: 'a', data: '10.10.10.10', ip_address: '10.10.10.10' }, { type: 'cname', data: 'bar.example.com.', hostname: 'bar.example.com.' }, { type: 'cname', data: 'bar2.example.com.', hostname: 'bar2.example.com.' }, ] } instead of { idnsname: 'foo', arecord: [ '10.10.10.10' ], cnamerecord: [ 'bar.example.com.', 'bar2.example.com.' ] } In CLI it may look like this: # ipa dnsrecordmx-show example.com @ --structured Record name: @ Record type: MX Data: 0 server1.example.com Preference: 0 Exchanger: server1.example.com Record type: NS Data: vm-068.idm.lab.bos.redhat.com. Hostname: vm-068.idm.lab.bos.redhat.com. instead of: # ipa dnsrecord-show example.com @ Record name: @ MX record: 0 server1.example.com NS record: vm-068.idm.lab.bos.redhat.com. Command help: ~~~~~~~~~~~~~ - since dnsrecord-add would accept all options from all DNS RR types, its list would be overwhelming and not very helpful - we can take advantage of OptionParser option groups. The help may look like this: $ ipa dnsrecord-add --help Usage: ipa [global-options] dnsrecord-add DNSZONE NAME [options] Options: -h, --help show this help message and exit SRV Options: --priority Priority --weight Weight --port Port --target Target MX Options: --priority Priority --exchanger A host willing to act as a mail exchanger ... Interactive mode in CLI: ~~~~~~~~~~~~~~~~~~~~~~~~ - ADD command: - when no option is passed to dnsrecord-add command, it may ask for --type and then for the options specific for the particular type - MOD command: - when no option is passed to dnsrecord-mod command, it may provide a list of current DNS record values and ask for specific DNS record parts to be changed for chosen value - DEL command: - when no option is passed to dnsrecord-del command, it may provide a list of current DNS record values remove the chosen value Any comments, suggestions? Do you think that introducing these new options in current dnsrecord-add/mod/show/del commands would be better and more usable that introducing these capabilities in separate commands? Thanks, Martin From dpal at redhat.com Wed Dec 14 22:01:57 2011 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 14 Dec 2011 17:01:57 -0500 Subject: [Freeipa-users] Optionistic approach for new DNS API In-Reply-To: <1323898917.17355.47.camel@priserak> References: <1323898917.17355.47.camel@priserak> Message-ID: <4EE91CD5.1010704@redhat.com> On 12/14/2011 04:41 PM, Martin Kosek wrote: > Hello all, > > we just had a good discussion with Rob and Endi about different approach > to the new DNS API. Current DNS API proposal (patches 174-176) > introduced new API based on different commands, e.g. for MX RR type: > > ipa dnsrecord-mx-add ZONE NAME --preference=0 --exchanger=server1.example.com. > ipa dnsrecord-mx-mod ZONE NAME "0 server1.example.com." --preference=1 > ipa dnsrecord-mx-show ZONE NAME > > As a side effect, this would introduce many new commands > (dnsrecord-mx-add/mod/show, dnsrecord-loc-add/mod/show, ...) which may > of course be confusing. > > Endi proposed an different approach to use rather per-type options > instead of commands, which I think is really interesting to think about. > I will summarize how the API may look like. > > Changes to DNS module commands: > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > - no new DNS command would be implemented, we would just enhance current > dns record commands: > * dnsrecord-add, dnsrecord-mod, dnsrecord-del and dnsrecord-find > - all changes must be compatible with 2.x clients, changes to output > shall be triggered by 3.x option > > Command Structure: > ~~~~~~~~~~~~~~~~~~ > - we would introduce --type option which would trigger the command to > use the new structured DNS options, i.e.: > > ipa dnsrecord-add ZONE NAME --type=mx --preference=0 --exchanger=server1.example.com. > > or > > ipa dnsrecord-mod ZONE NAME VALUE? --type=mx --preference=0 > > or > > ipa dnsrecord-del ZONE NAME --type=mx --preference=0 --exchanger=server1.example.com. > > - SHOW and FIND commands do not need this new --type parameter > > > Command Output: > ~~~~~~~~~~~~~~~ > - we would introduce a new --structured option which would switch > command output to "structured way" and present rather parsed DNS records > instead of raw DNS values (this is also needed for 2.x compatibility). > > For JSON output we may get: > > { > idnsname: 'foo', > records: [ > { > type: 'a', > data: '10.10.10.10', > ip_address: '10.10.10.10' > }, > { > type: 'cname', > data: 'bar.example.com.', > hostname: 'bar.example.com.' > }, > { > type: 'cname', > data: 'bar2.example.com.', > hostname: 'bar2.example.com.' > }, > ] > } > > instead of > > { > idnsname: 'foo', > arecord: [ > '10.10.10.10' > ], > cnamerecord: [ > 'bar.example.com.', > 'bar2.example.com.' > ] > } > > In CLI it may look like this: > # ipa dnsrecordmx-show example.com @ --structured dnsrecordmx? I assume it is a typo, right? > Record name: @ > Record type: MX > Data: 0 server1.example.com > Preference: 0 > Exchanger: server1.example.com > > Record type: NS > Data: vm-068.idm.lab.bos.redhat.com. > Hostname: vm-068.idm.lab.bos.redhat.com. > > instead of: > > # ipa dnsrecord-show example.com @ > Record name: @ > MX record: 0 server1.example.com > NS record: vm-068.idm.lab.bos.redhat.com. > > Command help: > ~~~~~~~~~~~~~ > - since dnsrecord-add would accept all options from all DNS RR types, > its list would be overwhelming and not very helpful > - we can take advantage of OptionParser option groups. The help may look > like this: > > $ ipa dnsrecord-add --help > Usage: ipa [global-options] dnsrecord-add DNSZONE NAME [options] > > Options: > -h, --help show this help message and exit > > SRV Options: > --priority Priority > --weight Weight > --port Port > --target Target > > MX Options: > --priority Priority > --exchanger A host willing to act as a mail exchanger > ... > > Interactive mode in CLI: > ~~~~~~~~~~~~~~~~~~~~~~~~ > - ADD command: > - when no option is passed to dnsrecord-add command, it may ask for > --type and then for the options specific for the particular type > - MOD command: > - when no option is passed to dnsrecord-mod command, it may provide a > list of current DNS record values and ask for specific DNS record parts > to be changed for chosen value > - DEL command: > - when no option is passed to dnsrecord-del command, it may provide a > list of current DNS record values remove the chosen value > > Any comments, suggestions? Do you think that introducing these new > options in current dnsrecord-add/mod/show/del commands would be better > and more usable that introducing these capabilities in separate > commands? > > Thanks, > Martin > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From ayoung at redhat.com Thu Dec 15 08:46:24 2011 From: ayoung at redhat.com (Adam Young) Date: Thu, 15 Dec 2011 03:46:24 -0500 Subject: [Freeipa-users] "User Administrator" role member doesn't see "User Groups" under identity tab In-Reply-To: <4EE7A2D1.9080500@redhat.com> References: <013112DA-2630-43F5-BAED-FACE055C7ACD@crystal.harvard.edu> <4EE7A2D1.9080500@redhat.com> Message-ID: <4EE9B3E0.6080506@redhat.com> On 12/13/2011 02:09 PM, Rob Crittenden wrote: > Ian Levesque wrote: >> Hello, >> >> I'm running version 2.0.0-23 under Scientific 6.1. I've noticed that >> users in the "User Administrator" role, don't have access via the >> web UI to actually manage groups. The only link under "Identity" is >> "Users". CLI management works as expected. Is this a known bug with >> the relatively old version of FreeIPA I'm running? >> >> $ ipa role-show "User Administrator" >> Role name: User Administrator >> Description: Responsible for creating Users and Groups >> Member users: levesque >> Privileges: user administrators, group administrators >> >> $ ipa privilege-show "group administrators" >> Privilege name: Group Administrators >> Description: Group Administrators >> Permissions: add groups, remove groups, modify groups, modify >> group membership >> Granting privilege to roles: User Administrator >> >> Best, >> Ian > > A similar issue was fixed in 2.1.3 but it affected all UI screens IIRC > (e.g. non-admins never saw anything extra). > > rob > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users Yes, that is the same issue. From mkosek at redhat.com Thu Dec 15 14:29:21 2011 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 15 Dec 2011 15:29:21 +0100 Subject: [Freeipa-users] Optionistic approach for new DNS API In-Reply-To: <4EE91CD5.1010704@redhat.com> References: <1323898917.17355.47.camel@priserak> <4EE91CD5.1010704@redhat.com> Message-ID: <1323959361.8812.2.camel@balmora.brq.redhat.com> On Wed, 2011-12-14 at 17:01 -0500, Dmitri Pal wrote: > On 12/14/2011 04:41 PM, Martin Kosek wrote: ... > > > > In CLI it may look like this: > > # ipa dnsrecordmx-show example.com @ --structured > > dnsrecordmx? I assume it is a typo, right? Right. All new options specific for supported DNS RR types would be added as options to current dnsrecord-* commands. No new command would be needed. Martin From danieljamesscott at gmail.com Thu Dec 15 15:41:47 2011 From: danieljamesscott at gmail.com (Dan Scott) Date: Thu, 15 Dec 2011 10:41:47 -0500 Subject: [Freeipa-users] ns-slapd hang/segfault Message-ID: Hi, On my Fedora 15 FreeIPA server, I'm having some problems with stability. The server appears to 'hang' and stops responding to LDAP lookups. When I restart the dirsrv service, I get: Dec 15 09:40:02 ohm kernel: [254566.011404] ns-slapd[28910]: segfault at 17d ip 00007f00dbc0208c sp 00007fff929b7848 error 4 in libc-2.14.so[7f00dbb87000+18f000] and the /var/log/dirsrv/slapd-EXAMPLE-COM/errors contains [15/Dec/2011:09:47:35 -0500] set_krb5_creds - Could not get initial credentials for principal [ldap/example.com at EXAMPLE.COM] in keytab [WRFILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for requested realm) [15/Dec/2011:09:47:35 -0500] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credentials cache file '/tmp/krb5cc_496' not found)) This is happening very frequently, I'm having to restart the dirsrv process once an hour, otherwise people start complaining. I experienced similar problems with FreeIPA 1, when I was using Fedora 14 and earlier, and had to regularly (also once per hour) restart the dirsrv process. Could this be related? I also noticed this: https://bugzilla.redhat.com/show_bug.cgi?id=730387 There are updates in 'updates-testing' which I believe fix the above issue, but I'm reluctant to install from a testing repo on my production server, can anyone report any feedback on this? Can anyone help me out? Thanks, Dan From rmeggins at redhat.com Thu Dec 15 15:58:00 2011 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 15 Dec 2011 08:58:00 -0700 Subject: [Freeipa-users] ns-slapd hang/segfault In-Reply-To: References: Message-ID: <4EEA1908.2040801@redhat.com> On 12/15/2011 08:41 AM, Dan Scott wrote: > Hi, > > On my Fedora 15 FreeIPA server, I'm having some problems with > stability. The server appears to 'hang' and stops responding to LDAP > lookups. When I restart the dirsrv service, I get: > > Dec 15 09:40:02 ohm kernel: [254566.011404] ns-slapd[28910]: segfault > at 17d ip 00007f00dbc0208c sp 00007fff929b7848 error 4 in > libc-2.14.so[7f00dbb87000+18f000] > > and the /var/log/dirsrv/slapd-EXAMPLE-COM/errors contains > > [15/Dec/2011:09:47:35 -0500] set_krb5_creds - Could not get initial > credentials for principal [ldap/example.com at EXAMPLE.COM] in keytab > [WRFILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC > for requested realm) > [15/Dec/2011:09:47:35 -0500] slapd_ldap_sasl_interactive_bind - Error: > could not perform interactive bind for id [] mech [GSSAPI]: error -2 > (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified > GSS failure. Minor code may provide more information (Credentials > cache file '/tmp/krb5cc_496' not found)) > > This is happening very frequently, I'm having to restart the dirsrv > process once an hour, otherwise people start complaining. > > I experienced similar problems with FreeIPA 1, when I was using Fedora > 14 and earlier, and had to regularly (also once per hour) restart the > dirsrv process. Could this be related? > > I also noticed this: > https://bugzilla.redhat.com/show_bug.cgi?id=730387 > > There are updates in 'updates-testing' which I believe fix the above > issue, but I'm reluctant to install from a testing repo on my > production server, can anyone report any feedback on this? The above bug does not cause a segfault. What version of 389-ds-base are you using? Please enable the collection of core dumps so we can debug the crash - see http://directory.fedoraproject.org/wiki/FAQ#Debugging_Crashes > Can anyone help me out? > > Thanks, > > Dan > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From rcritten at redhat.com Thu Dec 15 16:22:08 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 15 Dec 2011 11:22:08 -0500 Subject: [Freeipa-users] CA replication In-Reply-To: References: <4EE10224.9020104@redhat.com> <4EE21A3A.2040008@redhat.com> Message-ID: <4EEA1EB0.8020200@redhat.com> Dan Scott wrote: > Hi, > > On Fri, Dec 9, 2011 at 09:24, Rob Crittenden wrote: >> Dan Scott wrote: >>> >>> Hi, >>> >>> On Thu, Dec 8, 2011 at 13:29, Rob Crittenden wrote: >>>> >>>> Dan Scott wrote: >>>>> >>>>> >>>>> Hi, >>>>> >>>>> I just tried to add a CA replica to my IPA replica (Both Fedora 15) >>>>> using: >>>>> >>>>> ipa-ca-install replica-info-ohm.gpg >>>>> >>>>> It proceeds to configure the directory server for the CA, but fails >>>>> when 'configuring certificate server': >>>>> >>>>> Configuring certificate server: Estimated time 3 minutes 30 seconds >>>>> [1/11]: creating certificate server user >>>>> [2/11]: creating pki-ca instance >>>>> [3/11]: configuring certificate server instance >>>>> root : CRITICAL failed to configure ca instance Command >>>>> '/usr/bin/perl /usr/bin/pkisilent 'ConfigureCA' '-cs_hostname' >>>>> 'ohm.example.com' '-cs_port' '9445' '-client_certdb_dir' >>>>> '/tmp/tmp-Mbw1ut' '-client_certdb_pwd' XXXXXXXX '-preop_pin' >>>>> 'XXXXXXXXX' '-domain_name' 'IPA' '-admin_user' 'admin' '-admin_email' >>>>> 'root at localhost' '-admin_password' XXXXXXXX '-agent_name' >>>>> 'ipa-ca-agent' '-agent_key_size' '2048' '-agent_key_type' 'rsa' >>>>> '-agent_cert_subject' 'CN=ipa-ca-agent,O=EXAMPLE.COM' '-ldap_host' >>>>> 'ohm.example.com' '-ldap_port' '7389' '-bind_dn' 'cn=Directory >>>>> Manager' '-bind_password' XXXXXXXX '-base_dn' 'o=ipaca' '-db_name' >>>>> 'ipaca' '-key_size' '2048' '-key_type' 'rsa' '-key_algorithm' >>>>> 'SHA256withRSA' '-save_p12' 'true' '-backup_pwd' XXXXXXXX >>>>> '-subsystem_name' 'pki-cad' '-token_name' 'internal' >>>>> '-ca_subsystem_cert_subject_name' 'CN=CA Subsystem,O=EXAMPLE.COM' >>>>> '-ca_ocsp_cert_subject_name' 'CN=OCSP Subsystem,O=EXAMPLE.COM' >>>>> '-ca_server_cert_subject_name' 'CN=ohm.example.com,O=EXAMPLE.COM' >>>>> '-ca_audit_signing_cert_subject_name' 'CN=CA Audit,O=EXAMPLE.COM' >>>>> '-ca_sign_cert_subject_name' 'CN=Certificate Authority,O=EXAMPLE.COM' >>>>> '-external' 'false' '-clone' 'true' '-clone_p12_file' 'ca.p12' >>>>> '-clone_p12_password' XXXXXXXX '-sd_hostname' 'curie.example.com' >>>>> '-sd_admin_port' '443' '-sd_admin_name' 'admin' '-sd_admin_password' >>>>> XXXXXXXX '-clone_start_tls' 'true' '-clone_uri' >>>>> 'https://curie.example.com:443'' returned non-zero exit status 255 >>>>> creation of replica failed: Configuration of CA failed >>>>> >>>>> Some errors from /var/log/ipareplica-ca-install.log >>>>> >>>>> Error in DomainPanel(): updateStatus value is null >>>>> ERROR: ConfigureCA: DomainPanel() failure >>>>> ERROR: unable to create CA >>>>> >>>>> File "/usr/sbin/ipa-ca-install", line 156, in >>>>> main() >>>>> >>>>> File "/usr/sbin/ipa-ca-install", line 141, in main >>>>> (CA, cs) = cainstance.install_replica_ca(config, postinstall=True) >>>>> >>>>> File >>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", >>>>> line 1136, in install_replica_ca >>>>> subject_base=config.subject_base) >>>>> >>>>> File >>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", >>>>> line 537, in configure_instance >>>>> self.start_creation("Configuring certificate server", 210) >>>>> >>>>> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >>>>> line 248, in start_creation >>>>> method() >>>>> >>>>> File >>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", >>>>> line 680, in __configure_instance >>>>> raise RuntimeError('Configuration of CA failed') >>>>> >>>>> Anyone have any ideas? >>>> >>>> >>>> >>>> /var/log/pki-ca/debug probably has more details. >>> >>> >>> This file contains the following errors: >>> >>> [08/Dec/2011:12:24:40][http-9445-2]: SecurityDomainPanel: validating >>> SSL Admin HTTPS . . . >>> [08/Dec/2011:12:24:40][http-9445-2]: WizardPanelBase pingCS: started >>> [08/Dec/2011:12:24:40][http-9445-2]: WizardPanelBase: pingCS: parser >>> failedorg.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 50; >>> White spaces are required between publicId and systemId. >>> [08/Dec/2011:12:24:40][http-9445-2]: SecurityDomainPanel: pingAdminCS >>> no successful response for SSL Admin HTTPS >>> [08/Dec/2011:12:24:40][http-9445-2]: WizardPanelBase >>> getCertChainUsingSecureAdminPort start >>> [08/Dec/2011:12:24:40][http-9445-2]: >>> WizardPanelBase::getCertChainUsingSecureAdminPort() - >>> Exception=org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: >>> 50; White spaces are required between publicId and systemId. >>> [08/Dec/2011:12:24:40][http-9445-2]: WizardPanelBase: >>> getCertChainUsingSecureAdminPort: java.io.IOException: >>> org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 50; White >>> spaces are required between publicId and systemId. >>> [08/Dec/2011:12:24:40][http-9445-2]: WizardPanelBase pingCS: started >>> [08/Dec/2011:12:24:40][http-9445-1]: CMSServlet:service() uri = >>> /ca/admin/ca/getStatus >>> [08/Dec/2011:12:24:40][http-9445-1]: CMSServlet: caGetStatus start to >>> service. >>> [08/Dec/2011:12:24:40][http-9445-1]: CMSServlet: curDate=Thu Dec 08 >>> 12:24:40 EST 2011 id=caGetStatus time=32 >>> [08/Dec/2011:12:24:40][http-9445-2]: WizardPanelBase pingCS: got XML >>> parsed >>> [08/Dec/2011:12:24:40][http-9445-2]: WizardPanelBase pingCS: state=0 >>> [08/Dec/2011:12:24:40][http-9445-2]: panel no=3 >>> [08/Dec/2011:12:24:40][http-9445-2]: panel name=securitydomain >>> [08/Dec/2011:12:24:40][http-9445-2]: total number of panels=19 >>> [08/Dec/2011:12:24:40][http-9445-2]: WizardServlet: found xml >>> [08/Dec/2011:12:24:40][http-9445-2]: Error: unknown type >>> org.apache.catalina.connector.ResponseFacade >>> [08/Dec/2011:12:24:40][http-9445-2]: Error: unknown type >>> org.apache.catalina.connector.RequestFacade >> >> >> I'll point the dogtag guys at this to see if they notice anything. >> >> >>>> This might also be ticket https://fedorahosted.org/freeipa/ticket/2148 >>> >>> >>> The script passes the port-check, so it doesn't look like it's the >>> issue mentioned. Is there a workaround for this issue? >> >> >> This is different from port-check. Dogtag stores the security domain >> information in its LDAP database. When creating a replica (or clone, in >> dogtag lingo) it compares the ports being requested with what is stored in >> the security domain and will reject if they don't match. Look for invalid >> clone_uri in the debug log to see if this is the problem. > > There's no mention of clone_uri anywhere in the debug log. > > Dan Ok - so based on this - it looks like it fails to get the security domain from the master. We need to see the master log to see if any interaction is happening there at the time. rob From ian at crystal.harvard.edu Thu Dec 15 16:38:31 2011 From: ian at crystal.harvard.edu (Ian Levesque) Date: Thu, 15 Dec 2011 11:38:31 -0500 Subject: [Freeipa-users] "User Administrator" role member doesn't see "User Groups" under identity tab In-Reply-To: <4EE9B3E0.6080506@redhat.com> References: <013112DA-2630-43F5-BAED-FACE055C7ACD@crystal.harvard.edu> <4EE7A2D1.9080500@redhat.com> <4EE9B3E0.6080506@redhat.com> Message-ID: On Dec 15, 2011, at 3:46 AM, Adam Young wrote: >>> I'm running version 2.0.0-23 under Scientific 6.1. I've noticed that users in the "User Administrator" role, don't have access via the web UI to actually manage groups. The only link under "Identity" is "Users". CLI management works as expected. Is this a known bug with the relatively old version of FreeIPA I'm running? >>> >>> $ ipa role-show "User Administrator" >>> Role name: User Administrator >>> Description: Responsible for creating Users and Groups >>> Member users: levesque >>> Privileges: user administrators, group administrators >>> >>> $ ipa privilege-show "group administrators" >>> Privilege name: Group Administrators >>> Description: Group Administrators >>> Permissions: add groups, remove groups, modify groups, modify group membership >>> Granting privilege to roles: User Administrator >> >> A similar issue was fixed in 2.1.3 but it affected all UI screens IIRC (e.g. non-admins never saw anything extra). > > Yes, that is the same issue. Do you have a BZ link for this? We're tracking RHEL releases, and it appears that 6.2 will only get us up to version 2.1.1. I'm curious if the fix can be diff'ed in... Best, Ian From ohamada at redhat.com Thu Dec 15 20:02:01 2011 From: ohamada at redhat.com (Ondrej Hamada) Date: Thu, 15 Dec 2011 21:02:01 +0100 Subject: [Freeipa-users] FreeIPA_demonstration_tools CA creation error. In-Reply-To: <4EE8E3D1.7080801@redhat.com> References: <512A3AF8DAE8454D95C05141F746ECE136BE37C2@MLBMXUS21.cs.myharris.net> <4EE8E3D1.7080801@redhat.com> Message-ID: <4EEA5239.5080401@redhat.com> On 12/14/2011 06:58 PM, Dmitri Pal wrote: > On 12/14/2011 11:04 AM, Mercer, Rodney wrote: >> I've been attempting to install the virtual machine setup from >> http://freeipa.org/page/FreeIPA_demonstration_tools >> >> I install on fresh Fedora 15 x86_64 host, and I am able to complete the first two steps. >> >> When I run the last script, >> ./ipa-demo.sh >> I get from the ipa-demo-.log >> ---- >> CRITICAL:root:failed to configure ca instance >> ---- >> and later in the log: >> ---- >> Warning: skipping DNS resolution of host master.example.com >> The IPA Master Server will be configured with >> Hostname: master.example.com >> IP address: 192.168.122.32 >> Domain name: example.com >> ---- >> and >> ---- >> Configuring certificate server: Estimated time 3 minutes 30 seconds >> [1/17]: creating certificate server user >> [2/17]: creating pki-ca instance >> [3/17]: configuring certificate server instance >> Unexpected error - see ipaserver-install.log for details: >> Configuration of CA failed >> Server installation failed! >> Domain f15-ipa-server destroyed >> >> Domain f15-ipa-server has been undefined >> ---- >> >> I see the dhcp address changing for master.example.com each time the script is run. >> Is there a requirement for making the dhcp address consistent for master.example.com >> and having the address in /etc/hosts so that it can reverse resolve via dnsmasq? >> >> Or does the DNS resolution of ip to host have any bearing on the certificate creation as I suspect? >> >> > Consistent name resolution is a requirement for IPA. > Ondrej, can you please take a closer look and see if this is something > with the demo scripts or IPA itself? I don't see a problem in scripts. When the virtual machines are created by ipa-demo, they acquire addresses from dhcp, then - before installation of freeipa - they're configured to use static addresses(the currently assigned ip address is chosen) and also the records are added into /etc/hosts. I wasn't able to reproduce the problem on clean f15 x64, the installation was successful, but few errors like this one appeared: ERROR:root:certmonger failed starting to track certificate: Command '/usr/bin/ipa-getcert start-tracking -d /etc/httpd/alias -n Server-Cert -p /etc/httpd/alias/pwdfile.txt' returned non-zero exit status 1 root : ERROR certmonger failed starting to track certificate: Command '/usr/bin/ipa-getcert start-tracking -d /etc/httpd/alias -n Server-Cert -p /etc/httpd/alias/pwdfile.txt' returned non-zero exit status 1 WARNING:root:remove: '60' not in nsslapd-pluginPrecedence -- Regards, Ondrej Hamada FreeIPA team jabber: ohama at jabbim.cz IRC: ohamada From rcritten at redhat.com Thu Dec 15 20:15:55 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 15 Dec 2011 15:15:55 -0500 Subject: [Freeipa-users] "User Administrator" role member doesn't see "User Groups" under identity tab In-Reply-To: References: <013112DA-2630-43F5-BAED-FACE055C7ACD@crystal.harvard.edu> <4EE7A2D1.9080500@redhat.com> <4EE9B3E0.6080506@redhat.com> Message-ID: <4EEA557B.1040000@redhat.com> Ian Levesque wrote: > > On Dec 15, 2011, at 3:46 AM, Adam Young wrote: > >>>> I'm running version 2.0.0-23 under Scientific 6.1. I've noticed that users in the "User Administrator" role, don't have access via the web UI to actually manage groups. The only link under "Identity" is "Users". CLI management works as expected. Is this a known bug with the relatively old version of FreeIPA I'm running? >>>> >>>> $ ipa role-show "User Administrator" >>>> Role name: User Administrator >>>> Description: Responsible for creating Users and Groups >>>> Member users: levesque >>>> Privileges: user administrators, group administrators >>>> >>>> $ ipa privilege-show "group administrators" >>>> Privilege name: Group Administrators >>>> Description: Group Administrators >>>> Permissions: add groups, remove groups, modify groups, modify group membership >>>> Granting privilege to roles: User Administrator >>> >>> A similar issue was fixed in 2.1.3 but it affected all UI screens IIRC (e.g. non-admins never saw anything extra). >> >> Yes, that is the same issue. > > Do you have a BZ link for this? We're tracking RHEL releases, and it appears that 6.2 will only get us up to version 2.1.1. I'm curious if the fix can be diff'ed in... https://bugzilla.redhat.com/show_bug.cgi?id=745957 The current RHEL 6.2 release is based on freeIPA 2.1.3. rob From rmercer at harris.com Thu Dec 15 20:27:16 2011 From: rmercer at harris.com (Mercer, Rodney) Date: Thu, 15 Dec 2011 20:27:16 +0000 Subject: [Freeipa-users] FreeIPA_demonstration_tools CA creation error. In-Reply-To: <4EEA5239.5080401@redhat.com> References: <512A3AF8DAE8454D95C05141F746ECE136BE37C2@MLBMXUS21.cs.myharris.net> <4EE8E3D1.7080801@redhat.com> <4EEA5239.5080401@redhat.com> Message-ID: <512A3AF8DAE8454D95C05141F746ECE136BE7101@MLBMXUS21.cs.myharris.net> On Thu, 2011-12-15 at 21:02 +0100, Ondrej Hamada wrote: > On 12/14/2011 06:58 PM, Dmitri Pal wrote: > > On 12/14/2011 11:04 AM, Mercer, Rodney wrote: > >> I've been attempting to install the virtual machine setup from > >> http://freeipa.org/page/FreeIPA_demonstration_tools > >> > >> I install on fresh Fedora 15 x86_64 host, and I am able to complete the first two steps. > >> > >> When I run the last script, > >> ./ipa-demo.sh > >> I get from the ipa-demo-.log > >> ---- > >> CRITICAL:root:failed to configure ca instance > >> ---- > >> and later in the log: > >> ---- > >> Warning: skipping DNS resolution of host master.example.com > >> The IPA Master Server will be configured with > >> Hostname: master.example.com > >> IP address: 192.168.122.32 > >> Domain name: example.com > >> ---- > >> and > >> ---- > >> Configuring certificate server: Estimated time 3 minutes 30 seconds > >> [1/17]: creating certificate server user > >> [2/17]: creating pki-ca instance > >> [3/17]: configuring certificate server instance > >> Unexpected error - see ipaserver-install.log for details: > >> Configuration of CA failed > >> Server installation failed! > >> Domain f15-ipa-server destroyed > >> > >> Domain f15-ipa-server has been undefined > >> ---- > >> > >> I see the dhcp address changing for master.example.com each time the script is run. > >> Is there a requirement for making the dhcp address consistent for master.example.com > >> and having the address in /etc/hosts so that it can reverse resolve via dnsmasq? > >> > >> Or does the DNS resolution of ip to host have any bearing on the certificate creation as I suspect? > >> > >> > > Consistent name resolution is a requirement for IPA. > > Ondrej, can you please take a closer look and see if this is something > > with the demo scripts or IPA itself? > I don't see a problem in scripts. When the virtual machines are created > by ipa-demo, they acquire addresses from dhcp, then - before > installation of freeipa - they're configured to use static addresses(the > currently assigned ip address is chosen) and also the records are added > into /etc/hosts. > > I wasn't able to reproduce the problem on clean f15 x64, the > installation was successful, but few errors like this one appeared: > > ERROR:root:certmonger failed starting to track certificate: Command > '/usr/bin/ipa-getcert start-tracking -d /etc/httpd/alias -n Server-Cert > -p /etc/httpd/alias/pwdfile.txt' returned non-zero exit status 1 > root : ERROR certmonger failed starting to track certificate: > Command '/usr/bin/ipa-getcert start-tracking -d /etc/httpd/alias -n > Server-Cert -p /etc/httpd/alias/pwdfile.txt' returned non-zero exit status 1 > WARNING:root:remove: '60' not in nsslapd-pluginPrecedence > > Hmmm, that's odd. I'm currently trying to force mine to work. I've attempted several times with clean installs and no modifications both on a workstation and laptop. I think I will take the laptop home and start over from my home network. Maybe our work dns servers are causing an issue. In the meantime, I am attempting to make the installation work on my work network with the following libvirt modifications. /var/lib/libvirt/dnsmasq/default.hostsfile fe:54:00:8e:72:76,192.168.122.45,master.example.com fe:54:00:8e:72:77,192.168.122.46,ipa-client1.example.com fe:54:00:8e:72:78,192.168.122.47,ipa-client2.example.com # virsh -c qemu:///system net-destroy default # virsh -c qemu:///system net-edit default default 9c90ded8-3ed6-4200-98e9-5c668bcdc7cd # virsh -c qemu:///system net-start default -- Rodney Mercer Systems Administrator From edewata at redhat.com Thu Dec 15 21:20:40 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 15 Dec 2011 15:20:40 -0600 Subject: [Freeipa-users] Optionistic approach for new DNS API In-Reply-To: <1323898917.17355.47.camel@priserak> References: <1323898917.17355.47.camel@priserak> Message-ID: <4EEA64A8.801@redhat.com> On 12/14/2011 3:41 PM, Martin Kosek wrote: > ipa dnsrecord-mod ZONE NAME VALUE? --type=mx --preference=0 > ipa dnsrecord-del ZONE NAME --type=mx --preference=0 --exchanger=server1.example.com. I think the mod & del commands should use the same way to specify the existing data. If we use the raw data, it should be specified as an option instead of an argument: ipa dnsrecord-mod ZONE NAME --type=mx \ --rec-data="10 server1.example.com." --new-preference=20 ipa dnsrecord-del ZONE NAME --type=mx \ --rec-data="10 server1.example.com." Alternatively we can use separate option for each parameter: ipa dnsrecord-mod ZONE NAME --type=mx \ --preference=10 --exchanger=server1.example.com. \ --new-preference=0 ipa dnsrecord-del ZONE NAME --type=mx \ --preference=10 --exchanger=server1.example.com. Or we can support both. > - SHOW and FIND commands do not need this new --type parameter We can also add --types to specify the record types we want to get back in the result. This could be useful in case we want to refresh a certain table only in the record details page. Low priority. BTW, I'd rather use --rec-type instead of just --type because 'type' seems to be more generic. In case a certain DNS record type also has a 'type' parameter, it might conflict with that. Another possibility is to use a prefix for all type-specific options, e.g. --mx-preference. > - ADD command: > - when no option is passed to dnsrecord-add command, it may ask for > --type and then for the options specific for the particular type > - MOD command: > - when no option is passed to dnsrecord-mod command, it may provide a > list of current DNS record values and ask for specific DNS record parts > to be changed for chosen value > - DEL command: > - when no option is passed to dnsrecord-del command, it may provide a > list of current DNS record values remove the chosen value For consistency the mod & del commands can also ask for the type, then show the list of records in that type. This way the list can be shown in a nicely formatted table rather than just raw data. -- Endi S. Dewata From mkosek at redhat.com Thu Dec 15 22:03:09 2011 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 15 Dec 2011 23:03:09 +0100 Subject: [Freeipa-users] Optionistic approach for new DNS API In-Reply-To: <4EEA64A8.801@redhat.com> References: <1323898917.17355.47.camel@priserak> <4EEA64A8.801@redhat.com> Message-ID: <1323986589.5594.22.camel@priserak> On Thu, 2011-12-15 at 15:20 -0600, Endi Sukma Dewata wrote: > On 12/14/2011 3:41 PM, Martin Kosek wrote: > > ipa dnsrecord-mod ZONE NAME VALUE? --type=mx --preference=0 > > ipa dnsrecord-del ZONE NAME --type=mx --preference=0 --exchanger=server1.example.com. Thanks for comments Endi! Please, see my input bellow. > > I think the mod & del commands should use the same way to specify the > existing data. > > If we use the raw data, it should be specified as an option instead of > an argument: > > ipa dnsrecord-mod ZONE NAME --type=mx \ > --rec-data="10 server1.example.com." --new-preference=20 I was also thinking about using current param "--mx-rec": ipa dnsrecord-mod ZONE NAME --mx-rec="10 server1.example.com." \ --mx-preference=20 But this would be a misuse and unexpected behavior. A new option would be better for that. > > ipa dnsrecord-del ZONE NAME --type=mx \ > --rec-data="10 server1.example.com." Current command can do that: ipa dnsrecord-del ZONE NAME --mx-rec="10 server1.example.com." We have this behavior for free. > > Alternatively we can use separate option for each parameter: > > ipa dnsrecord-mod ZONE NAME --type=mx \ > --preference=10 --exchanger=server1.example.com. \ > --new-preference=0 > > ipa dnsrecord-del ZONE NAME --type=mx \ > --preference=10 --exchanger=server1.example.com. > > Or we can support both. I think I would implement the first option first. We can extend if we see it is useful. My point is that I don't think use would bother constructing structured DNS record from its options in dnsrecord-del/mod (fill --preference and --exchanger) but rather copy&paste raw DNS value or use the interactive mode. > > > - SHOW and FIND commands do not need this new --type parameter > > We can also add --types to specify the record types we want to get back > in the result. This could be useful in case we want to refresh a certain > table only in the record details page. Low priority. Ok, noted as an idea for enhancement. I would rather like to create a functional minimalistic API first and add all the bells and whistles later when we see it is useful. > > BTW, I'd rather use --rec-type instead of just --type because 'type' > seems to be more generic. In case a certain DNS record type also has a > 'type' parameter, it might conflict with that. Another possibility is to > use a prefix for all type-specific options, e.g. --mx-preference. Actually, I was discussing this with Honza today. The problem is that we can't add conflicting options to one command (e.g. --preference for MX record and --preference for KX record). We would have to use --mx-preference and --kx-preference anyway. This would also remove the necessity to use --rec-type at all. I think we could detect the type from the options that were passed. I.e. when the following command is passed: ipa dnsrecord-add ZONE NAME --mx-preference=0 --mx-exchanger=server1.example.com. We know that MX record is being created. > > > - ADD command: > > - when no option is passed to dnsrecord-add command, it may ask for > > --type and then for the options specific for the particular type > > - MOD command: > > - when no option is passed to dnsrecord-mod command, it may provide a > > list of current DNS record values and ask for specific DNS record parts > > to be changed for chosen value > > - DEL command: > > - when no option is passed to dnsrecord-del command, it may provide a > > list of current DNS record values remove the chosen value > > For consistency the mod & del commands can also ask for the type, then > show the list of records in that type. This way the list can be shown in > a nicely formatted table rather than just raw data. > IMO the interactive help I described is more effective - use just has to choose a record and start modification for a specific RR type. With your proposal, he would have to choose a type, then choose a record of that type and then start the modification - 2 steps instead of 1. (And I don't think that formatting nice tables with records in CLI would be a priority). Martin From ayoung at redhat.com Fri Dec 16 00:09:11 2011 From: ayoung at redhat.com (Adam Young) Date: Thu, 15 Dec 2011 19:09:11 -0500 Subject: [Freeipa-users] Optionistic approach for new DNS API In-Reply-To: <1323898917.17355.47.camel@priserak> References: <1323898917.17355.47.camel@priserak> Message-ID: <4EEA8C27.8070401@redhat.com> On 12/14/2011 04:41 PM, Martin Kosek wrote: > Hello all, > > we just had a good discussion with Rob and Endi about different approach > to the new DNS API. Current DNS API proposal (patches 174-176) > introduced new API based on different commands, e.g. for MX RR type: > > ipa dnsrecord-mx-add ZONE NAME --preference=0 --exchanger=server1.example.com. > ipa dnsrecord-mx-mod ZONE NAME "0 server1.example.com." --preference=1 > ipa dnsrecord-mx-show ZONE NAME > > As a side effect, this would introduce many new commands > (dnsrecord-mx-add/mod/show, dnsrecord-loc-add/mod/show, ...) which may > of course be confusing. > > Endi proposed an different approach to use rather per-type options > instead of commands, which I think is really interesting to think about. > I will summarize how the API may look like. > > Changes to DNS module commands: > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > - no new DNS command would be implemented, we would just enhance current > dns record commands: > * dnsrecord-add, dnsrecord-mod, dnsrecord-del and dnsrecord-find > - all changes must be compatible with 2.x clients, changes to output > shall be triggered by 3.x option You've got my attention... > > Command Structure: > ~~~~~~~~~~~~~~~~~~ > - we would introduce --type option which would trigger the command to > use the new structured DNS options, i.e.: > > ipa dnsrecord-add ZONE NAME --type=mx --preference=0 --exchanger=server1.example.com. > > or > > ipa dnsrecord-mod ZONE NAME VALUE? --type=mx --preference=0 > > or > > ipa dnsrecord-del ZONE NAME --type=mx --preference=0 --exchanger=server1.example.com. > > - SHOW and FIND commands do not need this new --type parameter Yes, much better. I like this. > > Command Output: > ~~~~~~~~~~~~~~~ > - we would introduce a new --structured option which would switch > command output to "structured way" and present rather parsed DNS records > instead of raw DNS values (this is also needed for 2.x compatibility). > > For JSON output we may get: > > { > idnsname: 'foo', > records: [ > { > type: 'a', > data: '10.10.10.10', > ip_address: '10.10.10.10' > }, > { > type: 'cname', > data: 'bar.example.com.', > hostname: 'bar.example.com.' > }, > { > type: 'cname', > data: 'bar2.example.com.', > hostname: 'bar2.example.com.' > }, > ] > } > > instead of > > { > idnsname: 'foo', > arecord: [ > '10.10.10.10' > ], > cnamerecord: [ > 'bar.example.com.', > 'bar2.example.com.' > ] > } Yes, definite improvement. > In CLI it may look like this: > # ipa dnsrecordmx-show example.com @ --structured > Record name: @ > Record type: MX > Data: 0 server1.example.com > Preference: 0 > Exchanger: server1.example.com > > Record type: NS > Data: vm-068.idm.lab.bos.redhat.com. > Hostname: vm-068.idm.lab.bos.redhat.com. > > instead of: > > # ipa dnsrecord-show example.com @ > Record name: @ > MX record: 0 server1.example.com > NS record: vm-068.idm.lab.bos.redhat.com. This is OK, but it might be a little weird compared to the other outputs. Are any of the other ones indented like this? > Command help: > ~~~~~~~~~~~~~ > - since dnsrecord-add would accept all options from all DNS RR types, > its list would be overwhelming and not very helpful > - we can take advantage of OptionParser option groups. The help may look > like this: > > $ ipa dnsrecord-add --help > Usage: ipa [global-options] dnsrecord-add DNSZONE NAME [options] > > Options: > -h, --help show this help message and exit > > SRV Options: > --priority Priority > --weight Weight > --port Port > --target Target > > MX Options: > --priority Priority > --exchanger A host willing to act as a mail exchanger > ... > > Interactive mode in CLI: > ~~~~~~~~~~~~~~~~~~~~~~~~ > - ADD command: > - when no option is passed to dnsrecord-add command, it may ask for > --type and then for the options specific for the particular type > - MOD command: > - when no option is passed to dnsrecord-mod command, it may provide a > list of current DNS record values and ask for specific DNS record parts > to be changed for chosen value > - DEL command: > - when no option is passed to dnsrecord-del command, it may provide a > list of current DNS record values remove the chosen value > > Any comments, suggestions? Do you think that introducing these new > options in current dnsrecord-add/mod/show/del commands would be better > and more usable that introducing these capabilities in separate > commands? This is a big improvement. Right off the top of my head I see no major problems from the UI side, and I think it will make things a lot easier to work with than the older proposal. > > Thanks, > Martin > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From edewata at redhat.com Fri Dec 16 01:24:25 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 15 Dec 2011 19:24:25 -0600 Subject: [Freeipa-users] Optionistic approach for new DNS API In-Reply-To: <1323986589.5594.22.camel@priserak> References: <1323898917.17355.47.camel@priserak> <4EEA64A8.801@redhat.com> <1323986589.5594.22.camel@priserak> Message-ID: <4EEA9DC9.6040505@redhat.com> On 12/15/2011 4:03 PM, Martin Kosek wrote: >> If we use the raw data, it should be specified as an option instead of >> an argument: >> >> ipa dnsrecord-mod ZONE NAME --type=mx \ >> --rec-data="10 server1.example.com." --new-preference=20 > > I was also thinking about using current param "--mx-rec": > > ipa dnsrecord-mod ZONE NAME --mx-rec="10 server1.example.com." \ > --mx-preference=20 > > But this would be a misuse and unexpected behavior. A new option would > be better for that. I'm OK with either options. The help doc describes the --mx-rec option as a "comma-separated list of MX records". It doesn't say how the parameter should be used. We could say the mod command can be used in 2 different modes. In the first mode (the original) the command modifies the entire record object and the ---rec is used to specify the new records. In the second mode the command modifies a record specified in the ---rec. It also syntactically means we could perform the same modification against several records at once, although I'm not sure if it makes sense: ipa dnsrecord-mod ZONE NAME \ --mx-rec="10 server1.example.com.,10 server2.example.com." --mx-preference=20 > Current command can do that: > ipa dnsrecord-del ZONE NAME --mx-rec="10 server1.example.com." > We have this behavior for free. This is probably another reason to use the same --mx-rec option in mod. >> Alternatively we can use separate option for each parameter: >> >> ipa dnsrecord-mod ZONE NAME --type=mx \ >> --preference=10 --exchanger=server1.example.com. \ >> --new-preference=0 >> >> ipa dnsrecord-del ZONE NAME --type=mx \ >> --preference=10 --exchanger=server1.example.com. >> >> Or we can support both. > > I think I would implement the first option first. We can extend if we > see it is useful. My point is that I don't think use would bother > constructing structured DNS record from its options in dnsrecord-del/mod > (fill --preference and --exchanger) but rather copy&paste raw DNS value > or use the interactive mode. It might be useful for someone writing an application using the CLI. This way we don't need to know the order of the parameters. It's a low priority, but we should plan what parameter names we're going to use in the future. If now we use --mx-preference to specify the new value, later when we implement the new mechanism we will need to use something like --mx-old-preference to specify the old value. I'd rather use --mx-new-preference for the new value. >>> - SHOW and FIND commands do not need this new --type parameter >> >> We can also add --types to specify the record types we want to get back >> in the result. This could be useful in case we want to refresh a certain >> table only in the record details page. Low priority. > > Ok, noted as an idea for enhancement. I would rather like to create a > functional minimalistic API first and add all the bells and whistles > later when we see it is useful. OK. >> BTW, I'd rather use --rec-type instead of just --type because 'type' >> seems to be more generic. In case a certain DNS record type also has a >> 'type' parameter, it might conflict with that. Another possibility is to >> use a prefix for all type-specific options, e.g. --mx-preference. > > Actually, I was discussing this with Honza today. The problem is that we > can't add conflicting options to one command (e.g. --preference for MX > record and --preference for KX record). We would have to use > --mx-preference and --kx-preference anyway. It probably depends on how it's actually implemented. I suppose it's possible to keep a separate list of options for each type-specific command, then merge the lists for the main dnsrecord-add/mod/del command while removing duplicates. But using prefix is OK too. > This would also remove the necessity to use --rec-type at all. I think > we could detect the type from the options that were passed. I.e. when > the following command is passed: > > ipa dnsrecord-add ZONE NAME --mx-preference=0 --mx-exchanger=server1.example.com. > > We know that MX record is being created. Without the --rec-type, it's syntactically possible to add/mod/del multiple RR types at once. I'm not sure if we want to support that: ipa dnsrecord-mod ZONE NAME \ --mx-preference=0 --mx-exchanger=server1.example.com \ --mx-new-preference=1 --kx-preference=0 --kx-exchanger=server1.example.com \ --kx-exchanger=server2.example.com >>> - ADD command: >>> - when no option is passed to dnsrecord-add command, it may ask for >>> --type and then for the options specific for the particular type >>> - MOD command: >>> - when no option is passed to dnsrecord-mod command, it may provide a >>> list of current DNS record values and ask for specific DNS record parts >>> to be changed for chosen value >>> - DEL command: >>> - when no option is passed to dnsrecord-del command, it may provide a >>> list of current DNS record values remove the chosen value >> >> For consistency the mod& del commands can also ask for the type, then >> show the list of records in that type. This way the list can be shown in >> a nicely formatted table rather than just raw data. > > IMO the interactive help I described is more effective - use just has to > choose a record and start modification for a specific RR type. With your > proposal, he would have to choose a type, then choose a record of that > type and then start the modification - 2 steps instead of 1. The difference is not that big. Also if we keep the --rec-type option we can skip the first step: ipa dnsrecord-mod ZONE NAME --rec-type=mx > (And I don't think that formatting nice tables with records in CLI > would be a priority). Table is a compact way to show the data while still describing what the values in the raw data mean. No. Preference Exchanger -------------------------------------- 1. 10 server1.example.com. 2. 20 server2.example.com. Without table we might have to label each value: Record #1 Preference: 10 Exchanger: server1.example.com. Record #2 Preference: 10 Exchanger: server2.example.com. or just show the raw data without labels: 1) MX: "10 server1.example.com." 2) MX: "20 server2.example.com." 3) SRV: "0 100 464 ldap" My preference would be using the table, but the other options are still acceptable. -- Endi S. Dewata From mkosek at redhat.com Fri Dec 16 09:51:59 2011 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 16 Dec 2011 10:51:59 +0100 Subject: [Freeipa-users] Optionistic approach for new DNS API In-Reply-To: <4EEA8C27.8070401@redhat.com> References: <1323898917.17355.47.camel@priserak> <4EEA8C27.8070401@redhat.com> Message-ID: <1324029119.29179.15.camel@balmora.brq.redhat.com> On Thu, 2011-12-15 at 19:09 -0500, Adam Young wrote: > On 12/14/2011 04:41 PM, Martin Kosek wrote: ... > > > In CLI it may look like this: > > # ipa dnsrecordmx-show example.com @ --structured > > Record name: @ > > Record type: MX > > Data: 0 server1.example.com > > Preference: 0 > > Exchanger: server1.example.com > > > > Record type: NS > > Data: vm-068.idm.lab.bos.redhat.com. > > Hostname: vm-068.idm.lab.bos.redhat.com. > > > > instead of: > > > > # ipa dnsrecord-show example.com @ > > Record name: @ > > MX record: 0 server1.example.com > > NS record: vm-068.idm.lab.bos.redhat.com. > This is OK, but it might be a little weird compared to the other > outputs. Are any of the other ones indented like this? I don't think so. There is some code in CLI output module to create nested entries with increased indentation though. But this was just an example, we think up something better and more consistent. > > > Command help: > > ~~~~~~~~~~~~~ > > - since dnsrecord-add would accept all options from all DNS RR types, > > its list would be overwhelming and not very helpful > > - we can take advantage of OptionParser option groups. The help may look > > like this: > > > > $ ipa dnsrecord-add --help > > Usage: ipa [global-options] dnsrecord-add DNSZONE NAME [options] > > > > Options: > > -h, --help show this help message and exit > > > > SRV Options: > > --priority Priority > > --weight Weight > > --port Port > > --target Target > > > > MX Options: > > --priority Priority > > --exchanger A host willing to act as a mail exchanger > > ... > > > > Interactive mode in CLI: > > ~~~~~~~~~~~~~~~~~~~~~~~~ > > - ADD command: > > - when no option is passed to dnsrecord-add command, it may ask for > > --type and then for the options specific for the particular type > > - MOD command: > > - when no option is passed to dnsrecord-mod command, it may provide a > > list of current DNS record values and ask for specific DNS record parts > > to be changed for chosen value > > - DEL command: > > - when no option is passed to dnsrecord-del command, it may provide a > > list of current DNS record values remove the chosen value > > > > Any comments, suggestions? Do you think that introducing these new > > options in current dnsrecord-add/mod/show/del commands would be better > > and more usable that introducing these capabilities in separate > > commands? > > This is a big improvement. Right off the top of my head I see no major > problems from the UI side, and I think it will make things a lot easier > to work with than the older proposal. Great, thanks for comments Adam. Martin From ayoung at redhat.com Fri Dec 16 10:35:40 2011 From: ayoung at redhat.com (Adam Young) Date: Fri, 16 Dec 2011 05:35:40 -0500 Subject: [Freeipa-users] Multi-tennancy and Freeipa In-Reply-To: References: <4E70C9E2.6090101@redhat.com> <1316027302.2684.305.camel@willson.li.ssimo.org> <1316027837.2684.311.camel@willson.li.ssimo.org> <4E70FE57.2010705@redhat.com> <1316028161.2684.317.camel@willson.li.ssimo.org> Message-ID: <4EEB1EFC.6040206@redhat.com> I opened a ticket for multitenancy https://fedorahosted.org/freeipa/ticket/2201 Here is a detailed write up of the issues. http://freeipa.org/page/Multitenancy Please provide any feedback that you have and I will update. From nalin at redhat.com Fri Dec 16 14:14:34 2011 From: nalin at redhat.com (Nalin Dahyabhai) Date: Fri, 16 Dec 2011 09:14:34 -0500 Subject: [Freeipa-users] FreeIPA_demonstration_tools CA creation error. In-Reply-To: <4EEA5239.5080401@redhat.com> References: <512A3AF8DAE8454D95C05141F746ECE136BE37C2@MLBMXUS21.cs.myharris.net> <4EE8E3D1.7080801@redhat.com> <4EEA5239.5080401@redhat.com> Message-ID: <20111216141434.GA10380@redhat.com> On Thu, Dec 15, 2011 at 09:02:01PM +0100, Ondrej Hamada wrote: > On 12/14/2011 06:58 PM, Dmitri Pal wrote: > >Consistent name resolution is a requirement for IPA. > >Ondrej, can you please take a closer look and see if this is something > >with the demo scripts or IPA itself? > I don't see a problem in scripts. When the virtual machines are > created by ipa-demo, they acquire addresses from dhcp, then - before > installation of freeipa - they're configured to use static > addresses(the currently assigned ip address is chosen) and also the > records are added into /etc/hosts. Do you have an example /etc/hosts that could be double-checked? > I wasn't able to reproduce the problem on clean f15 x64, the > installation was successful, but few errors like this one appeared: > > ERROR:root:certmonger failed starting to track certificate: Command > '/usr/bin/ipa-getcert start-tracking -d /etc/httpd/alias -n > Server-Cert -p /etc/httpd/alias/pwdfile.txt' returned non-zero exit > status 1 > root : ERROR certmonger failed starting to track > certificate: Command '/usr/bin/ipa-getcert start-tracking -d > /etc/httpd/alias -n Server-Cert -p /etc/httpd/alias/pwdfile.txt' > returned non-zero exit status 1 Was there anything logged in the the ipaserver-install.log which would indicate why it failed here? Nalin From ohamada at redhat.com Fri Dec 16 16:14:15 2011 From: ohamada at redhat.com (Ondrej Hamada) Date: Fri, 16 Dec 2011 17:14:15 +0100 Subject: [Freeipa-users] FreeIPA_demonstration_tools CA creation error. In-Reply-To: <20111216141434.GA10380@redhat.com> References: <512A3AF8DAE8454D95C05141F746ECE136BE37C2@MLBMXUS21.cs.myharris.net> <4EE8E3D1.7080801@redhat.com> <4EEA5239.5080401@redhat.com> <20111216141434.GA10380@redhat.com> Message-ID: <4EEB6E57.4060600@redhat.com> On 12/16/2011 03:14 PM, Nalin Dahyabhai wrote: > On Thu, Dec 15, 2011 at 09:02:01PM +0100, Ondrej Hamada wrote: >> On 12/14/2011 06:58 PM, Dmitri Pal wrote: >>> Consistent name resolution is a requirement for IPA. >>> Ondrej, can you please take a closer look and see if this is something >>> with the demo scripts or IPA itself? >> I don't see a problem in scripts. When the virtual machines are >> created by ipa-demo, they acquire addresses from dhcp, then - before >> installation of freeipa - they're configured to use static >> addresses(the currently assigned ip address is chosen) and also the >> records are added into /etc/hosts. > Do you have an example /etc/hosts that could be double-checked? /etc/hosts on server vm: 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 192.168.122.105 master.example.com master > >> I wasn't able to reproduce the problem on clean f15 x64, the >> installation was successful, but few errors like this one appeared: >> >> ERROR:root:certmonger failed starting to track certificate: Command >> '/usr/bin/ipa-getcert start-tracking -d /etc/httpd/alias -n >> Server-Cert -p /etc/httpd/alias/pwdfile.txt' returned non-zero exit >> status 1 >> root : ERROR certmonger failed starting to track >> certificate: Command '/usr/bin/ipa-getcert start-tracking -d >> /etc/httpd/alias -n Server-Cert -p /etc/httpd/alias/pwdfile.txt' >> returned non-zero exit status 1 > Was there anything logged in the the ipaserver-install.log which would > indicate why it failed here? > > Nalin Unfortunately no ipaserver-install.log was created on vm (investigating why). I'm using freeipa-server-2.1.4.1. All the packages on system are from actual updates-testing repository. I've updated the scripts to put whole ipaserver-install.log and /var/log/messages into log file when installation crashes. -- Regards, Ondrej Hamada FreeIPA team jabber: ohama at jabbim.cz IRC: ohamada From ohamada at redhat.com Fri Dec 16 16:37:14 2011 From: ohamada at redhat.com (Ondrej Hamada) Date: Fri, 16 Dec 2011 17:37:14 +0100 Subject: [Freeipa-users] FreeIPA_demonstration_tools CA creation error. In-Reply-To: <4EEB6E57.4060600@redhat.com> References: <512A3AF8DAE8454D95C05141F746ECE136BE37C2@MLBMXUS21.cs.myharris.net> <4EE8E3D1.7080801@redhat.com> <4EEA5239.5080401@redhat.com> <20111216141434.GA10380@redhat.com> <4EEB6E57.4060600@redhat.com> Message-ID: <4EEB73BA.5040907@redhat.com> On 12/16/2011 05:14 PM, Ondrej Hamada wrote: > On 12/16/2011 03:14 PM, Nalin Dahyabhai wrote: >> On Thu, Dec 15, 2011 at 09:02:01PM +0100, Ondrej Hamada wrote: >>> On 12/14/2011 06:58 PM, Dmitri Pal wrote: >>>> Consistent name resolution is a requirement for IPA. >>>> Ondrej, can you please take a closer look and see if this is something >>>> with the demo scripts or IPA itself? >>> I don't see a problem in scripts. When the virtual machines are >>> created by ipa-demo, they acquire addresses from dhcp, then - before >>> installation of freeipa - they're configured to use static >>> addresses(the currently assigned ip address is chosen) and also the >>> records are added into /etc/hosts. >> Do you have an example /etc/hosts that could be double-checked? > > /etc/hosts on server vm: > > 127.0.0.1 localhost localhost.localdomain localhost4 > localhost4.localdomain4 > ::1 localhost localhost.localdomain localhost6 > localhost6.localdomain6 > 192.168.122.105 master.example.com master >> >>> I wasn't able to reproduce the problem on clean f15 x64, the >>> installation was successful, but few errors like this one appeared: >>> >>> ERROR:root:certmonger failed starting to track certificate: Command >>> '/usr/bin/ipa-getcert start-tracking -d /etc/httpd/alias -n >>> Server-Cert -p /etc/httpd/alias/pwdfile.txt' returned non-zero exit >>> status 1 >>> root : ERROR certmonger failed starting to track >>> certificate: Command '/usr/bin/ipa-getcert start-tracking -d >>> /etc/httpd/alias -n Server-Cert -p /etc/httpd/alias/pwdfile.txt' >>> returned non-zero exit status 1 >> Was there anything logged in the the ipaserver-install.log which would >> indicate why it failed here? >> >> Nalin > Unfortunately no ipaserver-install.log was created on vm > (investigating why). I'm using freeipa-server-2.1.4.1. All the > packages on system are from actual updates-testing repository. > > I've updated the scripts to put whole ipaserver-install.log and > /var/log/messages into log file when installation crashes. > The missing logs problem is related just to the freeipa-server-2.1.4.1(from updates-testing). Logs are create correctly on recently built packages. -- Regards, Ondrej Hamada FreeIPA team jabber: ohama at jabbim.cz IRC: ohamada From alanwevans at gmail.com Fri Dec 16 19:37:29 2011 From: alanwevans at gmail.com (Alan Evans) Date: Fri, 16 Dec 2011 14:37:29 -0500 Subject: [Freeipa-users] Multi-tennancy and Freeipa In-Reply-To: <4EEB1EFC.6040206@redhat.com> References: <4E70C9E2.6090101@redhat.com> <1316027302.2684.305.camel@willson.li.ssimo.org> <1316027837.2684.311.camel@willson.li.ssimo.org> <4E70FE57.2010705@redhat.com> <1316028161.2684.317.camel@willson.li.ssimo.org> <4EEB1EFC.6040206@redhat.com> Message-ID: Adam, This is great news. The feedback I have after a quick read through (I will try to put a bit more time on it later) would be to make the 'tennant' separation more flexible and why not use existing ldap schema? Instead of forcing the user into cn={TENANT},cn=tenants,$suffix why not create a 'tennant' aux class that would allow the end user to design a DIT however they would like. We for example use o=,$suffix. Then any schema maintenance instead of being: For each tennant in (cn=tenants,$suffix) It would be: For each tennant in (ldapsearch (objectclass=tennant)) Then the end provider could design a DIT that fit their needs with replication in mind. Consider the flexibility of: o=,C=US,$suffix o=,C=UK,$suffix o=,OU=North America,$suffix o=,OU=Europe,$suffix That's my 2? at the moment. I'd be glad to banter back and forth about this with you. :) Regards, -Alan On Fri, Dec 16, 2011 at 5:35 AM, Adam Young wrote: > > I opened a ticket for multitenancy > > https://fedorahosted.org/freeipa/ticket/2201 > > Here is a detailed write up of the issues. > > http://freeipa.org/page/Multitenancy > > Please provide any feedback that you have and I will update. From dpal at redhat.com Fri Dec 16 20:41:32 2011 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 16 Dec 2011 15:41:32 -0500 Subject: [Freeipa-users] Multi-tennancy and Freeipa In-Reply-To: References: <4E70C9E2.6090101@redhat.com> <1316027302.2684.305.camel@willson.li.ssimo.org> <1316027837.2684.311.camel@willson.li.ssimo.org> <4E70FE57.2010705@redhat.com> <1316028161.2684.317.camel@willson.li.ssimo.org> <4EEB1EFC.6040206@redhat.com> Message-ID: <4EEBACFC.20505@redhat.com> On 12/16/2011 02:37 PM, Alan Evans wrote: > Adam, > > This is great news. The feedback I have after a quick read through (I > will try to put a bit more time on it later) would be to make the > 'tennant' separation more flexible and why not use existing ldap > schema? > > Instead of forcing the user into cn={TENANT},cn=tenants,$suffix why > not create a 'tennant' aux class that would allow the end user to > design a DIT however they would like. > > We for example use o=,$suffix. Then any schema > maintenance instead of being: > For each tennant in (cn=tenants,$suffix) > It would be: > For each tennant in (ldapsearch (objectclass=tennant)) > > Then the end provider could design a DIT that fit their needs with > replication in mind. Consider the flexibility of: > > o=,C=US,$suffix > o=,C=UK,$suffix > o=,OU=North America,$suffix > o=,OU=Europe,$suffix > > That's my 2? at the moment. I'd be glad to banter back and forth > about this with you. :) > > Regards, > -Alan This is very flexible but I am not sure IPA would be able to be that flexible. One of the design goals from the beginning was: static schema and flat DIT. The whole project is built around it. Such approach would really come as a "system shock". I am not against it, just saying it would be harder as it goes even further than Adam's proposal in changing the fundamental principals. > On Fri, Dec 16, 2011 at 5:35 AM, Adam Young wrote: >> I opened a ticket for multitenancy >> >> https://fedorahosted.org/freeipa/ticket/2201 >> >> Here is a detailed write up of the issues. >> >> http://freeipa.org/page/Multitenancy >> >> Please provide any feedback that you have and I will update. > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From sbingram at gmail.com Sun Dec 18 00:17:19 2011 From: sbingram at gmail.com (Stephen Ingram) Date: Sat, 17 Dec 2011 16:17:19 -0800 Subject: [Freeipa-users] other attributes on certificates issued by IPA CA Message-ID: Looking at the logs when FreeIPA server is first setup, it is easy to see that the only real information included for the CA besides the CN is the organization which is set to the kerberos realm. I'm creating some certificates manually to test out the various parts of a manual client join. I notice that if I include more information such as MAIL, L, ST, C, or, a Subject Alternate Name the certificate request is denied by IPA with the error: ipa: ERROR: invalid 'fqdn': must be Unicode text Is this due to fact that the installation routine doesn't allow additional attributes for the CA itself so the CA won't allow you to include this information in the certificates, or some other issue? It works perfectly when I only use "CN=clientname.example.com,O=EXAMPLE.COM" for the subject of the certificate. Steve From abokovoy at redhat.com Sun Dec 18 23:55:33 2011 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 19 Dec 2011 01:55:33 +0200 Subject: [Freeipa-users] FreeIPA_demonstration_tools CA creation error. In-Reply-To: <4EEB73BA.5040907@redhat.com> References: <512A3AF8DAE8454D95C05141F746ECE136BE37C2@MLBMXUS21.cs.myharris.net> <4EE8E3D1.7080801@redhat.com> <4EEA5239.5080401@redhat.com> <20111216141434.GA10380@redhat.com> <4EEB6E57.4060600@redhat.com> <4EEB73BA.5040907@redhat.com> Message-ID: <20111218235533.GA27769@redhat.com> On Fri, 16 Dec 2011, Ondrej Hamada wrote: > >>Nalin > >Unfortunately no ipaserver-install.log was created on vm > >(investigating why). I'm using freeipa-server-2.1.4.1. All the > >packages on system are from actual updates-testing repository. > > > >I've updated the scripts to put whole ipaserver-install.log and > >/var/log/messages into log file when installation crashes. > > > The missing logs problem is related just to the > freeipa-server-2.1.4.1(from updates-testing). Logs are create > correctly on recently built packages. Is it on F15 or F16? The issue of not creating ipa-server-install.log is due to use of logging before initialization by one of components. That was fixed a while ago but if you are saying we missed it in 2.1.4 build for F15/F16, please file a bug and we'll work on backporting that change. -- / Alexander Bokovoy From freeipa at noboost.org Mon Dec 19 00:55:31 2011 From: freeipa at noboost.org (Craig T) Date: Mon, 19 Dec 2011 11:55:31 +1100 Subject: [Freeipa-users] Fedora 16 with new RHEL 6.2 Server? (RPC failed at server Error) Message-ID: <20111219005531.GA1385@noboost.org> Hi, Has anyone done testing with the new RHEL6.2 and Fedora 16x64 client? Server: Red Hat Enterprise Linux Server release 6.2 (Santiago) ipa-admintools-2.1.3-9.el6.x86_64 ipa-client-2.1.3-9.el6.x86_64 ipa-pki-ca-theme-9.0.3-7.el6.noarch ipa-pki-common-theme-9.0.3-7.el6.noarch ipa-python-2.1.3-9.el6.x86_64 ipa-server-2.1.3-9.el6.x86_64 ipa-server-selinux-2.1.3-9.el6.x86_64 Client: Fedora release 16 (Verne) freeipa-client-2.1.3-5.fc16.x86_64 freeipa-python-2.1.3-5.fc16.x86_64 Error: -------------------------------------------------------------------------- \r\n \r\n join\r\n \r\n \r\n chtpc.teratext.saic.com.au\r\n \r\n \r\n nsosversion\r\n 3.1.5-2.fc16.x86_64\r\n nshardwareplatform\r\n x86_64\r\n \r\n \r\n \r\n XML-RPC RESPONSE: \n \n \n \n \n faultCode\n 911\n \n \n faultString\n Missing or invalid HTTP Referer, missing\n \n \n \n \n RPC failed at server. Missing or invalid HTTP Referer, missing -------------------------------------------------------------------------- Regards, Craig From sbingram at gmail.com Mon Dec 19 02:05:06 2011 From: sbingram at gmail.com (Stephen Ingram) Date: Sun, 18 Dec 2011 18:05:06 -0800 Subject: [Freeipa-users] Fwd: manual client join In-Reply-To: <4EDD2E63.8010005@redhat.com> References: <4ED68C4A.2090500@redhat.com> <4ED69937.80003@redhat.com> <4EDD2E63.8010005@redhat.com> Message-ID: On Mon, Dec 5, 2011 at 12:49 PM, Rob Crittenden wrote: ...snip... > > Be sure that the CN value is the FQDN of your server. > > IPA server: > # ipa cert-request --prinicipal HTTP/remote.example.com /path/to/csr.pem > # ipa service-show --out=/tmp/service.crt HTTP/remote.example.com > > Your cert will be in /tmp/service.crt and PEM formatted for easy use. The > output of cert-request is just a base64 blob. > ...snip... > > This may be handy to augment the IPA documentation too if you want to donate > back your findings :-) OK, I'm going through lots of different scenarios to try to document this entire process and ran into one problem so far. Using your suggested command above to retrieve the cert via the command line: ipa service-show --out=/tmp/service.crt HTTP/remote.example.com This does not work for the host certficiate: e.g. ipa service-show --out=/tmp/service.crt host/remote.example.com While it is now easy to get the PEM formatted cert from the UI in version 2.1.4, I don't see any way to obtain this particular cert from the command line other than ipa cert-show {serial number} which is obviously not very convenient. Is there another way I'm missing or is that it? Steve From erinn.looneytriggs at gmail.com Mon Dec 19 08:01:28 2011 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Sun, 18 Dec 2011 23:01:28 -0900 Subject: [Freeipa-users] Fedora 16 with new RHEL 6.2 Server? (RPC failed at server Error) In-Reply-To: <20111219005531.GA1385@noboost.org> References: <20111219005531.GA1385@noboost.org> Message-ID: <4EEEEF58.7080306@gmail.com> On 12/18/2011 03:55 PM, Craig T wrote: > Hi, > > Has anyone done testing with the new RHEL6.2 and Fedora 16x64 client? > > Server: > Red Hat Enterprise Linux Server release 6.2 (Santiago) > ipa-admintools-2.1.3-9.el6.x86_64 > ipa-client-2.1.3-9.el6.x86_64 > ipa-pki-ca-theme-9.0.3-7.el6.noarch > ipa-pki-common-theme-9.0.3-7.el6.noarch > ipa-python-2.1.3-9.el6.x86_64 > ipa-server-2.1.3-9.el6.x86_64 > ipa-server-selinux-2.1.3-9.el6.x86_64 > > Client: > Fedora release 16 (Verne) > freeipa-client-2.1.3-5.fc16.x86_64 > freeipa-python-2.1.3-5.fc16.x86_64 > > Error: > -------------------------------------------------------------------------- > \r\n > \r\n > join\r\n > \r\n > \r\n > chtpc.teratext.saic.com.au\r\n > \r\n > \r\n > nsosversion\r\n > 3.1.5-2.fc16.x86_64\r\n > nshardwareplatform\r\n > x86_64\r\n > \r\n > \r\n > \r\n > > XML-RPC RESPONSE: > > \n > \n > \n > \n > \n > faultCode\n > 911\n > \n > \n > faultString\n > Missing or invalid HTTP Referer, missing\n > \n > \n > \n > \n > > RPC failed at server. Missing or invalid HTTP Referer, missing > -------------------------------------------------------------------------- > > > Regards, > > Craig > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users Just did this yesterday myself and ran into no issues. I am on updates-testing though so if you try the latest version of freeipa-client it may work better for you. freeipa-client-2.1.4-2.fc16.x86_64 I believe there was a security fix, something to do with something that broke compatability, so this may be what you are running into. -Erinn From abokovoy at redhat.com Mon Dec 19 08:30:38 2011 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 19 Dec 2011 10:30:38 +0200 Subject: [Freeipa-users] Fedora 16 with new RHEL 6.2 Server? (RPC failed at server Error) In-Reply-To: <20111219005531.GA1385@noboost.org> References: <20111219005531.GA1385@noboost.org> Message-ID: <20111219083038.GA31934@redhat.com> On Mon, 19 Dec 2011, Craig T wrote: > Hi, > > Has anyone done testing with the new RHEL6.2 and Fedora 16x64 client? > > Server: > Red Hat Enterprise Linux Server release 6.2 (Santiago) > ipa-admintools-2.1.3-9.el6.x86_64 > ipa-client-2.1.3-9.el6.x86_64 > ipa-pki-ca-theme-9.0.3-7.el6.noarch > ipa-pki-common-theme-9.0.3-7.el6.noarch > ipa-python-2.1.3-9.el6.x86_64 > ipa-server-2.1.3-9.el6.x86_64 > ipa-server-selinux-2.1.3-9.el6.x86_64 > > Client: > Fedora release 16 (Verne) > freeipa-client-2.1.3-5.fc16.x86_64 > freeipa-python-2.1.3-5.fc16.x86_64 Please use packages for 2.1.4 version for the clients (available in updates-testing). -- / Alexander Bokovoy From freeipa at noboost.org Mon Dec 19 09:26:40 2011 From: freeipa at noboost.org (Craig T) Date: Mon, 19 Dec 2011 20:26:40 +1100 Subject: [Freeipa-users] Fedora 16 with new RHEL 6.2 Server? (RPC failed at server Error) In-Reply-To: <20111219083038.GA31934@redhat.com> References: <20111219005531.GA1385@noboost.org> <20111219083038.GA31934@redhat.com> Message-ID: <20111219092640.GA2967@noboost.org> Thanks for that, I will try it again tomorrow. Just curious, but I'm getting the impression that when we do finally go live with IPA v2.x. It will take some monitoring to ensure that clients are always compatible? I imagine that when Fedora 18 comes out, my "now" current IPA Server my have issues with that ipa-client? Are Redhat planning to make this backward and forward compatible? I only ask because at this stage we don't have a SOE for our LAN. cya Craig On Mon, Dec 19, 2011 at 10:30:38AM +0200, Alexander Bokovoy wrote: > On Mon, 19 Dec 2011, Craig T wrote: > > > Hi, > > > > Has anyone done testing with the new RHEL6.2 and Fedora 16x64 client? > > > > Server: > > Red Hat Enterprise Linux Server release 6.2 (Santiago) > > ipa-admintools-2.1.3-9.el6.x86_64 > > ipa-client-2.1.3-9.el6.x86_64 > > ipa-pki-ca-theme-9.0.3-7.el6.noarch > > ipa-pki-common-theme-9.0.3-7.el6.noarch > > ipa-python-2.1.3-9.el6.x86_64 > > ipa-server-2.1.3-9.el6.x86_64 > > ipa-server-selinux-2.1.3-9.el6.x86_64 > > > > Client: > > Fedora release 16 (Verne) > > freeipa-client-2.1.3-5.fc16.x86_64 > > freeipa-python-2.1.3-5.fc16.x86_64 > Please use packages for 2.1.4 version for the clients (available in > updates-testing). > > -- > / Alexander Bokovoy From abokovoy at redhat.com Mon Dec 19 10:04:06 2011 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 19 Dec 2011 12:04:06 +0200 Subject: [Freeipa-users] Fedora 16 with new RHEL 6.2 Server? (RPC failed at server Error) In-Reply-To: <20111219092640.GA2967@noboost.org> References: <20111219005531.GA1385@noboost.org> <20111219083038.GA31934@redhat.com> <20111219092640.GA2967@noboost.org> Message-ID: <20111219100406.GB31934@redhat.com> On Mon, 19 Dec 2011, Craig T wrote: > Thanks for that, I will try it again tomorrow. > > Just curious, but I'm getting the impression that when we do finally > go live with IPA v2.x. It will take some monitoring to ensure that > clients are always compatible? > > I imagine that when Fedora 18 comes out, my "now" current IPA Server > my have issues with that ipa-client? Are Redhat planning to make > this backward and forward compatible? I only ask because at this > stage we don't have a SOE for our LAN. The change between 2.1.3 and 2.1.4 is a pro-active fix of potential cross-site request forgery tracked with CVE-2011-3636. Unfortunately, it required change of the communication protocol details which made old clients incompatible. You may read more details in Simo's mail on December 6th, sent to freeipa-devel@ and freeipa-users@: https://www.redhat.com/archives/freeipa-devel/2011-December/msg00107.html We have released updates to F15, F16, F17 (as 2.1.4), and various versions of RHEL5/RHEL6 (as a patch on top of 2.1.3), but on Fedora 16 side critpath was blocked due to some issues with glibc packages which created a delay in package flows for more than two weeks. There are no protocol changes planned for IPAv2 anymore. In the scope of IPAv3 there will be command set extensions but we are doing our best to maintain backward compatibility for older clients so that they would be able to use the functionality they are aware of against newer servers, after CSRF fix. I hope that our effort preventing possible remote attacks on core piece of enterprise infrastructure will be helpful when you'll go live with your installation. -- / Alexander Bokovoy From jdennis at redhat.com Mon Dec 19 13:36:24 2011 From: jdennis at redhat.com (John Dennis) Date: Mon, 19 Dec 2011 08:36:24 -0500 Subject: [Freeipa-users] Fwd: manual client join In-Reply-To: References: <4ED68C4A.2090500@redhat.com> <4ED69937.80003@redhat.com> <4EDD2E63.8010005@redhat.com> Message-ID: <4EEF3DD8.7010009@redhat.com> On 12/18/2011 09:05 PM, Stephen Ingram wrote: > On Mon, Dec 5, 2011 at 12:49 PM, Rob Crittenden wrote: > > ...snip... > >> >> Be sure that the CN value is the FQDN of your server. >> >> IPA server: >> # ipa cert-request --prinicipal HTTP/remote.example.com /path/to/csr.pem >> # ipa service-show --out=/tmp/service.crt HTTP/remote.example.com >> >> Your cert will be in /tmp/service.crt and PEM formatted for easy use. The >> output of cert-request is just a base64 blob. >> > ...snip... >> >> This may be handy to augment the IPA documentation too if you want to donate >> back your findings :-) > > OK, I'm going through lots of different scenarios to try to document > this entire process and ran into one problem so far. Using your > suggested command above to retrieve the cert via the command line: > > ipa service-show --out=/tmp/service.crt HTTP/remote.example.com > > This does not work for the host certficiate: > > e.g. ipa service-show --out=/tmp/service.crt host/remote.example.com > > While it is now easy to get the PEM formatted cert from the UI in > version 2.1.4, I don't see any way to obtain this particular cert from > the command line other than > > ipa cert-show {serial number} > > which is obviously not very convenient. > > Is there another way I'm missing or is that it? Sorry, but currently on the command line the only way to specify a certificate is via it's serial number. The serial number is the only identifier guaranteed to be unique. However, I agree it's not convenient. Would you like to open an RFE (Request for Enhancement) on https://fedorahosted.org/freeipa/ -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Mon Dec 19 13:53:39 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 19 Dec 2011 08:53:39 -0500 Subject: [Freeipa-users] Fwd: manual client join In-Reply-To: References: <4ED68C4A.2090500@redhat.com> <4ED69937.80003@redhat.com> <4EDD2E63.8010005@redhat.com> Message-ID: <4EEF41E3.7090305@redhat.com> Stephen Ingram wrote: > On Mon, Dec 5, 2011 at 12:49 PM, Rob Crittenden wrote: > > ...snip... > >> >> Be sure that the CN value is the FQDN of your server. >> >> IPA server: >> # ipa cert-request --prinicipal HTTP/remote.example.com /path/to/csr.pem >> # ipa service-show --out=/tmp/service.crt HTTP/remote.example.com >> >> Your cert will be in /tmp/service.crt and PEM formatted for easy use. The >> output of cert-request is just a base64 blob. >> > ...snip... >> >> This may be handy to augment the IPA documentation too if you want to donate >> back your findings :-) > > OK, I'm going through lots of different scenarios to try to document > this entire process and ran into one problem so far. Using your > suggested command above to retrieve the cert via the command line: > > ipa service-show --out=/tmp/service.crt HTTP/remote.example.com > > This does not work for the host certficiate: > > e.g. ipa service-show --out=/tmp/service.crt host/remote.example.com > > While it is now easy to get the PEM formatted cert from the UI in > version 2.1.4, I don't see any way to obtain this particular cert from > the command line other than > > ipa cert-show {serial number} > > which is obviously not very convenient. > > Is there another way I'm missing or is that it? > > Steve The host service principal is treated differently. It is stored in the host entry itself so use host-show --out rob From rcritten at redhat.com Mon Dec 19 13:59:51 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 19 Dec 2011 08:59:51 -0500 Subject: [Freeipa-users] Fedora 16 with new RHEL 6.2 Server? (RPC failed at server Error) In-Reply-To: <20111219100406.GB31934@redhat.com> References: <20111219005531.GA1385@noboost.org> <20111219083038.GA31934@redhat.com> <20111219092640.GA2967@noboost.org> <20111219100406.GB31934@redhat.com> Message-ID: <4EEF4357.3000907@redhat.com> Alexander Bokovoy wrote: > On Mon, 19 Dec 2011, Craig T wrote: > >> Thanks for that, I will try it again tomorrow. >> >> Just curious, but I'm getting the impression that when we do finally >> go live with IPA v2.x. It will take some monitoring to ensure that >> clients are always compatible? >> >> I imagine that when Fedora 18 comes out, my "now" current IPA Server >> my have issues with that ipa-client? Are Redhat planning to make >> this backward and forward compatible? I only ask because at this >> stage we don't have a SOE for our LAN. > The change between 2.1.3 and 2.1.4 is a pro-active fix of potential > cross-site request forgery tracked with CVE-2011-3636. Unfortunately, > it required change of the communication protocol details which made > old clients incompatible. You may read more details in Simo's mail on > December 6th, sent to freeipa-devel@ and freeipa-users@: > https://www.redhat.com/archives/freeipa-devel/2011-December/msg00107.html > > We have released updates to F15, F16, F17 (as 2.1.4), and various > versions of RHEL5/RHEL6 (as a patch on top of 2.1.3), but on Fedora 16 > side critpath was blocked due to some issues with glibc packages which > created a delay in package flows for more than two weeks. > > There are no protocol changes planned for IPAv2 anymore. In the scope > of IPAv3 there will be command set extensions but we are doing our > best to maintain backward compatibility for older clients so that they > would be able to use the functionality they are aware of against newer > servers, after CSRF fix. > > I hope that our effort preventing possible remote attacks on > core piece of enterprise infrastructure will be helpful when you'll go > live with your installation. Also, this only affected client enrollment. An already enrolled client is be affected as long as the certmonger package is updated befored the host SSL certificate expires (and then only if the client is actually using the cert). rob From rcritten at redhat.com Mon Dec 19 14:04:17 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 19 Dec 2011 09:04:17 -0500 Subject: [Freeipa-users] other attributes on certificates issued by IPA CA In-Reply-To: References: Message-ID: <4EEF4461.2090403@redhat.com> Stephen Ingram wrote: > Looking at the logs when FreeIPA server is first setup, it is easy to > see that the only real information included for the CA besides the CN > is the organization which is set to the kerberos realm. I'm creating > some certificates manually to test out the various parts of a manual > client join. I notice that if I include more information such as MAIL, > L, ST, C, or, a Subject Alternate Name the certificate request is > denied by IPA with the error: > > ipa: ERROR: invalid 'fqdn': must be Unicode text > > Is this due to fact that the installation routine doesn't allow > additional attributes for the CA itself so the CA won't allow you to > include this information in the certificates, or some other issue? It > works perfectly when I only use > "CN=clientname.example.com,O=EXAMPLE.COM" for the subject of the > certificate. > > Steve Well, that isn't the right error message. It should be complaining that the subject doesn't match. You can't include extra subject information. With a dogtag CA install it will all be silently dropped. A selfsign CA install does validation to ensure it matches the subject. The subject base is configurable only at install time. rob From danieljamesscott at gmail.com Mon Dec 19 16:01:42 2011 From: danieljamesscott at gmail.com (Dan Scott) Date: Mon, 19 Dec 2011 11:01:42 -0500 Subject: [Freeipa-users] ns-slapd hang/segfault In-Reply-To: <4EEA2589.5060400@redhat.com> References: <4EEA1908.2040801@redhat.com> <4EEA2589.5060400@redhat.com> Message-ID: On Thu, Dec 15, 2011 at 11:51, Rich Megginson wrote: > On 12/15/2011 09:48 AM, Dan Scott wrote: >> >> Hi, >> >> On Thu, Dec 15, 2011 at 10:58, Rich Megginson ?wrote: >>> >>> On 12/15/2011 08:41 AM, Dan Scott wrote: >>>> >>>> Hi, >>>> >>>> On my Fedora 15 FreeIPA server, I'm having some problems with >>>> stability. The server appears to 'hang' and stops responding to LDAP >>>> lookups. When I restart the dirsrv service, I get: >>>> >>>> Dec 15 09:40:02 ohm kernel: [254566.011404] ns-slapd[28910]: segfault >>>> at 17d ip 00007f00dbc0208c sp 00007fff929b7848 error 4 in >>>> libc-2.14.so[7f00dbb87000+18f000] >>>> >>>> and the /var/log/dirsrv/slapd-EXAMPLE-COM/errors contains >>>> >>>> [15/Dec/2011:09:47:35 -0500] set_krb5_creds - Could not get initial >>>> credentials for principal [ldap/example.com at EXAMPLE.COM] in keytab >>>> [WRFILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC >>>> for requested realm) >>>> [15/Dec/2011:09:47:35 -0500] slapd_ldap_sasl_interactive_bind - Error: >>>> could not perform interactive bind for id [] mech [GSSAPI]: error -2 >>>> (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified >>>> GSS failure. ?Minor code may provide more information (Credentials >>>> cache file '/tmp/krb5cc_496' not found)) >>>> >>>> This is happening very frequently, I'm having to restart the dirsrv >>>> process once an hour, otherwise people start complaining. >>>> >>>> I experienced similar problems with FreeIPA 1, when I was using Fedora >>>> 14 and earlier, and had to regularly (also once per hour) restart the >>>> dirsrv process. Could this be related? >>>> >>>> I also noticed this: >>>> https://bugzilla.redhat.com/show_bug.cgi?id=730387 >>>> >>>> There are updates in 'updates-testing' which I believe fix the above >>>> issue, but I'm reluctant to install from a testing repo on my >>>> production server, can anyone report any feedback on this? >>> >>> The above bug does not cause a segfault. >>> What version of 389-ds-base are you using? >> >> [root at ohm ~]# rpm -qa|grep 389 >> 389-ds-base-libs-1.2.10-0.4.a4.fc15.x86_64 >> 389-ds-base-1.2.10-0.4.a4.fc15.x86_64 >> [root at ohm ~]# > > a4 is alpha software. ?Not sure how that got released to stable. > >>> Please enable the collection of core dumps so we can debug the crash - >>> see >>> http://directory.fedoraproject.org/wiki/FAQ#Debugging_Crashes >> >> OK. I think there is a small typo in the instructions: >> >> 'debuginfo-install 389-ds-base-debuginfo' should be 'debuginfo-install >> 389-ds-base' > > Thanks. ?Fixed. > >> I managed to get the core dump (attached - so I only sent this message >> to you, not the list as well), but it doesn't contain much >> information. > > This is https://bugzilla.redhat.com/show_bug.cgi?id=755725 > > Will be fixed in 1.2.10.a6 > > But this still doesn't explain your kerberos errors. An additional problem is also occurring. I've been finding that the: /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif file is empty and prevents dirsrv from starting. I can restore it from dse.ldif.bak or dse.ldif.startOK, but this may be related to the LDAP problems that I'm having? Thanks, Dan From rmeggins at redhat.com Mon Dec 19 16:03:23 2011 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 19 Dec 2011 09:03:23 -0700 Subject: [Freeipa-users] ns-slapd hang/segfault In-Reply-To: References: <4EEA1908.2040801@redhat.com> <4EEA2589.5060400@redhat.com> Message-ID: <4EEF604B.3010209@redhat.com> On 12/19/2011 09:01 AM, Dan Scott wrote: > On Thu, Dec 15, 2011 at 11:51, Rich Megginson wrote: >> On 12/15/2011 09:48 AM, Dan Scott wrote: >>> Hi, >>> >>> On Thu, Dec 15, 2011 at 10:58, Rich Megginson wrote: >>>> On 12/15/2011 08:41 AM, Dan Scott wrote: >>>>> Hi, >>>>> >>>>> On my Fedora 15 FreeIPA server, I'm having some problems with >>>>> stability. The server appears to 'hang' and stops responding to LDAP >>>>> lookups. When I restart the dirsrv service, I get: >>>>> >>>>> Dec 15 09:40:02 ohm kernel: [254566.011404] ns-slapd[28910]: segfault >>>>> at 17d ip 00007f00dbc0208c sp 00007fff929b7848 error 4 in >>>>> libc-2.14.so[7f00dbb87000+18f000] >>>>> >>>>> and the /var/log/dirsrv/slapd-EXAMPLE-COM/errors contains >>>>> >>>>> [15/Dec/2011:09:47:35 -0500] set_krb5_creds - Could not get initial >>>>> credentials for principal [ldap/example.com at EXAMPLE.COM] in keytab >>>>> [WRFILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC >>>>> for requested realm) >>>>> [15/Dec/2011:09:47:35 -0500] slapd_ldap_sasl_interactive_bind - Error: >>>>> could not perform interactive bind for id [] mech [GSSAPI]: error -2 >>>>> (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified >>>>> GSS failure. Minor code may provide more information (Credentials >>>>> cache file '/tmp/krb5cc_496' not found)) >>>>> >>>>> This is happening very frequently, I'm having to restart the dirsrv >>>>> process once an hour, otherwise people start complaining. >>>>> >>>>> I experienced similar problems with FreeIPA 1, when I was using Fedora >>>>> 14 and earlier, and had to regularly (also once per hour) restart the >>>>> dirsrv process. Could this be related? >>>>> >>>>> I also noticed this: >>>>> https://bugzilla.redhat.com/show_bug.cgi?id=730387 >>>>> >>>>> There are updates in 'updates-testing' which I believe fix the above >>>>> issue, but I'm reluctant to install from a testing repo on my >>>>> production server, can anyone report any feedback on this? >>>> The above bug does not cause a segfault. >>>> What version of 389-ds-base are you using? >>> [root at ohm ~]# rpm -qa|grep 389 >>> 389-ds-base-libs-1.2.10-0.4.a4.fc15.x86_64 >>> 389-ds-base-1.2.10-0.4.a4.fc15.x86_64 >>> [root at ohm ~]# >> a4 is alpha software. Not sure how that got released to stable. >> >>>> Please enable the collection of core dumps so we can debug the crash - >>>> see >>>> http://directory.fedoraproject.org/wiki/FAQ#Debugging_Crashes >>> OK. I think there is a small typo in the instructions: >>> >>> 'debuginfo-install 389-ds-base-debuginfo' should be 'debuginfo-install >>> 389-ds-base' >> Thanks. Fixed. >> >>> I managed to get the core dump (attached - so I only sent this message >>> to you, not the list as well), but it doesn't contain much >>> information. >> This is https://bugzilla.redhat.com/show_bug.cgi?id=755725 >> >> Will be fixed in 1.2.10.a6 >> >> But this still doesn't explain your kerberos errors. > An additional problem is also occurring. I've been finding that the: > > /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif > > file is empty and prevents dirsrv from starting. I can restore it from > dse.ldif.bak or dse.ldif.startOK, but this may be related to the LDAP > problems that I'm having? I don't know. What is the sequence of operations that causes dse.ldif to become empty? > Thanks, > > Dan From danieljamesscott at gmail.com Mon Dec 19 16:13:48 2011 From: danieljamesscott at gmail.com (Dan Scott) Date: Mon, 19 Dec 2011 11:13:48 -0500 Subject: [Freeipa-users] ns-slapd hang/segfault In-Reply-To: <4EEF604B.3010209@redhat.com> References: <4EEA1908.2040801@redhat.com> <4EEA2589.5060400@redhat.com> <4EEF604B.3010209@redhat.com> Message-ID: On Mon, Dec 19, 2011 at 11:03, Rich Megginson wrote: > On 12/19/2011 09:01 AM, Dan Scott wrote: >> >> On Thu, Dec 15, 2011 at 11:51, Rich Megginson ?wrote: >>> >>> On 12/15/2011 09:48 AM, Dan Scott wrote: >>>> >>>> Hi, >>>> >>>> On Thu, Dec 15, 2011 at 10:58, Rich Megginson >>>> ?wrote: >>>>> >>>>> On 12/15/2011 08:41 AM, Dan Scott wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> On my Fedora 15 FreeIPA server, I'm having some problems with >>>>>> stability. The server appears to 'hang' and stops responding to LDAP >>>>>> lookups. When I restart the dirsrv service, I get: >>>>>> >>>>>> Dec 15 09:40:02 ohm kernel: [254566.011404] ns-slapd[28910]: segfault >>>>>> at 17d ip 00007f00dbc0208c sp 00007fff929b7848 error 4 in >>>>>> libc-2.14.so[7f00dbb87000+18f000] >>>>>> >>>>>> and the /var/log/dirsrv/slapd-EXAMPLE-COM/errors contains >>>>>> >>>>>> [15/Dec/2011:09:47:35 -0500] set_krb5_creds - Could not get initial >>>>>> credentials for principal [ldap/example.com at EXAMPLE.COM] in keytab >>>>>> [WRFILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC >>>>>> for requested realm) >>>>>> [15/Dec/2011:09:47:35 -0500] slapd_ldap_sasl_interactive_bind - Error: >>>>>> could not perform interactive bind for id [] mech [GSSAPI]: error -2 >>>>>> (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified >>>>>> GSS failure. ?Minor code may provide more information (Credentials >>>>>> cache file '/tmp/krb5cc_496' not found)) >>>>>> >>>>>> This is happening very frequently, I'm having to restart the dirsrv >>>>>> process once an hour, otherwise people start complaining. >>>>>> >>>>>> I experienced similar problems with FreeIPA 1, when I was using Fedora >>>>>> 14 and earlier, and had to regularly (also once per hour) restart the >>>>>> dirsrv process. Could this be related? >>>>>> >>>>>> I also noticed this: >>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=730387 >>>>>> >>>>>> There are updates in 'updates-testing' which I believe fix the above >>>>>> issue, but I'm reluctant to install from a testing repo on my >>>>>> production server, can anyone report any feedback on this? >>>>> >>>>> The above bug does not cause a segfault. >>>>> What version of 389-ds-base are you using? >>>> >>>> [root at ohm ~]# rpm -qa|grep 389 >>>> 389-ds-base-libs-1.2.10-0.4.a4.fc15.x86_64 >>>> 389-ds-base-1.2.10-0.4.a4.fc15.x86_64 >>>> [root at ohm ~]# >>> >>> a4 is alpha software. ?Not sure how that got released to stable. >>> >>>>> Please enable the collection of core dumps so we can debug the crash - >>>>> see >>>>> http://directory.fedoraproject.org/wiki/FAQ#Debugging_Crashes >>>> >>>> OK. I think there is a small typo in the instructions: >>>> >>>> 'debuginfo-install 389-ds-base-debuginfo' should be 'debuginfo-install >>>> 389-ds-base' >>> >>> Thanks. ?Fixed. >>> >>>> I managed to get the core dump (attached - so I only sent this message >>>> to you, not the list as well), but it doesn't contain much >>>> information. >>> >>> This is https://bugzilla.redhat.com/show_bug.cgi?id=755725 >>> >>> Will be fixed in 1.2.10.a6 >>> >>> But this still doesn't explain your kerberos errors. >> >> An additional problem is also occurring. I've been finding that the: >> >> /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif >> >> file is empty and prevents dirsrv from starting. I can restore it from >> dse.ldif.bak or dse.ldif.startOK, but this may be related to the LDAP >> problems that I'm having? > > I don't know. ?What is the sequence of operations that causes dse.ldif to > become empty? Can I find this in the logs? The dirsrv process is crashing regularly, so I have to regularly restart it. Occasionally (seemingly randomly) it fails to restart because the dse.ldif file is empty. From rmeggins at redhat.com Mon Dec 19 16:16:27 2011 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 19 Dec 2011 09:16:27 -0700 Subject: [Freeipa-users] ns-slapd hang/segfault In-Reply-To: References: <4EEA1908.2040801@redhat.com> <4EEA2589.5060400@redhat.com> <4EEF604B.3010209@redhat.com> Message-ID: <4EEF635B.8040702@redhat.com> On 12/19/2011 09:13 AM, Dan Scott wrote: > On Mon, Dec 19, 2011 at 11:03, Rich Megginson wrote: >> On 12/19/2011 09:01 AM, Dan Scott wrote: >>> On Thu, Dec 15, 2011 at 11:51, Rich Megginson wrote: >>>> On 12/15/2011 09:48 AM, Dan Scott wrote: >>>>> Hi, >>>>> >>>>> On Thu, Dec 15, 2011 at 10:58, Rich Megginson >>>>> wrote: >>>>>> On 12/15/2011 08:41 AM, Dan Scott wrote: >>>>>>> Hi, >>>>>>> >>>>>>> On my Fedora 15 FreeIPA server, I'm having some problems with >>>>>>> stability. The server appears to 'hang' and stops responding to LDAP >>>>>>> lookups. When I restart the dirsrv service, I get: >>>>>>> >>>>>>> Dec 15 09:40:02 ohm kernel: [254566.011404] ns-slapd[28910]: segfault >>>>>>> at 17d ip 00007f00dbc0208c sp 00007fff929b7848 error 4 in >>>>>>> libc-2.14.so[7f00dbb87000+18f000] >>>>>>> >>>>>>> and the /var/log/dirsrv/slapd-EXAMPLE-COM/errors contains >>>>>>> >>>>>>> [15/Dec/2011:09:47:35 -0500] set_krb5_creds - Could not get initial >>>>>>> credentials for principal [ldap/example.com at EXAMPLE.COM] in keytab >>>>>>> [WRFILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC >>>>>>> for requested realm) >>>>>>> [15/Dec/2011:09:47:35 -0500] slapd_ldap_sasl_interactive_bind - Error: >>>>>>> could not perform interactive bind for id [] mech [GSSAPI]: error -2 >>>>>>> (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified >>>>>>> GSS failure. Minor code may provide more information (Credentials >>>>>>> cache file '/tmp/krb5cc_496' not found)) >>>>>>> >>>>>>> This is happening very frequently, I'm having to restart the dirsrv >>>>>>> process once an hour, otherwise people start complaining. >>>>>>> >>>>>>> I experienced similar problems with FreeIPA 1, when I was using Fedora >>>>>>> 14 and earlier, and had to regularly (also once per hour) restart the >>>>>>> dirsrv process. Could this be related? >>>>>>> >>>>>>> I also noticed this: >>>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=730387 >>>>>>> >>>>>>> There are updates in 'updates-testing' which I believe fix the above >>>>>>> issue, but I'm reluctant to install from a testing repo on my >>>>>>> production server, can anyone report any feedback on this? >>>>>> The above bug does not cause a segfault. >>>>>> What version of 389-ds-base are you using? >>>>> [root at ohm ~]# rpm -qa|grep 389 >>>>> 389-ds-base-libs-1.2.10-0.4.a4.fc15.x86_64 >>>>> 389-ds-base-1.2.10-0.4.a4.fc15.x86_64 >>>>> [root at ohm ~]# >>>> a4 is alpha software. Not sure how that got released to stable. >>>> >>>>>> Please enable the collection of core dumps so we can debug the crash - >>>>>> see >>>>>> http://directory.fedoraproject.org/wiki/FAQ#Debugging_Crashes >>>>> OK. I think there is a small typo in the instructions: >>>>> >>>>> 'debuginfo-install 389-ds-base-debuginfo' should be 'debuginfo-install >>>>> 389-ds-base' >>>> Thanks. Fixed. >>>> >>>>> I managed to get the core dump (attached - so I only sent this message >>>>> to you, not the list as well), but it doesn't contain much >>>>> information. >>>> This is https://bugzilla.redhat.com/show_bug.cgi?id=755725 >>>> >>>> Will be fixed in 1.2.10.a6 >>>> >>>> But this still doesn't explain your kerberos errors. >>> An additional problem is also occurring. I've been finding that the: >>> >>> /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif >>> >>> file is empty and prevents dirsrv from starting. I can restore it from >>> dse.ldif.bak or dse.ldif.startOK, but this may be related to the LDAP >>> problems that I'm having? >> I don't know. What is the sequence of operations that causes dse.ldif to >> become empty? > Can I find this in the logs? The dirsrv process is crashing regularly, > so I have to regularly restart it. Occasionally (seemingly randomly) > it fails to restart because the dse.ldif file is empty. Let me push out the crash fix build to testing and see if that helps. From ayoung at redhat.com Mon Dec 19 16:50:01 2011 From: ayoung at redhat.com (Adam Young) Date: Mon, 19 Dec 2011 11:50:01 -0500 Subject: [Freeipa-users] Multi-tennancy and Freeipa In-Reply-To: <4EEBACFC.20505@redhat.com> References: <4E70C9E2.6090101@redhat.com> <1316027302.2684.305.camel@willson.li.ssimo.org> <1316027837.2684.311.camel@willson.li.ssimo.org> <4E70FE57.2010705@redhat.com> <1316028161.2684.317.camel@willson.li.ssimo.org> <4EEB1EFC.6040206@redhat.com> <4EEBACFC.20505@redhat.com> Message-ID: <4EEF6B39.8090308@redhat.com> On 12/16/2011 03:41 PM, Dmitri Pal wrote: > On 12/16/2011 02:37 PM, Alan Evans wrote: >> Adam, >> >> This is great news. The feedback I have after a quick read through (I >> will try to put a bit more time on it later) would be to make the >> 'tennant' separation more flexible and why not use existing ldap >> schema? >> >> Instead of forcing the user into cn={TENANT},cn=tenants,$suffix why >> not create a 'tennant' aux class that would allow the end user to >> design a DIT however they would like. >> >> We for example use o=,$suffix. Then any schema >> maintenance instead of being: >> For each tennant in (cn=tenants,$suffix) >> It would be: >> For each tennant in (ldapsearch (objectclass=tennant)) >> >> Then the end provider could design a DIT that fit their needs with >> replication in mind. Consider the flexibility of: >> >> o=,C=US,$suffix >> o=,C=UK,$suffix >> o=,OU=North America,$suffix >> o=,OU=Europe,$suffix >> >> That's my 2? at the moment. I'd be glad to banter back and forth >> about this with you. :) >> >> Regards, >> -Alan > This is very flexible but I am not sure IPA would be able to be that > flexible. > One of the design goals from the beginning was: static schema and flat > DIT. The whole project is built around it. Such approach would really > come as a "system shock". I am not against it, just saying it would be > harder as it goes even further than Adam's proposal in changing the > fundamental principals. Also, it is not just the user table that we need to segregate but the entire DIT. Roles, Groups, SUDO, HBAC, and so forth all need to be segregated into a separate subtree, not just the user lists. So putting users in a aux class doesn't really support sufficient segregation. The assumption for us is that the IPA base scheme would be for administrative machines, and then each of the tenant subtrees would be for a subset of the machines in the system. But that is really only one view of it, and I think I can see where you are coming from: you want to be able to manage,say customers, but use the same rules for them as you do for employees? > >> On Fri, Dec 16, 2011 at 5:35 AM, Adam Young wrote: >>> I opened a ticket for multitenancy >>> >>> https://fedorahosted.org/freeipa/ticket/2201 >>> >>> Here is a detailed write up of the issues. >>> >>> http://freeipa.org/page/Multitenancy >>> >>> Please provide any feedback that you have and I will update. >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> > From simo at redhat.com Mon Dec 19 19:14:57 2011 From: simo at redhat.com (Simo Sorce) Date: Mon, 19 Dec 2011 14:14:57 -0500 Subject: [Freeipa-users] ns-slapd hang/segfault In-Reply-To: References: <4EEA1908.2040801@redhat.com> <4EEA2589.5060400@redhat.com> Message-ID: <1324322097.28622.98.camel@willson.li.ssimo.org> On Mon, 2011-12-19 at 11:01 -0500, Dan Scott wrote: > On Thu, Dec 15, 2011 at 11:51, Rich Megginson wrote: > > On 12/15/2011 09:48 AM, Dan Scott wrote: > >> > >> Hi, > >> > >> On Thu, Dec 15, 2011 at 10:58, Rich Megginson wrote: > >>> > >>> On 12/15/2011 08:41 AM, Dan Scott wrote: > >>>> > >>>> Hi, > >>>> > >>>> On my Fedora 15 FreeIPA server, I'm having some problems with > >>>> stability. The server appears to 'hang' and stops responding to LDAP > >>>> lookups. When I restart the dirsrv service, I get: > >>>> > >>>> Dec 15 09:40:02 ohm kernel: [254566.011404] ns-slapd[28910]: segfault > >>>> at 17d ip 00007f00dbc0208c sp 00007fff929b7848 error 4 in > >>>> libc-2.14.so[7f00dbb87000+18f000] > >>>> > >>>> and the /var/log/dirsrv/slapd-EXAMPLE-COM/errors contains > >>>> > >>>> [15/Dec/2011:09:47:35 -0500] set_krb5_creds - Could not get initial > >>>> credentials for principal [ldap/example.com at EXAMPLE.COM] in keytab > >>>> [WRFILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC > >>>> for requested realm) > >>>> [15/Dec/2011:09:47:35 -0500] slapd_ldap_sasl_interactive_bind - Error: > >>>> could not perform interactive bind for id [] mech [GSSAPI]: error -2 > >>>> (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified > >>>> GSS failure. Minor code may provide more information (Credentials > >>>> cache file '/tmp/krb5cc_496' not found)) > >>>> > >>>> This is happening very frequently, I'm having to restart the dirsrv > >>>> process once an hour, otherwise people start complaining. > >>>> > >>>> I experienced similar problems with FreeIPA 1, when I was using Fedora > >>>> 14 and earlier, and had to regularly (also once per hour) restart the > >>>> dirsrv process. Could this be related? > >>>> > >>>> I also noticed this: > >>>> https://bugzilla.redhat.com/show_bug.cgi?id=730387 > >>>> > >>>> There are updates in 'updates-testing' which I believe fix the above > >>>> issue, but I'm reluctant to install from a testing repo on my > >>>> production server, can anyone report any feedback on this? > >>> > >>> The above bug does not cause a segfault. > >>> What version of 389-ds-base are you using? > >> > >> [root at ohm ~]# rpm -qa|grep 389 > >> 389-ds-base-libs-1.2.10-0.4.a4.fc15.x86_64 > >> 389-ds-base-1.2.10-0.4.a4.fc15.x86_64 > >> [root at ohm ~]# > > > > a4 is alpha software. Not sure how that got released to stable. > > > >>> Please enable the collection of core dumps so we can debug the crash - > >>> see > >>> http://directory.fedoraproject.org/wiki/FAQ#Debugging_Crashes > >> > >> OK. I think there is a small typo in the instructions: > >> > >> 'debuginfo-install 389-ds-base-debuginfo' should be 'debuginfo-install > >> 389-ds-base' > > > > Thanks. Fixed. > > > >> I managed to get the core dump (attached - so I only sent this message > >> to you, not the list as well), but it doesn't contain much > >> information. > > > > This is https://bugzilla.redhat.com/show_bug.cgi?id=755725 > > > > Will be fixed in 1.2.10.a6 > > > > But this still doesn't explain your kerberos errors. > > An additional problem is also occurring. I've been finding that the: > > /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif > > file is empty and prevents dirsrv from starting. I can restore it from > dse.ldif.bak or dse.ldif.startOK, but this may be related to the LDAP > problems that I'm having? This is an upgrade time problem, it should be fixed in latest packages. Did you recently upgrade freeipa packages if so from what version to what version ? (If you used yum you can use 'yum history' to find out) Simo. -- Simo Sorce * Red Hat, Inc * New York From danieljamesscott at gmail.com Mon Dec 19 20:26:46 2011 From: danieljamesscott at gmail.com (Dan Scott) Date: Mon, 19 Dec 2011 15:26:46 -0500 Subject: [Freeipa-users] ns-slapd hang/segfault In-Reply-To: <1324322097.28622.98.camel@willson.li.ssimo.org> References: <4EEA1908.2040801@redhat.com> <4EEA2589.5060400@redhat.com> <1324322097.28622.98.camel@willson.li.ssimo.org> Message-ID: On Mon, Dec 19, 2011 at 14:14, Simo Sorce wrote: > On Mon, 2011-12-19 at 11:01 -0500, Dan Scott wrote: >> On Thu, Dec 15, 2011 at 11:51, Rich Megginson wrote: >> > On 12/15/2011 09:48 AM, Dan Scott wrote: >> >> >> >> Hi, >> >> >> >> On Thu, Dec 15, 2011 at 10:58, Rich Megginson ?wrote: >> >>> >> >>> On 12/15/2011 08:41 AM, Dan Scott wrote: >> >>>> >> >>>> Hi, >> >>>> >> >>>> On my Fedora 15 FreeIPA server, I'm having some problems with >> >>>> stability. The server appears to 'hang' and stops responding to LDAP >> >>>> lookups. When I restart the dirsrv service, I get: >> >>>> >> >>>> Dec 15 09:40:02 ohm kernel: [254566.011404] ns-slapd[28910]: segfault >> >>>> at 17d ip 00007f00dbc0208c sp 00007fff929b7848 error 4 in >> >>>> libc-2.14.so[7f00dbb87000+18f000] >> >>>> >> >>>> and the /var/log/dirsrv/slapd-EXAMPLE-COM/errors contains >> >>>> >> >>>> [15/Dec/2011:09:47:35 -0500] set_krb5_creds - Could not get initial >> >>>> credentials for principal [ldap/example.com at EXAMPLE.COM] in keytab >> >>>> [WRFILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC >> >>>> for requested realm) >> >>>> [15/Dec/2011:09:47:35 -0500] slapd_ldap_sasl_interactive_bind - Error: >> >>>> could not perform interactive bind for id [] mech [GSSAPI]: error -2 >> >>>> (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified >> >>>> GSS failure. ?Minor code may provide more information (Credentials >> >>>> cache file '/tmp/krb5cc_496' not found)) >> >>>> >> >>>> This is happening very frequently, I'm having to restart the dirsrv >> >>>> process once an hour, otherwise people start complaining. >> >>>> >> >>>> I experienced similar problems with FreeIPA 1, when I was using Fedora >> >>>> 14 and earlier, and had to regularly (also once per hour) restart the >> >>>> dirsrv process. Could this be related? >> >>>> >> >>>> I also noticed this: >> >>>> https://bugzilla.redhat.com/show_bug.cgi?id=730387 >> >>>> >> >>>> There are updates in 'updates-testing' which I believe fix the above >> >>>> issue, but I'm reluctant to install from a testing repo on my >> >>>> production server, can anyone report any feedback on this? >> >>> >> >>> The above bug does not cause a segfault. >> >>> What version of 389-ds-base are you using? >> >> >> >> [root at ohm ~]# rpm -qa|grep 389 >> >> 389-ds-base-libs-1.2.10-0.4.a4.fc15.x86_64 >> >> 389-ds-base-1.2.10-0.4.a4.fc15.x86_64 >> >> [root at ohm ~]# >> > >> > a4 is alpha software. ?Not sure how that got released to stable. >> > >> >>> Please enable the collection of core dumps so we can debug the crash - >> >>> see >> >>> http://directory.fedoraproject.org/wiki/FAQ#Debugging_Crashes >> >> >> >> OK. I think there is a small typo in the instructions: >> >> >> >> 'debuginfo-install 389-ds-base-debuginfo' should be 'debuginfo-install >> >> 389-ds-base' >> > >> > Thanks. ?Fixed. >> > >> >> I managed to get the core dump (attached - so I only sent this message >> >> to you, not the list as well), but it doesn't contain much >> >> information. >> > >> > This is https://bugzilla.redhat.com/show_bug.cgi?id=755725 >> > >> > Will be fixed in 1.2.10.a6 >> > >> > But this still doesn't explain your kerberos errors. >> >> An additional problem is also occurring. I've been finding that the: >> >> /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif >> >> file is empty and prevents dirsrv from starting. I can restore it from >> dse.ldif.bak or dse.ldif.startOK, but this may be related to the LDAP >> problems that I'm having? > > This is an upgrade time problem, it should be fixed in latest packages. > Did you recently upgrade freeipa packages if so from what version to > what version ? The 0 length file doesn't appear related to upgrades. Possibly it only happens on the first service restart after an upgrade? It's happened at least 4 times since the last freeipa package upgrade on 4th November, so it seems to be happening too regularly to be the result of an upgrade. [root at curie ~]# grep freeipa /var/log/yum.log Sep 06 16:56:51 Installed: freeipa-python-2.0.1-2.fc15.x86_64 Sep 06 17:00:13 Installed: freeipa-client-2.0.1-2.fc15.x86_64 Sep 06 17:00:14 Installed: freeipa-admintools-2.0.1-2.fc15.x86_64 Sep 06 17:01:52 Installed: freeipa-server-selinux-2.0.1-2.fc15.x86_64 Sep 06 17:01:56 Installed: freeipa-server-2.0.1-2.fc15.x86_64 Sep 08 11:23:35 Updated: freeipa-python-2.1.0-1.fc15.x86_64 Sep 08 11:23:41 Updated: freeipa-client-2.1.0-1.fc15.x86_64 Sep 08 11:23:41 Updated: freeipa-admintools-2.1.0-1.fc15.x86_64 Sep 08 11:25:00 Updated: freeipa-server-selinux-2.1.0-1.fc15.x86_64 Sep 08 11:26:06 Updated: freeipa-server-2.1.0-1.fc15.x86_64 Nov 04 15:46:43 Updated: freeipa-python-2.1.3-2.fc15.x86_64 Nov 04 15:52:48 Updated: freeipa-client-2.1.3-2.fc15.x86_64 Nov 04 15:52:48 Updated: freeipa-admintools-2.1.3-2.fc15.x86_64 Nov 04 15:54:47 Updated: freeipa-server-2.1.3-2.fc15.x86_64 Nov 04 15:56:02 Updated: freeipa-server-selinux-2.1.3-2.fc15.x86_64 Dan From erinn.looneytriggs at gmail.com Tue Dec 20 21:59:45 2011 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Tue, 20 Dec 2011 12:59:45 -0900 Subject: [Freeipa-users] Sudo configuration question Message-ID: <4EF10551.2030209@gmail.com> I have been working through configuring sudo via IPA and ran into the following situation. There is a directive in the documentation to configure /etc/sssd/sssd.conf on the clients with something like the following: ldap_netgroup_search_base = cn=ng,cn=compat,dc=example,dc=com This is pulled from the docse here for reference: http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/example-configuring-sudo.html This is fine and causes no problems, however, when I mistakenly left it out on a few systems, sudo continued to function, so I am wondering what it is that this directive does? Does this get sssd into the loop to cache sudo rules for offline use? Any ideas? -Erinn From jzeleny at redhat.com Wed Dec 21 07:27:54 2011 From: jzeleny at redhat.com (Jan =?iso-8859-1?q?Zelen=FD?=) Date: Wed, 21 Dec 2011 08:27:54 +0100 Subject: [Freeipa-users] Sudo configuration question In-Reply-To: <4EF10551.2030209@gmail.com> References: <4EF10551.2030209@gmail.com> Message-ID: <201112210827.58480.jzeleny@redhat.com> > I have been working through configuring sudo via IPA and ran into the > following situation. > > There is a directive in the documentation to configure > /etc/sssd/sssd.conf on the clients with something like the following: > > ldap_netgroup_search_base = cn=ng,cn=compat,dc=example,dc=com > > > This is pulled from the docse here for reference: > http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_ > Management_Guide/example-configuring-sudo.html > > This is fine and causes no problems, however, when I mistakenly left it > out on a few systems, sudo continued to function, so I am wondering what > it is that this directive does? Does this get sssd into the loop to > cache sudo rules for offline use? Support for SUDO in SSSD has been added just about a week ago into master branch and is considered experimental right now. And as I understand it, the support in SUDO itself is still not entirely complete. So the simple answer is: hang on, the support is coming. Jan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From erinn.looneytriggs at gmail.com Wed Dec 21 08:28:46 2011 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Tue, 20 Dec 2011 23:28:46 -0900 Subject: [Freeipa-users] Sudo configuration question In-Reply-To: <201112210827.58480.jzeleny@redhat.com> References: <4EF10551.2030209@gmail.com> <201112210827.58480.jzeleny@redhat.com> Message-ID: <4EF198BE.1050800@gmail.com> On 12/20/2011 10:27 PM, Jan Zelen? wrote: >> I have been working through configuring sudo via IPA and ran into the >> following situation. >> >> There is a directive in the documentation to configure >> /etc/sssd/sssd.conf on the clients with something like the following: >> >> ldap_netgroup_search_base = cn=ng,cn=compat,dc=example,dc=com >> >> >> This is pulled from the docse here for reference: >> http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_ >> Management_Guide/example-configuring-sudo.html >> >> This is fine and causes no problems, however, when I mistakenly left it >> out on a few systems, sudo continued to function, so I am wondering what >> it is that this directive does? Does this get sssd into the loop to >> cache sudo rules for offline use? > Support for SUDO in SSSD has been added just about a week ago into master > branch and is considered experimental right now. And as I understand it, the > support in SUDO itself is still not entirely complete. So the simple answer > is: hang on, the support is coming. > > Jan Hmm, that is odd. I am not trying to be on the bleeding edge here, my sudo setup is taken directly from the RHEL 6.2 documentation concerning identity management. It would be very strange if RHEL was running such an experimental and bleeding edge thing in the base RHEL setup. So I guess to back up a bit here, IF sudo were working with SSSD as it will in the future would the aforementioned directive be the way to make it work. Understanding of course that for now it doesn't. -Erinn From jzeleny at redhat.com Wed Dec 21 09:22:45 2011 From: jzeleny at redhat.com (Jan =?iso-8859-1?q?Zelen=FD?=) Date: Wed, 21 Dec 2011 10:22:45 +0100 Subject: [Freeipa-users] Sudo configuration question In-Reply-To: <4EF198BE.1050800@gmail.com> References: <4EF10551.2030209@gmail.com> <201112210827.58480.jzeleny@redhat.com> <4EF198BE.1050800@gmail.com> Message-ID: <201112211022.48849.jzeleny@redhat.com> > On 12/20/2011 10:27 PM, Jan Zelen? wrote: > >> I have been working through configuring sudo via IPA and ran into the > >> following situation. > >> > >> There is a directive in the documentation to configure > >> /etc/sssd/sssd.conf on the clients with something like the following: > >> > >> ldap_netgroup_search_base = cn=ng,cn=compat,dc=example,dc=com > >> > >> > >> This is pulled from the docse here for reference: > >> http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Identi > >> ty_ Management_Guide/example-configuring-sudo.html > >> > >> This is fine and causes no problems, however, when I mistakenly left it > >> out on a few systems, sudo continued to function, so I am wondering what > >> it is that this directive does? Does this get sssd into the loop to > >> cache sudo rules for offline use? > > > > Support for SUDO in SSSD has been added just about a week ago into master > > branch and is considered experimental right now. And as I understand it, > > the support in SUDO itself is still not entirely complete. So the simple > > answer is: hang on, the support is coming. > > > > Jan > > Hmm, that is odd. I am not trying to be on the bleeding edge here, my > sudo setup is taken directly from the RHEL 6.2 documentation concerning > identity management. It would be very strange if RHEL was running such > an experimental and bleeding edge thing in the base RHEL setup. Of course, it's not even in Fedora yet. The documentation link you sent doesn't refer to SSSD but directly to sudo LDAP plugin which should be working as described there. > So I guess to back up a bit here, IF sudo were working with SSSD as it > will in the future would the aforementioned directive be the way to make > it work. Understanding of course that for now it doesn't. I assume you are referring to the SSSD search base directive. In that case the correct directive will be ldap_sudo_search_base. There are also 11 more directives which can be used to configure attribute names of LDAP sudo objects like ldap_sudorule_name, ldap_sudorule_command, etc. Some configuration will be also needed for the entire chain to work. For example sudo responder config section will have to be set up. But let's not skip ahead, I'm sure everything will be well documented by the time when the sudo chain is stable. I hope this answers your question. If you have any more questions please don't hesitate to ask. Thanks Jan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From erinn.looneytriggs at gmail.com Wed Dec 21 09:37:18 2011 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Wed, 21 Dec 2011 00:37:18 -0900 Subject: [Freeipa-users] Sudo configuration question In-Reply-To: <201112211022.48849.jzeleny@redhat.com> References: <4EF10551.2030209@gmail.com> <201112210827.58480.jzeleny@redhat.com> <4EF198BE.1050800@gmail.com> <201112211022.48849.jzeleny@redhat.com> Message-ID: <4EF1A8CE.8050106@gmail.com> On 12/21/2011 12:22 AM, Jan Zelen? wrote: >> On 12/20/2011 10:27 PM, Jan Zelen? wrote: >>>> I have been working through configuring sudo via IPA and ran into the >>>> following situation. >>>> >>>> There is a directive in the documentation to configure >>>> /etc/sssd/sssd.conf on the clients with something like the following: >>>> >>>> ldap_netgroup_search_base = cn=ng,cn=compat,dc=example,dc=com >>>> >>>> >>>> This is pulled from the docse here for reference: >>>> http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Identi >>>> ty_ Management_Guide/example-configuring-sudo.html >>>> >>>> This is fine and causes no problems, however, when I mistakenly left it >>>> out on a few systems, sudo continued to function, so I am wondering what >>>> it is that this directive does? Does this get sssd into the loop to >>>> cache sudo rules for offline use? >>> Support for SUDO in SSSD has been added just about a week ago into master >>> branch and is considered experimental right now. And as I understand it, >>> the support in SUDO itself is still not entirely complete. So the simple >>> answer is: hang on, the support is coming. >>> >>> Jan >> Hmm, that is odd. I am not trying to be on the bleeding edge here, my >> sudo setup is taken directly from the RHEL 6.2 documentation concerning >> identity management. It would be very strange if RHEL was running such >> an experimental and bleeding edge thing in the base RHEL setup. > Of course, it's not even in Fedora yet. The documentation link you sent > doesn't refer to SSSD but directly to sudo LDAP plugin which should be working > as described there. > >> So I guess to back up a bit here, IF sudo were working with SSSD as it >> will in the future would the aforementioned directive be the way to make >> it work. Understanding of course that for now it doesn't. > I assume you are referring to the SSSD search base directive. In that case the > correct directive will be ldap_sudo_search_base. There are also 11 more > directives which can be used to configure attribute names of LDAP sudo objects > like ldap_sudorule_name, ldap_sudorule_command, etc. > > Some configuration will be also needed for the entire chain to work. For > example sudo responder config section will have to be set up. But let's not > skip ahead, I'm sure everything will be well documented by the time when the > sudo chain is stable. > > I hope this answers your question. If you have any more questions please don't > hesitate to ask. > > Thanks > Jan Ok thanks. I think we are talking about two slightly different things here. I am just trying to figure out why that directive is supposed to be in sssd.conf (according to the docs) and why sudo continues to function with the IPA server if that directive is not in sssd.conf. -Erinn From jzeleny at redhat.com Wed Dec 21 09:50:17 2011 From: jzeleny at redhat.com (Jan =?iso-8859-1?q?Zelen=FD?=) Date: Wed, 21 Dec 2011 10:50:17 +0100 Subject: [Freeipa-users] Sudo configuration question In-Reply-To: <4EF1A8CE.8050106@gmail.com> References: <4EF10551.2030209@gmail.com> <201112211022.48849.jzeleny@redhat.com> <4EF1A8CE.8050106@gmail.com> Message-ID: <201112211050.21554.jzeleny@redhat.com> > On 12/21/2011 12:22 AM, Jan Zelen? wrote: > >> On 12/20/2011 10:27 PM, Jan Zelen? wrote: > >>>> I have been working through configuring sudo via IPA and ran into the > >>>> following situation. > >>>> > >>>> There is a directive in the documentation to configure > >>>> /etc/sssd/sssd.conf on the clients with something like the following: > >>>> > >>>> ldap_netgroup_search_base = cn=ng,cn=compat,dc=example,dc=com > >>>> > >>>> > >>>> This is pulled from the docse here for reference: > >>>> http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Iden > >>>> ti ty_ Management_Guide/example-configuring-sudo.html > >>>> > >>>> This is fine and causes no problems, however, when I mistakenly left > >>>> it out on a few systems, sudo continued to function, so I am > >>>> wondering what it is that this directive does? Does this get sssd > >>>> into the loop to cache sudo rules for offline use? > >>> > >>> Support for SUDO in SSSD has been added just about a week ago into > >>> master branch and is considered experimental right now. And as I > >>> understand it, the support in SUDO itself is still not entirely > >>> complete. So the simple answer is: hang on, the support is coming. > >>> > >>> Jan > >> > >> Hmm, that is odd. I am not trying to be on the bleeding edge here, my > >> sudo setup is taken directly from the RHEL 6.2 documentation concerning > >> identity management. It would be very strange if RHEL was running such > >> an experimental and bleeding edge thing in the base RHEL setup. > > > > Of course, it's not even in Fedora yet. The documentation link you sent > > doesn't refer to SSSD but directly to sudo LDAP plugin which should be > > working as described there. > > > >> So I guess to back up a bit here, IF sudo were working with SSSD as it > >> will in the future would the aforementioned directive be the way to make > >> it work. Understanding of course that for now it doesn't. > > > > I assume you are referring to the SSSD search base directive. In that > > case the correct directive will be ldap_sudo_search_base. There are also > > 11 more directives which can be used to configure attribute names of > > LDAP sudo objects like ldap_sudorule_name, ldap_sudorule_command, etc. > > > > Some configuration will be also needed for the entire chain to work. For > > example sudo responder config section will have to be set up. But let's > > not skip ahead, I'm sure everything will be well documented by the time > > when the sudo chain is stable. > > > > I hope this answers your question. If you have any more questions please > > don't hesitate to ask. > > > > Thanks > > Jan > > Ok thanks. I think we are talking about two slightly different things > here. I am just trying to figure out why that directive is supposed to > be in sssd.conf (according to the docs) and why sudo continues to > function with the IPA server if that directive is not in sssd.conf. It's there because sudo rules can be based, among other things, on netgroups and users' memberships in them. Therefore what happens with that configuration is that sudo LDAP plugin asks for sudo objects, but SSSD is used to retreive information about netgroups and maybe also about common users/groups (I'm not completely sure about that since I haven't check the documentation thoroughly). I hope the whole thing is a bit more clear to you now Thanks Jan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From jhrozek at redhat.com Wed Dec 21 10:39:13 2011 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 21 Dec 2011 11:39:13 +0100 Subject: [Freeipa-users] Sudo configuration question In-Reply-To: <4EF10551.2030209@gmail.com> References: <4EF10551.2030209@gmail.com> Message-ID: <20111221103913.GA2441@zeppelin.brq.redhat.com> On Tue, Dec 20, 2011 at 12:59:45PM -0900, Erinn Looney-Triggs wrote: > I have been working through configuring sudo via IPA and ran into the > following situation. > > There is a directive in the documentation to configure > /etc/sssd/sssd.conf on the clients with something like the following: > > ldap_netgroup_search_base = cn=ng,cn=compat,dc=example,dc=com > > > This is pulled from the docse here for reference: > http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/example-configuring-sudo.html > > This is fine and causes no problems, however, when I mistakenly left it > out on a few systems, sudo continued to function, so I am wondering what > it is that this directive does? Does this get sssd into the loop to > cache sudo rules for offline use? > > Any ideas? > > -Erinn > When sudo performs a lookup it does so in two iterations: 1) Try to find a matching rule using ALL, username or any of group names 2) if 1) does not match, search for all netgroups and look if user is a member of a netgroup with innetgr() so I assume that your sudo lookups matched with the first iteration and never actually needed to look up netgroup data. From sgallagh at redhat.com Wed Dec 21 13:37:44 2011 From: sgallagh at redhat.com (Stephen Gallagher) Date: Wed, 21 Dec 2011 08:37:44 -0500 Subject: [Freeipa-users] Sudo configuration question In-Reply-To: <4EF10551.2030209@gmail.com> References: <4EF10551.2030209@gmail.com> Message-ID: <1324474664.2278.48.camel@sgallagh520.sgallagh.bos.redhat.com> On Tue, 2011-12-20 at 12:59 -0900, Erinn Looney-Triggs wrote: > I have been working through configuring sudo via IPA and ran into the > following situation. > > There is a directive in the documentation to configure > /etc/sssd/sssd.conf on the clients with something like the following: > > ldap_netgroup_search_base = cn=ng,cn=compat,dc=example,dc=com > > > This is pulled from the docse here for reference: > http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/example-configuring-sudo.html > > This is fine and causes no problems, however, when I mistakenly left it > out on a few systems, sudo continued to function, so I am wondering what > it is that this directive does? Does this get sssd into the loop to > cache sudo rules for offline use? > > Any ideas? Sorry for the confusion in the other responses to this thread. The short answer is this: SUDO can use LDAP rules (as you clearly know). It does this with its own internal LDAP lookup (it doesn't currently go through SSSD to accomplish this). However, SUDO rules can specify netgroups as part of their restrictions on who can do what (usually these are used to limit functions to certain hosts). In order to do this, SSSD needs to be configured to look up netgroups properly so that SUDO can use the 'getnetgrent()' glibc command to locate the netgroups. The doc you are looking at is actually a bit out of date. It's no longer necessary to provide that option, because if it's unspecified, we set it automatically to cn=ng,cn=compat,dc=example,dc=com (using the appropriate base, of course). Jan's comments about upstream work were that we recently made changes to avoid needing to use the compat tree for netgroup lookups and can instead use FreeIPA's native, custom schema for netgroups. That's not terribly relevant to you, but it's a useful piece of information. So, in short, you don't need to set it, the doc is outdated. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From jzeleny at redhat.com Wed Dec 21 13:58:30 2011 From: jzeleny at redhat.com (Jan =?iso-8859-1?q?Zelen=FD?=) Date: Wed, 21 Dec 2011 14:58:30 +0100 Subject: [Freeipa-users] Sudo configuration question In-Reply-To: <1324474664.2278.48.camel@sgallagh520.sgallagh.bos.redhat.com> References: <4EF10551.2030209@gmail.com> <1324474664.2278.48.camel@sgallagh520.sgallagh.bos.redhat.com> Message-ID: <201112211458.34582.jzeleny@redhat.com> > On Tue, 2011-12-20 at 12:59 -0900, Erinn Looney-Triggs wrote: > > I have been working through configuring sudo via IPA and ran into the > > following situation. > > > > There is a directive in the documentation to configure > > /etc/sssd/sssd.conf on the clients with something like the following: > > > > ldap_netgroup_search_base = cn=ng,cn=compat,dc=example,dc=com > > > > > > This is pulled from the docse here for reference: > > http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Identit > > y_Management_Guide/example-configuring-sudo.html > > > > This is fine and causes no problems, however, when I mistakenly left it > > out on a few systems, sudo continued to function, so I am wondering what > > it is that this directive does? Does this get sssd into the loop to > > cache sudo rules for offline use? > > > > Any ideas? > > Sorry for the confusion in the other responses to this thread. The short > answer is this: SUDO can use LDAP rules (as you clearly know). It does > this with its own internal LDAP lookup (it doesn't currently go through > SSSD to accomplish this). > > However, SUDO rules can specify netgroups as part of their restrictions > on who can do what (usually these are used to limit functions to certain > hosts). In order to do this, SSSD needs to be configured to look up > netgroups properly so that SUDO can use the 'getnetgrent()' glibc > command to locate the netgroups. > > The doc you are looking at is actually a bit out of date. It's no longer > necessary to provide that option, because if it's unspecified, we set it > automatically to cn=ng,cn=compat,dc=example,dc=com (using the > appropriate base, of course). > > Jan's comments about upstream work were that we recently made changes to > avoid needing to use the compat tree for netgroup lookups and can > instead use FreeIPA's native, custom schema for netgroups. That's not > terribly relevant to you, but it's a useful piece of information. Actually no, my comment was a reaction to the original question if the SSSD can get into loop to cache sudo rules for offline use. > So, in short, you don't need to set it, the doc is outdated. Jan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From erinn.looneytriggs at gmail.com Wed Dec 21 18:08:55 2011 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Wed, 21 Dec 2011 09:08:55 -0900 Subject: [Freeipa-users] Sudo configuration question In-Reply-To: <1324474664.2278.48.camel@sgallagh520.sgallagh.bos.redhat.com> References: <4EF10551.2030209@gmail.com> <1324474664.2278.48.camel@sgallagh520.sgallagh.bos.redhat.com> Message-ID: <4EF220B7.9090108@gmail.com> On 12/21/2011 04:37 AM, Stephen Gallagher wrote: > On Tue, 2011-12-20 at 12:59 -0900, Erinn Looney-Triggs wrote: >> I have been working through configuring sudo via IPA and ran into the >> following situation. >> >> There is a directive in the documentation to configure >> /etc/sssd/sssd.conf on the clients with something like the following: >> >> ldap_netgroup_search_base = cn=ng,cn=compat,dc=example,dc=com >> >> >> This is pulled from the docse here for reference: >> http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/example-configuring-sudo.html >> >> This is fine and causes no problems, however, when I mistakenly left it >> out on a few systems, sudo continued to function, so I am wondering what >> it is that this directive does? Does this get sssd into the loop to >> cache sudo rules for offline use? >> >> Any ideas? > Sorry for the confusion in the other responses to this thread. The short > answer is this: SUDO can use LDAP rules (as you clearly know). It does > this with its own internal LDAP lookup (it doesn't currently go through > SSSD to accomplish this). > > However, SUDO rules can specify netgroups as part of their restrictions > on who can do what (usually these are used to limit functions to certain > hosts). In order to do this, SSSD needs to be configured to look up > netgroups properly so that SUDO can use the 'getnetgrent()' glibc > command to locate the netgroups. > > The doc you are looking at is actually a bit out of date. It's no longer > necessary to provide that option, because if it's unspecified, we set it > automatically to cn=ng,cn=compat,dc=example,dc=com (using the > appropriate base, of course). > > Jan's comments about upstream work were that we recently made changes to > avoid needing to use the compat tree for netgroup lookups and can > instead use FreeIPA's native, custom schema for netgroups. That's not > terribly relevant to you, but it's a useful piece of information. > > So, in short, you don't need to set it, the doc is outdated. > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users Ok thanks, that makes sense. One final question here, is there a way to verify that sssd is in fact setting this properly? Not that I doubt you of course, it is just a matter of so many versions of sssd in so many places that it would be good to verify that it works automagically on RHEL 5, 6, and whatever else, say Ubuntu etc. -Erinn -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgallagh at redhat.com Wed Dec 21 18:14:58 2011 From: sgallagh at redhat.com (Stephen Gallagher) Date: Wed, 21 Dec 2011 13:14:58 -0500 Subject: [Freeipa-users] Sudo configuration question In-Reply-To: <4EF220B7.9090108@gmail.com> References: <4EF10551.2030209@gmail.com> <1324474664.2278.48.camel@sgallagh520.sgallagh.bos.redhat.com> <4EF220B7.9090108@gmail.com> Message-ID: <1324491298.2278.52.camel@sgallagh520.sgallagh.bos.redhat.com> On Wed, 2011-12-21 at 09:08 -0900, Erinn Looney-Triggs wrote: > On 12/21/2011 04:37 AM, Stephen Gallagher wrote: > > On Tue, 2011-12-20 at 12:59 -0900, Erinn Looney-Triggs wrote: > > > I have been working through configuring sudo via IPA and ran into the > > > following situation. > > > > > > There is a directive in the documentation to configure > > > /etc/sssd/sssd.conf on the clients with something like the following: > > > > > > ldap_netgroup_search_base = cn=ng,cn=compat,dc=example,dc=com > > > > > > > > > This is pulled from the docse here for reference: > > > http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/example-configuring-sudo.html > > > > > > This is fine and causes no problems, however, when I mistakenly left it > > > out on a few systems, sudo continued to function, so I am wondering what > > > it is that this directive does? Does this get sssd into the loop to > > > cache sudo rules for offline use? > > > > > > Any ideas? > > Sorry for the confusion in the other responses to this thread. The short > > answer is this: SUDO can use LDAP rules (as you clearly know). It does > > this with its own internal LDAP lookup (it doesn't currently go through > > SSSD to accomplish this). > > > > However, SUDO rules can specify netgroups as part of their restrictions > > on who can do what (usually these are used to limit functions to certain > > hosts). In order to do this, SSSD needs to be configured to look up > > netgroups properly so that SUDO can use the 'getnetgrent()' glibc > > command to locate the netgroups. > > > > The doc you are looking at is actually a bit out of date. It's no longer > > necessary to provide that option, because if it's unspecified, we set it > > automatically to cn=ng,cn=compat,dc=example,dc=com (using the > > appropriate base, of course). > > > > Jan's comments about upstream work were that we recently made changes to > > avoid needing to use the compat tree for netgroup lookups and can > > instead use FreeIPA's native, custom schema for netgroups. That's not > > terribly relevant to you, but it's a useful piece of information. > > > > So, in short, you don't need to set it, the doc is outdated. > > > > > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-users > > Ok thanks, that makes sense. One final question here, is there a way > to verify that sssd is in fact setting this properly? Not that I doubt > you of course, it is just a matter of so many versions of sssd in so > many places that it would be good to verify that it works > automagically on RHEL 5, 6, and whatever else, say Ubuntu etc. > > -Erinn > You can set 'debug_level = 6' in [domain/] of sssd.conf and restart. If you look in the sssd_.log, you should see a line setting the ldap_netgroup_search_base option. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From erinn.looneytriggs at gmail.com Wed Dec 21 18:40:07 2011 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Wed, 21 Dec 2011 09:40:07 -0900 Subject: [Freeipa-users] Sudo configuration question In-Reply-To: <1324491298.2278.52.camel@sgallagh520.sgallagh.bos.redhat.com> References: <4EF10551.2030209@gmail.com> <1324474664.2278.48.camel@sgallagh520.sgallagh.bos.redhat.com> <4EF220B7.9090108@gmail.com> <1324491298.2278.52.camel@sgallagh520.sgallagh.bos.redhat.com> Message-ID: <4EF22807.3030007@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/21/2011 09:14 AM, Stephen Gallagher wrote: > On Wed, 2011-12-21 at 09:08 -0900, Erinn Looney-Triggs wrote: >> On 12/21/2011 04:37 AM, Stephen Gallagher wrote: >>> On Tue, 2011-12-20 at 12:59 -0900, Erinn Looney-Triggs wrote: >>>> I have been working through configuring sudo via IPA and ran into the >>>> following situation. >>>> >>>> There is a directive in the documentation to configure >>>> /etc/sssd/sssd.conf on the clients with something like the following: >>>> >>>> ldap_netgroup_search_base = cn=ng,cn=compat,dc=example,dc=com >>>> >>>> >>>> This is pulled from the docse here for reference: >>>> http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/example-configuring-sudo.html >>>> >>>> This is fine and causes no problems, however, when I mistakenly left it >>>> out on a few systems, sudo continued to function, so I am wondering what >>>> it is that this directive does? Does this get sssd into the loop to >>>> cache sudo rules for offline use? >>>> >>>> Any ideas? >>> Sorry for the confusion in the other responses to this thread. The short >>> answer is this: SUDO can use LDAP rules (as you clearly know). It does >>> this with its own internal LDAP lookup (it doesn't currently go through >>> SSSD to accomplish this). >>> >>> However, SUDO rules can specify netgroups as part of their restrictions >>> on who can do what (usually these are used to limit functions to certain >>> hosts). In order to do this, SSSD needs to be configured to look up >>> netgroups properly so that SUDO can use the 'getnetgrent()' glibc >>> command to locate the netgroups. >>> >>> The doc you are looking at is actually a bit out of date. It's no longer >>> necessary to provide that option, because if it's unspecified, we set it >>> automatically to cn=ng,cn=compat,dc=example,dc=com (using the >>> appropriate base, of course). >>> >>> Jan's comments about upstream work were that we recently made changes to >>> avoid needing to use the compat tree for netgroup lookups and can >>> instead use FreeIPA's native, custom schema for netgroups. That's not >>> terribly relevant to you, but it's a useful piece of information. >>> >>> So, in short, you don't need to set it, the doc is outdated. >>> >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> Ok thanks, that makes sense. One final question here, is there a way >> to verify that sssd is in fact setting this properly? Not that I doubt >> you of course, it is just a matter of so many versions of sssd in so >> many places that it would be good to verify that it works >> automagically on RHEL 5, 6, and whatever else, say Ubuntu etc. >> >> -Erinn >> > > You can set 'debug_level = 6' in [domain/] of sssd.conf and > restart. If you look in the sssd_.log, you should see a line > setting the ldap_netgroup_search_base option. Great, thank you so much for your time. I really appreciate it. - -Erinn -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJO8igHAAoJENetaK3v/E7PHTEH/iFlfavkBEholqDzym2G4PPU 8d8pmL0LLQqnssxFXShMICQqzjnIb+f/TGiBAIBvFaKUzT7UAO9QD5LI42UuoZIw Npbh2rBTAXQ0nTXRHkA4/VwtCVHWbZFenbfztyR87MrZsv+cNgZQ0PFA2shgu3pb VzAPx7ow7jPpFrAk/NC1bCJv2rJQZHMWS15zfgV9d0cS1kPfXeAJqQge12zEaFLQ 6EaaavlQulv8KubAJxMa3BL/JTy2cgnHYC32l1zA/RUGBXglceRdAydReoQuXGYm IcEbhqtpS4PEPlwYoI7Ir21YtUMFomqdpjUSvTOWnC62a7EiI6qyns9DcPgN/PI= =8wy+ -----END PGP SIGNATURE----- From danieljamesscott at gmail.com Wed Dec 21 19:10:43 2011 From: danieljamesscott at gmail.com (Dan Scott) Date: Wed, 21 Dec 2011 14:10:43 -0500 Subject: [Freeipa-users] ns-slapd hang/segfault In-Reply-To: References: <4EEA1908.2040801@redhat.com> <4EEA2589.5060400@redhat.com> <1324322097.28622.98.camel@willson.li.ssimo.org> Message-ID: On Mon, Dec 19, 2011 at 15:26, Dan Scott wrote: > On Mon, Dec 19, 2011 at 14:14, Simo Sorce wrote: >> On Mon, 2011-12-19 at 11:01 -0500, Dan Scott wrote: >>> On Thu, Dec 15, 2011 at 11:51, Rich Megginson wrote: >>> > On 12/15/2011 09:48 AM, Dan Scott wrote: >>> >> >>> >> Hi, >>> >> >>> >> On Thu, Dec 15, 2011 at 10:58, Rich Megginson ?wrote: >>> >>> >>> >>> On 12/15/2011 08:41 AM, Dan Scott wrote: >>> >>>> >>> >>>> Hi, >>> >>>> >>> >>>> On my Fedora 15 FreeIPA server, I'm having some problems with >>> >>>> stability. The server appears to 'hang' and stops responding to LDAP >>> >>>> lookups. When I restart the dirsrv service, I get: >>> >>>> >>> >>>> Dec 15 09:40:02 ohm kernel: [254566.011404] ns-slapd[28910]: segfault >>> >>>> at 17d ip 00007f00dbc0208c sp 00007fff929b7848 error 4 in >>> >>>> libc-2.14.so[7f00dbb87000+18f000] >>> >>>> >>> >>>> and the /var/log/dirsrv/slapd-EXAMPLE-COM/errors contains >>> >>>> >>> >>>> [15/Dec/2011:09:47:35 -0500] set_krb5_creds - Could not get initial >>> >>>> credentials for principal [ldap/example.com at EXAMPLE.COM] in keytab >>> >>>> [WRFILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC >>> >>>> for requested realm) >>> >>>> [15/Dec/2011:09:47:35 -0500] slapd_ldap_sasl_interactive_bind - Error: >>> >>>> could not perform interactive bind for id [] mech [GSSAPI]: error -2 >>> >>>> (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified >>> >>>> GSS failure. ?Minor code may provide more information (Credentials >>> >>>> cache file '/tmp/krb5cc_496' not found)) >>> >>>> >>> >>>> This is happening very frequently, I'm having to restart the dirsrv >>> >>>> process once an hour, otherwise people start complaining. >>> >>>> >>> >>>> I experienced similar problems with FreeIPA 1, when I was using Fedora >>> >>>> 14 and earlier, and had to regularly (also once per hour) restart the >>> >>>> dirsrv process. Could this be related? >>> >>>> >>> >>>> I also noticed this: >>> >>>> https://bugzilla.redhat.com/show_bug.cgi?id=730387 >>> >>>> >>> >>>> There are updates in 'updates-testing' which I believe fix the above >>> >>>> issue, but I'm reluctant to install from a testing repo on my >>> >>>> production server, can anyone report any feedback on this? >>> >>> >>> >>> The above bug does not cause a segfault. >>> >>> What version of 389-ds-base are you using? >>> >> >>> >> [root at ohm ~]# rpm -qa|grep 389 >>> >> 389-ds-base-libs-1.2.10-0.4.a4.fc15.x86_64 >>> >> 389-ds-base-1.2.10-0.4.a4.fc15.x86_64 >>> >> [root at ohm ~]# >>> > >>> > a4 is alpha software. ?Not sure how that got released to stable. >>> > >>> >>> Please enable the collection of core dumps so we can debug the crash - >>> >>> see >>> >>> http://directory.fedoraproject.org/wiki/FAQ#Debugging_Crashes >>> >> >>> >> OK. I think there is a small typo in the instructions: >>> >> >>> >> 'debuginfo-install 389-ds-base-debuginfo' should be 'debuginfo-install >>> >> 389-ds-base' >>> > >>> > Thanks. ?Fixed. >>> > >>> >> I managed to get the core dump (attached - so I only sent this message >>> >> to you, not the list as well), but it doesn't contain much >>> >> information. >>> > >>> > This is https://bugzilla.redhat.com/show_bug.cgi?id=755725 >>> > >>> > Will be fixed in 1.2.10.a6 >>> > >>> > But this still doesn't explain your kerberos errors. >>> >>> An additional problem is also occurring. I've been finding that the: >>> >>> /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif >>> >>> file is empty and prevents dirsrv from starting. I can restore it from >>> dse.ldif.bak or dse.ldif.startOK, but this may be related to the LDAP >>> problems that I'm having? >> >> This is an upgrade time problem, it should be fixed in latest packages. >> Did you recently upgrade freeipa packages if so from what version to >> what version ? > > The 0 length file doesn't appear related to upgrades. Possibly it only > happens on the first service restart after an upgrade? > > It's happened at least 4 times since the last freeipa package upgrade > on 4th November, so it seems to be happening too regularly to be the > result of an upgrade. > > [root at curie ~]# grep freeipa /var/log/yum.log > Sep 06 16:56:51 Installed: freeipa-python-2.0.1-2.fc15.x86_64 > Sep 06 17:00:13 Installed: freeipa-client-2.0.1-2.fc15.x86_64 > Sep 06 17:00:14 Installed: freeipa-admintools-2.0.1-2.fc15.x86_64 > Sep 06 17:01:52 Installed: freeipa-server-selinux-2.0.1-2.fc15.x86_64 > Sep 06 17:01:56 Installed: freeipa-server-2.0.1-2.fc15.x86_64 > Sep 08 11:23:35 Updated: freeipa-python-2.1.0-1.fc15.x86_64 > Sep 08 11:23:41 Updated: freeipa-client-2.1.0-1.fc15.x86_64 > Sep 08 11:23:41 Updated: freeipa-admintools-2.1.0-1.fc15.x86_64 > Sep 08 11:25:00 Updated: freeipa-server-selinux-2.1.0-1.fc15.x86_64 > Sep 08 11:26:06 Updated: freeipa-server-2.1.0-1.fc15.x86_64 > Nov 04 15:46:43 Updated: freeipa-python-2.1.3-2.fc15.x86_64 > Nov 04 15:52:48 Updated: freeipa-client-2.1.3-2.fc15.x86_64 > Nov 04 15:52:48 Updated: freeipa-admintools-2.1.3-2.fc15.x86_64 > Nov 04 15:54:47 Updated: freeipa-server-2.1.3-2.fc15.x86_64 > Nov 04 15:56:02 Updated: freeipa-server-selinux-2.1.3-2.fc15.x86_64 > > Dan I'm still having fairly serious problems. I keep getting: ipa: ERROR: Kerberos error: Kerberos error: ('Unspecified GSS failure. Minor code may provide more information', 851968)/('Cannot contact any KDC for requested realm', -1765328228)/ Whenever I try and run IPA commands on either of my servers, or a client with the admin tools installed. The server logs contain: slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error -1 (Can't contact LDAP server) ((null)) slapi_ldap_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error -1 (Can't contact LDAP server) And I can't create new replicas because they fail with: 2011-12-21 11:25:58,356 DEBUG Failed to start replication File "/usr/sbin/ipa-replica-install", line 484, in main() File "/usr/sbin/ipa-replica-install", line 435, in main ds = install_replica_ds(config) File "/usr/sbin/ipa-replica-install", line 137, in install_replica_ds pkcs12_info) File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line 284, in create_replica self.start_creation("Configuring directory server", 60) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 248, in start_creation method() File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line 297, in __setup_replica r_bindpw=self.dm_password) File "/usr/lib/python2.7/site-packages/ipaserver/install/replication.py", line 694, in setup_replication raise RuntimeError("Failed to start replication") Can someone help me? This is getting fairly serious because I can't create/modify anything and I'm worried that there will be problems with existing users soon as well. Thanks, Dan From simo at redhat.com Wed Dec 21 21:43:02 2011 From: simo at redhat.com (Simo Sorce) Date: Wed, 21 Dec 2011 16:43:02 -0500 Subject: [Freeipa-users] ns-slapd hang/segfault In-Reply-To: References: <4EEA1908.2040801@redhat.com> <4EEA2589.5060400@redhat.com> <1324322097.28622.98.camel@willson.li.ssimo.org> Message-ID: <1324503782.28622.166.camel@willson.li.ssimo.org> On Wed, 2011-12-21 at 15:33 -0500, Dan Scott wrote: > On Wed, Dec 21, 2011 at 14:10, Dan Scott wrote: > > On Mon, Dec 19, 2011 at 15:26, Dan Scott wrote: > >> On Mon, Dec 19, 2011 at 14:14, Simo Sorce wrote: > >>> On Mon, 2011-12-19 at 11:01 -0500, Dan Scott wrote: > >>>> On Thu, Dec 15, 2011 at 11:51, Rich Megginson wrote: > >>>> > On 12/15/2011 09:48 AM, Dan Scott wrote: > >>>> >> > >>>> >> Hi, > >>>> >> > >>>> >> On Thu, Dec 15, 2011 at 10:58, Rich Megginson wrote: > >>>> >>> > >>>> >>> On 12/15/2011 08:41 AM, Dan Scott wrote: > >>>> >>>> > >>>> >>>> Hi, > >>>> >>>> > >>>> >>>> On my Fedora 15 FreeIPA server, I'm having some problems with > >>>> >>>> stability. The server appears to 'hang' and stops responding to LDAP > >>>> >>>> lookups. When I restart the dirsrv service, I get: > >>>> >>>> > >>>> >>>> Dec 15 09:40:02 ohm kernel: [254566.011404] ns-slapd[28910]: segfault > >>>> >>>> at 17d ip 00007f00dbc0208c sp 00007fff929b7848 error 4 in > >>>> >>>> libc-2.14.so[7f00dbb87000+18f000] > >>>> >>>> > >>>> >>>> and the /var/log/dirsrv/slapd-EXAMPLE-COM/errors contains > >>>> >>>> > >>>> >>>> [15/Dec/2011:09:47:35 -0500] set_krb5_creds - Could not get initial > >>>> >>>> credentials for principal [ldap/example.com at EXAMPLE.COM] in keytab > >>>> >>>> [WRFILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC > >>>> >>>> for requested realm) > >>>> >>>> [15/Dec/2011:09:47:35 -0500] slapd_ldap_sasl_interactive_bind - Error: > >>>> >>>> could not perform interactive bind for id [] mech [GSSAPI]: error -2 > >>>> >>>> (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified > >>>> >>>> GSS failure. Minor code may provide more information (Credentials > >>>> >>>> cache file '/tmp/krb5cc_496' not found)) > >>>> >>>> > >>>> >>>> This is happening very frequently, I'm having to restart the dirsrv > >>>> >>>> process once an hour, otherwise people start complaining. > >>>> >>>> > >>>> >>>> I experienced similar problems with FreeIPA 1, when I was using Fedora > >>>> >>>> 14 and earlier, and had to regularly (also once per hour) restart the > >>>> >>>> dirsrv process. Could this be related? > >>>> >>>> > >>>> >>>> I also noticed this: > >>>> >>>> https://bugzilla.redhat.com/show_bug.cgi?id=730387 > >>>> >>>> > >>>> >>>> There are updates in 'updates-testing' which I believe fix the above > >>>> >>>> issue, but I'm reluctant to install from a testing repo on my > >>>> >>>> production server, can anyone report any feedback on this? > >>>> >>> > >>>> >>> The above bug does not cause a segfault. > >>>> >>> What version of 389-ds-base are you using? > >>>> >> > >>>> >> [root at ohm ~]# rpm -qa|grep 389 > >>>> >> 389-ds-base-libs-1.2.10-0.4.a4.fc15.x86_64 > >>>> >> 389-ds-base-1.2.10-0.4.a4.fc15.x86_64 > >>>> >> [root at ohm ~]# > >>>> > > >>>> > a4 is alpha software. Not sure how that got released to stable. > >>>> > > >>>> >>> Please enable the collection of core dumps so we can debug the crash - > >>>> >>> see > >>>> >>> http://directory.fedoraproject.org/wiki/FAQ#Debugging_Crashes > >>>> >> > >>>> >> OK. I think there is a small typo in the instructions: > >>>> >> > >>>> >> 'debuginfo-install 389-ds-base-debuginfo' should be 'debuginfo-install > >>>> >> 389-ds-base' > >>>> > > >>>> > Thanks. Fixed. > >>>> > > >>>> >> I managed to get the core dump (attached - so I only sent this message > >>>> >> to you, not the list as well), but it doesn't contain much > >>>> >> information. > >>>> > > >>>> > This is https://bugzilla.redhat.com/show_bug.cgi?id=755725 > >>>> > > >>>> > Will be fixed in 1.2.10.a6 > >>>> > > >>>> > But this still doesn't explain your kerberos errors. > >>>> > >>>> An additional problem is also occurring. I've been finding that the: > >>>> > >>>> /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif > >>>> > >>>> file is empty and prevents dirsrv from starting. I can restore it from > >>>> dse.ldif.bak or dse.ldif.startOK, but this may be related to the LDAP > >>>> problems that I'm having? > >>> > >>> This is an upgrade time problem, it should be fixed in latest packages. > >>> Did you recently upgrade freeipa packages if so from what version to > >>> what version ? > >> > >> The 0 length file doesn't appear related to upgrades. Possibly it only > >> happens on the first service restart after an upgrade? > >> > >> It's happened at least 4 times since the last freeipa package upgrade > >> on 4th November, so it seems to be happening too regularly to be the > >> result of an upgrade. > >> > >> [root at curie ~]# grep freeipa /var/log/yum.log > >> Sep 06 16:56:51 Installed: freeipa-python-2.0.1-2.fc15.x86_64 > >> Sep 06 17:00:13 Installed: freeipa-client-2.0.1-2.fc15.x86_64 > >> Sep 06 17:00:14 Installed: freeipa-admintools-2.0.1-2.fc15.x86_64 > >> Sep 06 17:01:52 Installed: freeipa-server-selinux-2.0.1-2.fc15.x86_64 > >> Sep 06 17:01:56 Installed: freeipa-server-2.0.1-2.fc15.x86_64 > >> Sep 08 11:23:35 Updated: freeipa-python-2.1.0-1.fc15.x86_64 > >> Sep 08 11:23:41 Updated: freeipa-client-2.1.0-1.fc15.x86_64 > >> Sep 08 11:23:41 Updated: freeipa-admintools-2.1.0-1.fc15.x86_64 > >> Sep 08 11:25:00 Updated: freeipa-server-selinux-2.1.0-1.fc15.x86_64 > >> Sep 08 11:26:06 Updated: freeipa-server-2.1.0-1.fc15.x86_64 > >> Nov 04 15:46:43 Updated: freeipa-python-2.1.3-2.fc15.x86_64 > >> Nov 04 15:52:48 Updated: freeipa-client-2.1.3-2.fc15.x86_64 > >> Nov 04 15:52:48 Updated: freeipa-admintools-2.1.3-2.fc15.x86_64 > >> Nov 04 15:54:47 Updated: freeipa-server-2.1.3-2.fc15.x86_64 > >> Nov 04 15:56:02 Updated: freeipa-server-selinux-2.1.3-2.fc15.x86_64 > >> > >> Dan > > > > I'm still having fairly serious problems. I keep getting: > > > > ipa: ERROR: Kerberos error: Kerberos error: ('Unspecified GSS failure. > > Minor code may provide more information', 851968)/('Cannot contact > > any KDC for requested realm', -1765328228)/ > > > > Whenever I try and run IPA commands on either of my servers, or a > > client with the admin tools installed. > > > > The server logs contain: > > > > slapd_ldap_sasl_interactive_bind - Error: could not perform > > interactive bind for id [] mech [GSSAPI]: error -1 (Can't contact LDAP > > server) ((null)) > > slapi_ldap_bind - Error: could not perform interactive bind for id [] > > mech [GSSAPI]: error -1 (Can't contact LDAP server) > > > > And I can't create new replicas because they fail with: > > > > 2011-12-21 11:25:58,356 DEBUG Failed to start replication > > File "/usr/sbin/ipa-replica-install", line 484, in > > main() > > > > File "/usr/sbin/ipa-replica-install", line 435, in main > > ds = install_replica_ds(config) > > > > File "/usr/sbin/ipa-replica-install", line 137, in install_replica_ds > > pkcs12_info) > > > > File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", > > line 284, in create_replica > > self.start_creation("Configuring directory server", 60) > > > > File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", > > line 248, in start_creation > > method() > > > > File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", > > line 297, in __setup_replica > > r_bindpw=self.dm_password) > > > > File "/usr/lib/python2.7/site-packages/ipaserver/install/replication.py", > > line 694, in setup_replication > > raise RuntimeError("Failed to start replication") > > > > Can someone help me? This is getting fairly serious because I can't > > create/modify anything and I'm worried that there will be problems > > with existing users soon as well. > > OK, I think I'm narrowing in on this. It looks like the replication > agreement is broken and the servers have got out of sync: odd > On the 'master' server (which contains the PKI dirsrv process): The PKI instance uses a diffeent set of replication agreementsso you can't see those agreements with ipa-replica-manage which handles only the IPA Idm instance. > [root at fileserver1 ~]# ipa-replica-manage list > fileserver1.example.com: master > > On the other server: > > [root at fileserver2 ~]# ipa-replica-manage list > fileserver1.example.com: master > fileserver2.example.com: master strange indeed. > When I try and add the missing replication: > > [root at fileserver1 ~]# ipa-replica-manage connect fileserver2.example.com > unexpected error: list index out of range > > Do I need to delete the replication from fileserver2? You can't remove a replication agreement if it is the only agreement you have. This is to avoid split-brain situations. Not sure how to handle a disappeared agreement though it's theorethically not possible unless you 'inadvertently' ran ipa-replica-manage --force del fileserver2 on fileserver1 ... Can you look into cn=config and see if you have references toi fileserver2 ? Maybe it is just a bug in displaying actually active replicas. > As an aside, there are some errors in the documentation for > ipa-replica-manage. Some of the examples have 'ipa replica-manage' > instead of 'ipa-replica-manage' (space instead of '-'). Thanks will file a doc bug. Simo. -- Simo Sorce * Red Hat, Inc * New York From danieljamesscott at gmail.com Wed Dec 21 22:39:26 2011 From: danieljamesscott at gmail.com (Dan Scott) Date: Wed, 21 Dec 2011 17:39:26 -0500 Subject: [Freeipa-users] ns-slapd hang/segfault In-Reply-To: <1324503782.28622.166.camel@willson.li.ssimo.org> References: <4EEA1908.2040801@redhat.com> <4EEA2589.5060400@redhat.com> <1324322097.28622.98.camel@willson.li.ssimo.org> <1324503782.28622.166.camel@willson.li.ssimo.org> Message-ID: On Wed, Dec 21, 2011 at 16:43, Simo Sorce wrote: > On Wed, 2011-12-21 at 15:33 -0500, Dan Scott wrote: >> On Wed, Dec 21, 2011 at 14:10, Dan Scott wrote: >> > On Mon, Dec 19, 2011 at 15:26, Dan Scott wrote: >> >> On Mon, Dec 19, 2011 at 14:14, Simo Sorce wrote: >> >>> On Mon, 2011-12-19 at 11:01 -0500, Dan Scott wrote: >> >>>> On Thu, Dec 15, 2011 at 11:51, Rich Megginson wrote: >> >>>> > On 12/15/2011 09:48 AM, Dan Scott wrote: >> >>>> >> >> >>>> >> Hi, >> >>>> >> >> >>>> >> On Thu, Dec 15, 2011 at 10:58, Rich Megginson ?wrote: >> >>>> >>> >> >>>> >>> On 12/15/2011 08:41 AM, Dan Scott wrote: >> >>>> >>>> >> >>>> >>>> Hi, >> >>>> >>>> >> >>>> >>>> On my Fedora 15 FreeIPA server, I'm having some problems with >> >>>> >>>> stability. The server appears to 'hang' and stops responding to LDAP >> >>>> >>>> lookups. When I restart the dirsrv service, I get: >> >>>> >>>> >> >>>> >>>> Dec 15 09:40:02 ohm kernel: [254566.011404] ns-slapd[28910]: segfault >> >>>> >>>> at 17d ip 00007f00dbc0208c sp 00007fff929b7848 error 4 in >> >>>> >>>> libc-2.14.so[7f00dbb87000+18f000] >> >>>> >>>> >> >>>> >>>> and the /var/log/dirsrv/slapd-EXAMPLE-COM/errors contains >> >>>> >>>> >> >>>> >>>> [15/Dec/2011:09:47:35 -0500] set_krb5_creds - Could not get initial >> >>>> >>>> credentials for principal [ldap/example.com at EXAMPLE.COM] in keytab >> >>>> >>>> [WRFILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC >> >>>> >>>> for requested realm) >> >>>> >>>> [15/Dec/2011:09:47:35 -0500] slapd_ldap_sasl_interactive_bind - Error: >> >>>> >>>> could not perform interactive bind for id [] mech [GSSAPI]: error -2 >> >>>> >>>> (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified >> >>>> >>>> GSS failure. ?Minor code may provide more information (Credentials >> >>>> >>>> cache file '/tmp/krb5cc_496' not found)) >> >>>> >>>> >> >>>> >>>> This is happening very frequently, I'm having to restart the dirsrv >> >>>> >>>> process once an hour, otherwise people start complaining. >> >>>> >>>> >> >>>> >>>> I experienced similar problems with FreeIPA 1, when I was using Fedora >> >>>> >>>> 14 and earlier, and had to regularly (also once per hour) restart the >> >>>> >>>> dirsrv process. Could this be related? >> >>>> >>>> >> >>>> >>>> I also noticed this: >> >>>> >>>> https://bugzilla.redhat.com/show_bug.cgi?id=730387 >> >>>> >>>> >> >>>> >>>> There are updates in 'updates-testing' which I believe fix the above >> >>>> >>>> issue, but I'm reluctant to install from a testing repo on my >> >>>> >>>> production server, can anyone report any feedback on this? >> >>>> >>> >> >>>> >>> The above bug does not cause a segfault. >> >>>> >>> What version of 389-ds-base are you using? >> >>>> >> >> >>>> >> [root at ohm ~]# rpm -qa|grep 389 >> >>>> >> 389-ds-base-libs-1.2.10-0.4.a4.fc15.x86_64 >> >>>> >> 389-ds-base-1.2.10-0.4.a4.fc15.x86_64 >> >>>> >> [root at ohm ~]# >> >>>> > >> >>>> > a4 is alpha software. ?Not sure how that got released to stable. >> >>>> > >> >>>> >>> Please enable the collection of core dumps so we can debug the crash - >> >>>> >>> see >> >>>> >>> http://directory.fedoraproject.org/wiki/FAQ#Debugging_Crashes >> >>>> >> >> >>>> >> OK. I think there is a small typo in the instructions: >> >>>> >> >> >>>> >> 'debuginfo-install 389-ds-base-debuginfo' should be 'debuginfo-install >> >>>> >> 389-ds-base' >> >>>> > >> >>>> > Thanks. ?Fixed. >> >>>> > >> >>>> >> I managed to get the core dump (attached - so I only sent this message >> >>>> >> to you, not the list as well), but it doesn't contain much >> >>>> >> information. >> >>>> > >> >>>> > This is https://bugzilla.redhat.com/show_bug.cgi?id=755725 >> >>>> > >> >>>> > Will be fixed in 1.2.10.a6 >> >>>> > >> >>>> > But this still doesn't explain your kerberos errors. >> >>>> >> >>>> An additional problem is also occurring. I've been finding that the: >> >>>> >> >>>> /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif >> >>>> >> >>>> file is empty and prevents dirsrv from starting. I can restore it from >> >>>> dse.ldif.bak or dse.ldif.startOK, but this may be related to the LDAP >> >>>> problems that I'm having? >> >>> >> >>> This is an upgrade time problem, it should be fixed in latest packages. >> >>> Did you recently upgrade freeipa packages if so from what version to >> >>> what version ? >> >> >> >> The 0 length file doesn't appear related to upgrades. Possibly it only >> >> happens on the first service restart after an upgrade? >> >> >> >> It's happened at least 4 times since the last freeipa package upgrade >> >> on 4th November, so it seems to be happening too regularly to be the >> >> result of an upgrade. >> >> >> >> [root at curie ~]# grep freeipa /var/log/yum.log >> >> Sep 06 16:56:51 Installed: freeipa-python-2.0.1-2.fc15.x86_64 >> >> Sep 06 17:00:13 Installed: freeipa-client-2.0.1-2.fc15.x86_64 >> >> Sep 06 17:00:14 Installed: freeipa-admintools-2.0.1-2.fc15.x86_64 >> >> Sep 06 17:01:52 Installed: freeipa-server-selinux-2.0.1-2.fc15.x86_64 >> >> Sep 06 17:01:56 Installed: freeipa-server-2.0.1-2.fc15.x86_64 >> >> Sep 08 11:23:35 Updated: freeipa-python-2.1.0-1.fc15.x86_64 >> >> Sep 08 11:23:41 Updated: freeipa-client-2.1.0-1.fc15.x86_64 >> >> Sep 08 11:23:41 Updated: freeipa-admintools-2.1.0-1.fc15.x86_64 >> >> Sep 08 11:25:00 Updated: freeipa-server-selinux-2.1.0-1.fc15.x86_64 >> >> Sep 08 11:26:06 Updated: freeipa-server-2.1.0-1.fc15.x86_64 >> >> Nov 04 15:46:43 Updated: freeipa-python-2.1.3-2.fc15.x86_64 >> >> Nov 04 15:52:48 Updated: freeipa-client-2.1.3-2.fc15.x86_64 >> >> Nov 04 15:52:48 Updated: freeipa-admintools-2.1.3-2.fc15.x86_64 >> >> Nov 04 15:54:47 Updated: freeipa-server-2.1.3-2.fc15.x86_64 >> >> Nov 04 15:56:02 Updated: freeipa-server-selinux-2.1.3-2.fc15.x86_64 >> >> >> >> Dan >> > >> > I'm still having fairly serious problems. I keep getting: >> > >> > ipa: ERROR: Kerberos error: Kerberos error: ('Unspecified GSS failure. >> > ?Minor code may provide more information', 851968)/('Cannot contact >> > any KDC for requested realm', -1765328228)/ >> > >> > Whenever I try and run IPA commands on either of my servers, or a >> > client with the admin tools installed. >> > >> > The server logs contain: >> > >> > slapd_ldap_sasl_interactive_bind - Error: could not perform >> > interactive bind for id [] mech [GSSAPI]: error -1 (Can't contact LDAP >> > server) ((null)) >> > slapi_ldap_bind - Error: could not perform interactive bind for id [] >> > mech [GSSAPI]: error -1 (Can't contact LDAP server) >> > >> > And I can't create new replicas because they fail with: >> > >> > 2011-12-21 11:25:58,356 DEBUG Failed to start replication >> > ?File "/usr/sbin/ipa-replica-install", line 484, in >> > ? ?main() >> > >> > ?File "/usr/sbin/ipa-replica-install", line 435, in main >> > ? ?ds = install_replica_ds(config) >> > >> > ?File "/usr/sbin/ipa-replica-install", line 137, in install_replica_ds >> > ? ?pkcs12_info) >> > >> > ?File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", >> > line 284, in create_replica >> > ? ?self.start_creation("Configuring directory server", 60) >> > >> > ?File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >> > line 248, in start_creation >> > ? ?method() >> > >> > ?File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", >> > line 297, in __setup_replica >> > ? ?r_bindpw=self.dm_password) >> > >> > ?File "/usr/lib/python2.7/site-packages/ipaserver/install/replication.py", >> > line 694, in setup_replication >> > ? ?raise RuntimeError("Failed to start replication") >> > >> > Can someone help me? This is getting fairly serious because I can't >> > create/modify anything and I'm worried that there will be problems >> > with existing users soon as well. >> >> OK, I think I'm narrowing in on this. It looks like the replication >> agreement is broken and the servers have got out of sync: > > odd > >> On the 'master' server (which contains the PKI dirsrv process): > > The PKI instance uses a diffeent set of replication agreementsso you > can't see those agreements with ipa-replica-manage which handles only > the IPA Idm instance. > >> [root at fileserver1 ~]# ipa-replica-manage list >> fileserver1.example.com: master >> >> On the other server: >> >> [root at fileserver2 ~]# ipa-replica-manage list >> fileserver1.example.com: master >> fileserver2.example.com: master > > strange indeed. > >> When I try and add the missing replication: >> >> [root at fileserver1 ~]# ipa-replica-manage connect fileserver2.example.com >> unexpected error: list index out of range >> >> Do I need to delete the replication from fileserver2? > > You can't remove a replication agreement if it is the only agreement you > have. This is to avoid split-brain situations. > > Not sure how to handle a disappeared agreement though it's > theorethically not possible unless you 'inadvertently' ran > ipa-replica-manage --force del fileserver2 on fileserver1 ... This is possible... oops. I tried a few times to add another replica (fileserver3) which failed as I mentioned above. The replication process got most of the way through and showed up on one of the servers, but not the other, so I removed the replica. It's possible that I force removed fileserver2 by mistake. > Can you look into cn=config and see if you have references toi > fileserver2 ? > Maybe it is just a bug in displaying actually active replicas. I'm using 'jxplore' LDAP browser (my command line LDAP skills aren't very good, I can't seem to get the kerberos authentication working properly. In any case, I'm having trouble authenticating because of the problems mentioned above) and did an unauthenticated search for cn=config on fileserver1, no results. In cn=ipa,cn=etc there are: cn=masters which contains an entry for fileserver1 and cn=replicas which is empty. Thanks, Dan From simo at redhat.com Thu Dec 22 15:12:27 2011 From: simo at redhat.com (Simo Sorce) Date: Thu, 22 Dec 2011 10:12:27 -0500 Subject: [Freeipa-users] ns-slapd hang/segfault In-Reply-To: References: <4EEA1908.2040801@redhat.com> <4EEA2589.5060400@redhat.com> <1324322097.28622.98.camel@willson.li.ssimo.org> <1324503782.28622.166.camel@willson.li.ssimo.org> Message-ID: <1324566747.28622.172.camel@willson.li.ssimo.org> On Wed, 2011-12-21 at 17:39 -0500, Dan Scott wrote: > This is possible... oops. I tried a few times to add another replica > (fileserver3) which failed as I mentioned above. The replication > process got most of the way through and showed up on one of the > servers, but not the other, so I removed the replica. It's possible > that I force removed fileserver2 by mistake. In this case the only way out is to reinstall fileserver2. > > Can you look into cn=config and see if you have references toi > > fileserver2 ? > > Maybe it is just a bug in displaying actually active replicas. > > I'm using 'jxplore' LDAP browser (my command line LDAP skills aren't > very good, I can't seem to get the kerberos authentication working > properly. In any case, I'm having trouble authenticating because of > the problems mentioned above) and did an unauthenticated search for > cn=config on fileserver1, no results. cn=config is a separate tree within DS it is not a subtree of the data partition, you need to use that as the basedn in jxplore. > In cn=ipa,cn=etc there are: cn=masters which contains an entry for > fileserver1 and cn=replicas which is empty. This strongly indicate you force deleted fileserver2, which is very unfortunate. Be careful with --force we imposed such a flag for a very good reason. Simo. -- Simo Sorce * Red Hat, Inc * New York From danieljamesscott at gmail.com Thu Dec 22 15:42:14 2011 From: danieljamesscott at gmail.com (Dan Scott) Date: Thu, 22 Dec 2011 10:42:14 -0500 Subject: [Freeipa-users] ns-slapd hang/segfault In-Reply-To: <1324566747.28622.172.camel@willson.li.ssimo.org> References: <4EEA1908.2040801@redhat.com> <4EEA2589.5060400@redhat.com> <1324322097.28622.98.camel@willson.li.ssimo.org> <1324503782.28622.166.camel@willson.li.ssimo.org> <1324566747.28622.172.camel@willson.li.ssimo.org> Message-ID: On Thu, Dec 22, 2011 at 10:12, Simo Sorce wrote: > On Wed, 2011-12-21 at 17:39 -0500, Dan Scott wrote: > >> This is possible... oops. I tried a few times to add another replica >> (fileserver3) which failed as I mentioned above. The replication >> process got most of the way through and showed up on one of the >> servers, but not the other, so I removed the replica. It's possible >> that I force removed fileserver2 by mistake. > > In this case the only way out is to reinstall fileserver2. Which would be fine, if I were confident of being able to create a new replica. However, my attempts to create new replicas are failing miserably as explained previously. I'm extremely reluctant to wipe fileserver2 unless I can get another replica of fileserver1 up and running first. If I can get another replica up and running I would be fine. However, the slapi_ldap_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error -1 (Can't contact LDAP server) error is causing problems during replication. When a replica is initialised, I guess that it replicates only from the master server? So I need to figure out the replication problem first, then I can re-install fileserver2 >> > Can you look into cn=config and see if you have references toi >> > fileserver2 ? >> > Maybe it is just a bug in displaying actually active replicas. >> >> I'm using 'jxplore' LDAP browser (my command line LDAP skills aren't >> very good, I can't seem to get the kerberos authentication working >> properly. In any case, I'm having trouble authenticating because of >> the problems mentioned above) and did an unauthenticated search for >> cn=config on fileserver1, no results. > > cn=config is a separate tree within DS it is not a subtree of the data > partition, you need to use that as the basedn in jxplore. OK, thanks. cn=config only contains a SNMP entry, no references to the other server. Thanks, Dan From rmeggins at redhat.com Thu Dec 22 17:10:59 2011 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 22 Dec 2011 10:10:59 -0700 Subject: [Freeipa-users] ns-slapd hang/segfault In-Reply-To: References: <4EEA1908.2040801@redhat.com> <4EEA2589.5060400@redhat.com> <1324322097.28622.98.camel@willson.li.ssimo.org> <1324503782.28622.166.camel@willson.li.ssimo.org> <1324566747.28622.172.camel@willson.li.ssimo.org> Message-ID: <4EF364A3.70107@redhat.com> On 12/22/2011 08:42 AM, Dan Scott wrote: > On Thu, Dec 22, 2011 at 10:12, Simo Sorce wrote: >> On Wed, 2011-12-21 at 17:39 -0500, Dan Scott wrote: >> >>> This is possible... oops. I tried a few times to add another replica >>> (fileserver3) which failed as I mentioned above. The replication >>> process got most of the way through and showed up on one of the >>> servers, but not the other, so I removed the replica. It's possible >>> that I force removed fileserver2 by mistake. >> In this case the only way out is to reinstall fileserver2. > Which would be fine, if I were confident of being able to create a new > replica. However, my attempts to create new replicas are failing > miserably as explained previously. I'm extremely reluctant to wipe > fileserver2 unless I can get another replica of fileserver1 up and > running first. > > If I can get another replica up and running I would be fine. However, the > > slapi_ldap_bind - Error: could not perform interactive bind for id [] > mech [GSSAPI]: error -1 (Can't contact LDAP server) > > error is causing problems during replication. > > When a replica is initialised, I guess that it replicates only from > the master server? So I need to figure out the replication problem > first, then I can re-install fileserver2 > >>>> Can you look into cn=config and see if you have references toi >>>> fileserver2 ? >>>> Maybe it is just a bug in displaying actually active replicas. >>> I'm using 'jxplore' LDAP browser (my command line LDAP skills aren't >>> very good, I can't seem to get the kerberos authentication working >>> properly. In any case, I'm having trouble authenticating because of >>> the problems mentioned above) and did an unauthenticated search for >>> cn=config on fileserver1, no results. >> cn=config is a separate tree within DS it is not a subtree of the data >> partition, you need to use that as the basedn in jxplore. > OK, thanks. cn=config only contains a SNMP entry, no references to the > other server. That's the only entry that you can view with anonymous credentials. You'll need to use an authenticated admin user (e.g. cn=Directory Manager) to see the rest of the tree. > Thanks, > > Dan > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From danieljamesscott at gmail.com Thu Dec 22 17:58:41 2011 From: danieljamesscott at gmail.com (Dan Scott) Date: Thu, 22 Dec 2011 12:58:41 -0500 Subject: [Freeipa-users] ns-slapd hang/segfault In-Reply-To: <4EF364A3.70107@redhat.com> References: <4EEA1908.2040801@redhat.com> <4EEA2589.5060400@redhat.com> <1324322097.28622.98.camel@willson.li.ssimo.org> <1324503782.28622.166.camel@willson.li.ssimo.org> <1324566747.28622.172.camel@willson.li.ssimo.org> <4EF364A3.70107@redhat.com> Message-ID: On Thu, Dec 22, 2011 at 12:10, Rich Megginson wrote: > On 12/22/2011 08:42 AM, Dan Scott wrote: >> >> On Thu, Dec 22, 2011 at 10:12, Simo Sorce ?wrote: >>> >>> On Wed, 2011-12-21 at 17:39 -0500, Dan Scott wrote: >>> >>>> This is possible... oops. I tried a few times to add another replica >>>> (fileserver3) which failed as I mentioned above. The replication >>>> process got most of the way through and showed up on one of the >>>> servers, but not the other, so I removed the replica. It's possible >>>> that I force removed fileserver2 by mistake. >>> >>> In this case the only way out is to reinstall fileserver2. >> >> Which would be fine, if I were confident of being able to create a new >> replica. However, my attempts to create new replicas are failing >> miserably as explained previously. I'm extremely reluctant to wipe >> fileserver2 unless I can get another replica of fileserver1 up and >> running first. >> >> If I can get another replica up and running I would be fine. However, the >> >> slapi_ldap_bind - Error: could not perform interactive bind for id [] >> mech [GSSAPI]: error -1 (Can't contact LDAP server) >> >> error is causing problems during replication. >> >> When a replica is initialised, I guess that it replicates only from >> the master server? So I need to figure out the replication problem >> first, then I can re-install fileserver2 >> >>>>> Can you look into cn=config and see if you have references toi >>>>> fileserver2 ? >>>>> Maybe it is just a bug in displaying actually active replicas. >>>> >>>> I'm using 'jxplore' LDAP browser (my command line LDAP skills aren't >>>> very good, I can't seem to get the kerberos authentication working >>>> properly. In any case, I'm having trouble authenticating because of >>>> the problems mentioned above) and did an unauthenticated search for >>>> cn=config on fileserver1, no results. >>> >>> cn=config is a separate tree within DS it is not a subtree of the data >>> partition, you need to use that as the basedn in jxplore. >> >> OK, thanks. cn=config only contains a SNMP entry, no references to the >> other server. > > That's the only entry that you can view with anonymous credentials. ?You'll > need to use an authenticated admin user (e.g. cn=Directory Manager) to see > the rest of the tree. Ahh, OK, thanks. I can see a lot more now. There's no replication agreement with fileserver2 showing up. I managed to 'mostly' replicate with a new Fedora 16 IPA fileserver3 (using the updates-testing release of FreeIPA freeipa-server-2.1.4-2.fc16.x86_64). But it failed with: 2011-12-22 11:37:49,053 DEBUG done configuring dirsrv. 2011-12-22 11:37:52,058 DEBUG args=/bin/systemctl restart dirsrv.target 2011-12-22 11:37:52,059 DEBUG stdout= 2011-12-22 11:37:52,059 DEBUG stderr= 2011-12-22 11:37:52,183 DEBUG args=/bin/systemctl restart krb5kdc.service 2011-12-22 11:37:52,184 DEBUG stdout= 2011-12-22 11:37:52,184 DEBUG stderr=Job failed. See system logs and 'systemctl status' for details. 2011-12-22 11:37:52,188 DEBUG Command '/bin/systemctl restart krb5kdc.service' returned non-zero exit status 1 File "/usr/sbin/ipa-replica-install", line 484, in main() File "/usr/sbin/ipa-replica-install", line 460, in main ipaservices.knownservices.krb5kdc.restart() File "/usr/lib/python2.7/site-packages/ipapython/platform/systemd.py", line 85, in restart ipautil.run(["/bin/systemctl", "restart", self.service_instance(instance_name)], capture_output=capture_output) File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 273, in run raise CalledProcessError(p.returncode, args) I can send the full log file directly to someone off list if this would help. The data seems to be replicating mostly, so I'm less concerned than I was previously. However there still seem to be a few problems. Is it dangerous to update my fileserver1 to freeipa-server-2.1.4-2.fc16.x86_64. I'm a little concerned about the slapd-PKI-IPA replication now, since I haven't been able to replicate that properly. I'm going to try and replicate the PKI directory now, with the 2.1.4 version into fileserver4. Thanks, Dan From abokovoy at redhat.com Thu Dec 22 19:17:40 2011 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 22 Dec 2011 21:17:40 +0200 Subject: [Freeipa-users] ns-slapd hang/segfault In-Reply-To: References: <1324322097.28622.98.camel@willson.li.ssimo.org> <1324503782.28622.166.camel@willson.li.ssimo.org> <1324566747.28622.172.camel@willson.li.ssimo.org> <4EF364A3.70107@redhat.com> Message-ID: <20111222191730.GB20629@redhat.com> On Thu, 22 Dec 2011, Dan Scott wrote: > Ahh, OK, thanks. I can see a lot more now. There's no replication > agreement with fileserver2 showing up. > > I managed to 'mostly' replicate with a new Fedora 16 IPA fileserver3 > (using the updates-testing release of FreeIPA > freeipa-server-2.1.4-2.fc16.x86_64). But it failed with: > > 2011-12-22 11:37:49,053 DEBUG done configuring dirsrv. > 2011-12-22 11:37:52,058 DEBUG args=/bin/systemctl restart dirsrv.target > 2011-12-22 11:37:52,059 DEBUG stdout= > 2011-12-22 11:37:52,059 DEBUG stderr= > 2011-12-22 11:37:52,183 DEBUG args=/bin/systemctl restart krb5kdc.service > 2011-12-22 11:37:52,184 DEBUG stdout= > 2011-12-22 11:37:52,184 DEBUG stderr=Job failed. See system logs and > 'systemctl status' for details. > > 2011-12-22 11:37:52,188 DEBUG Command '/bin/systemctl restart > krb5kdc.service' returned non-zero exit status 1 > File "/usr/sbin/ipa-replica-install", line 484, in > main() > > File "/usr/sbin/ipa-replica-install", line 460, in main > ipaservices.knownservices.krb5kdc.restart() > > File "/usr/lib/python2.7/site-packages/ipapython/platform/systemd.py", > line 85, in restart > ipautil.run(["/bin/systemctl", "restart", > self.service_instance(instance_name)], capture_output=capture_output) > > File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 273, in run > raise CalledProcessError(p.returncode, args) > > I can send the full log file directly to someone off list if this would help. Please send the log to me. Also please include /etc/sysconfig/krb5kdc, output of 'stat /etc/sysconfig/krb5kdc', and output of 'ls -l /etc/systemd/system/' > The data seems to be replicating mostly, so I'm less concerned than I > was previously. However there still seem to be a few problems. Is it > dangerous to update my fileserver1 to > freeipa-server-2.1.4-2.fc16.x86_64. I'm a little concerned about the > slapd-PKI-IPA replication now, since I haven't been able to replicate > that properly. Did you install Fedora 16 from scratch or was it upgrade from Fedora 15? The latter might explain some of these issues. -- / Alexander Bokovoy From ranger at opennms.org Fri Dec 23 02:46:40 2011 From: ranger at opennms.org (Benjamin Reed) Date: Thu, 22 Dec 2011 21:46:40 -0500 Subject: [Freeipa-users] anonymous bind + ipa-install-client failure Message-ID: <4EF3EB90.9060003@opennms.org> I'm attempting to configure a CentOS6 box to talk to a RHEL6.2 IPA server. The IPA server has anonymous bind disabled since it's on the public Internet. When I run ipa-client-install, I get the following error: ---(snip!)--- [root at nen ~]# ipa-client-install --domain=OPENNMS.COM -w root : ERROR LDAP Error: Connect error: TLS error -8172:Unknown code ___f 20 Failed to verify that connect.opennms.com is an IPA Server. This may mean that the remote server is not up or is not reachable due to network or firewall settings. Installation failed. Rolling back changes. IPA client is not configured on this system. ---(snip!)--- I've tried without the -w, or with -W to see if that makes a difference. I don't see any --help options that tell me how to go about telling it to bind non-anonymously, AFAICT. Any ideas how this is supposed to work? https://bugzilla.redhat.com/show_bug.cgi?id=741050 implies it should figure it out on it's own... client: ipa-admintools-2.1.3-9.el6.x86_64 ipa-python-2.1.3-9.el6.x86_64 ipa-client-2.1.3-9.el6.x86_64 server: ipa-pki-ca-theme-9.0.3-7.el6.noarch ipa-server-2.1.3-9.el6.x86_64 ipa-client-2.1.3-9.el6.x86_64 ipa-pki-common-theme-9.0.3-7.el6.noarch ipa-python-2.1.3-9.el6.x86_64 ipa-server-selinux-2.1.3-9.el6.x86_64 ipa-admintools-2.1.3-9.el6.x86_64 -- Benjamin Reed The OpenNMS Group http://www.opennms.org/ From ranger at opennms.org Fri Dec 23 03:54:42 2011 From: ranger at opennms.org (Benjamin Reed) Date: Thu, 22 Dec 2011 22:54:42 -0500 Subject: [Freeipa-users] anonymous bind + ipa-install-client failure In-Reply-To: <4EF3EB90.9060003@opennms.org> References: <4EF3EB90.9060003@opennms.org> Message-ID: <4EF3FB82.1010800@opennms.org> On 12/22/11 9:46 PM, Benjamin Reed wrote: > I'm attempting to configure a CentOS6 box to talk to a RHEL6.2 IPA > server. The IPA server has anonymous bind disabled since it's on the > public Internet. When I run ipa-client-install, I get the following error: So the full log makes more sense with debug on: ---(snip!)--- [root at nen etc]# ipa-client-install --domain=OPENNMS.COM --debug root : DEBUG /usr/sbin/ipa-client-install was invoked with options: {'conf_ntp': True, 'domain': 'OPENNMS.COM', 'uninstall': False, 'force': False, 'sssd': True, 'krb5_offline_passwords': True, 'hostname': None, 'preserve_sssd': False, 'server': None, 'prompt_password': False, 'mkhomedir': False, 'dns_updates': False, 'permit': False, 'debug': True, 'on_master': False, 'ntp_server': None, 'realm_name': None, 'unattended': None, 'principal': None} root : DEBUG missing options might be asked for interactively later root : DEBUG Loading Index file from '/var/lib/ipa-client/sysrestore/sysrestore.index' root : DEBUG Loading StateFile from '/var/lib/ipa-client/sysrestore/sysrestore.state' root : DEBUG [ipadnssearchldap] root : DEBUG [ipadnssearchkrb] root : DEBUG [ipacheckldap] root : DEBUG args=/usr/bin/wget -O /tmp/tmpjxJzV_/ca.crt -T 15 -t 2 http://connect.opennms.com/ipa/config/ca.crt root : DEBUG stdout= root : DEBUG stderr=--2011-12-22 22:47:39-- http://connect.opennms.com/ipa/config/ca.crt Resolving connect.opennms.com... 66.135.60.215 Connecting to connect.opennms.com|66.135.60.215|:80... connected. HTTP request sent, awaiting response... 302 Found Location: https://connect.opennms.com/ipa/config/ca.crt [following] --2011-12-22 22:47:39-- https://connect.opennms.com/ipa/config/ca.crt Connecting to connect.opennms.com|66.135.60.215|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 1313 (1.3K) [application/x-x509-ca-cert] Saving to: "/tmp/tmpjxJzV_/ca.crt" 0K . 100% 3.11M=0s 2011-12-22 22:47:40 (3.11 MB/s) - "/tmp/tmpjxJzV_/ca.crt" saved [1313/1313] root : DEBUG Init ldap with: ldap://connect.opennms.com:389 root : ERROR LDAP Error: Connect error: TLS error -8172:Unknown code ___f 20 root : DEBUG will use domain: OPENNMS.COM root : DEBUG will use server: connect.opennms.com Failed to verify that connect.opennms.com is an IPA Server. This may mean that the remote server is not up or is not reachable due to network or firewall settings. Installation failed. Rolling back changes. IPA client is not configured on this system. ---(snip!)--- This implies I guess the LDAP server isn't accepting this cert? Is there a log that might explain what's going on on the server side? -- Benjamin Reed The OpenNMS Group http://www.opennms.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Fri Dec 23 17:02:17 2011 From: simo at redhat.com (Simo Sorce) Date: Fri, 23 Dec 2011 12:02:17 -0500 Subject: [Freeipa-users] anonymous bind + ipa-install-client failure In-Reply-To: <4EF3FB82.1010800@opennms.org> References: <4EF3EB90.9060003@opennms.org> <4EF3FB82.1010800@opennms.org> Message-ID: <1324659737.28622.202.camel@willson.li.ssimo.org> On Thu, 2011-12-22 at 22:54 -0500, Benjamin Reed wrote: > > This implies I guess the LDAP server isn't accepting this cert? No, more that the client does not recognized the LDAP server's cert as trusted. It may be because the ca.crt that is downloaded has not been updated and so the client is getting the old ca.cert you had before the selfsign -> dogtag migration I helped you with some time ago. One thing you can test is if the ca.crt exposed via http is the same that is stored on the server in /etc/ipa/ca.crt > Is there a log that might explain what's going on on the server side? You can look into the dirsrv access log under /var/log/dirsrv/slpad-INSTANCE_NAME/access (the log is buffered so you may have to wait a few seconds before you see the log after the operation you want to monitor has been performed). Simo. > -- Simo Sorce * Red Hat, Inc * New York From JR.Aquino at citrix.com Fri Dec 23 20:20:59 2011 From: JR.Aquino at citrix.com (JR Aquino) Date: Fri, 23 Dec 2011 20:20:59 +0000 Subject: [Freeipa-users] FreeIPA Replica Manage Reinitialize causes ALL Severs to rerun memberof fixup Message-ID: I have a multimaster infrastructure with 3 core FreeIPA servers and 10 supporting (procedurally read-only) FreeIPA servers. I notice that occasionally 1 of the systems starts producing errors filling up /var/log/dirsrv/slapd-DOMAIN-COM/errors: Replica has a different generation ID than the local data (I suspect this is due to ntp problems that I am trying to work out) http://www.centos.org/docs/5/html/CDS/ag/8.0/Managing_Replication-Troubleshooting_Replication_Related_Problems.html ^ This document suggests that I should re-initialize the problematic system from one of the core master servers. Upon so doing, I am finding that all 13 servers CPU's spike to 100% of 1 core while they re-process memberof data... Even though there are many many cores in these systems the intense & single threaded nature of this process causes a performance hit in all 13 data centers for all clients. Am I reading the documentation wrong? Shouldn't a re-initialization of the problematic host only cause a replication: master -> slave + slave memberof fixup? This seems like a fairly severe performance effecting bug. -JR From ranger at opennms.org Fri Dec 23 21:38:40 2011 From: ranger at opennms.org (Benjamin Reed) Date: Fri, 23 Dec 2011 16:38:40 -0500 Subject: [Freeipa-users] anonymous bind + ipa-install-client failure In-Reply-To: <1324659737.28622.202.camel@willson.li.ssimo.org> References: <4EF3EB90.9060003@opennms.org> <4EF3FB82.1010800@opennms.org> <1324659737.28622.202.camel@willson.li.ssimo.org> Message-ID: <4EF4F4E0.2060708@opennms.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/23/11 12:02 PM, Simo Sorce wrote: > One thing you can test is if the ca.crt exposed via http is the same > that is stored on the server in /etc/ipa/ca.crt they are identical, I did find that the errors file is complaining about this: [22/Dec/2011:21:31:15 -0600] attrcrypt - attrcrypt_unwrap_key: failed to unwrap key for cipher AES [22/Dec/2011:21:31:15 -0600] attrcrypt - attrcrypt_cipher_init: symmetric key failed to unwrap with the private key; Cert might have been renewed since the key is wrapped. To recover the encrypted contents, keep the wrapped symmetric key value. [22/Dec/2011:21:31:15 -0600] attrcrypt - attrcrypt_unwrap_key: failed to unwrap key for cipher 3DES [22/Dec/2011:21:31:15 -0600] attrcrypt - attrcrypt_cipher_init: symmetric key failed to unwrap with the private key; Cert might have been renewed since the key is wrapped. To recover the encrypted contents, keep the wrapped symmetric key value. [22/Dec/2011:21:31:16 -0600] attrcrypt - All prepared ciphers are not available. Please disable attribute encryption. - -- Benjamin Reed The OpenNMS Group http://www.opennms.org/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFO9PTfUu+jZtP2Zf4RAveHAJ9TniJdF74K/XSI3r8o8eKSS0+TEACfT6xc wWKYP73YzPY5SsnzNwnt16g= =KnIi -----END PGP SIGNATURE----- From borepstein at gmail.com Tue Dec 27 14:06:22 2011 From: borepstein at gmail.com (Boris Epstein) Date: Tue, 27 Dec 2011 09:06:22 -0500 Subject: [Freeipa-users] NIS maps via FreeIPA Message-ID: Hello all, How do I control which NIS maps FreeIPA makes available? Specifically I may need?passwd.byname. Also, how do I control what sort of encryption it uses for passwords? Thanks. Boris. From freeipa at noboost.org Wed Dec 28 01:01:19 2011 From: freeipa at noboost.org (Craig T) Date: Wed, 28 Dec 2011 12:01:19 +1100 Subject: [Freeipa-users] Hot Backup Solution for IPA 2.x? Message-ID: <20111228010119.GA32480@noboost.org> Hi, Is there a hot backup technique for IPA? From my reading the best solution is to setup a replication server then shut the replication server down and do a backup? cya Craig From borepstein at gmail.com Wed Dec 28 16:11:36 2011 From: borepstein at gmail.com (Boris Epstein) Date: Wed, 28 Dec 2011 11:11:36 -0500 Subject: [Freeipa-users] MD5 passwords in NIS Message-ID: Hello listmates, Apparently, in order to authenticate a Mac OS X Lion client to NIS one needs passwords encrypted in MD5 hash shown in the passwd and passwd.byname maps. FreeIPA at this point only shows a "*". Is there a way to change that? Thanks and Happy New Year! Boris. -------------- next part -------------- An HTML attachment was scrubbed... URL: From erinn.looneytriggs at gmail.com Wed Dec 28 17:34:39 2011 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Wed, 28 Dec 2011 08:34:39 -0900 Subject: [Freeipa-users] Hot Backup Solution for IPA 2.x? In-Reply-To: <20111228010119.GA32480@noboost.org> References: <20111228010119.GA32480@noboost.org> Message-ID: <4EFB532F.8030902@gmail.com> On 12/27/2011 04:01 PM, Craig T wrote: > Hi, > > Is there a hot backup technique for IPA? From my reading the best solution is to setup a replication server then shut the replication server down and do a backup? > > cya > > Craig > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users Yeah this seems to be a bit of a problem. I am currently working through the same thing and all I can find is advice like, "back everything up", because there are files used by IPA all over the place. That seems a bit ridiculous to me, so I am trying to piece together what it really does, and what files are really needed. One part I have found so far is the hot backups for the directory servers (note the plural, PKI has its own instance). You need to use the db2bak.pl (not the db2bak script which requires dirsrv to be stopped) script to do a hot backup of the directory server. The general idea can be found in these docs here: http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Populating_Directory_Databases-Backing_Up_and_Restoring_Data.html Under section 4.3.1.2. Unfortunately, those docs are wrong about how to run the db2bak.pl script, so to figure that out you have to read here: http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Configuration_Command_and_File_Reference/Perl_Scripts.html#Perl_Scripts-db2bak.pl_Create_backup_of_database So far that is all I have, just remember to back up both your domain instance of the LDAP db, as well as the PKI instance. You can then easily copy those backup files, using your backup tool of choice. As well as taking a copy of /etc/dirsrv/ and all it contains. -Erinn -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 554 bytes Desc: OpenPGP digital signature URL: From simo at redhat.com Thu Dec 29 03:18:22 2011 From: simo at redhat.com (Simo Sorce) Date: Wed, 28 Dec 2011 22:18:22 -0500 Subject: [Freeipa-users] MD5 passwords in NIS In-Reply-To: References: Message-ID: <1325128702.2664.11.camel@willson.li.ssimo.org> On Wed, 2011-12-28 at 11:11 -0500, Boris Epstein wrote: > Hello listmates, > > > Apparently, in order to authenticate a Mac OS X Lion client to NIS one > needs passwords encrypted in MD5 hash shown in the passwd and > passwd.byname maps. FreeIPA at this point only shows a "*". Is there a > way to change that? No, we decided that one of the rules with FreeIPA was to never expose hashes to clients. Same reason why we do not export a shadow map for example. With Mac OS X you should be better off using just LDAP auth. > > Thanks and Happy New Year! Same! Simo. -- Simo Sorce * Red Hat, Inc * New York From borepstein at gmail.com Thu Dec 29 18:13:31 2011 From: borepstein at gmail.com (Boris Epstein) Date: Thu, 29 Dec 2011 13:13:31 -0500 Subject: [Freeipa-users] MD5 passwords in NIS In-Reply-To: <1325128702.2664.11.camel@willson.li.ssimo.org> References: <1325128702.2664.11.camel@willson.li.ssimo.org> Message-ID: On Wed, Dec 28, 2011 at 10:18 PM, Simo Sorce wrote: > On Wed, 2011-12-28 at 11:11 -0500, Boris Epstein wrote: > > Hello listmates, > > > > > > Apparently, in order to authenticate a Mac OS X Lion client to NIS one > > needs passwords encrypted in MD5 hash shown in the passwd and > > passwd.byname maps. FreeIPA at this point only shows a "*". Is there a > > way to change that? > > No, we decided that one of the rules with FreeIPA was to never expose > hashes to clients. Same reason why we do not export a shadow map for > example. > > With Mac OS X you should be better off using just LDAP auth. > > > Simo, thanks! Is there a decent manual on how to link up Mac OS X (specifically, V10.7, "Lion") to a FreeIPA server as an LDAP client? I tried that - and just seem to be getting nowhere as the Mac wouldn't even give me an error message (or perhaps it is my fault for not knowing where to look but I am just lost there). Boris. -------------- next part -------------- An HTML attachment was scrubbed... URL: From erinn.looneytriggs at gmail.com Sat Dec 31 01:45:05 2011 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Fri, 30 Dec 2011 16:45:05 -0900 Subject: [Freeipa-users] Large slow down when using IPA Message-ID: <4EFE6921.8060900@gmail.com> I have been slowly rolling out FreeIPA to my systems, trying to track differences/changes. One of the most noticeable has been a large slow down in file access times. Let me explain as best as I can. I use AIDE to track the file system (think tripwire) and it runs checks once a day. During these checks it is scanning (almost) the entire file system and comparing it to a stored database. On a moderately powered system with ~151k files, an AIDE run will usually take ~30 minutes. After the system becomes an IPA client the same run will generally take ~90-120 minutes. Un-install the ipa-client, back to ~30 minutes for an AIDE run. Now clearly a lot of lookups are being done for user names and group names, and this will have a performance hit that is dependant on the network. However, the odd thing is that even when running on the IPA server itself the slowdown is still the same. Not sure if this is an IPA problem, an SSSD problem, a bit of both, or neither, perhaps it is just the way it is, but a slowdown of 3-4x seems a bit much to me. Clearly the results are not scientific, however, they have been generally reproducible since I started rolling IPA out. As a side note this slowdown has also broken bacula backups, as the bacula client is scanning the filesystem for change (using accurate backups) the director times out. Any thoughts, or opinions? Workarounds etc? I have checked to make sure that SSSD caching is enabled, and functional. Thanks, -Erinn -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 554 bytes Desc: OpenPGP digital signature URL: From JR.Aquino at citrix.com Sat Dec 31 04:19:13 2011 From: JR.Aquino at citrix.com (JR Aquino) Date: Sat, 31 Dec 2011 04:19:13 +0000 Subject: [Freeipa-users] Large slow down when using IPA In-Reply-To: <4EFE6921.8060900@gmail.com> References: <4EFE6921.8060900@gmail.com> Message-ID: <16D2D5DF-82DA-43B5-B2B2-609C35BBFE41@citrixonline.com> On Dec 30, 2011, at 5:45 PM, Erinn Looney-Triggs wrote: > I have been slowly rolling out FreeIPA to my systems, trying to track > differences/changes. One of the most noticeable has been a large slow > down in file access times. > > Let me explain as best as I can. I use AIDE to track the file system > (think tripwire) and it runs checks once a day. During these checks it > is scanning (almost) the entire file system and comparing it to a stored > database. On a moderately powered system with ~151k files, an AIDE run > will usually take ~30 minutes. After the system becomes an IPA client > the same run will generally take ~90-120 minutes. Un-install the > ipa-client, back to ~30 minutes for an AIDE run. > > Now clearly a lot of lookups are being done for user names and group > names, and this will have a performance hit that is dependant on the > network. However, the odd thing is that even when running on the IPA > server itself the slowdown is still the same. > > Not sure if this is an IPA problem, an SSSD problem, a bit of both, or > neither, perhaps it is just the way it is, but a slowdown of 3-4x seems > a bit much to me. Clearly the results are not scientific, however, they > have been generally reproducible since I started rolling IPA out. > > As a side note this slowdown has also broken bacula backups, as the > bacula client is scanning the filesystem for change (using accurate > backups) the director times out. > > Any thoughts, or opinions? Workarounds etc? I have checked to make sure > that SSSD caching is enabled, and functional. > > Thanks, > > -Erinn I am assuming that these are all running as local users. >From the sssd.conf man page in the nss section: filter_users, filter_groups (string) Exclude certain users from being fetched from the sss NSS database. This is particularly useful for system accounts. This option can also be set per-domain or include fully-qualified names to filter only users from the particular domain. Default: root Try adding this to your sssd.conf: [nss] filter_groups = root,bacula,aide,otherdaemonuser <-as needed filter_users = root,bacula,aide,otherdaemonuser <- as needed Let me know if that solves your issue. From erinn.looneytriggs at gmail.com Sat Dec 31 10:35:31 2011 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Sat, 31 Dec 2011 01:35:31 -0900 Subject: [Freeipa-users] Large slow down when using IPA In-Reply-To: <16D2D5DF-82DA-43B5-B2B2-609C35BBFE41@citrixonline.com> References: <4EFE6921.8060900@gmail.com> <16D2D5DF-82DA-43B5-B2B2-609C35BBFE41@citrixonline.com> Message-ID: <4EFEE573.5020503@gmail.com> On 12/30/2011 07:19 PM, JR Aquino wrote: > > On Dec 30, 2011, at 5:45 PM, Erinn Looney-Triggs wrote: > >> I have been slowly rolling out FreeIPA to my systems, trying to track >> differences/changes. One of the most noticeable has been a large slow >> down in file access times. >> >> Let me explain as best as I can. I use AIDE to track the file system >> (think tripwire) and it runs checks once a day. During these checks it >> is scanning (almost) the entire file system and comparing it to a stored >> database. On a moderately powered system with ~151k files, an AIDE run >> will usually take ~30 minutes. After the system becomes an IPA client >> the same run will generally take ~90-120 minutes. Un-install the >> ipa-client, back to ~30 minutes for an AIDE run. >> >> Now clearly a lot of lookups are being done for user names and group >> names, and this will have a performance hit that is dependant on the >> network. However, the odd thing is that even when running on the IPA >> server itself the slowdown is still the same. >> >> Not sure if this is an IPA problem, an SSSD problem, a bit of both, or >> neither, perhaps it is just the way it is, but a slowdown of 3-4x seems >> a bit much to me. Clearly the results are not scientific, however, they >> have been generally reproducible since I started rolling IPA out. >> >> As a side note this slowdown has also broken bacula backups, as the >> bacula client is scanning the filesystem for change (using accurate >> backups) the director times out. >> >> Any thoughts, or opinions? Workarounds etc? I have checked to make sure >> that SSSD caching is enabled, and functional. >> >> Thanks, >> >> -Erinn > > I am assuming that these are all running as local users. > > From the sssd.conf man page in the nss section: > > filter_users, filter_groups (string) > Exclude certain users from being fetched from the sss NSS database. This is particularly useful for system accounts. This option can also be set per-domain or include fully-qualified names to filter only users from the > particular domain. > > Default: root > > > Try adding this to your sssd.conf: > > [nss] > filter_groups = root,bacula,aide,otherdaemonuser <-as needed > filter_users = root,bacula,aide,otherdaemonuser <- as needed > > Let me know if that solves your issue. > Thanks for pointing that out, completely missed that option! Wouldn't it be sweet to have an option that say looked at /etc/login.defs and just didn't lookup anything under MIN_UID, on the assumption that those are system accounts? Certainly would stop a lot of lookups I imagine. Of course you would have to leave it as an option and probably default it to off given the odd things people do with their systems. -Erinn -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 554 bytes Desc: OpenPGP digital signature URL: