From mohan.cheema at arrkgroup.com Tue Oct 1 02:59:17 2013 From: mohan.cheema at arrkgroup.com (Mohan Cheema) Date: Tue, 1 Oct 2013 03:59:17 +0100 Subject: [Freeipa-users] krb5kdc Additional pre-authentication required In-Reply-To: <20130930144659.GR10000@localhost.localdomain> References: <5d4a01cebde8$42833340$c78999c0$@cheema@arrkgroup.com> <20130930144659.GR10000@localhost.localdomain> Message-ID: <61a401cebe52$3910ef90$ab32ceb0$@cheema@arrkgroup.com> > -----Original Message----- > From: freeipa-users-bounces at redhat.com [mailto:freeipa-users- > bounces at redhat.com] On Behalf Of Sumit Bose > Sent: Monday, September 30, 2013 3:47 PM > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] krb5kdc Additional pre-authentication > required > > On Mon, Sep 30, 2013 at 03:20:46PM +0100, Mohan Cheema wrote: > > Hi, > > > > > > > > We are trying to authenticate from Windows machine and getting below > error. > > > > > > > > -------------------- > > Sep 30 14:07:34 kdc1.domain.com krb5kdc[10105](info): AS_REQ (7 > etypes {18 > > 17 23 3 1 24 -135}) 10.43.2.45: NEEDED_PREAUTH: user at DOMAIN.COM for > > krbtgt/DOMAIN.COM at DOMAIN.COM, Additional pre-authentication required > > This is expected behaviour. The client will first send the AS-REQ > without any pre-authentication data. If the server requires > pre-authentication for this principal it will return this error to the > client to indicate that pre-authentication is expected. > > > > Sep 30 14:07:34 kdc1.domain.com krb5kdc[10105](info): AS_REQ (7 > etypes {18 > > 17 23 3 1 24 -135}) 10.43.2.45: ISSUE: authtime 1380550054, etypes > {rep=18 > > tkt=18 ses=18}, user at DOMAIN.COM for krbtgt/DOMAIN.COM at DOMAIN.COM > > In the second AS-REQ the client has included some pre-authentication > data which is accepted by the KDC and a ticket is issued to the client. > > HTH > > bye, > Sumit > > > > > Sep 30 14:07:34 kdc1.domain.com krb5kdc[10105](info): TGS_REQ (7 > etypes {18 > > 17 23 3 1 24 -135}) 10.43.2.45: ISSUE: authtime 1380550054, etypes > {rep=18 > > tkt=23 ses=23}, user at DOMAIN.COM for host/av.domain.com at DOMAIN.COM > > -------------------- > > > > > > > > We followed the instruction to integrate windows for authentication. > > > > > > > > Windows Client: Windows server 2008 R2 > > > > > > > > We are not able to figure out what the problem is. > > > > > > > > We are not using DNS server, instead we are using host file entries. > DNS > > server setup is not an option for us right now. > > > > > > > > Same user can authenticate from Linux machine. > > > > > > > > Regards, > > > > > > > > Mohan Cheema > > > > > > > > > _______________________________________________ > > 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 Thanks for the info Sumit. However, if ticket is issued user should be able to login to system. Instead on Windows we are getting "user name or password is incorrect". Are there any other setting that needs to be done so that user can login to system. Regards, Mohan From lukas.bezdicka at gooddata.com Tue Oct 1 08:08:35 2013 From: lukas.bezdicka at gooddata.com (=?UTF-8?B?THVrw6HFoSBCZXpkacSNa2E=?=) Date: Tue, 1 Oct 2013 10:08:35 +0200 Subject: [Freeipa-users] RFE - groups of services Message-ID: We came to situation when we need to add parameter memberOf to services, but there is no configuration in 389 for this nor UI in freeipa. Is it possible to implement groups for services? Example of usecase: We have web service infront of which we put apache with kerberos authentication and ldap authorization. This service is used by both users and services/scripts running on nodes. For this we setup service keytabs per service as we want them unprivileged and we don't want those services to touch host's principal. This works pretty well so far but management of the ldap authorization makes it pain in the ass :( In ideal usecase we'd love to see groups which can contain services or users or hosts. Thank you, Lukas Bezdicka -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret.wortman at damascusgrp.com Tue Oct 1 14:46:07 2013 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Tue, 1 Oct 2013 10:46:07 -0400 Subject: [Freeipa-users] Best place to start debugging sudo issue Message-ID: One some of my nodes, attempting to sudo yields this: $ sudo su - sudo: ldap_start_tls_s(): Connect error [sudo] password for bretw: When the policy for my account is set up for !authenticate on all systems. On my own workstation, and most of our systems, it works just fine. But on a few, this is happening. What's the best way to start debugging this? I'm not looking for someone to do the work for me, but some pointers to the right logfiles or extra flags would be helpful. Thanks! * * *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue Oct 1 14:53:30 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 01 Oct 2013 10:53:30 -0400 Subject: [Freeipa-users] Best place to start debugging sudo issue In-Reply-To: References: Message-ID: <524AE1EA.8030107@redhat.com> Bret Wortman wrote: > One some of my nodes, attempting to sudo yields this: > > $ sudo su - > sudo: ldap_start_tls_s(): Connect error > [sudo] password for bretw: > > When the policy for my account is set up for !authenticate on all systems. > > On my own workstation, and most of our systems, it works just fine. But > on a few, this is happening. What's the best way to start debugging > this? I'm not looking for someone to do the work for me, but some > pointers to the right logfiles or extra flags would be helpful. Add 'sudoers_debug: 2' to the sudo ldap configuration file. Check the DS access log on the IPA server this connects to for SSL errors. You should have these set: ssl start_tls tls_cacertfile /etc/ipa/ca.crt tls_checkpeer yes rob From bret.wortman at damascusgrp.com Tue Oct 1 14:58:11 2013 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Tue, 1 Oct 2013 10:58:11 -0400 Subject: [Freeipa-users] Best place to start debugging sudo issue In-Reply-To: <524AE1EA.8030107@redhat.com> References: <524AE1EA.8030107@redhat.com> Message-ID: Thanks. In this case, on a lark, I compared the sizes of the ca.crt file between the working and nonworking nodes and there was a 4 byte difference. Copying over the working copy to the nonworking node got things flowing again. I'm filing these notes in my nv stack for later reference, though. Thanks, Rob. * * *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret On Tue, Oct 1, 2013 at 10:53 AM, Rob Crittenden wrote: > Bret Wortman wrote: > >> One some of my nodes, attempting to sudo yields this: >> >> $ sudo su - >> sudo: ldap_start_tls_s(): Connect error >> [sudo] password for bretw: >> >> When the policy for my account is set up for !authenticate on all systems. >> >> On my own workstation, and most of our systems, it works just fine. But >> on a few, this is happening. What's the best way to start debugging >> this? I'm not looking for someone to do the work for me, but some >> pointers to the right logfiles or extra flags would be helpful. >> > > Add 'sudoers_debug: 2' to the sudo ldap configuration file. > > Check the DS access log on the IPA server this connects to for SSL errors. > > You should have these set: > > ssl start_tls > tls_cacertfile /etc/ipa/ca.crt > tls_checkpeer yes > > rob > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Tue Oct 1 15:11:16 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 01 Oct 2013 17:11:16 +0200 Subject: [Freeipa-users] DNS views: request for comments Message-ID: <524AE614.8090808@redhat.com> Hello list, we would like to get more details about DNS views and how you use them in real life. Also, any idea how user a interface should work is more than welcome! (If you don't know views, read it as "differentiate answer to a DNS query on client's IP address basics".) Questions are: - For what purpose do you use views? E.g. handling clients inside/outside of company network (e.g. hiding internal names); Selecting nearest server in a big network; Some other weird 'Cloud' scenarios etc. etc. - How many views do you use? - Do you share some data between views? How did you solve that? Do you use some user interface for that? - Do you use DNS updates? (nsupdate/RFC 2136/RFC 3007) Previous discussions about DNS views: https://www.redhat.com/archives/freeipa-users/2012-April/msg00070.html https://www.redhat.com/archives/freeipa-devel/2012-May/msg00208.html Related tickets & bugs: https://fedorahosted.org/freeipa/ticket/2802 https://bugzilla.redhat.com/show_bug.cgi?id=815621 https://fedorahosted.org/freeipa/ticket/3725 https://fedorahosted.org/bind-dyndb-ldap/ticket/69 The next step will be to design LDAP schema for DNS data with views ... I can see three basic options: 1) Resign from any data sharing, which will make the thing pretty easy :-) In that case 'view1' will be represented by one sub-tree in LDAP, 'view2' will be another sub-tree etc. 2) Select one sub-tree which will be 'the base' containing all shared records. All other views will inherit and override data from the shared 'base'. 3) Make it as general as possible and allow multiple levels of inheritance. View3 inherits from View2 and it inherits from Base. (View3 <- View2 <- Base) It is basically generalized variant (2), but it could require different LDAP schema. Please post your opinions! -- Petr^2 Spacek From erinn.looneytriggs at gmail.com Tue Oct 1 15:40:27 2013 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Tue, 01 Oct 2013 09:40:27 -0600 Subject: [Freeipa-users] DNS views: request for comments In-Reply-To: <524AE614.8090808@redhat.com> References: <524AE614.8090808@redhat.com> Message-ID: <524AECEB.8050103@gmail.com> On 10/01/2013 09:11 AM, Petr Spacek wrote: > Hello list, > > we would like to get more details about DNS views and how you use them > in real life. Also, any idea how user a interface should work is more > than welcome! > > (If you don't know views, read it as "differentiate answer to a DNS > query on client's IP address basics".) > > > Questions are: > - For what purpose do you use views? > E.g. handling clients inside/outside of company network (e.g. hiding > internal names); Selecting nearest server in a big network; Some other > weird 'Cloud' scenarios etc. etc. > > - How many views do you use? > > - Do you share some data between views? How did you solve that? Do you > use some user interface for that? > > - Do you use DNS updates? (nsupdate/RFC 2136/RFC 3007) > > Previous discussions about DNS views: > https://www.redhat.com/archives/freeipa-users/2012-April/msg00070.html > https://www.redhat.com/archives/freeipa-devel/2012-May/msg00208.html > > Related tickets & bugs: > https://fedorahosted.org/freeipa/ticket/2802 > https://bugzilla.redhat.com/show_bug.cgi?id=815621 > https://fedorahosted.org/freeipa/ticket/3725 > https://fedorahosted.org/bind-dyndb-ldap/ticket/69 > > > The next step will be to design LDAP schema for DNS data with views ... > > I can see three basic options: > > 1) Resign from any data sharing, which will make the thing pretty easy :-) > In that case 'view1' will be represented by one sub-tree in LDAP, > 'view2' will be another sub-tree etc. > > 2) Select one sub-tree which will be 'the base' containing all shared > records. All other views will inherit and override data from the shared > 'base'. > > 3) Make it as general as possible and allow multiple levels of > inheritance. View3 inherits from View2 and it inherits from Base. > (View3 <- View2 <- Base) > > It is basically generalized variant (2), but it could require different > LDAP schema. > > > Please post your opinions! > We use split-horizon, or DNS views, very simply. We have an internal view and an external view. I am not really sure if I buy into the whole security aspect of views, however with NAT it seems pointless to publish all of your non routable records out there in the world. Hence internal and external. I have spoken with other organizations that have many views ( a view for the Tokyo office, a view for the Beijing office, etc.), however for the most part they are all trying to get to a simpler internal and external only view to save their sanity. I do share data between views. In my zone I have a common file of all data that is going to be in both views which is then included in the respective view files. It just makes it simpler to edit it in one place. And in fact in our case the common file is the external view as the internal view only adds entries. If that make sense. The zones are all dynamic in my case, this just simplifies key management for DNSSEC as I allow BIND to handle most of the work. So yes I use DNS updates. However for the most part what I end up doing is freezing the zone/view editing the file and then thawing the zone/view. However, my needs are very modest. Views and DNSSEC are the only two reasons why I don't use the integrated DNS that is part of IPA. Y'all fix these two and you got me :). I can't speak much for the LDAP layout, y'all are better than me in that regard. But the above is my general usage scenario. -Erinn From chorn at fluxcoil.net Tue Oct 1 15:54:07 2013 From: chorn at fluxcoil.net (Christian Horn) Date: Tue, 1 Oct 2013 17:54:07 +0200 Subject: [Freeipa-users] DNS views: request for comments In-Reply-To: <524AE614.8090808@redhat.com> References: <524AE614.8090808@redhat.com> Message-ID: <20131001155407.GA26361@fluxcoil.net> Hi, On Tue, Oct 01, 2013 at 05:11:16PM +0200, Petr Spacek wrote: > Questions are: > - For what purpose do you use views? I see only use for 2 views: a) Internal clients, domain members. They - see everything (internet DNS records plus IPA domain data) - can request recursive lookups - one could consider DNS updates here b) Internet view - basically just handing out a single zone to the internet - no AXFR, no reqursive lookups, maybe rate limiting etc. as this is internet facing Christian From brian at interlinx.bc.ca Thu Oct 3 15:35:48 2013 From: brian at interlinx.bc.ca (Brian J. Murrell) Date: Thu, 03 Oct 2013 11:35:48 -0400 Subject: [Freeipa-users] /var/kerberos/krb5kdc/principal missing Message-ID: I have a FreeIPA server set up on EL 6.4 with the following package versions: ipa-admintools-3.0.0-26.el6_4.4.x86_64 krb5-libs-1.10.3-10.el6_4.6.x86_64 ipa-server-selinux-3.0.0-26.el6_4.4.x86_64 ipa-client-3.0.0-26.el6_4.4.x86_64 ipa-pki-common-theme-9.0.3-7.el6.noarch krb5-server-1.10.3-10.el6_4.6.x86_64 ipa-server-3.0.0-26.el6_4.4.x86_64 krb5-workstation-1.10.3-10.el6_4.6.x86_64 ipa-python-3.0.0-26.el6_4.4.x86_64 When I try to start it the startup fails: # ipactl start Starting Directory Service Starting dirsrv: EXAMPLE-COM... [ OK ] PKI-IPA... [ OK ] Starting KDC Service Starting Kerberos 5 KDC: krb5kdc: cannot initialize realm EXAMPLE.COM - see log file for details [FAILED] Failed to start KDC Service Shutting down Stopping Kerberos 5 KDC: [FAILED] Stopping Kerberos 5 Admin Server: [FAILED] Stopping httpd: [FAILED] Stopping pki-ca: [ OK ] Shutting down dirsrv: EXAMPLE-COM... [ OK ] PKI-IPA... [ OK ] Aborting ipactl So trying to start krb5kdc: # service krb5kdc start Starting Kerberos 5 KDC: krb5kdc: cannot initialize realm EXAMPLE.COM - see log file for details [FAILED] Unfortunately there is nothing in /var/log/krb5kdc.log. Looking in /var/log/messages I see: Oct 3 08:28:25 ipa0 krb5kdc[26676]: No such file or directory - while initializing database for realm EXAMPLE.COM Unfortunately it doesn't tell us which file is missing. Strace helps here though: # strace -f /usr/sbin/krb5kdc -r EXAMPLE.COM -P /var/run/krb5kdc.pid ... open("/var/kerberos/krb5kdc/principal", O_RDONLY) = -1 ENOENT (No such file or directory) gettimeofday({1380814261, 82991}, NULL) = 0 open("/etc/localtime", O_RDONLY) = 4 fstat(4, {st_mode=S_IFREG|0644, st_size=2819, ...}) = 0 fstat(4, {st_mode=S_IFREG|0644, st_size=2819, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f095f58d000 read(4, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0\0"..., 4096) = 2819 lseek(4, -1802, SEEK_CUR) = 1017 read(4, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\5\0\0\0\5\0\0\0\0"..., 4096) = 1802 close(4) = 0 munmap(0x7f095f58d000, 4096) = 0 sendto(3, "<35>Oct 3 08:31:01 krb5kdc[2669"..., 115, MSG_NOSIGNAL, NULL, 0) = 115 munmap(0x7f0956c7e000, 2200608) = 0 write(2, "krb5kdc: cannot initialize realm"..., 74krb5kdc: cannot initialize realm EXAMPLE.COM - see log file for details ) = 74 exit_group(1) = ? Sure enough /var/kerberos/krb5kdc/principal doesn't exist. I have no idea why though and no backup to restore from, yet. Was still in the process of setting this machine up. Is this a known issue? Any theories on why it went missing? And most importantly, any ideas on my recovery process here? Do I have to throw my KRB5 database away and start from scratch? Cheers, b. From rcritten at redhat.com Thu Oct 3 15:49:02 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 03 Oct 2013 11:49:02 -0400 Subject: [Freeipa-users] /var/kerberos/krb5kdc/principal missing In-Reply-To: References: Message-ID: <524D91EE.9060608@redhat.com> Brian J. Murrell wrote: > I have a FreeIPA server set up on EL 6.4 with the following package > versions: > > ipa-admintools-3.0.0-26.el6_4.4.x86_64 > krb5-libs-1.10.3-10.el6_4.6.x86_64 > ipa-server-selinux-3.0.0-26.el6_4.4.x86_64 > ipa-client-3.0.0-26.el6_4.4.x86_64 > ipa-pki-common-theme-9.0.3-7.el6.noarch > krb5-server-1.10.3-10.el6_4.6.x86_64 > ipa-server-3.0.0-26.el6_4.4.x86_64 > krb5-workstation-1.10.3-10.el6_4.6.x86_64 > ipa-python-3.0.0-26.el6_4.4.x86_64 > > When I try to start it the startup fails: > > # ipactl start > Starting Directory Service > Starting dirsrv: > EXAMPLE-COM... [ OK ] > PKI-IPA... [ OK ] > Starting KDC Service > Starting Kerberos 5 KDC: krb5kdc: cannot initialize realm EXAMPLE.COM - > see log file for details > [FAILED] > Failed to start KDC Service > Shutting down > Stopping Kerberos 5 KDC: [FAILED] > Stopping Kerberos 5 Admin Server: [FAILED] > Stopping httpd: [FAILED] > Stopping pki-ca: [ OK ] > Shutting down dirsrv: > EXAMPLE-COM... > [ OK ] > PKI-IPA... [ OK ] > Aborting ipactl > > So trying to start krb5kdc: > > # service krb5kdc start > Starting Kerberos 5 KDC: krb5kdc: cannot initialize realm EXAMPLE.COM - > see log file for details > [FAILED] > > Unfortunately there is nothing in /var/log/krb5kdc.log. Looking in > /var/log/messages I see: > > Oct 3 08:28:25 ipa0 krb5kdc[26676]: No such file or directory - while > initializing database for realm EXAMPLE.COM > > Unfortunately it doesn't tell us which file is missing. Strace helps > here though: > > # strace -f /usr/sbin/krb5kdc -r EXAMPLE.COM -P /var/run/krb5kdc.pid > ... > open("/var/kerberos/krb5kdc/principal", O_RDONLY) = -1 ENOENT (No such > file or directory) > gettimeofday({1380814261, 82991}, NULL) = 0 > open("/etc/localtime", O_RDONLY) = 4 > fstat(4, {st_mode=S_IFREG|0644, st_size=2819, ...}) = 0 > fstat(4, {st_mode=S_IFREG|0644, st_size=2819, ...}) = 0 > mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) > = 0x7f095f58d000 > read(4, > "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0\0"..., 4096) > = 2819 > lseek(4, -1802, SEEK_CUR) = 1017 > read(4, > "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\5\0\0\0\5\0\0\0\0"..., 4096) > = 1802 > close(4) = 0 > munmap(0x7f095f58d000, 4096) = 0 > sendto(3, "<35>Oct 3 08:31:01 krb5kdc[2669"..., 115, MSG_NOSIGNAL, > NULL, 0) = 115 > munmap(0x7f0956c7e000, 2200608) = 0 > write(2, "krb5kdc: cannot initialize realm"..., 74krb5kdc: cannot > initialize realm EXAMPLE.COM - see log file for details > ) = 74 > exit_group(1) = ? > > Sure enough /var/kerberos/krb5kdc/principal doesn't exist. I have no > idea why though and no backup to restore from, yet. Was still in the > process of setting this machine up. > > Is this a known issue? Any theories on why it went missing? > > And most importantly, any ideas on my recovery process here? Do I have > to throw my KRB5 database away and start from scratch? Can clues on how it got to this point? Files changed, etc? What does the dbmodules section of /etc/krb5.conf look like? rob From brian at interlinx.bc.ca Thu Oct 3 17:55:34 2013 From: brian at interlinx.bc.ca (Brian J. Murrell) Date: Thu, 03 Oct 2013 13:55:34 -0400 Subject: [Freeipa-users] /var/kerberos/krb5kdc/principal missing In-Reply-To: <524D91EE.9060608@redhat.com> References: <524D91EE.9060608@redhat.com> Message-ID: <524DAF96.80507@interlinx.bc.ca> On 13-10-03 11:49 AM, Rob Crittenden wrote: > > Can clues on how it got to this point? Files changed, etc? Not really. This machine has been sitting mostly dormant in fact since I was last working on it a week or two ago. > What does the dbmodules section of /etc/krb5.conf look like? And there it goes. Did you hear the other shoe drop? :-) A badly written configuration management recipe overwrote that file. I have one from an older FreeIPA that I can re-mold for this server but if anyone has one from a current EL6.4 machine I would feel more comfortable that I have a representative replacement. Cheers, b. From rcritten at redhat.com Thu Oct 3 18:16:36 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 03 Oct 2013 14:16:36 -0400 Subject: [Freeipa-users] /var/kerberos/krb5kdc/principal missing In-Reply-To: <524DAF96.80507@interlinx.bc.ca> References: <524D91EE.9060608@redhat.com> <524DAF96.80507@interlinx.bc.ca> Message-ID: <524DB484.809@redhat.com> Brian J. Murrell wrote: > On 13-10-03 11:49 AM, Rob Crittenden wrote: >> >> Can clues on how it got to this point? Files changed, etc? > > Not really. This machine has been sitting mostly dormant in fact since > I was last working on it a week or two ago. > >> What does the dbmodules section of /etc/krb5.conf look like? > > And there it goes. Did you hear the other shoe drop? :-) > > A badly written configuration management recipe overwrote that file. > > I have one from an older FreeIPA that I can re-mold for this server but > if anyone has one from a current EL6.4 machine I would feel more > comfortable that I have a representative replacement. > > Cheers, > b. > includedir /var/lib/sss/pubconf/krb5.include.d [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] default_realm = EXAMPLE.COM dns_lookup_realm = false dns_lookup_kdc = true rdns = false ticket_lifetime = 24h forwardable = yes [realms] EXAMPLE.COM = { kdc = ipa.EXAMPLE.COM:88 master_kdc = ipa.EXAMPLE.COM:88 admin_server = ipa.EXAMPLE.COM:749 default_domain = EXAMPLE.COM pkinit_anchors = FILE:/etc/ipa/ca.crt } [domain_realm] .EXAMPLE.COM = EXAMPLE.COM EXAMPLE.COM = EXAMPLE.COM [dbmodules] EXAMPLE.COM = { db_library = ipadb.so } From brian at interlinx.bc.ca Thu Oct 3 18:56:53 2013 From: brian at interlinx.bc.ca (Brian J. Murrell) Date: Thu, 03 Oct 2013 14:56:53 -0400 Subject: [Freeipa-users] /var/kerberos/krb5kdc/principal missing In-Reply-To: <524DB484.809@redhat.com> References: <524D91EE.9060608@redhat.com> <524DAF96.80507@interlinx.bc.ca> <524DB484.809@redhat.com> Message-ID: <524DBDF5.9080304@interlinx.bc.ca> Thanks much! That got things back up and running. Now to go fix the errant configuration management recipe. Cheers, b. From dpal at redhat.com Thu Oct 3 20:54:31 2013 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 03 Oct 2013 16:54:31 -0400 Subject: [Freeipa-users] RFE - groups of services In-Reply-To: References: Message-ID: <524DD987.9090809@redhat.com> On 10/01/2013 04:08 AM, Luk?s( Bezdic(ka wrote: > We came to situation when we need to add parameter memberOf to > services, but there is no configuration in 389 for this nor UI in > freeipa. Is it possible to implement groups for services? > > Example of usecase: > We have web service infront of which we put apache with kerberos > authentication and ldap authorization. This service is used by both > users and services/scripts running on nodes. For this we setup service > keytabs per service as we want them unprivileged and we don't want > those services to touch host's principal. This works pretty well so > far but management of the ldap authorization > makes it pain in the ass :( 1) Please explain what this means. What kind of access control you are talking about? In your application? You are looking to have something like HBAC library but for services that can be reused by applications? 2) Please answer above and file an RFE 3) The RFE would most likely get into a pile and sit there for couple years as we have other things that seem more pressing so contributing the code for something like this would be a good option. We can help and guide. Are you interested? Thanks Dmitri > In ideal usecase we'd love to see groups which can contain services or > users or hosts. > > Thank you, > Lukas Bezdicka > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. x ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Thu Oct 3 21:02:44 2013 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 03 Oct 2013 17:02:44 -0400 Subject: [Freeipa-users] Startup issue witrh dirsrv using slapi-nis In-Reply-To: References: Message-ID: <524DDB74.3080501@redhat.com> On 09/27/2013 08:13 AM, Ade wrote: > Hi > > I have a dirsrv server using the slapi-nis plugin to provide 190+ nis > maps. It works well apart from one issue - boot up > > If I do a reboot, the dirsrv starts up ok, but slapi-nis doesnt seem > to register to rpc - logging in and restarting dirsrv fixes it > > I tried disabling dirsrv and putting a start into rc.local - exactly the same > > I tried disabling dirsrv and putting a start into rc.local with a > sleep 120 first, and this works !! > > So it seems like it needs something to startup and settle first - any > ideas? I can see that rpcbind starts before dirsrv. I even wrote a > small script that waits for rpcinfo -p to return non zero before > continuing to start dirsrv - didnt work > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > Did anyone reply? Was the problem solved? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Thu Oct 3 21:05:36 2013 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 03 Oct 2013 17:05:36 -0400 Subject: [Freeipa-users] krb5kdc Additional pre-authentication required In-Reply-To: <61a401cebe52$3910ef90$ab32ceb0$@cheema@arrkgroup.com> References: <5d4a01cebde8$42833340$c78999c0$@cheema@arrkgroup.com> <20130930144659.GR10000@localhost.localdomain> <61a401cebe52$3910ef90$ab32ceb0$@cheema@arrkgroup.com> Message-ID: <524DDC20.9010502@redhat.com> On 09/30/2013 10:59 PM, Mohan Cheema wrote: >> -----Original Message----- >> From: freeipa-users-bounces at redhat.com [mailto:freeipa-users- >> bounces at redhat.com] On Behalf Of Sumit Bose >> Sent: Monday, September 30, 2013 3:47 PM >> To: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] krb5kdc Additional pre-authentication >> required >> >> On Mon, Sep 30, 2013 at 03:20:46PM +0100, Mohan Cheema wrote: >>> Hi, >>> >>> >>> >>> We are trying to authenticate from Windows machine and getting below >> error. >>> >>> >>> -------------------- >>> Sep 30 14:07:34 kdc1.domain.com krb5kdc[10105](info): AS_REQ (7 >> etypes {18 >>> 17 23 3 1 24 -135}) 10.43.2.45: NEEDED_PREAUTH: user at DOMAIN.COM for >>> krbtgt/DOMAIN.COM at DOMAIN.COM, Additional pre-authentication required >> This is expected behaviour. The client will first send the AS-REQ >> without any pre-authentication data. If the server requires >> pre-authentication for this principal it will return this error to the >> client to indicate that pre-authentication is expected. >>> Sep 30 14:07:34 kdc1.domain.com krb5kdc[10105](info): AS_REQ (7 >> etypes {18 >>> 17 23 3 1 24 -135}) 10.43.2.45: ISSUE: authtime 1380550054, etypes >> {rep=18 >>> tkt=18 ses=18}, user at DOMAIN.COM for krbtgt/DOMAIN.COM at DOMAIN.COM >> In the second AS-REQ the client has included some pre-authentication >> data which is accepted by the KDC and a ticket is issued to the client. >> >> HTH >> >> bye, >> Sumit >> >>> Sep 30 14:07:34 kdc1.domain.com krb5kdc[10105](info): TGS_REQ (7 >> etypes {18 >>> 17 23 3 1 24 -135}) 10.43.2.45: ISSUE: authtime 1380550054, etypes >> {rep=18 >>> tkt=23 ses=23}, user at DOMAIN.COM for host/av.domain.com at DOMAIN.COM >>> -------------------- >>> >>> >>> >>> We followed the instruction to integrate windows for authentication. >>> >>> >>> >>> Windows Client: Windows server 2008 R2 >>> >>> >>> >>> We are not able to figure out what the problem is. >>> >>> >>> >>> We are not using DNS server, instead we are using host file entries. >> DNS >>> server setup is not an option for us right now. >>> >>> >>> >>> Same user can authenticate from Linux machine. >>> >>> >>> >>> Regards, >>> >>> >>> >>> Mohan Cheema >>> >>> >>> >>> _______________________________________________ >>> 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 > Thanks for the info Sumit. > > However, if ticket is issued user should be able to login to system. Instead > on Windows we are getting "user name or password is incorrect". Are there > any other setting that needs to be done so that user can login to system. This thread seems to have no follow up. Was the problem solved? AFAIR for Windows system to allow the authentication one really needs to map user to a local user. There were some instructions in the HOWTO section of the IPA wiki. Have you checked them? > > Regards, > > Mohan > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From nalin at redhat.com Thu Oct 3 22:09:53 2013 From: nalin at redhat.com (Nalin Dahyabhai) Date: Thu, 3 Oct 2013 18:09:53 -0400 Subject: [Freeipa-users] Startup issue witrh dirsrv using slapi-nis In-Reply-To: <524DDB74.3080501@redhat.com> References: <524DDB74.3080501@redhat.com> Message-ID: <20131003220953.GA21036@redhat.com> On Thu, Oct 03, 2013 at 05:02:44PM -0400, Dmitri Pal wrote: > On 09/27/2013 08:13 AM, Ade wrote: > > I have a dirsrv server using the slapi-nis plugin to provide 190+ nis > > maps. It works well apart from one issue - boot up > > > > If I do a reboot, the dirsrv starts up ok, but slapi-nis doesnt seem > > to register to rpc - logging in and restarting dirsrv fixes it > > > > I tried disabling dirsrv and putting a start into rc.local - exactly the same > > > > I tried disabling dirsrv and putting a start into rc.local with a > > sleep 120 first, and this works !! > > > > So it seems like it needs something to startup and settle first - any > > ideas? I can see that rpcbind starts before dirsrv. I even wrote a > > small script that waits for rpcinfo -p to return non zero before > > continuing to start dirsrv - didnt work > > Did anyone reply? Not on the list, but given the sender, I think he found me elsewhere, and we debugged it. > Was the problem solved? Yes, it should be fixed in slapi-nis 0.50. That version reconnects to rpcbind if rpcbind has dropped the connection from the plugin since the plugin last connected to rpcbind (the plugin connects first before the server drops privileges, then after the server drops privileges, it computes the contents of map entries, and it only sends the registration request to rpcbind once it's ready to answer client queries). It turns out some RPC libraries (which rpcbind links with) will disconnect clients which they consider to be "idle" after some period, and that was biting us because computing map contents was taking more than that length of time, in part because the search filter that was used to select entries for use in populating NIS maps was referring to attributes that weren't indexed. Nalin From dpal at redhat.com Thu Oct 3 23:09:35 2013 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 03 Oct 2013 19:09:35 -0400 Subject: [Freeipa-users] Automated Kickstart Enrollment In-Reply-To: References: <56343345B145C043AE990701E3D1939501D56C0B@EXVS2.nrplc.localnet> <52260536.5070309@redhat.com> Message-ID: <524DF92F.5010500@redhat.com> On 09/28/2013 12:24 PM, Charlie Derwent wrote: > > On Tue, Sep 3, 2013 at 4:50 PM, Dmitri Pal > wrote: > > On 09/03/2013 04:21 AM, Innes, Duncan wrote: >> Hi folks, >> >> I've got a question about kickstart enrollment with a one-time >> password. Namely, is there any way that it can be done *without* >> the one-time password. We're comfortable with the pre-creation >> of the host in IPA, but just wonder if there's a way to enrol >> without the one-time password. >> >> The estate is Red Hat (mostly 6) and we deploy systems via >> kickstart from the Satellite. Can the Satellite push out a >> certificate from the IPA system that would allow client to enrol >> without the OTP? Our enrollment script runs as part of the >> kickstart postinstall with the OTP effectively sitting in plain >> text in the script. Removing the OTP would remove the plain text >> authentication from this script, but I may be opening other >> security holes as a result. >> > Hello, > > > There have been 3 ways about how the host can be enrolled: > a) High level admin using his credential (no need to have a > pre-created host) > b) Lower level admin using his credential (requires a pre-created > host) > c) OTP based (requires a pre-created host) > > All provisioning methods that use static kickstart files would > have to have something injected into the kickstart. OTP is the > safest and if leaked can be used to only provision this specific > system. The fact that OTP was stolen can be detected easily by > having a failed enrollment of the valid system combined with IPA > logs indicating that there was a successful enrollment of the new > host with the same name. The fact that intruder was able to join a > machine into IPA domain does not escalate his privileges against > other systems and since it can be easily caught it is a risk but > not a huge one. > > The right approach of cause is not to have the OTP stored in > kickstart but rather parameterized in some way. In Satellite 6 > (that we are looking at) this will be done via Foreman and its > smart proxies. The design is not polished yet but we hope that we > would be able to limit the exposure of the OTPs there. > > Also a new provisioning method has been added in FreeIPA 3.2 > mostly for re-provisioning - ability to provision if you already > have a keytab. > This method will be sort of equivalent to what you are asking with > a cert. But instead of the cert you would need to get keytab first > by creating a host and then using ipa-getkeytab command and > passing keytab to the kickstart. That can be done now and would > address the issue you are concerned about. > > Hi Dimitri (or anyone who knows), > > Is there anyway except for waiting for RHEL 6.5 to get FreeIPA 3.2+ > running in production? Really keen to get the re-provisioning > functionality up and running but don't want to run it on Fedora. Also > can you generate a keytab with ipa-getkeytab before you enrol a > host, possibly when you add a host to the ipa-server for the first > time? Or is the pattern provision with OTP first then backup keytab > and provision with keytab after? Sorry I am a bit behind with the e-mails. 1) 3.2 is in RHEL7 not 6.5 2) If you need it earlier you/we would have to backport but you need to go via "official" channels for this to happen in RHEL 3) AFAIR one should be able to add a host and then user ipa-getkeytab for it, deliver keytab to the host and use it for enrollment. This should work. If not IMO it is a bug. But I am not sure why you need it. The flow is the same as with OTP but more complex permissions wise. I mean getting OTP is simple, you can get it as a part of the host add while getting keytab requires separate call and privileges to actually get the keytab for the host. > > Thanks, > Charlie > > > > HTH > > Thanks, > Dmitri >> Cheers >> >> Duncan Innes >> >> >> This message has been checked for viruses and spam by the Virgin >> Money email scanning system powered by Messagelabs. >> >> >> >> This e-mail is intended to be confidential to the recipient. If >> you receive a copy in error, please inform the sender and then >> delete this message. >> >> Virgin Money plc - Registered in England and Wales (Company no. >> 6952311). Registered office - Jubilee House, Gosforth, Newcastle >> upon Tyne NE3 4PL. Virgin Money plc is authorised by the >> Prudential Regulation Authority and regulated by the Financial >> Conduct Authority and the Prudential Regulation Authority. >> >> The following companies also trade as Virgin Money. They are both >> authorised and regulated by the Financial Conduct Authority, are >> registered in England and Wales and have their registered office >> at Discovery House, Whiting Road, Norwich NR4 6EJ: Virgin Money >> Personal Financial Service Limited (Company no. 3072766) and >> Virgin Money Unit Trust Managers Limited (Company no. 3000482). >> >> For further details of Virgin Money group companies please visit >> our website at virginmoney.com >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > 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 for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Thu Oct 3 23:11:06 2013 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 03 Oct 2013 19:11:06 -0400 Subject: [Freeipa-users] Fwd: FreeIPA on Fedora 19 won't work In-Reply-To: References: <53DB8A94-C71C-45D2-86AD-004F7A13AA59@monkey.org> <51BB7971.1080001@RedHat.com> <20130617133324.GA24492@redhat.com> Message-ID: <524DF98A.2070808@redhat.com> On 09/29/2013 06:48 AM, Glenn Jenkins wrote: > Alexander Bokovoy writes: > >> On Fri, 14 Jun 2013, Steve Dickson wrote: >>> The $subject says it all... Any ideas what is going on here? >> I did fresh install right now on a up to date F19 VM and experienced no >> problem whatsoever. >> >> There were updates in pki-* and 389-ds-* packages over weekend. >> >>> 2013-06-14T16:54:45Z DEBUG Starting external process >>> 2013-06-14T16:54:45Z DEBUG args=/usr/sbin/pkispawn -s CA -f /tmp/tmpO2lDxI >>> 2013-06-14T16:54:51Z DEBUG Process finished, return code=1 >>> 2013-06-14T16:54:51Z DEBUG stdout=Loading deployment configuration from > /tmp/tmpO2lDxI. >> ^^^ The date corresponds to Friday last week, also there was issue with >> metadata information in Fedora 19 and Rawhide repositories which >> prevented proper packages propagating. >> >> Please try up to date packages from update-testing as of Monday. >> > I think this is similar to a bug I've seen reported elsewhere I believe the > underlying cause may be the HTTP_PROXY and HTTPS_PROXY variables. If these > are set then the ipa install script has problems locating the dogtag server > and fails. The error I see in my install log is something along the lines > of certificate server failed to restart. From the point of view of the > running script the failure looks the same as that produced if the script is > run twice. > > It should be easy to re-create this bug simply by setting HTTP_PROXY and > HTTPS_PROXY on a test server and running the server install. Posts in other > forums suggest re-installation solves the problem, I suggest this simply > removes these variables. Could the install script check for them being set > and unset-reset them or simply warn the user? Did we confirm that this is a bug? Was it filed? > > G > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From mohan.cheema at arrkgroup.com Fri Oct 4 03:15:01 2013 From: mohan.cheema at arrkgroup.com (Mohan Cheema) Date: Fri, 4 Oct 2013 04:15:01 +0100 Subject: [Freeipa-users] krb5kdc Additional pre-authentication required In-Reply-To: <524DDC20.9010502@redhat.com> References: <5d4a01cebde8$42833340$c78999c0$@cheema@arrkgroup.com> <20130930144659.GR10000@localhost.localdomain> <61a401cebe52$3910ef90$ab32ceb0$@cheema@arrkgroup.com> <524DDC20.9010502@redhat.com> Message-ID: <002101cec0af$eb2da510$c188ef30$@cheema@arrkgroup.com> Hi Dmitri, Yes its solved now. It didn't work with single user mapping I had map all users as per the HOWTO and it worked. Initially I was trying with just one user mapped to ipa user which didn't worked. Regards, Mohan > -----Original Message----- > From: freeipa-users-bounces at redhat.com [mailto:freeipa-users- > bounces at redhat.com] On Behalf Of Dmitri Pal > Sent: Thursday, October 03, 2013 10:06 PM > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] krb5kdc Additional pre-authentication > required > > On 09/30/2013 10:59 PM, Mohan Cheema wrote: > >> -----Original Message----- > >> From: freeipa-users-bounces at redhat.com [mailto:freeipa-users- > >> bounces at redhat.com] On Behalf Of Sumit Bose > >> Sent: Monday, September 30, 2013 3:47 PM > >> To: freeipa-users at redhat.com > >> Subject: Re: [Freeipa-users] krb5kdc Additional pre-authentication > >> required > >> > >> On Mon, Sep 30, 2013 at 03:20:46PM +0100, Mohan Cheema wrote: > >>> Hi, > >>> > >>> > >>> > >>> We are trying to authenticate from Windows machine and getting > below > >> error. > >>> > >>> > >>> -------------------- > >>> Sep 30 14:07:34 kdc1.domain.com krb5kdc[10105](info): AS_REQ (7 > >> etypes {18 > >>> 17 23 3 1 24 -135}) 10.43.2.45: NEEDED_PREAUTH: user at DOMAIN.COM for > >>> krbtgt/DOMAIN.COM at DOMAIN.COM, Additional pre-authentication > required > >> This is expected behaviour. The client will first send the AS-REQ > >> without any pre-authentication data. If the server requires > >> pre-authentication for this principal it will return this error to > the > >> client to indicate that pre-authentication is expected. > >>> Sep 30 14:07:34 kdc1.domain.com krb5kdc[10105](info): AS_REQ (7 > >> etypes {18 > >>> 17 23 3 1 24 -135}) 10.43.2.45: ISSUE: authtime 1380550054, etypes > >> {rep=18 > >>> tkt=18 ses=18}, user at DOMAIN.COM for krbtgt/DOMAIN.COM at DOMAIN.COM > >> In the second AS-REQ the client has included some pre-authentication > >> data which is accepted by the KDC and a ticket is issued to the > client. > >> > >> HTH > >> > >> bye, > >> Sumit > >> > >>> Sep 30 14:07:34 kdc1.domain.com krb5kdc[10105](info): TGS_REQ (7 > >> etypes {18 > >>> 17 23 3 1 24 -135}) 10.43.2.45: ISSUE: authtime 1380550054, etypes > >> {rep=18 > >>> tkt=23 ses=23}, user at DOMAIN.COM for host/av.domain.com at DOMAIN.COM > >>> -------------------- > >>> > >>> > >>> > >>> We followed the instruction to integrate windows for > authentication. > >>> > >>> > >>> > >>> Windows Client: Windows server 2008 R2 > >>> > >>> > >>> > >>> We are not able to figure out what the problem is. > >>> > >>> > >>> > >>> We are not using DNS server, instead we are using host file > entries. > >> DNS > >>> server setup is not an option for us right now. > >>> > >>> > >>> > >>> Same user can authenticate from Linux machine. > >>> > >>> > >>> > >>> Regards, > >>> > >>> > >>> > >>> Mohan Cheema > >>> > >>> > >>> > >>> _______________________________________________ > >>> 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 > > Thanks for the info Sumit. > > > > However, if ticket is issued user should be able to login to system. > Instead > > on Windows we are getting "user name or password is incorrect". Are > there > > any other setting that needs to be done so that user can login to > system. > > > This thread seems to have no follow up. > Was the problem solved? > AFAIR for Windows system to allow the authentication one really needs > to > map user to a local user. > There were some instructions in the HOWTO section of the IPA wiki. > Have you checked them? > > > > > Regards, > > > > Mohan > > > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > 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 dpal at redhat.com Fri Oct 4 03:38:18 2013 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 03 Oct 2013 23:38:18 -0400 Subject: [Freeipa-users] krb5kdc Additional pre-authentication required In-Reply-To: <002101cec0af$eb2da510$c188ef30$@cheema@arrkgroup.com> References: <5d4a01cebde8$42833340$c78999c0$@cheema@arrkgroup.com> <20130930144659.GR10000@localhost.localdomain> <61a401cebe52$3910ef90$ab32ceb0$@cheema@arrkgroup.com> <524DDC20.9010502@redhat.com> <002101cec0af$eb2da510$c188ef30$@cheema@arrkgroup.com> Message-ID: <524E382A.4010604@redhat.com> On 10/03/2013 11:15 PM, Mohan Cheema wrote: > Hi Dmitri, > > Yes its solved now. It didn't work with single user mapping I had map all > users as per the HOWTO and it worked. Initially I was trying with just one > user mapped to ipa user which didn't worked. Anything would be worth adding to the HOWTO based on your experience? > > Regards, > > Mohan > >> -----Original Message----- >> From: freeipa-users-bounces at redhat.com [mailto:freeipa-users- >> bounces at redhat.com] On Behalf Of Dmitri Pal >> Sent: Thursday, October 03, 2013 10:06 PM >> To: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] krb5kdc Additional pre-authentication >> required >> >> On 09/30/2013 10:59 PM, Mohan Cheema wrote: >>>> -----Original Message----- >>>> From: freeipa-users-bounces at redhat.com [mailto:freeipa-users- >>>> bounces at redhat.com] On Behalf Of Sumit Bose >>>> Sent: Monday, September 30, 2013 3:47 PM >>>> To: freeipa-users at redhat.com >>>> Subject: Re: [Freeipa-users] krb5kdc Additional pre-authentication >>>> required >>>> >>>> On Mon, Sep 30, 2013 at 03:20:46PM +0100, Mohan Cheema wrote: >>>>> Hi, >>>>> >>>>> >>>>> >>>>> We are trying to authenticate from Windows machine and getting >> below >>>> error. >>>>> >>>>> -------------------- >>>>> Sep 30 14:07:34 kdc1.domain.com krb5kdc[10105](info): AS_REQ (7 >>>> etypes {18 >>>>> 17 23 3 1 24 -135}) 10.43.2.45: NEEDED_PREAUTH: user at DOMAIN.COM for >>>>> krbtgt/DOMAIN.COM at DOMAIN.COM, Additional pre-authentication >> required >>>> This is expected behaviour. The client will first send the AS-REQ >>>> without any pre-authentication data. If the server requires >>>> pre-authentication for this principal it will return this error to >> the >>>> client to indicate that pre-authentication is expected. >>>>> Sep 30 14:07:34 kdc1.domain.com krb5kdc[10105](info): AS_REQ (7 >>>> etypes {18 >>>>> 17 23 3 1 24 -135}) 10.43.2.45: ISSUE: authtime 1380550054, etypes >>>> {rep=18 >>>>> tkt=18 ses=18}, user at DOMAIN.COM for krbtgt/DOMAIN.COM at DOMAIN.COM >>>> In the second AS-REQ the client has included some pre-authentication >>>> data which is accepted by the KDC and a ticket is issued to the >> client. >>>> HTH >>>> >>>> bye, >>>> Sumit >>>> >>>>> Sep 30 14:07:34 kdc1.domain.com krb5kdc[10105](info): TGS_REQ (7 >>>> etypes {18 >>>>> 17 23 3 1 24 -135}) 10.43.2.45: ISSUE: authtime 1380550054, etypes >>>> {rep=18 >>>>> tkt=23 ses=23}, user at DOMAIN.COM for host/av.domain.com at DOMAIN.COM >>>>> -------------------- >>>>> >>>>> >>>>> >>>>> We followed the instruction to integrate windows for >> authentication. >>>>> >>>>> >>>>> Windows Client: Windows server 2008 R2 >>>>> >>>>> >>>>> >>>>> We are not able to figure out what the problem is. >>>>> >>>>> >>>>> >>>>> We are not using DNS server, instead we are using host file >> entries. >>>> DNS >>>>> server setup is not an option for us right now. >>>>> >>>>> >>>>> >>>>> Same user can authenticate from Linux machine. >>>>> >>>>> >>>>> >>>>> Regards, >>>>> >>>>> >>>>> >>>>> Mohan Cheema >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>> Thanks for the info Sumit. >>> >>> However, if ticket is issued user should be able to login to system. >> Instead >>> on Windows we are getting "user name or password is incorrect". Are >> there >>> any other setting that needs to be done so that user can login to >> system. >> >> >> This thread seems to have no follow up. >> Was the problem solved? >> AFAIR for Windows system to allow the authentication one really needs >> to >> map user to a local user. >> There were some instructions in the HOWTO section of the IPA wiki. >> Have you checked them? >> >>> Regards, >>> >>> Mohan >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager for IdM portfolio >> 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 -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From mohan.cheema at arrkgroup.com Fri Oct 4 03:52:32 2013 From: mohan.cheema at arrkgroup.com (Mohan Cheema) Date: Fri, 4 Oct 2013 04:52:32 +0100 Subject: [Freeipa-users] FreeIPA client setup in AWS Message-ID: <005e01cec0b5$28ded9b0$7a9c8d10$@cheema@arrkgroup.com> Hi, We are number of Amazon AMI (Amazon Linux) in AWS. As this is based on RHEL we installed number of packages to enable user on those machine to get authenticated against ipa. The client gets configured with below warning. ----------------------------------- WARNING Installed OpenSSH server does not support dynamically loading authorized user keys. Public key authentication of IPA users will not be available. ----------------------------------- When user tries to authenticate the SSH connection is dropped, ipa server issues the authentication ticket to the machine. Packages that has been installed. ---------------------------------------------- ipa-python-3.0.0-25.el6.x86_64.rpm python-ldap-2.3.10-1.el6.x86_64.rpm cyrus-sasl-gssapi-2.1.23-13.el6_3.1.x86_64.rpm pam_krb5-2.3.11-9.el6.i686.rpm sssd-1.9.2-82.el6.x86_64.rpm certmonger-0.61-3.el6.x86_64.rpm oddjob-mkhomedir-0.30-5.el6.x86_64.rpm python-krbV-1.0.90-3.el6.x86_64.rpm libsss_autofs-1.9.2-82.el6.x86_64.rpm autofs-5.0.5-73.el6.x86_64.rpm nfs-utils-1.2.3-36.el6.x86_64.rpm sssd-client-1.9.2-82.el6.x86_64.rpm python-kerberos-1.1-6.2.el6.x86_64.rpm python-nss-0.13-1.el6.x86_64.rpm python-lxml-2.2.3-1.1.el6.x86_64.rpm python-netaddr-0.7.5-4.el6.noarch.rpm pyOpenSSL-0.10-2.el6.x86_64.rpm libipa_hbac-python-1.9.2-82.el6.x86_64.rpm libgssglue-0.1-11.el6.x86_64.rpm nfs-utils-lib-1.1.5-6.el6.x86_64.rpm rpcbind-0.2.0-11.el6.x86_64.rpm oddjob-0.30-5.el6.x86_64.rpm libipa_hbac-1.9.2-82.el6.x86_64.rpm libldb-1.1.13-3.el6.x86_64.rpm libsss_idmap-1.9.2-82.el6.x86_64.rpm libevent-1.4.13-4.el6.x86_64.rpm libtalloc-2.0.7-2.el6.x86_64.rpm keyutils-1.4-4.el6.x86_64.rpm libdhash-0.4.2-9.el6.x86_64.rpm libtirpc-0.2.1-5.el6.x86_64.rpm ipa-client-3.0.0-25.el6.x86_64.rpm libtevent-0.9.17-1.el6.x86_64.rpm libtdb-1.2.10-1.el6.x86_64.rpm libini_config-0.6.1-9.el6.x86_64.rpm libcollection-0.6.0-9.el6.x86_64.rpm libpath_utils-0.2.1-9.el6.x86_64.rpm libref_array-0.1.1-9.el6.x86_64.rpm c-ares-1.7.0-6.el6.x86_64.rpm samba4-libs-4.0.0-55.el6.rc4.x86_64.rpm libnl-1.1-14.el6.x86_64.rpm ---------------------------------------------- Are there any other package that need to be installed to make it working. Below is the ssh version. # rpm -qa | grep ssh libssh2-1.4.2-1.10.amzn1.x86_64 openssh-6.2p2-4.34.amzn1.x86_64 openssh-clients-6.2p2-4.34.amzn1.x86_64 openssh-server-6.2p2-4.34.amzn1.x86_64 Regards, Mohan -------------- next part -------------- An HTML attachment was scrubbed... URL: From mohan.cheema at arrkgroup.com Fri Oct 4 03:55:41 2013 From: mohan.cheema at arrkgroup.com (Mohan Cheema) Date: Fri, 4 Oct 2013 04:55:41 +0100 Subject: [Freeipa-users] krb5kdc Additional pre-authentication required In-Reply-To: <524E382A.4010604@redhat.com> References: <5d4a01cebde8$42833340$c78999c0$@cheema@arrkgroup.com> <20130930144659.GR10000@localhost.localdomain> <61a401cebe52$3910ef90$ab32ceb0$@cheema@arrkgroup.com> <524DDC20.9010502@redhat.com> <002101cec0af$eb2da510$c188ef30$@cheema@arrkgroup.com> <524E382A.4010604@redhat.com> Message-ID: <006301cec0b5$9938e7a0$cbaab6e0$@cheema@arrkgroup.com> > -----Original Message----- > From: Dmitri Pal [mailto:dpal at redhat.com] > Sent: Friday, October 04, 2013 4:38 AM > To: Mohan Cheema > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] krb5kdc Additional pre-authentication > required > > On 10/03/2013 11:15 PM, Mohan Cheema wrote: > > Hi Dmitri, > > > > Yes its solved now. It didn't work with single user mapping I had map > all > > users as per the HOWTO and it worked. Initially I was trying with > just one > > user mapped to ipa user which didn't worked. > > Anything would be worth adding to the HOWTO based on your experience? I think just mentioning that one need to map all the users instead of just single user and create only those windows user locally who will be accessing the machine. > > > > > Regards, > > > > Mohan > > > >> -----Original Message----- > >> From: freeipa-users-bounces at redhat.com [mailto:freeipa-users- > >> bounces at redhat.com] On Behalf Of Dmitri Pal > >> Sent: Thursday, October 03, 2013 10:06 PM > >> To: freeipa-users at redhat.com > >> Subject: Re: [Freeipa-users] krb5kdc Additional pre-authentication > >> required > >> > >> On 09/30/2013 10:59 PM, Mohan Cheema wrote: > >>>> -----Original Message----- > >>>> From: freeipa-users-bounces at redhat.com [mailto:freeipa-users- > >>>> bounces at redhat.com] On Behalf Of Sumit Bose > >>>> Sent: Monday, September 30, 2013 3:47 PM > >>>> To: freeipa-users at redhat.com > >>>> Subject: Re: [Freeipa-users] krb5kdc Additional pre-authentication > >>>> required > >>>> > >>>> On Mon, Sep 30, 2013 at 03:20:46PM +0100, Mohan Cheema wrote: > >>>>> Hi, > >>>>> > >>>>> > >>>>> > >>>>> We are trying to authenticate from Windows machine and getting > >> below > >>>> error. > >>>>> > >>>>> -------------------- > >>>>> Sep 30 14:07:34 kdc1.domain.com krb5kdc[10105](info): AS_REQ (7 > >>>> etypes {18 > >>>>> 17 23 3 1 24 -135}) 10.43.2.45: NEEDED_PREAUTH: user at DOMAIN.COM > for > >>>>> krbtgt/DOMAIN.COM at DOMAIN.COM, Additional pre-authentication > >> required > >>>> This is expected behaviour. The client will first send the AS-REQ > >>>> without any pre-authentication data. If the server requires > >>>> pre-authentication for this principal it will return this error to > >> the > >>>> client to indicate that pre-authentication is expected. > >>>>> Sep 30 14:07:34 kdc1.domain.com krb5kdc[10105](info): AS_REQ (7 > >>>> etypes {18 > >>>>> 17 23 3 1 24 -135}) 10.43.2.45: ISSUE: authtime 1380550054, > etypes > >>>> {rep=18 > >>>>> tkt=18 ses=18}, user at DOMAIN.COM for krbtgt/DOMAIN.COM at DOMAIN.COM > >>>> In the second AS-REQ the client has included some pre- > authentication > >>>> data which is accepted by the KDC and a ticket is issued to the > >> client. > >>>> HTH > >>>> > >>>> bye, > >>>> Sumit > >>>> > >>>>> Sep 30 14:07:34 kdc1.domain.com krb5kdc[10105](info): TGS_REQ (7 > >>>> etypes {18 > >>>>> 17 23 3 1 24 -135}) 10.43.2.45: ISSUE: authtime 1380550054, > etypes > >>>> {rep=18 > >>>>> tkt=23 ses=23}, user at DOMAIN.COM for host/av.domain.com at DOMAIN.COM > >>>>> -------------------- > >>>>> > >>>>> > >>>>> > >>>>> We followed the instruction to integrate windows for > >> authentication. > >>>>> > >>>>> > >>>>> Windows Client: Windows server 2008 R2 > >>>>> > >>>>> > >>>>> > >>>>> We are not able to figure out what the problem is. > >>>>> > >>>>> > >>>>> > >>>>> We are not using DNS server, instead we are using host file > >> entries. > >>>> DNS > >>>>> server setup is not an option for us right now. > >>>>> > >>>>> > >>>>> > >>>>> Same user can authenticate from Linux machine. > >>>>> > >>>>> > >>>>> > >>>>> Regards, > >>>>> > >>>>> > >>>>> > >>>>> Mohan Cheema > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> 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 > >>> Thanks for the info Sumit. > >>> > >>> However, if ticket is issued user should be able to login to > system. > >> Instead > >>> on Windows we are getting "user name or password is incorrect". Are > >> there > >>> any other setting that needs to be done so that user can login to > >> system. > >> > >> > >> This thread seems to have no follow up. > >> Was the problem solved? > >> AFAIR for Windows system to allow the authentication one really > needs > >> to > >> map user to a local user. > >> There were some instructions in the HOWTO section of the IPA wiki. > >> Have you checked them? > >> > >>> Regards, > >>> > >>> Mohan > >>> > >>> _______________________________________________ > >>> Freeipa-users mailing list > >>> Freeipa-users at redhat.com > >>> https://www.redhat.com/mailman/listinfo/freeipa-users > >> > >> -- > >> Thank you, > >> Dmitri Pal > >> > >> Sr. Engineering Manager for IdM portfolio > >> 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 > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > Regards, Mohan From dpal at redhat.com Fri Oct 4 11:46:46 2013 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 04 Oct 2013 07:46:46 -0400 Subject: [Freeipa-users] krb5kdc Additional pre-authentication required In-Reply-To: <006301cec0b5$9938e7a0$cbaab6e0$@cheema@arrkgroup.com> References: <5d4a01cebde8$42833340$c78999c0$@cheema@arrkgroup.com> <20130930144659.GR10000@localhost.localdomain> <61a401cebe52$3910ef90$ab32ceb0$@cheema@arrkgroup.com> <524DDC20.9010502@redhat.com> <002101cec0af$eb2da510$c188ef30$@cheema@arrkgroup.com> <524E382A.4010604@redhat.com> <006301cec0b5$9938e7a0$cbaab6e0$@cheema@arrkgroup.com> Message-ID: <524EAAA6.4090307@redhat.com> On 10/03/2013 11:55 PM, Mohan Cheema wrote: >> -----Original Message----- >> From: Dmitri Pal [mailto:dpal at redhat.com] >> Sent: Friday, October 04, 2013 4:38 AM >> To: Mohan Cheema >> Cc: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] krb5kdc Additional pre-authentication >> required >> >> On 10/03/2013 11:15 PM, Mohan Cheema wrote: >>> Hi Dmitri, >>> >>> Yes its solved now. It didn't work with single user mapping I had map >> all >>> users as per the HOWTO and it worked. Initially I was trying with >> just one >>> user mapped to ipa user which didn't worked. >> Anything would be worth adding to the HOWTO based on your experience? > > I think just mentioning that one need to map all the users instead of just > single user and create only those windows user locally who will be accessing > the machine. Well, http://www.freeipa.org/page/Windows_authentication_against_FreeIPA states "...for each user..." > >>> Regards, >>> >>> Mohan >>> >>>> -----Original Message----- >>>> From: freeipa-users-bounces at redhat.com [mailto:freeipa-users- >>>> bounces at redhat.com] On Behalf Of Dmitri Pal >>>> Sent: Thursday, October 03, 2013 10:06 PM >>>> To: freeipa-users at redhat.com >>>> Subject: Re: [Freeipa-users] krb5kdc Additional pre-authentication >>>> required >>>> >>>> On 09/30/2013 10:59 PM, Mohan Cheema wrote: >>>>>> -----Original Message----- >>>>>> From: freeipa-users-bounces at redhat.com [mailto:freeipa-users- >>>>>> bounces at redhat.com] On Behalf Of Sumit Bose >>>>>> Sent: Monday, September 30, 2013 3:47 PM >>>>>> To: freeipa-users at redhat.com >>>>>> Subject: Re: [Freeipa-users] krb5kdc Additional pre-authentication >>>>>> required >>>>>> >>>>>> On Mon, Sep 30, 2013 at 03:20:46PM +0100, Mohan Cheema wrote: >>>>>>> Hi, >>>>>>> >>>>>>> >>>>>>> >>>>>>> We are trying to authenticate from Windows machine and getting >>>> below >>>>>> error. >>>>>>> -------------------- >>>>>>> Sep 30 14:07:34 kdc1.domain.com krb5kdc[10105](info): AS_REQ (7 >>>>>> etypes {18 >>>>>>> 17 23 3 1 24 -135}) 10.43.2.45: NEEDED_PREAUTH: user at DOMAIN.COM >> for >>>>>>> krbtgt/DOMAIN.COM at DOMAIN.COM, Additional pre-authentication >>>> required >>>>>> This is expected behaviour. The client will first send the AS-REQ >>>>>> without any pre-authentication data. If the server requires >>>>>> pre-authentication for this principal it will return this error to >>>> the >>>>>> client to indicate that pre-authentication is expected. >>>>>>> Sep 30 14:07:34 kdc1.domain.com krb5kdc[10105](info): AS_REQ (7 >>>>>> etypes {18 >>>>>>> 17 23 3 1 24 -135}) 10.43.2.45: ISSUE: authtime 1380550054, >> etypes >>>>>> {rep=18 >>>>>>> tkt=18 ses=18}, user at DOMAIN.COM for krbtgt/DOMAIN.COM at DOMAIN.COM >>>>>> In the second AS-REQ the client has included some pre- >> authentication >>>>>> data which is accepted by the KDC and a ticket is issued to the >>>> client. >>>>>> HTH >>>>>> >>>>>> bye, >>>>>> Sumit >>>>>> >>>>>>> Sep 30 14:07:34 kdc1.domain.com krb5kdc[10105](info): TGS_REQ (7 >>>>>> etypes {18 >>>>>>> 17 23 3 1 24 -135}) 10.43.2.45: ISSUE: authtime 1380550054, >> etypes >>>>>> {rep=18 >>>>>>> tkt=23 ses=23}, user at DOMAIN.COM for host/av.domain.com at DOMAIN.COM >>>>>>> -------------------- >>>>>>> >>>>>>> >>>>>>> >>>>>>> We followed the instruction to integrate windows for >>>> authentication. >>>>>>> >>>>>>> Windows Client: Windows server 2008 R2 >>>>>>> >>>>>>> >>>>>>> >>>>>>> We are not able to figure out what the problem is. >>>>>>> >>>>>>> >>>>>>> >>>>>>> We are not using DNS server, instead we are using host file >>>> entries. >>>>>> DNS >>>>>>> server setup is not an option for us right now. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Same user can authenticate from Linux machine. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> >>>>>>> >>>>>>> Mohan Cheema >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>> Thanks for the info Sumit. >>>>> >>>>> However, if ticket is issued user should be able to login to >> system. >>>> Instead >>>>> on Windows we are getting "user name or password is incorrect". Are >>>> there >>>>> any other setting that needs to be done so that user can login to >>>> system. >>>> >>>> >>>> This thread seems to have no follow up. >>>> Was the problem solved? >>>> AFAIR for Windows system to allow the authentication one really >> needs >>>> to >>>> map user to a local user. >>>> There were some instructions in the HOWTO section of the IPA wiki. >>>> Have you checked them? >>>> >>>>> Regards, >>>>> >>>>> Mohan >>>>> >>>>> _______________________________________________ >>>>> Freeipa-users mailing list >>>>> Freeipa-users at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>> -- >>>> Thank you, >>>> Dmitri Pal >>>> >>>> Sr. Engineering Manager for IdM portfolio >>>> 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 >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager for IdM portfolio >> Red Hat Inc. >> >> >> ------------------------------- >> Looking to carve out IT costs? >> www.redhat.com/carveoutcosts/ >> > Regards, > > Mohan > -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Fri Oct 4 12:56:05 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 04 Oct 2013 08:56:05 -0400 Subject: [Freeipa-users] Fwd: FreeIPA on Fedora 19 won't work In-Reply-To: <524DF98A.2070808@redhat.com> References: <53DB8A94-C71C-45D2-86AD-004F7A13AA59@monkey.org> <51BB7971.1080001@RedHat.com> <20130617133324.GA24492@redhat.com> <524DF98A.2070808@redhat.com> Message-ID: <524EBAE5.6020203@redhat.com> Dmitri Pal wrote: > On 09/29/2013 06:48 AM, Glenn Jenkins wrote: >> Alexander Bokovoy writes: >> >>> On Fri, 14 Jun 2013, Steve Dickson wrote: >>>> The $subject says it all... Any ideas what is going on here? >>> I did fresh install right now on a up to date F19 VM and experienced no >>> problem whatsoever. >>> >>> There were updates in pki-* and 389-ds-* packages over weekend. >>> >>>> 2013-06-14T16:54:45Z DEBUG Starting external process >>>> 2013-06-14T16:54:45Z DEBUG args=/usr/sbin/pkispawn -s CA -f /tmp/tmpO2lDxI >>>> 2013-06-14T16:54:51Z DEBUG Process finished, return code=1 >>>> 2013-06-14T16:54:51Z DEBUG stdout=Loading deployment configuration from >> /tmp/tmpO2lDxI. >>> ^^^ The date corresponds to Friday last week, also there was issue with >>> metadata information in Fedora 19 and Rawhide repositories which >>> prevented proper packages propagating. >>> >>> Please try up to date packages from update-testing as of Monday. >>> >> I think this is similar to a bug I've seen reported elsewhere I believe the >> underlying cause may be the HTTP_PROXY and HTTPS_PROXY variables. If these >> are set then the ipa install script has problems locating the dogtag server >> and fails. The error I see in my install log is something along the lines >> of certificate server failed to restart. From the point of view of the >> running script the failure looks the same as that produced if the script is >> run twice. >> >> It should be easy to re-create this bug simply by setting HTTP_PROXY and >> HTTPS_PROXY on a test server and running the server install. Posts in other >> forums suggest re-installation solves the problem, I suggest this simply >> removes these variables. Could the install script check for them being set >> and unset-reset them or simply warn the user? > > Did we confirm that this is a bug? > Was it filed? The user added this information to https://bugzilla.redhat.com/show_bug.cgi?id=953488 last week. rob From rcritten at redhat.com Fri Oct 4 13:03:27 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 04 Oct 2013 09:03:27 -0400 Subject: [Freeipa-users] FreeIPA client setup in AWS In-Reply-To: <005e01cec0b5$28ded9b0$7a9c8d10$@cheema@arrkgroup.com> References: <005e01cec0b5$28ded9b0$7a9c8d10$@cheema@arrkgroup.com> Message-ID: <524EBC9F.7090209@redhat.com> Mohan Cheema wrote: > Hi, > > We are number of Amazon AMI (Amazon Linux) in AWS. As this is based on > RHEL we installed number of packages to enable user on those machine to > get authenticated against ipa. The client gets configured with below > warning. > > ----------------------------------- > WARNING Installed OpenSSH server does not support dynamically loading > authorized user keys. Public key authentication of IPA users will not be > available. > ----------------------------------- > > When user tries to authenticate the SSH connection is dropped, ipa > server issues the authentication ticket to the machine. > > Packages that has been installed. > > ---------------------------------------------- > ipa-python-3.0.0-25.el6.x86_64.rpm > > python-ldap-2.3.10-1.el6.x86_64.rpm > > cyrus-sasl-gssapi-2.1.23-13.el6_3.1.x86_64.rpm > > pam_krb5-2.3.11-9.el6.i686.rpm > > sssd-1.9.2-82.el6.x86_64.rpm > > certmonger-0.61-3.el6.x86_64.rpm > > oddjob-mkhomedir-0.30-5.el6.x86_64.rpm > > python-krbV-1.0.90-3.el6.x86_64.rpm > > libsss_autofs-1.9.2-82.el6.x86_64.rpm > > autofs-5.0.5-73.el6.x86_64.rpm > > nfs-utils-1.2.3-36.el6.x86_64.rpm > > sssd-client-1.9.2-82.el6.x86_64.rpm > > python-kerberos-1.1-6.2.el6.x86_64.rpm > > python-nss-0.13-1.el6.x86_64.rpm > > python-lxml-2.2.3-1.1.el6.x86_64.rpm > > python-netaddr-0.7.5-4.el6.noarch.rpm > > pyOpenSSL-0.10-2.el6.x86_64.rpm > > libipa_hbac-python-1.9.2-82.el6.x86_64.rpm > > libgssglue-0.1-11.el6.x86_64.rpm > > nfs-utils-lib-1.1.5-6.el6.x86_64.rpm > > rpcbind-0.2.0-11.el6.x86_64.rpm > > oddjob-0.30-5.el6.x86_64.rpm > > libipa_hbac-1.9.2-82.el6.x86_64.rpm > > libldb-1.1.13-3.el6.x86_64.rpm > > libsss_idmap-1.9.2-82.el6.x86_64.rpm > > libevent-1.4.13-4.el6.x86_64.rpm > > libtalloc-2.0.7-2.el6.x86_64.rpm > > keyutils-1.4-4.el6.x86_64.rpm > > libdhash-0.4.2-9.el6.x86_64.rpm > > libtirpc-0.2.1-5.el6.x86_64.rpm > > ipa-client-3.0.0-25.el6.x86_64.rpm > > libtevent-0.9.17-1.el6.x86_64.rpm > > libtdb-1.2.10-1.el6.x86_64.rpm > > libini_config-0.6.1-9.el6.x86_64.rpm > > libcollection-0.6.0-9.el6.x86_64.rpm > > libpath_utils-0.2.1-9.el6.x86_64.rpm > > libref_array-0.1.1-9.el6.x86_64.rpm > > c-ares-1.7.0-6.el6.x86_64.rpm > > samba4-libs-4.0.0-55.el6.rc4.x86_64.rpm > > libnl-1.1-14.el6.x86_64.rpm > ---------------------------------------------- > > Are there any other package that need to be installed to make it working. > > Below is the ssh version. > > # rpm -qa | grep ssh > > libssh2-1.4.2-1.10.amzn1.x86_64 > > openssh-6.2p2-4.34.amzn1.x86_64 > > openssh-clients-6.2p2-4.34.amzn1.x86_64 > > openssh-server-6.2p2-4.34.amzn1.x86_64 I'm guessing the problem is the Amazon-specific version of ssh. It needs to support one of these command combinations: AuthorizedKeysCommand and AuthorizedKeysCommandUser AuthorizedKeysCommand and AuthorizedKeysCommandRunAs PubKeyAgent and PubKeyAgentRunAs /var/log/ipaclient-install.log should contain the output of the probing for this support. rob From mussz624 at robertmorris.edu Fri Oct 4 14:34:28 2013 From: mussz624 at robertmorris.edu (Zach Musselman) Date: Fri, 4 Oct 2013 09:34:28 -0500 Subject: [Freeipa-users] IPA 3.0 RHEL 6.4 Message-ID: Hello, My company is having issues with our current install of IPA on RHEL 6.4. ** We had group patches that worked with IPA 2.2.0 and allowed us to enter samba groups directly in the IPA web interface. Red Hat is unable to confirm these patches are updated for IPA 3.0 RHEL 6.4 even though their Red Hat consultant created these a year ago. ** IPA password policy (history, length, complexity, etc.) enforcement Our current versions are not allowing the IPA password policy to work with Samba. My Windows users are able to change their password either MANUALLY or WHEN FORCED to reset via the IPA interface. However, non of the password history, length, complexity and so on are enforced with Samba and users are able to either keep the same password or change it to anything they want without restrictions. ** Samba password change also changing correctly the IPA expiration date so IPA can successfully reset the (sambaPwdLastSet: 0) value upon 90 days since last password change If we manually run ldapmodify and change the value of sambaPwdLastSet to equal 0, this correctly forces the end user to change their password in Windows. The issue though is their IPA password expiration date listed in the interface isn't correctly showing the amount of days to expire NEXT. I have a test user that has a password policy of 1 day expiration. I would expect this user to show an expiration date of the next day after password change but for some reason it always keeps showing about 90 days out, which is my default policy for all users. I need to be able to test that IPA is correctly expiring the password after 1 day so that I know in 90 days my other users will receive the same expiration. For most of this year password expiration was not working and IPA is showing a password expiration of months ago when their password should have expired (samba never prompted for this change). Since we updated to IPA 3.0, I'm hoping that when I reset their sambaPwdLastSet to 0 that IPA will start enforcing a 90 day expiration again. Any help you can provide on these issues would be greatly appreciated! Also, what would you recommend for future IPA versions and Samba? Will RHEL 6.5 include a newer version of IPA that will work and integrate better with Samba? Or should we start looking at other options that integrate our password features more as they are needed, like Samba 4? Thanks again! -- Zach -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Fri Oct 4 14:56:14 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 04 Oct 2013 10:56:14 -0400 Subject: [Freeipa-users] IPA 3.0 RHEL 6.4 In-Reply-To: References: Message-ID: <524ED70E.1080906@redhat.com> Zach Musselman wrote: > Hello, > > My company is having issues with our current install of IPA on RHEL 6.4. > > ** We had group patches that worked with IPA 2.2.0 and allowed us to > enter samba groups directly in the IPA web interface. Red Hat is unable > to confirm these patches are updated for IPA 3.0 RHEL 6.4 even though > their Red Hat consultant created these a year ago. I'm not clear what you mean by updated for IPA 3.0. Are you asking the patches to be rebased? It is also unclear if things were working properly with 2.2.0 and broke with 3.0, or if these things never worked, or something else. > > ** IPA password policy (history, length, complexity, etc.) enforcement > > Our current versions are not allowing the IPA password policy to work > with Samba. My Windows users are able to change their password either > MANUALLY or WHEN FORCED to reset via the IPA interface. However, non of > the password history, length, complexity and so on are enforced with > Samba and users are able to either keep the same password or change it > to anything they want without restrictions. Can you be more specific about where the password changes are happening? What do mean by manually? Changing it via the UI should apply password policy because that is really independent of any Samba changes that have been made. > > ** Samba password change also changing correctly the IPA expiration date > so IPA can successfully reset the (sambaPwdLastSet: 0) value upon 90 > days since last password change > > If we manually run ldapmodify and change the value of sambaPwdLastSet to > equal 0, this correctly forces the end user to change their password in > Windows. > > The issue though is their IPA password expiration date listed in the > interface isn't correctly showing the amount of days to expire NEXT. I > have a test user that has a password policy of 1 day expiration. I > would expect this user to show an expiration date of the next day after > password change but for some reason it always keeps showing about 90 > days out, which is my default policy for all users. > > I need to be able to test that IPA is correctly expiring the password > after 1 day so that I know in 90 days my other users will receive the > same expiration. > > For most of this year password expiration was not working and IPA is > showing a password expiration of months ago when their password should > have expired (samba never prompted for this change). Since we updated > to IPA 3.0, I'm hoping that when I reset their sambaPwdLastSet to 0 that > IPA will start enforcing a 90 day expiration again. I don't really know much about how Windows/Samba does password expiration, but IPA has no process to look at the last set date, compare that to the policy, and reset sambaPwdLastSet. Is that what you're expecting? > > Any help you can provide on these issues would be greatly appreciated! > > Also, what would you recommend for future IPA versions and Samba? Will > RHEL 6.5 include a newer version of IPA that will work and integrate > better with Samba? Or should we start looking at other options that > integrate our password features more as they are needed, like Samba 4? There are no Samba integration changes made that I know of. rob From dpal at redhat.com Fri Oct 4 15:14:01 2013 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 04 Oct 2013 11:14:01 -0400 Subject: [Freeipa-users] IPA 3.0 RHEL 6.4 In-Reply-To: References: Message-ID: <524EDB39.9090203@redhat.com> On 10/04/2013 10:34 AM, Zach Musselman wrote: > Hello, > > My company is having issues with our current install of IPA on RHEL 6.4. > > ** We had group patches that worked with IPA 2.2.0 and allowed us to > enter samba groups directly in the IPA web interface. Red Hat is > unable to confirm these patches are updated for IPA 3.0 RHEL 6.4 even > though their Red Hat consultant created these a year ago. > > > ** IPA password policy (history, length, complexity, etc.) enforcement > > Our current versions are not allowing the IPA password policy to work > with Samba. My Windows users are able to change their password either > MANUALLY or WHEN FORCED to reset via the IPA interface. However, non > of the password history, length, complexity and so on are enforced > with Samba and users are able to either keep the same password or > change it to anything they want without restrictions. > > > ** Samba password change also changing correctly the IPA expiration > date so IPA can successfully reset the (sambaPwdLastSet: 0) value upon > 90 days since last password change > > If we manually run ldapmodify and change the value of sambaPwdLastSet > to equal 0, this correctly forces the end user to change their > password in Windows. > > The issue though is their IPA password expiration date listed in the > interface isn't correctly showing the amount of days to expire NEXT. > I have a test user that has a password policy of 1 day expiration. I > would expect this user to show an expiration date of the next day > after password change but for some reason it always keeps showing > about 90 days out, which is my default policy for all users. > > I need to be able to test that IPA is correctly expiring the password > after 1 day so that I know in 90 days my other users will receive the > same expiration. > > For most of this year password expiration was not working and IPA is > showing a password expiration of months ago when their password should > have expired (samba never prompted for this change). Since we updated > to IPA 3.0, I'm hoping that when I reset their sambaPwdLastSet to 0 > that IPA will start enforcing a 90 day expiration again. > > > Any help you can provide on these issues would be greatly appreciated! > > Also, what would you recommend for future IPA versions and Samba? > Will RHEL 6.5 include a newer version of IPA that will work and > integrate better with Samba? Or should we start looking at other > options that integrate our password features more as they are needed, > like Samba 4? > > Thanks again! > Hello, We would be glad to help you but it is unclear what kind of setup you have. It is definitely something custom made that was created based on your requirements and not exactly usual use case we see in the community. So let us understand what we are talking about . Haw are you using Samba? As a file server, as a NT style DC or you are talking about Winbind? If you are using FreeIPA DS as a back end DS store for Samba then this something we did not try nor can guarantee would work between the IPA upgrades. Based on your comment above it looks like that you are trying to use Windows clients with Samba NT style DC that uses IPA as its back end store. If it is the case it is not something that we support upstream or recommend. And the main reason is that we anticipate it to be very fragile and hard to maintain (and your experience above proves that). So in the current situation the best would be to understand the requirements and see what is the best solution we can recommend based on the tools we have. Sorry that you went through such experience, it must be really frustrating. We will try to help the best we can. Thanks Dmitri > > -- > Zach > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Fri Oct 4 15:20:30 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 04 Oct 2013 17:20:30 +0200 Subject: [Freeipa-users] Announcing FreeIPA 3.3.2 Message-ID: <524EDCBE.6060107@redhat.com> The FreeIPA team is proud to announce FreeIPA v3.3.2! It can be downloaded from http://www.freeipa.org/page/Downloads. Fedora 19 builds are already on their way to updates-testing repo. == Highlights in 3.3.2 == === Enhancements === * Multiple domains from a trusted Active Directory forest supported now * Issue warnings when installed FreeIPA realm differs from the main domain as this setup prevents configuring AD trusts * Allow PKCS#12 files with empty password in install tools === Bug fixes === * ipa-replica-manage no longer returns RUV error when removing a replica * ipa-replica-install no longer crashes when being run against a master with older Directory Server * When creating AD trust, report supported enctypes based on Kerberos realm configuration * ... and numerous other small fixes === Test improvements === * New tests for forced client re-enrollment feature * Integration tests no longer require python-paramiko and can run on top of bare SSH connection * Numerous small fixes in beakerlib integration == Supporting Multiple Domains from Trusted Active Directory Forest == Previously only a root level domain of a trusted AD forest was supported. Now all domains of the trusted AD forest can access resources in a FreeIPA domain. Free IPA admins are now able to refresh list of domains from a trusted AD forest and selectively enable and disable specific domains from accessing resources in FreeIPA domain. Following commands were added to FreeIPA CLI: * ipa trust-fetch-domains ** Refresh list of domains from a trusted AD forest. By default all found domains belonging to the forest will be allowed to access IPA resources. * ipa trustdomain-find [domain] ** List domains of the trusted AD forest, displaying their attributes. When ''domain'' is specified in addition to the trust name, only information about ''domain'' is shown. * ipa trustdomain-disable ** Disable access from of the to IPA resources. * ipa trustdomain-enable ** Enable access from of the to IPA resources. * ipa trustdomain-del ** Remove information about of the from IPA view about the trusted AD forest. Users from will not be able to access IPA resources. Following IPA commands were extended: * ipa trust-add ** When trust to an AD forest is established, list of domains of the forest will be fetched and identity ranges for them will be created automatically. In case of POSIX attributes being managed by the AD forest, a single identity range for the trusted forest's root level domain will be re-used. ** When trust to an AD forest is established, list of domains associated with IPA is provided to the DC of the forest root level domain. This information is used to enable name suffix routing for systems belonging to IPA domain. As result, if IPA master servers don't belong to IPA DNS domain namespace, they will be able to access resources in the trusted AD forest. FreeIPA 3.3.2 requires use of SSSD 1.11.1 due to integration of non-root level forest domains support. == Upgrading == === FreeIPA servers with CA installed prior to version 3.1 === Manual upgrade procedure is required for FreeIPA servers installed with version prior to 3.1. Please see http://www.freeipa.org/page/Howto/Dogtag9ToDogtag10Migration for details. === Other FreeIPA servers and clients === An IPA server can be upgraded simply by installing updated rpms. The server does not need to be shut down in advance. Please note that if you are doing the upgrade in special environment (e.g. FedUp) which does not allow running the LDAP server during upgrade process, upgrade scripts need to be run manually after the first boot: # ipa-upgradeconfig # ipa-ldap-updater --upgrade Also note that the performance improvements require an extended set of indexes to be configured. RPM update for an IPA server with a excessive number of users may require several minutes to finish. If you have multiple servers you may upgrade them one at a time. It is expected that all servers will be upgraded in a relatively short period (days or weeks, not months). They should be able to co-exist peacefully but new features will not be available on old servers and enrolling a new client against an old server will result in the SSH keys not being uploaded. Downgrading a server once upgraded is not supported. Upgrading from 2.2.0 and later versions is supported. Upgrading from previous versions is not supported and has not been tested. An enrolled client does not need the new packages installed unless you want to re-enroll it. SSH keys for already installed clients are not uploaded, you will have to re-enroll the client or manually upload the keys. == Feedback == Please provide comments, bugs and other feedback via the freeipa-users mailing list (http://www.redhat.com/mailman/listinfo/freeipa-users) or #freeipa channel on Freenode. == Detailed Changelog since 3.3.1 == === Alexander Bokovoy (11): === * ipa-sam: do not modify objectclass when trust object already created * ipa-sam: do not leak LDAPMessage on ipa-sam initialization * ipa-sam: report supported enctypes based on Kerberos realm configuration * ipaserver/dcerpc.py: populate forest trust information using realmdomains * trusts: support subdomains in a forest * frontend: report arguments errors with better detail * ipaserver/dcerpc: remove use of trust account authentication * trust: integrate subdomains support into trust-add * ipasam: for subdomains pick up defaults for missing values * KDC: implement transition check for trusted domains * ipa-kdb: Handle parent-child relationship for subdomains === Ana Krivokapic (5): === * Add integration tests for forced client re-enrollment * Create DS user and group during ipa-restore * Add warning when uninstalling active replica * Do not crash if DS is down during server uninstall * Follow tmpfiles.d packaging guidelines === Jan Cholasta (3): === * Fix nsslapdPlugin object class after initial replication. * Read passwords from stdin when importing PKCS#12 files with pk12util. * Allow PKCS#12 files with empty password in install tools. === Martin Kosek (5): === * Use FQDN when creating MSDCS SRV records * Do not set DNS discovery domain in server mode * Require new SSSD to pull required AD subdomain fixes * Remove faulty DNS memberOf Task * Become IPA 3.3.2 === Nathaniel McCallum (1): === * Ensure credentials structure is initialized === Petr Spacek (1): === * Add timestamps to named debug logs in /var/named/data/named.run === Petr Viktorin (15): === * Remove __all__ specifications in ipaclient and ipaserver.install * Make make-lint compatible with Pylint 1.0 * test_integration.host: Move transport-related functionality to a new module * test_integration: Add OpenSSHTransport, used if paramiko is not available * ipatests.test_integration.test_caless: Fix mkdir_recursive call * ipatests.beakerlib_plugin: Warn instead of failing when some logs are missing * ipatests.order_plugin: Exclude test generators from the order * ipatests.beakerlib_plugin: Add argument of generated tests to test captions * ipatests.test_cmdline.test_help: Re-raise unexpected exceptions on failure * Add tests for installing with empty PKCS#12 password * Update translations from Transifex * ipa-client-install: Use direct RPC instead of api.Command * ipa-client-install: Verify RPC connection with a ping * Do not fail upgrade if the global anonymous read ACI is not found * ipapython.nsslib: Name arguments to NSPRError === Petr Vobornik (5): === * Fix RUV search scope in ipa-replica-manage * Fix redirection on deletion of last dns record entry * Allow edit of ipakrbokasdelegate in Web UI when attrlevelrights are unknown * Fix enablement of automount map type selector * ipatests.test_integration.host: Add logging to ldap_connect() === Simo Sorce (1): === * Add Delegation Info to MS-PAC === Sumit Bose (1): === * CLDAP: do not read IPA domain from hostname === Tomas Babej (3): === * Use getent admin at domain for nss check in ipa-client-install * Do not add trust to AD in case of IPA realm-domain mismatch * Warn user about realm-domain mismatch in install scripts From tompos at martos.bme.hu Fri Oct 4 15:21:19 2013 From: tompos at martos.bme.hu (Tamas Papp) Date: Fri, 04 Oct 2013 17:21:19 +0200 Subject: [Freeipa-users] service not starting after reboot Message-ID: <524EDCEF.6020504@martos.bme.hu> hi All, I installed freeipa on F19 by yum and ipa-server-install. It works fine until I reboot the machine, then it's not starting anymore: # ipactl start Existing service file detected! Assuming stale, cleaning and proceeding Starting Directory Service Failed to data from service file: Failed to get list of services to probe status: Directory Server is stopped Shutting down I'm not really familiar with systemd. Is there something I missed? # systemctl status dirsrv.target dirsrv.target - 389 Directory Server Loaded: loaded (/usr/lib/systemd/system/dirsrv.target; enabled) Active: inactive (dead) since Fri 2013-10-04 19:14:45 CEST; 2min 23s ago Oct 04 19:14:45 ipa12.bpo.cxn systemd[1]: Starting 389 Directory Server. Oct 04 19:14:45 ipa12.bpo.cxn systemd[1]: Reached target 389 Directory Server. Oct 04 19:14:45 ipa12.bpo.cxn systemd[1]: Stopping 389 Directory Server. Oct 04 19:14:45 ipa12.bpo.cxn systemd[1]: Stopped target 389 Directory Server. Thank you, tamas From mkosek at redhat.com Fri Oct 4 15:25:22 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 04 Oct 2013 17:25:22 +0200 Subject: [Freeipa-users] service not starting after reboot In-Reply-To: <524EDCEF.6020504@martos.bme.hu> References: <524EDCEF.6020504@martos.bme.hu> Message-ID: <524EDDE2.9090201@redhat.com> On 10/04/2013 05:21 PM, Tamas Papp wrote: > hi All, > > I installed freeipa on F19 by yum and ipa-server-install. > It works fine until I reboot the machine, then it's not starting anymore: > > # ipactl start > Existing service file detected! > Assuming stale, cleaning and proceeding > Starting Directory Service > Failed to data from service file: Failed to get list of services to probe status: > Directory Server is stopped > Shutting down > > > > I'm not really familiar with systemd. Is there something I missed? > > > # systemctl status dirsrv.target > dirsrv.target - 389 Directory Server > Loaded: loaded (/usr/lib/systemd/system/dirsrv.target; enabled) > Active: inactive (dead) since Fri 2013-10-04 19:14:45 CEST; 2min 23s ago > > Oct 04 19:14:45 ipa12.bpo.cxn systemd[1]: Starting 389 Directory Server. > Oct 04 19:14:45 ipa12.bpo.cxn systemd[1]: Reached target 389 Directory Server. > Oct 04 19:14:45 ipa12.bpo.cxn systemd[1]: Stopping 389 Directory Server. > Oct 04 19:14:45 ipa12.bpo.cxn systemd[1]: Stopped target 389 Directory Server. > > > Thank you, > tamas > It seems that dirsrv fails to start or ipactl is unable to read from it. Can you please: 1) Check /var/log/dirsrv/slapd-MARTINOVO-TEST/errors for start errors? 2) Check if there were not AVCs logged by FreeIPA installation or start? # ausearch -m avc -ts today That should help us start investigating your issue. Martin From mkosek at redhat.com Fri Oct 4 15:31:44 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 04 Oct 2013 17:31:44 +0200 Subject: [Freeipa-users] service not starting after reboot In-Reply-To: <524EDDE2.9090201@redhat.com> References: <524EDCEF.6020504@martos.bme.hu> <524EDDE2.9090201@redhat.com> Message-ID: <524EDF60.70202@redhat.com> On 10/04/2013 05:25 PM, Martin Kosek wrote: > On 10/04/2013 05:21 PM, Tamas Papp wrote: ... > 1) Check /var/log/dirsrv/slapd-MARTINOVO-TEST/errors for start errors? Of course, please replace "MARTINOVO-TEST" with your own realm that you configured FreeIPA with. Martin From tompos at martos.bme.hu Fri Oct 4 15:35:20 2013 From: tompos at martos.bme.hu (Tamas Papp) Date: Fri, 04 Oct 2013 17:35:20 +0200 Subject: [Freeipa-users] service not starting after reboot In-Reply-To: <524EDDE2.9090201@redhat.com> References: <524EDCEF.6020504@martos.bme.hu> <524EDDE2.9090201@redhat.com> Message-ID: <524EE038.8030707@martos.bme.hu> On 10/04/2013 05:25 PM, Martin Kosek wrote: > It seems that dirsrv fails to start or ipactl is unable to read from it. Can > you please: > > 1) Check /var/log/dirsrv/slapd-MARTINOVO-TEST/errors for start errors? Hmm, you're right, I could start with this. There was no /var/run/dirsrv I guess it supposed to be created by the init script? > 2) Check if there were not AVCs logged by FreeIPA installation or start? > # ausearch -m avc -ts today No result. Thanks, tamas From bill at pecknet.com Fri Oct 4 15:36:12 2013 From: bill at pecknet.com (Bill Peck) Date: Fri, 4 Oct 2013 11:36:12 -0400 Subject: [Freeipa-users] service not starting after reboot In-Reply-To: <524EDDE2.9090201@redhat.com> References: <524EDCEF.6020504@martos.bme.hu> <524EDDE2.9090201@redhat.com> Message-ID: Could be this bug? https://bugzilla.redhat.com/show_bug.cgi?id=996716 On Fri, Oct 4, 2013 at 11:25 AM, Martin Kosek wrote: > On 10/04/2013 05:21 PM, Tamas Papp wrote: > > hi All, > > > > I installed freeipa on F19 by yum and ipa-server-install. > > It works fine until I reboot the machine, then it's not starting anymore: > > > > # ipactl start > > Existing service file detected! > > Assuming stale, cleaning and proceeding > > Starting Directory Service > > Failed to data from service file: Failed to get list of services to > probe status: > > Directory Server is stopped > > Shutting down > > > > > > > > I'm not really familiar with systemd. Is there something I missed? > > > > > > # systemctl status dirsrv.target > > dirsrv.target - 389 Directory Server > > Loaded: loaded (/usr/lib/systemd/system/dirsrv.target; enabled) > > Active: inactive (dead) since Fri 2013-10-04 19:14:45 CEST; 2min 23s > ago > > > > Oct 04 19:14:45 ipa12.bpo.cxn systemd[1]: Starting 389 Directory Server. > > Oct 04 19:14:45 ipa12.bpo.cxn systemd[1]: Reached target 389 Directory > Server. > > Oct 04 19:14:45 ipa12.bpo.cxn systemd[1]: Stopping 389 Directory Server. > > Oct 04 19:14:45 ipa12.bpo.cxn systemd[1]: Stopped target 389 Directory > Server. > > > > > > Thank you, > > tamas > > > > It seems that dirsrv fails to start or ipactl is unable to read from it. > Can > you please: > > 1) Check /var/log/dirsrv/slapd-MARTINOVO-TEST/errors for start errors? > 2) Check if there were not AVCs logged by FreeIPA installation or start? > # ausearch -m avc -ts today > > That should help us start investigating your issue. > > Martin > > _______________________________________________ > 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 mkosek at redhat.com Fri Oct 4 15:51:27 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 04 Oct 2013 17:51:27 +0200 Subject: [Freeipa-users] service not starting after reboot In-Reply-To: <524EE038.8030707@martos.bme.hu> References: <524EDCEF.6020504@martos.bme.hu> <524EDDE2.9090201@redhat.com> <524EE038.8030707@martos.bme.hu> Message-ID: <524EE3FF.8090308@redhat.com> On 10/04/2013 05:35 PM, Tamas Papp wrote: > On 10/04/2013 05:25 PM, Martin Kosek wrote: >> It seems that dirsrv fails to start or ipactl is unable to read from it. Can >> you please: >> >> 1) Check /var/log/dirsrv/slapd-MARTINOVO-TEST/errors for start errors? > > Hmm, you're right, I could start with this. > There was no /var/run/dirsrv > > > I guess it supposed to be created by the init script? > >> 2) Check if there were not AVCs logged by FreeIPA installation or start? >> # ausearch -m avc -ts today > > No result. > > > Thanks, > tamas > This bug is probably the reason https://bugzilla.redhat.com/show_bug.cgi?id=1008306 Tamas, can you try updating to 389-ds-base-1.3.1.11-1.fc19 and checking if it fixes the /var/run/dirsrv issue? Martin From tompos at martos.bme.hu Fri Oct 4 18:49:24 2013 From: tompos at martos.bme.hu (Tamas Papp) Date: Fri, 04 Oct 2013 20:49:24 +0200 Subject: [Freeipa-users] service not starting after reboot In-Reply-To: <524EE3FF.8090308@redhat.com> References: <524EDCEF.6020504@martos.bme.hu> <524EDDE2.9090201@redhat.com> <524EE038.8030707@martos.bme.hu> <524EE3FF.8090308@redhat.com> Message-ID: <524F0DB4.9090408@martos.bme.hu> On 10/04/2013 05:51 PM, Martin Kosek wrote: > This bug is probably the reason > https://bugzilla.redhat.com/show_bug.cgi?id=1008306 > > Tamas, can you try updating to 389-ds-base-1.3.1.11-1.fc19 and checking if it > fixes the /var/run/dirsrv issue? Works like a charm. Thanks, tamas From mohan.cheema at arrkgroup.com Mon Oct 7 13:05:37 2013 From: mohan.cheema at arrkgroup.com (Mohan Cheema) Date: Mon, 7 Oct 2013 14:05:37 +0100 Subject: [Freeipa-users] Unable to install clien Message-ID: <18e601cec35d$ebca1f70$c35e5e50$@cheema@arrkgroup.com> Hi, I am trying to install client on one of the machine I'm getting following error: -------------------------------- Cannot obtain CA certificate 'ldap://ipa1.example.com' doesn't have a certificate. Installation failed. Rolling back changes. IPA client is not configured on this system. -------------------------------- I am able to install same on other clients. Output of running in debug ------------------------------------- /usr/sbin/ipa-client-install was invoked with options: {'domain': 'EXAMPLE.COM', 'force': False, 'krb5_offline_passwords': True, 'primary': True, 'mkhomedir': False, 'create_sshfp': True, 'conf_sshd': True, 'on_master': False, 'conf_ntp': True, 'ca_cert_file': None, 'ntp_server': None, 'principal': None, 'hostname': None, 'no_ac': False, 'unattended': None, 'sssd': True, 'trust_sshfp': False, 'dns_updates': False, 'realm_name': None, 'conf_ssh': True, 'server': ['ipa1.example.com', 'ipa2.example.com'], 'prompt_password': False, 'permit': False, 'debug': True, 'preserve_sssd': False, 'uninstall': False} missing options might be asked for interactively later Loading Index file from '/var/lib/ipa-client/sysrestore/sysrestore.index' Loading StateFile from '/var/lib/ipa-client/sysrestore/sysrestore.state' [IPA Discovery] Starting IPA discovery with domain=EXAMPLE.COM, server=['ipa1.example.com', 'ipa2.example.com'], hostname=perf-fe1.example.com Server and domain forced [Kerberos realm search] Search DNS for TXT record of _kerberos.EXAMPLE.COM. No DNS record found [LDAP server check] Verifying that ipa1.example.com (realm None) is an IPA server Init LDAP connection with: ldap://ipa1.example.com:389 Search LDAP server for IPA base DN Check if naming context 'dc=example,dc=com' is for IPA Naming context 'dc=example,dc=com' is a valid IPA context Search for (objectClass=krbRealmContainer) in dc=example,dc=com (sub) Found: cn=EXAMPLE.COM,cn=kerberos,dc=example,dc=com Discovery result: Success; server=ipa1.example.com, domain=EXAMPLE.COM, ipa=None, basedn=dc=example,dc=com will use discovered domain: EXAMPLE.COM Using servers from command line, disabling DNS discovery will use provided server: ipa1.example.com, ipa2.example.com Autodiscovery of servers for failover cannot work with this configuration. If you proceed with the installation, services will be configured to always access the discovered server for all operations and will not fail over to other servers in case of failure. Proceed with fixed values and no DNS discovery? [no]: yes will use discovered realm: EXAMPLE.COM will use discovered basedn: dc=example,dc=com [IPA Discovery] Starting IPA discovery with domain=EXAMPLE.COM, server=ipa2.example.com, hostname=perf-fe1.example.com Server and domain forced [Kerberos realm search] Search DNS for TXT record of _kerberos.EXAMPLE.COM. No DNS record found [LDAP server check] Verifying that ipa2.example.com (realm None) is an IPA server Init LDAP connection with: ldap://ipa2.example.com:389 Search LDAP server for IPA base DN Check if naming context 'dc=example,dc=com' is for IPA Naming context 'dc=example,dc=com' is a valid IPA context Search for (objectClass=krbRealmContainer) in dc=example,dc=com (sub) Found: cn=EXAMPLE.COM,cn=kerberos,dc=example,dc=com Discovery result: Success; server=ipa2.example.com, domain=EXAMPLE.COM, ipa=None, basedn=dc=example,dc=com Hostname: perf-fe1.example.com Hostname source: Machine's FQDN Realm: EXAMPLE.COM Realm source: Discovered from LDAP DNS records in ipa1.example.com DNS Domain: EXAMPLE.COM DNS Domain source: Forced IPA Server: ipa1.example.com, ipa2.example.com IPA Server source: Provided as option BaseDN: dc=example,dc=com BaseDN source: From IPA server ldap://ipa1.example.com:389 Continue to configure the system with these values? [no]: yes args=/usr/sbin/ipa-rmkeytab -k /etc/krb5.keytab -r EXAMPLE.COM stdout= stderr=Failed to open keytab '/etc/krb5.keytab': No such file or directory User authorized to enroll computers: admin Synchronizing time with KDC... Search DNS for SRV record of _ntp._udp.EXAMPLE.COM. No DNS record found args=/usr/sbin/ntpdate -U ntp -s -b -v ipa1.example.com stdout= stderr= args=/usr/sbin/ntpdate -U ntp -s -b -v ipa1.example.com stdout= stderr= args=/usr/sbin/ntpdate -U ntp -s -b -v ipa1.example.com stdout= stderr= Unable to sync time with IPA NTP server, assuming the time is in sync. Please check that 123 UDP port is opened. Writing Kerberos configuration to /tmp/tmpune77A: #File modified by ipa-client-install includedir /var/lib/sss/pubconf/krb5.include.d/ [libdefaults] default_realm = EXAMPLE.COM dns_lookup_realm = false dns_lookup_ipa = false rdns = false ticket_lifetime = 24h forwardable = yes [realms] EXAMPLE.COM = { ipa = ipa1.example.com:88 master_ipa = ipa1.example.com:88 admin_server = ipa1.example.com:749 ipa = ipa2.example.com:88 master_ipa = ipa2.example.com:88 admin_server = ipa2.example.com:749 default_domain = EXAMPLE.COM pkinit_anchors = FILE:/etc/ipa/ca.crt } [domain_realm] .EXAMPLE.COM = EXAMPLE.COM EXAMPLE.COM = EXAMPLE.COM .example.com = EXAMPLE.COM example.com = EXAMPLE.COM Password for admin at EXAMPLE.COM: args=kinit admin at EXAMPLE.COM stdout=Password for admin at EXAMPLE.COM: stderr= trying to retrieve CA cert via LDAP from ldap://ipa1.example.com get_ca_cert_from_ldap() error: Unknown authentication method SASL(-4): no mechanism available: No worthy mechs found {'info': 'SASL(-4): no mechanism available: No worthy mechs found', 'desc': 'Unknown authentication method'} Cannot obtain CA certificate 'ldap://ipa1.example.com' doesn't have a certificate. Installation failed. Rolling back changes. IPA client is not configured on this system. ------------------------------------- Seeing above it seems that LDAP is not running on SSL I have verified it following command 'ldapsearch -Y GSSAPI -b "dc=example,dc=com" uid=admin' and it does return the results. Any help/info will be really helpful. Regards, Mohan -------------- next part -------------- An HTML attachment was scrubbed... URL: From tompos at martos.bme.hu Mon Oct 7 16:06:36 2013 From: tompos at martos.bme.hu (Tamas Papp) Date: Mon, 07 Oct 2013 18:06:36 +0200 Subject: [Freeipa-users] memberOf Message-ID: <5252DC0C.4080307@martos.bme.hu> hi All, I have a fedora directory server with memberOf attributes. I'm able to migrate users to Freeipa, but I can see there are no such attributes at the new place. If I understand correctly, a memberOf plugin should be enabled. How can I do that? Thanks, tamas From dpal at redhat.com Mon Oct 7 16:24:50 2013 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 07 Oct 2013 12:24:50 -0400 Subject: [Freeipa-users] memberOf In-Reply-To: <5252DC0C.4080307@martos.bme.hu> References: <5252DC0C.4080307@martos.bme.hu> Message-ID: <5252E052.8070401@redhat.com> On 10/07/2013 12:06 PM, Tamas Papp wrote: > hi All, > > I have a fedora directory server with memberOf attributes. > I'm able to migrate users to Freeipa, but I can see there are no such > attributes at the new place. > If I understand correctly, a memberOf plugin should be enabled. How can > I do that? > > Thanks, > tamas > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users Are you using ipa migrate-ds command? Were your groups migrated? If there are no groups then the membership will not be migrated. Memeberof is enabled by default so there might be something wrong with how the migration happened. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From tompos at martos.bme.hu Mon Oct 7 16:32:37 2013 From: tompos at martos.bme.hu (Tamas Papp) Date: Mon, 07 Oct 2013 18:32:37 +0200 Subject: [Freeipa-users] memberOf In-Reply-To: <5252DC0C.4080307@martos.bme.hu> References: <5252DC0C.4080307@martos.bme.hu> Message-ID: <5252E225.6030304@martos.bme.hu> On 10/07/2013 06:06 PM, Tamas Papp wrote: > hi All, > > I have a fedora directory server with memberOf attributes. > I'm able to migrate users to Freeipa, but I can see there are no such > attributes at the new place. > If I understand correctly, a memberOf plugin should be enabled. How can > I do that? I wasn't correct here. This works: # ldapsearch -Y GSSAPI 2>/dev/null |grep memberOf|wc -l 2424 This not: # ldapsearch -x 2>/dev/null |grep memberOf|wc -l 0 I miss something, but I don't know, what. I'm not really an ldap or IPA expert, please give me some advise:) Thanks, tamas From dpal at redhat.com Mon Oct 7 18:59:18 2013 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 07 Oct 2013 14:59:18 -0400 Subject: [Freeipa-users] memberOf In-Reply-To: <5252E225.6030304@martos.bme.hu> References: <5252DC0C.4080307@martos.bme.hu> <5252E225.6030304@martos.bme.hu> Message-ID: <52530486.8030809@redhat.com> On 10/07/2013 12:32 PM, Tamas Papp wrote: > On 10/07/2013 06:06 PM, Tamas Papp wrote: >> hi All, >> >> I have a fedora directory server with memberOf attributes. >> I'm able to migrate users to Freeipa, but I can see there are no such >> attributes at the new place. >> If I understand correctly, a memberOf plugin should be enabled. How can >> I do that? > I wasn't correct here. > > This works: > # ldapsearch -Y GSSAPI 2>/dev/null |grep memberOf|wc -l > 2424 > > > This not: > # ldapsearch -x 2>/dev/null |grep memberOf|wc -l > 0 > > > I miss something, but I don't know, what. I'm not really an ldap or IPA > expert, please give me some advise:) With anonymous bind you do not see any data. With GSSAPI you authenticate and thus entitled to see what you are looking for. > > Thanks, > tamas > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From tompos at martos.bme.hu Mon Oct 7 20:18:19 2013 From: tompos at martos.bme.hu (Tamas Papp) Date: Mon, 07 Oct 2013 22:18:19 +0200 Subject: [Freeipa-users] memberOf In-Reply-To: <52530486.8030809@redhat.com> References: <5252DC0C.4080307@martos.bme.hu> <5252E225.6030304@martos.bme.hu> <52530486.8030809@redhat.com> Message-ID: <5253170B.2050708@martos.bme.hu> On 10/07/2013 08:59 PM, Dmitri Pal wrote: > On 10/07/2013 12:32 PM, Tamas Papp wrote: >> On 10/07/2013 06:06 PM, Tamas Papp wrote: >>> hi All, >>> >>> I have a fedora directory server with memberOf attributes. >>> I'm able to migrate users to Freeipa, but I can see there are no such >>> attributes at the new place. >>> If I understand correctly, a memberOf plugin should be enabled. How can >>> I do that? >> I wasn't correct here. >> >> This works: >> # ldapsearch -Y GSSAPI 2>/dev/null |grep memberOf|wc -l >> 2424 >> >> >> This not: >> # ldapsearch -x 2>/dev/null |grep memberOf|wc -l >> 0 >> >> >> I miss something, but I don't know, what. I'm not really an ldap or IPA >> expert, please give me some advise:) > With anonymous bind you do not see any data. With GSSAPI you > authenticate and thus entitled to see what you are looking for. > I see, that's true. Although I don't understand why memberOf not works if every other information available? ldapsearch -x uid=user and ldapsearch -x cn=group works fine. Therefore all information is available, just not showed up right. Am I wrong? Thanks, tamas From rcritten at redhat.com Mon Oct 7 20:21:25 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 07 Oct 2013 16:21:25 -0400 Subject: [Freeipa-users] memberOf In-Reply-To: <5253170B.2050708@martos.bme.hu> References: <5252DC0C.4080307@martos.bme.hu> <5252E225.6030304@martos.bme.hu> <52530486.8030809@redhat.com> <5253170B.2050708@martos.bme.hu> Message-ID: <525317C5.8030407@redhat.com> Tamas Papp wrote: > > On 10/07/2013 08:59 PM, Dmitri Pal wrote: >> On 10/07/2013 12:32 PM, Tamas Papp wrote: >>> On 10/07/2013 06:06 PM, Tamas Papp wrote: >>>> hi All, >>>> >>>> I have a fedora directory server with memberOf attributes. >>>> I'm able to migrate users to Freeipa, but I can see there are no such >>>> attributes at the new place. >>>> If I understand correctly, a memberOf plugin should be enabled. How can >>>> I do that? >>> I wasn't correct here. >>> >>> This works: >>> # ldapsearch -Y GSSAPI 2>/dev/null |grep memberOf|wc -l >>> 2424 >>> >>> >>> This not: >>> # ldapsearch -x 2>/dev/null |grep memberOf|wc -l >>> 0 >>> >>> >>> I miss something, but I don't know, what. I'm not really an ldap or IPA >>> expert, please give me some advise:) >> With anonymous bind you do not see any data. With GSSAPI you >> authenticate and thus entitled to see what you are looking for. >> > > I see, that's true. > Although I don't understand why memberOf not works if every other > information available? > > ldapsearch -x uid=user and ldapsearch -x cn=group works fine. Therefore > all information is available, just not showed up right. > Am I wrong? memberOf can contain some privileged information that you don't want to expose to anonymous users, like sudo and HBAC rule membership. rob From joe.hoot at itec.suny.edu Mon Oct 7 23:30:38 2013 From: joe.hoot at itec.suny.edu (Hoot, Joseph) Date: Mon, 7 Oct 2013 23:30:38 +0000 Subject: [Freeipa-users] Requesting IDM Consulting Message-ID: Hi all, I'm interested in finding a consultant who might be able to help us with our IDM solutions. Does anyone have any suggestions as to who would be good to use for discussing a possible engagement with? Thanks, Joe =========================== Joseph R. Hoot @ SUNY ITEC Supervising Programmer/Analyst (w) 716-878-4832 (Office - Receptionist/able to leave message) (w) 716-878-4863 (Direct - no voicemail) (c) 716-759-HOOT joe.hoot at itec.suny.edu GPG KEY: 7145F633 =========================== Managing trade-offs, attempting to reduce risk, instilling trust, and accepting responsibility for the system and networking team at SUNY ITEC. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Tue Oct 8 06:43:46 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 08 Oct 2013 08:43:46 +0200 Subject: [Freeipa-users] what was the meaning of 'ion>' in SELinux docs? In-Reply-To: References: Message-ID: <5253A9A2.1000903@redhat.com> Hello, I'm forwarding the question below to FreeIPA-users list. Broader audience could be interested in the answer :-) Petr^2 Spacek -------- Original Message -------- Subject: [Freeipa-devel] [DOC] what was the meaning? Date: Mon, 7 Oct 2013 22:43:05 +0200 To: Freeipa-devel at redhat.com Hi all, Found in SelinuxMap.xml: As with adding a user to a ion> value identifies the host-based access control rule to use for mapping. The access control rule must specify both users and hosts appropriately so that the SELinux map can construct the SELinux user, &IPA; user, and host triple. What was "ion>" supposed to be? Regards, J. -- J?r?me Fenal From mkosek at redhat.com Tue Oct 8 10:07:26 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 08 Oct 2013 12:07:26 +0200 Subject: [Freeipa-users] what was the meaning of 'ion>' in SELinux docs? In-Reply-To: <5253A9A2.1000903@redhat.com> References: <5253A9A2.1000903@redhat.com> Message-ID: <5253D95E.1050702@redhat.com> On 10/08/2013 08:43 AM, Petr Spacek wrote: > Hello, > > I'm forwarding the question below to FreeIPA-users list. Broader audience could > be interested in the answer :-) > > Petr^2 Spacek > > -------- Original Message -------- > Subject: [Freeipa-devel] [DOC] what was the meaning? > Date: Mon, 7 Oct 2013 22:43:05 +0200 > To: Freeipa-devel at redhat.com > > Hi all, > > Found in SelinuxMap.xml: > > As with adding a user to a ion> value identifies > the host-based access control rule to use for mapping. The access > control rule must specify both users and hosts appropriately so that > the SELinux map can construct the SELinux user, &IPA; user, and host > triple. > > What was "ion>" supposed to be? > > Regards, > > J. This is just a typo in docs, see my response on freeipa-devel: -------- Original Message -------- Subject: Re: [Freeipa-devel] [DOC] what was the meaning? Date: Tue, 08 Oct 2013 09:31:59 +0200 From: Martin Kosek To: J?r?me Fenal CC: Freeipa-devel at redhat.com ... I see this was wrong even in the original version of the paragraph. The first sentence is actually pretty cryptic. I would rather replace the whole paragraph with """ A specific user or host can be removed from an SELinux map by using either the selinuxusermap-remove-host or selinuxusermap-remove-user command. """ which is now above it. Ccing Petr and Martin to check that. Martin From mussz624 at robertmorris.edu Tue Oct 8 14:25:47 2013 From: mussz624 at robertmorris.edu (Zachary Musselman) Date: Tue, 8 Oct 2013 09:25:47 -0500 Subject: [Freeipa-users] IPA 3.0 RHEL 6.4 In-Reply-To: <524ED70E.1080906@redhat.com> References: <524ED70E.1080906@redhat.com> Message-ID: Hello Dmitri, We are currently using Samba as a file server and a DC with NT style domain for our Windows clients. IPA is the password backend for Samba. Our Red Hat consultant originally had the following items working when this system was installed last year. ** Ability to add groups in the IPA web interface for samba I have these patches and need to make sure that they work with IPA 3.0 and RHEL 6.4 before I apply them. ** We have a default password policy of 90 days expiration. This policy also has complexity, history, length, etc. Early this year that 90 day expiration stopped working and my Windows users were no longer receiving a "must change password" notice. We were hoping the update to RHEL 6.4 and IPA 3.0 would fix this but it has not. Currently my users are showing an EXPIRATION in IPA of June/July or so time frame. Back in April we manually changed all user's passwords to a temporary. That prompted them to login and change their password, hoping this would kickstart the 90 day expiration again. That was NOT successful. At a MINIMUM we are needing to correctly have IPA expire a user's password and allow Samba to understand that as well based on the password policy IPA shows for a given user. I have a test user who has a 2nd password policy we created. That users has 1 day expiration within IPA. When I change the following value using ldapmodify, It CORRECTLY makes Samba prompt the user to change their password when logging in the next time. When I change this test password, IPA reset's the EXPIRATION DATE to 90 days out and not 1 day from the time password was changed. --- A third item we need fixed if possible, is the ability to enforce password complexity, history, length, etc. through Samba based on what IPA shows for a user's password policy. I cannot confirm if this WAS working or not after it was initially installed. I guess you or Rob would be the individuals who could tell me what is possible to enable this feature. On Fri, Oct 4, 2013 at 9:56 AM, Rob Crittenden wrote: > Zach Musselman wrote: > >> Hello, >> >> My company is having issues with our current install of IPA on RHEL 6.4. >> >> ** We had group patches that worked with IPA 2.2.0 and allowed us to >> enter samba groups directly in the IPA web interface. Red Hat is unable >> to confirm these patches are updated for IPA 3.0 RHEL 6.4 even though >> their Red Hat consultant created these a year ago. >> > > I'm not clear what you mean by updated for IPA 3.0. Are you asking the > patches to be rebased? > > It is also unclear if things were working properly with 2.2.0 and broke > with 3.0, or if these things never worked, or something else. > > >> ** IPA password policy (history, length, complexity, etc.) enforcement >> >> Our current versions are not allowing the IPA password policy to work >> with Samba. My Windows users are able to change their password either >> MANUALLY or WHEN FORCED to reset via the IPA interface. However, non of >> the password history, length, complexity and so on are enforced with >> Samba and users are able to either keep the same password or change it >> to anything they want without restrictions. >> > > Can you be more specific about where the password changes are happening? > What do mean by manually? Changing it via the UI should apply password > policy because that is really independent of any Samba changes that have > been made. > > >> ** Samba password change also changing correctly the IPA expiration date >> so IPA can successfully reset the (sambaPwdLastSet: 0) value upon 90 >> days since last password change >> >> If we manually run ldapmodify and change the value of sambaPwdLastSet to >> equal 0, this correctly forces the end user to change their password in >> Windows. >> >> The issue though is their IPA password expiration date listed in the >> interface isn't correctly showing the amount of days to expire NEXT. I >> have a test user that has a password policy of 1 day expiration. I >> would expect this user to show an expiration date of the next day after >> password change but for some reason it always keeps showing about 90 >> days out, which is my default policy for all users. >> >> I need to be able to test that IPA is correctly expiring the password >> after 1 day so that I know in 90 days my other users will receive the >> same expiration. >> >> For most of this year password expiration was not working and IPA is >> showing a password expiration of months ago when their password should >> have expired (samba never prompted for this change). Since we updated >> to IPA 3.0, I'm hoping that when I reset their sambaPwdLastSet to 0 that >> IPA will start enforcing a 90 day expiration again. >> > > I don't really know much about how Windows/Samba does password expiration, > but IPA has no process to look at the last set date, compare that to the > policy, and reset sambaPwdLastSet. Is that what you're expecting? > > >> Any help you can provide on these issues would be greatly appreciated! >> >> Also, what would you recommend for future IPA versions and Samba? Will >> RHEL 6.5 include a newer version of IPA that will work and integrate >> better with Samba? Or should we start looking at other options that >> integrate our password features more as they are needed, like Samba 4? >> > > There are no Samba integration changes made that I know of. > > rob > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mmarzantowicz at osdf.com.pl Tue Oct 8 16:33:19 2013 From: mmarzantowicz at osdf.com.pl (Mateusz Marzantowicz) Date: Tue, 08 Oct 2013 18:33:19 +0200 Subject: [Freeipa-users] Required services are not started after reboot Message-ID: <525433CF.4060905@osdf.com.pl> Finally, I've managed to install FreeIPA on Fedora 20 without any errors. I was even able to log in through web UI and make some changes. Sadly after system reboot, non of IPA related services were started and now nothing works as expected. What services need to be enabled (I need to enable manually) to make ipa server operational again? I'd be thankful for any links to official documentation that covers this topic. Mateusz Marzantowicz From tompos at martos.bme.hu Tue Oct 8 16:43:49 2013 From: tompos at martos.bme.hu (Tamas Papp) Date: Tue, 08 Oct 2013 18:43:49 +0200 Subject: [Freeipa-users] Required services are not started after reboot In-Reply-To: <525433CF.4060905@osdf.com.pl> References: <525433CF.4060905@osdf.com.pl> Message-ID: <52543645.1080106@martos.bme.hu> On 10/08/2013 06:33 PM, Mateusz Marzantowicz wrote: > Finally, I've managed to install FreeIPA on Fedora 20 without any > errors. I was even able to log in through web UI and make some changes. > Sadly after system reboot, non of IPA related services were started and > now nothing works as expected. > > What services need to be enabled (I need to enable manually) to make ipa > server operational again? I'd be thankful for any links to official > documentation that covers this topic. See: https://bugzilla.redhat.com/show_bug.cgi?id=1008306 t -------------- next part -------------- An HTML attachment was scrubbed... URL: From cbulist at gmail.com Tue Oct 8 16:51:20 2013 From: cbulist at gmail.com (cbulist at gmail.com) Date: Tue, 08 Oct 2013 11:51:20 -0500 Subject: [Freeipa-users] Force to change password in first login Message-ID: <52543808.1090805@gmail.com> Hi All, I created a script to add users to freeipa using ldapadd command and it works great. Now I want to forcibly change the password in the first user login. What attribute do I have to change to accomplish this? Thanks! From rmercer at harris.com Tue Oct 8 17:07:31 2013 From: rmercer at harris.com (Rodney L. Mercer) Date: Tue, 8 Oct 2013 13:07:31 -0400 Subject: [Freeipa-users] Force to change password in first login In-Reply-To: <52543808.1090805@gmail.com> References: <52543808.1090805@gmail.com> Message-ID: <1381252051.5771.171.camel@osc145> I've used this to extend the password expiration. It "should" work for setting an expired password expiration. You have to hit enter twice after the krbPasswordExpiration: 20131008000000Z line. # ldapmodify -x -D 'cn=Directory Manager' -W Enter LDAP Password: dn: uid=username,cn=users,cn=accounts,dc=example,dc=com changetype: modify replace: krbPasswordExpiration krbPasswordExpiration: 20131008000000Z modifying entry "uid=username,cn=users,cn=accounts,dc=example,dc=com" ctrl-d On Tue, 2013-10-08 at 11:51 -0500, cbulist at gmail.com wrote: > Hi All, > > I created a script to add users to freeipa using ldapadd command and it > works great. Now I want to forcibly change the password in the first > user login. What attribute do I have to change to accomplish this? > > Thanks! > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From loris at lgs.com.ve Tue Oct 8 17:15:34 2013 From: loris at lgs.com.ve (Loris Santamaria) Date: Tue, 08 Oct 2013 12:45:34 -0430 Subject: [Freeipa-users] IPA 3.0 RHEL 6.4 In-Reply-To: References: <524ED70E.1080906@redhat.com> Message-ID: <1381252534.2607.43.camel@toron.pzo.lgs.com.ve> El mar, 08-10-2013 a las 09:25 -0500, Zachary Musselman escribi?: > Hello Dmitri, > > > We are currently using Samba as a file server and a DC with NT style > domain for our Windows clients. IPA is the password backend for > Samba. > > > Our Red Hat consultant originally had the following items working when > this system was installed last year. > > > ** Ability to add groups in the IPA web interface for samba > > > I have these patches and need to make sure that they work with IPA 3.0 > and RHEL 6.4 before I apply them. Those patches surely could be adapted without much work. The web interface for groups has not changed much between IPA 2.2 and 3.0 Anyway, there is not a real need to patch the web interface to have IPA add the objectClasses (sambaGroupMapping) and attributes (sambaSID and sambaGroupType) required by Samba. I've done this for some customers adding a DNA plugin configuration for sambaSID and extending the IPA group object to add the objectclass and sambagrouptype, as explained in http://abbra.fedorapeople.org/guide.html#sec-4. No need to patch the Web UI here. > ** We have a default password policy of 90 days expiration. This > policy also has complexity, history, length, etc. > > > Early this year that 90 day expiration stopped working and my Windows > users were no longer receiving a "must change password" notice. We > were hoping the update to RHEL 6.4 and IPA 3.0 would fix this but it > has not. Currently my users are showing an EXPIRATION in IPA of > June/July or so time frame. Back in April we manually changed all > user's passwords to a temporary. That prompted them to login and > change their password, hoping this would kickstart the 90 day > expiration again. That was NOT successful. > > > At a MINIMUM we are needing to correctly have IPA expire a user's > password and allow Samba to understand that as well based on the > password policy IPA shows for a given user. To have some correspondence between IPA password policies and samba password policies you need to: 1. Create a sufficiently privileged "bind user" in ipa and have samba connect to IPA using that "bind user". For example uid=sambaadmin,cn=sysaccounts,cn=etc,dc=example,dc=com 2. To have password changes in windows work as normal user password changes (instead of password resets) you must add the above "bind user" to the "passsyncmanagersdn" attribute of the ipa_pwd_extop plugin configuration. Similar to what is explained here: http://www.freeipa.org/docs/1.2/Installation_Deployment_Guide/en-US/html/sect-Installation_and_Deployment_Guide-Setting_up_Synchronization_Between_IPA_and_Active_Directory-Setting_up_Windows_Sync_on_the_IPA_Server.html 3. Samba should not mess with password expiration attributes in ldap, so you should set "ldap passwd sync = only" in smb.conf 4. You need a small patch in the ipa_pwd_extop plugin to have it set the sambaPwdLastSet attributes on password changes 5. Samba password policies (Maximum password duration, minimum password duration) should match the IPA password policies At least that is the route we took with customers and it has worked fairly well. > I have a test user who has a 2nd password policy we created. That > users has 1 day expiration within IPA. When I change the following > value using ldapmodify, It CORRECTLY makes Samba prompt the user to > change their password when logging in the next time. When I change > this test password, IPA reset's the EXPIRATION DATE to 90 days out and > not 1 day from the time password was changed. Probably samba is connecting to IPA with an admin user and password changes work end being don by IPA as password resets. See point 2 above > A third item we need fixed if possible, is the ability to enforce > password complexity, history, length, etc. through Samba based on what > IPA shows for a user's password policy. I cannot confirm if this WAS > working or not after it was initially installed. I guess you or Rob > would be the individuals who could tell me what is possible to enable > this feature. We've done it manually (with pdbedit -P) and after that everything works ok, password history, password length, password duration and complexity, all match between samba and IPA. Hope it helps. > On Fri, Oct 4, 2013 at 9:56 AM, Rob Crittenden > wrote: > Zach Musselman wrote: > Hello, > > My company is having issues with our current install > of IPA on RHEL 6.4. > > ** We had group patches that worked with IPA 2.2.0 and > allowed us to > enter samba groups directly in the IPA web interface. > Red Hat is unable > to confirm these patches are updated for IPA 3.0 RHEL > 6.4 even though > their Red Hat consultant created these a year ago. > > I'm not clear what you mean by updated for IPA 3.0. Are you > asking the patches to be rebased? > > It is also unclear if things were working properly with 2.2.0 > and broke with 3.0, or if these things never worked, or > something else. > > > ** IPA password policy (history, length, complexity, > etc.) enforcement > > Our current versions are not allowing the IPA password > policy to work > with Samba. My Windows users are able to change their > password either > MANUALLY or WHEN FORCED to reset via the IPA > interface. However, non of > the password history, length, complexity and so on are > enforced with > Samba and users are able to either keep the same > password or change it > to anything they want without restrictions. > > Can you be more specific about where the password changes are > happening? What do mean by manually? Changing it via the UI > should apply password policy because that is really > independent of any Samba changes that have been made. > > > ** Samba password change also changing correctly the > IPA expiration date > so IPA can successfully reset the (sambaPwdLastSet: 0) > value upon 90 > days since last password change > > If we manually run ldapmodify and change the value of > sambaPwdLastSet to > equal 0, this correctly forces the end user to change > their password in > Windows. > > The issue though is their IPA password expiration date > listed in the > interface isn't correctly showing the amount of days > to expire NEXT. I > have a test user that has a password policy of 1 day > expiration. I > would expect this user to show an expiration date of > the next day after > password change but for some reason it always keeps > showing about 90 > days out, which is my default policy for all users. > > I need to be able to test that IPA is correctly > expiring the password > after 1 day so that I know in 90 days my other users > will receive the > same expiration. > > For most of this year password expiration was not > working and IPA is > showing a password expiration of months ago when their > password should > have expired (samba never prompted for this change). > Since we updated > to IPA 3.0, I'm hoping that when I reset their > sambaPwdLastSet to 0 that > IPA will start enforcing a 90 day expiration again. > > I don't really know much about how Windows/Samba does password > expiration, but IPA has no process to look at the last set > date, compare that to the policy, and reset sambaPwdLastSet. > Is that what you're expecting? > > > Any help you can provide on these issues would be > greatly appreciated! > > Also, what would you recommend for future IPA versions > and Samba? Will > RHEL 6.5 include a newer version of IPA that will work > and integrate > better with Samba? Or should we start looking at > other options that > integrate our password features more as they are > needed, like Samba 4? > > There are no Samba integration changes made that I know of. > > rob > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Loris Santamaria linux user #70506 xmpp:loris at lgs.com.ve Links Global Services, C.A. http://www.lgs.com.ve Tel: 0286 952.06.87 Cel: 0414 095.00.10 sip:103 at lgs.com.ve ------------------------------------------------------------ "If I'd asked my customers what they wanted, they'd have said a faster horse" - Henry Ford -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5727 bytes Desc: not available URL: From cbulist at gmail.com Tue Oct 8 17:28:04 2013 From: cbulist at gmail.com (cbulist at gmail.com) Date: Tue, 08 Oct 2013 12:28:04 -0500 Subject: [Freeipa-users] Force to change password in first login In-Reply-To: <1381252051.5771.171.camel@osc145> References: <52543808.1090805@gmail.com> <1381252051.5771.171.camel@osc145> Message-ID: <525440A4.2030000@gmail.com> Rodney, Thanks!...I forgot it totally... Let me ask you about modify the password using ldapmodify command, I tried changing userPassword attribute with {MD5} encryption and it did not work. ldapmodify -x -H ldap://ipaserver -D "cn=directory manager" -w 'password' < I've used this to extend the password expiration. It "should" work for > setting an expired password expiration. You have to hit enter twice > after the krbPasswordExpiration: 20131008000000Z line. > > # ldapmodify -x -D 'cn=Directory Manager' -W > Enter LDAP Password: > dn: uid=username,cn=users,cn=accounts,dc=example,dc=com > changetype: modify > replace: krbPasswordExpiration > krbPasswordExpiration: 20131008000000Z > > > modifying entry > "uid=username,cn=users,cn=accounts,dc=example,dc=com" > > ctrl-d > > > > On Tue, 2013-10-08 at 11:51 -0500, cbulist at gmail.com wrote: >> Hi All, >> >> I created a script to add users to freeipa using ldapadd command and it >> works great. Now I want to forcibly change the password in the first >> user login. What attribute do I have to change to accomplish this? >> >> Thanks! >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users From rmercer at harris.com Tue Oct 8 17:45:36 2013 From: rmercer at harris.com (Rodney L. Mercer) Date: Tue, 8 Oct 2013 13:45:36 -0400 Subject: [Freeipa-users] Force to change password in first login In-Reply-To: <525440A4.2030000@gmail.com> References: <52543808.1090805@gmail.com> <1381252051.5771.171.camel@osc145> <525440A4.2030000@gmail.com> Message-ID: <1381254336.5771.179.camel@osc145> I've used grub-md5-crypt to create a password for an openldap server and used this format: # grub-md5-crypt Password: Retype password: $1$mGzMO1$zF/c9QxKV.ZZXwlvyR8UO1 Here is the ldif that I used to modify the entry on the openldap server: #cat usermod.ldif dn: uid=username,cn=users,cn=accounts,dc=example,dc=com changetype: modify replace: userPassword userPassword: {crypt}$1$mGzMO1$zF/c9QxKV.ZZXwlvyR8UO1 I'm not sure if this will work for the directory server that IPA uses? Worth a shot I suppose. Rodney. On Tue, 2013-10-08 at 12:28 -0500, cbulist at gmail.com wrote: > Rodney, > > Thanks!...I forgot it totally... > > Let me ask you about modify the password using ldapmodify command, I > tried changing userPassword attribute with {MD5} encryption and it did > not work. > > ldapmodify -x -H ldap://ipaserver -D "cn=directory manager" -w > 'password' < changetype: modify > replace: userPassword > userPassword: {MD5}QvdJref54ZW/R183pEyvyw== > EOF > > Do I need to modify another attribute?...any clue? > > Thanks in advance! > > > > On 10/08/2013 12:07 PM, Rodney L. Mercer wrote: > > I've used this to extend the password expiration. It "should" work for > > setting an expired password expiration. You have to hit enter twice > > after the krbPasswordExpiration: 20131008000000Z line. > > > > # ldapmodify -x -D 'cn=Directory Manager' -W > > Enter LDAP Password: > > dn: uid=username,cn=users,cn=accounts,dc=example,dc=com > > changetype: modify > > replace: krbPasswordExpiration > > krbPasswordExpiration: 20131008000000Z > > > > > > modifying entry > > "uid=username,cn=users,cn=accounts,dc=example,dc=com" > > > > ctrl-d > > > > > > > > On Tue, 2013-10-08 at 11:51 -0500, cbulist at gmail.com wrote: > >> Hi All, > >> > >> I created a script to add users to freeipa using ldapadd command and it > >> works great. Now I want to forcibly change the password in the first > >> user login. What attribute do I have to change to accomplish this? > >> > >> Thanks! > >> > >> _______________________________________________ > >> Freeipa-users mailing list > >> Freeipa-users at redhat.com > >> https://www.redhat.com/mailman/listinfo/freeipa-users > From rcritten at redhat.com Tue Oct 8 17:53:08 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 08 Oct 2013 13:53:08 -0400 Subject: [Freeipa-users] Force to change password in first login In-Reply-To: <1381254336.5771.179.camel@osc145> References: <52543808.1090805@gmail.com> <1381252051.5771.171.camel@osc145> <525440A4.2030000@gmail.com> <1381254336.5771.179.camel@osc145> Message-ID: <52544684.2060109@redhat.com> Rodney L. Mercer wrote: > I've used grub-md5-crypt to create a password for an openldap server and > used this format: > # grub-md5-crypt > Password: > Retype password: > $1$mGzMO1$zF/c9QxKV.ZZXwlvyR8UO1 > > Here is the ldif that I used to modify the entry on the openldap server: > > #cat usermod.ldif > dn: uid=username,cn=users,cn=accounts,dc=example,dc=com > changetype: modify > replace: userPassword > userPassword: {crypt}$1$mGzMO1$zF/c9QxKV.ZZXwlvyR8UO1 > > > I'm not sure if this will work for the directory server that IPA uses? > > Worth a shot I suppose. crypt will work. Or you can pass it in the clear and it will encrypt it for you using the default password scheme, SSHA1 IIRC. rob > > Rodney. > > > > On Tue, 2013-10-08 at 12:28 -0500, cbulist at gmail.com wrote: >> Rodney, >> >> Thanks!...I forgot it totally... >> >> Let me ask you about modify the password using ldapmodify command, I >> tried changing userPassword attribute with {MD5} encryption and it did >> not work. >> >> ldapmodify -x -H ldap://ipaserver -D "cn=directory manager" -w >> 'password' <> changetype: modify >> replace: userPassword >> userPassword: {MD5}QvdJref54ZW/R183pEyvyw== >> EOF >> >> Do I need to modify another attribute?...any clue? >> >> Thanks in advance! >> >> >> >> On 10/08/2013 12:07 PM, Rodney L. Mercer wrote: >>> I've used this to extend the password expiration. It "should" work for >>> setting an expired password expiration. You have to hit enter twice >>> after the krbPasswordExpiration: 20131008000000Z line. >>> >>> # ldapmodify -x -D 'cn=Directory Manager' -W >>> Enter LDAP Password: >>> dn: uid=username,cn=users,cn=accounts,dc=example,dc=com >>> changetype: modify >>> replace: krbPasswordExpiration >>> krbPasswordExpiration: 20131008000000Z >>> >>> >>> modifying entry >>> "uid=username,cn=users,cn=accounts,dc=example,dc=com" >>> >>> ctrl-d >>> >>> >>> >>> On Tue, 2013-10-08 at 11:51 -0500, cbulist at gmail.com wrote: >>>> Hi All, >>>> >>>> I created a script to add users to freeipa using ldapadd command and it >>>> works great. Now I want to forcibly change the password in the first >>>> user login. What attribute do I have to change to accomplish this? >>>> >>>> Thanks! >>>> >>>> _______________________________________________ >>>> 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 mussz624 at robertmorris.edu Tue Oct 8 17:55:03 2013 From: mussz624 at robertmorris.edu (Zachary Musselman) Date: Tue, 8 Oct 2013 12:55:03 -0500 Subject: [Freeipa-users] IPA 3.0 RHEL 6.4 In-Reply-To: <1381252534.2607.43.camel@toron.pzo.lgs.com.ve> References: <524ED70E.1080906@redhat.com> <1381252534.2607.43.camel@toron.pzo.lgs.com.ve> Message-ID: Hi Loris, Thanks for the quick and informational response. I'm going to ask for a little hand holding here. I'm not well versed in LDAP or IPA. ******************************************************************************************** >>>>>>>> How would I use ldapsearch to check that this value is correctly set already? I have already set "ldap passwd sync = only in smb.conf" as recommended by our Red Hat Consultant. >>>>>>>> Where can I find that patch that is needed to correctly set the sambaPwdLastSet attribute? To have some correspondence between IPA password policies and samba password policies you need to: 1. Create a sufficiently privileged "bind user" in ipa and have samba connect to IPA using that "bind user". For example uid=sambaadmin,cn=sysaccounts,cn=etc,dc=example,dc=com 2. To have password changes in windows work as normal user password changes (instead of password resets) you must add the above "bind user" to the "passsyncmanagersdn" attribute of the ipa_pwd_extop plugin configuration. Similar to what is explained here: http://www.freeipa.org/docs/1.2/Installation_Deployment_Guide/en-US/html/sect-Installation_and_Deployment_Guide-Setting_up_Synchronization_Between_IPA_and_Active_Directory-Setting_up_Windows_Sync_on_the_IPA_Server.html 3. Samba should not mess with password expiration attributes in ldap, so you should set "ldap passwd sync = only" in smb.conf 4. You need a small patch in the ipa_pwd_extop plugin to have it set the sambaPwdLastSet attributes on password changes 5. Samba password policies (Maximum password duration, minimum password duration) should match the IPA password policies >>>>>>>>> Below are the patches I received from our Red Hat consultant. Is this similar to what your talking about? ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ --- group.js.orig 2012-06-25 11:59:02.789096058 -0700 +++ group.js 2012-06-25 12:02:47.669143612 -0700 @@ -37,7 +37,8 @@ columns: [ 'cn', 'gidnumber', - 'description' + 'description', + 'sambagrouptype' ] }). details_facet({ @@ -50,7 +51,8 @@ type: 'textarea', name: 'description' }, - 'gidnumber' + 'gidnumber', + 'sambagrouptype' ] } ] @@ -116,6 +118,14 @@ label: IPA.messages.objects.group.posix, checked: true }, + { + factory: IPA.select_widget, + name: 'sambagrouptype', + label: IPA.messages.objects.group.sambagrouptype, + options: [ + {label: 'Domain', value: 2}, + {label: 'Local', value: 4}] + }, 'gidnumber' ] }); ---------------------------------------------------------------------------------------------------------------------------- --- group.py.orig 2012-06-25 12:06:13.265838223 -0700 +++ group.py 2012-06-25 12:06:19.513906111 -0700 @@ -102,7 +102,7 @@ takes_params = ( Str('cn', - pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', + pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_. -]{0,252}[a-zA-Z0-9_.$-]?$', pattern_errmsg='may only include letters, numbers, _, -, . and $', maxlength=255, cli_name='group_name', @@ -121,6 +121,13 @@ doc=_('GID (use this option to set it manually)'), minvalue=1, ), + Int('sambagrouptype', + cli_name='sgt', + label=_('Samba Group Type'), + doc=_('Samba Group Type (default is 2)'), + default=2, + autofill=True, + ), ) api.register(group) --------------------------------------------------------------------------------------------------------------------------------------- On Tue, Oct 8, 2013 at 12:15 PM, Loris Santamaria wrote: > El mar, 08-10-2013 a las 09:25 -0500, Zachary Musselman escribi?: > > Hello Dmitri, > > > > > > We are currently using Samba as a file server and a DC with NT style > > domain for our Windows clients. IPA is the password backend for > > Samba. > > > > > > Our Red Hat consultant originally had the following items working when > > this system was installed last year. > > > > > > ** Ability to add groups in the IPA web interface for samba > > > > > > I have these patches and need to make sure that they work with IPA 3.0 > > and RHEL 6.4 before I apply them. > > Those patches surely could be adapted without much work. The web > interface for groups has not changed much between IPA 2.2 and 3.0 > > Anyway, there is not a real need to patch the web interface to have IPA > add the objectClasses (sambaGroupMapping) and attributes (sambaSID and > sambaGroupType) required by Samba. I've done this for some customers > adding a DNA plugin configuration for sambaSID and extending the IPA > group object to add the objectclass and sambagrouptype, as explained in > http://abbra.fedorapeople.org/guide.html#sec-4. No need to patch the Web > UI here. > > > ** We have a default password policy of 90 days expiration. This > > policy also has complexity, history, length, etc. > > > > > > Early this year that 90 day expiration stopped working and my Windows > > users were no longer receiving a "must change password" notice. We > > were hoping the update to RHEL 6.4 and IPA 3.0 would fix this but it > > has not. Currently my users are showing an EXPIRATION in IPA of > > June/July or so time frame. Back in April we manually changed all > > user's passwords to a temporary. That prompted them to login and > > change their password, hoping this would kickstart the 90 day > > expiration again. That was NOT successful. > > > > > > At a MINIMUM we are needing to correctly have IPA expire a user's > > password and allow Samba to understand that as well based on the > > password policy IPA shows for a given user. > > To have some correspondence between IPA password policies and samba > password policies you need to: > > 1. Create a sufficiently privileged "bind user" in ipa and have > samba connect to IPA using that "bind user". For example > uid=sambaadmin,cn=sysaccounts,cn=etc,dc=example,dc=com > 2. To have password changes in windows work as normal user password > changes (instead of password resets) you must add the above > "bind user" to the "passsyncmanagersdn" attribute of the > ipa_pwd_extop plugin configuration. Similar to what is explained > here: > > http://www.freeipa.org/docs/1.2/Installation_Deployment_Guide/en-US/html/sect-Installation_and_Deployment_Guide-Setting_up_Synchronization_Between_IPA_and_Active_Directory-Setting_up_Windows_Sync_on_the_IPA_Server.html > 3. Samba should not mess with password expiration attributes in > ldap, so you should set "ldap passwd sync = only" in smb.conf > 4. You need a small patch in the ipa_pwd_extop plugin to have it > set the sambaPwdLastSet attributes on password changes > 5. Samba password policies (Maximum password duration, minimum > password duration) should match the IPA password policies > > At least that is the route we took with customers and it has worked > fairly well. > > > I have a test user who has a 2nd password policy we created. That > > users has 1 day expiration within IPA. When I change the following > > value using ldapmodify, It CORRECTLY makes Samba prompt the user to > > change their password when logging in the next time. When I change > > this test password, IPA reset's the EXPIRATION DATE to 90 days out and > > not 1 day from the time password was changed. > > Probably samba is connecting to IPA with an admin user and password > changes work end being don by IPA as password resets. See point 2 above > > > A third item we need fixed if possible, is the ability to enforce > > password complexity, history, length, etc. through Samba based on what > > IPA shows for a user's password policy. I cannot confirm if this WAS > > working or not after it was initially installed. I guess you or Rob > > would be the individuals who could tell me what is possible to enable > > this feature. > > We've done it manually (with pdbedit -P) and after that everything works > ok, password history, password length, password duration and complexity, > all match between samba and IPA. > > Hope it helps. > > > > On Fri, Oct 4, 2013 at 9:56 AM, Rob Crittenden > > wrote: > > Zach Musselman wrote: > > Hello, > > > > My company is having issues with our current install > > of IPA on RHEL 6.4. > > > > ** We had group patches that worked with IPA 2.2.0 and > > allowed us to > > enter samba groups directly in the IPA web interface. > > Red Hat is unable > > to confirm these patches are updated for IPA 3.0 RHEL > > 6.4 even though > > their Red Hat consultant created these a year ago. > > > > I'm not clear what you mean by updated for IPA 3.0. Are you > > asking the patches to be rebased? > > > > It is also unclear if things were working properly with 2.2.0 > > and broke with 3.0, or if these things never worked, or > > something else. > > > > > > ** IPA password policy (history, length, complexity, > > etc.) enforcement > > > > Our current versions are not allowing the IPA password > > policy to work > > with Samba. My Windows users are able to change their > > password either > > MANUALLY or WHEN FORCED to reset via the IPA > > interface. However, non of > > the password history, length, complexity and so on are > > enforced with > > Samba and users are able to either keep the same > > password or change it > > to anything they want without restrictions. > > > > Can you be more specific about where the password changes are > > happening? What do mean by manually? Changing it via the UI > > should apply password policy because that is really > > independent of any Samba changes that have been made. > > > > > > ** Samba password change also changing correctly the > > IPA expiration date > > so IPA can successfully reset the (sambaPwdLastSet: 0) > > value upon 90 > > days since last password change > > > > If we manually run ldapmodify and change the value of > > sambaPwdLastSet to > > equal 0, this correctly forces the end user to change > > their password in > > Windows. > > > > The issue though is their IPA password expiration date > > listed in the > > interface isn't correctly showing the amount of days > > to expire NEXT. I > > have a test user that has a password policy of 1 day > > expiration. I > > would expect this user to show an expiration date of > > the next day after > > password change but for some reason it always keeps > > showing about 90 > > days out, which is my default policy for all users. > > > > I need to be able to test that IPA is correctly > > expiring the password > > after 1 day so that I know in 90 days my other users > > will receive the > > same expiration. > > > > For most of this year password expiration was not > > working and IPA is > > showing a password expiration of months ago when their > > password should > > have expired (samba never prompted for this change). > > Since we updated > > to IPA 3.0, I'm hoping that when I reset their > > sambaPwdLastSet to 0 that > > IPA will start enforcing a 90 day expiration again. > > > > I don't really know much about how Windows/Samba does password > > expiration, but IPA has no process to look at the last set > > date, compare that to the policy, and reset sambaPwdLastSet. > > Is that what you're expecting? > > > > > > Any help you can provide on these issues would be > > greatly appreciated! > > > > Also, what would you recommend for future IPA versions > > and Samba? Will > > RHEL 6.5 include a newer version of IPA that will work > > and integrate > > better with Samba? Or should we start looking at > > other options that > > integrate our password features more as they are > > needed, like Samba 4? > > > > There are no Samba integration changes made that I know of. > > > > rob > > > > > > > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-users > > -- > Loris Santamaria linux user #70506 xmpp:loris at lgs.com.ve > Links Global Services, C.A. http://www.lgs.com.ve > Tel: 0286 952.06.87 Cel: 0414 095.00.10 sip:103 at lgs.com.ve > ------------------------------------------------------------ > "If I'd asked my customers what they wanted, they'd have said > a faster horse" - Henry Ford > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cbulist at gmail.com Tue Oct 8 18:32:51 2013 From: cbulist at gmail.com (cbulist at gmail.com) Date: Tue, 08 Oct 2013 13:32:51 -0500 Subject: [Freeipa-users] Force to change password in first login In-Reply-To: <52544684.2060109@redhat.com> References: <52543808.1090805@gmail.com> <1381252051.5771.171.camel@osc145> <525440A4.2030000@gmail.com> <1381254336.5771.179.camel@osc145> <52544684.2060109@redhat.com> Message-ID: <52544FD3.2050901@gmail.com> Thanks Rob and Rodney! Your recommendations worked. On 10/08/2013 12:53 PM, Rob Crittenden wrote: > Rodney L. Mercer wrote: >> I've used grub-md5-crypt to create a password for an openldap server and >> used this format: >> # grub-md5-crypt >> Password: >> Retype password: >> $1$mGzMO1$zF/c9QxKV.ZZXwlvyR8UO1 >> >> Here is the ldif that I used to modify the entry on the openldap server: >> >> #cat usermod.ldif >> dn: uid=username,cn=users,cn=accounts,dc=example,dc=com >> changetype: modify >> replace: userPassword >> userPassword: {crypt}$1$mGzMO1$zF/c9QxKV.ZZXwlvyR8UO1 >> >> >> I'm not sure if this will work for the directory server that IPA uses? >> >> Worth a shot I suppose. > crypt will work. Or you can pass it in the clear and it will encrypt it > for you using the default password scheme, SSHA1 IIRC. > > rob > >> Rodney. >> >> >> >> On Tue, 2013-10-08 at 12:28 -0500, cbulist at gmail.com wrote: >>> Rodney, >>> >>> Thanks!...I forgot it totally... >>> >>> Let me ask you about modify the password using ldapmodify command, I >>> tried changing userPassword attribute with {MD5} encryption and it did >>> not work. >>> >>> ldapmodify -x -H ldap://ipaserver -D "cn=directory manager" -w >>> 'password' <>> changetype: modify >>> replace: userPassword >>> userPassword: {MD5}QvdJref54ZW/R183pEyvyw== >>> EOF >>> >>> Do I need to modify another attribute?...any clue? >>> >>> Thanks in advance! >>> >>> >>> >>> On 10/08/2013 12:07 PM, Rodney L. Mercer wrote: >>>> I've used this to extend the password expiration. It "should" work for >>>> setting an expired password expiration. You have to hit enter twice >>>> after the krbPasswordExpiration: 20131008000000Z line. >>>> >>>> # ldapmodify -x -D 'cn=Directory Manager' -W >>>> Enter LDAP Password: >>>> dn: uid=username,cn=users,cn=accounts,dc=example,dc=com >>>> changetype: modify >>>> replace: krbPasswordExpiration >>>> krbPasswordExpiration: 20131008000000Z >>>> >>>> >>>> modifying entry >>>> "uid=username,cn=users,cn=accounts,dc=example,dc=com" >>>> >>>> ctrl-d >>>> >>>> >>>> >>>> On Tue, 2013-10-08 at 11:51 -0500, cbulist at gmail.com wrote: >>>>> Hi All, >>>>> >>>>> I created a script to add users to freeipa using ldapadd command and it >>>>> works great. Now I want to forcibly change the password in the first >>>>> user login. What attribute do I have to change to accomplish this? >>>>> >>>>> Thanks! >>>>> >>>>> _______________________________________________ >>>>> 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 mohan.cheema at arrkgroup.com Wed Oct 9 10:31:02 2013 From: mohan.cheema at arrkgroup.com (Mohan Cheema) Date: Wed, 9 Oct 2013 11:31:02 +0100 Subject: [Freeipa-users] FreeIPA client setup in AWS In-Reply-To: <524EBC9F.7090209@redhat.com> References: <005e01cec0b5$28ded9b0$7a9c8d10$@cheema@arrkgroup.com> <524EBC9F.7090209@redhat.com> Message-ID: <0b8401cec4da$a82a6b70$f87f4250$@cheema@arrkgroup.com> Thanks Rob your comment helped me. I'm putting the steps here just in case somebody needs it. First Install IPA Client Get the rpm from centos site (see get.txt) # mkdir -p /opt/ipa && cd /opt/ipa # vi get.txt Paste the following http://mirror.centos.org/centos/6/os/x86_64/Packages/ipa-client-3.0.0-25.el6 .x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/autofs-5.0.5-73.el6.x86 _64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/certmonger-0.61-3.el6.x 86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/ipa-python-3.0.0-25.el6 .x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/keyutils-1.4-4.el6.x86_ 64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/libcollection-0.6.0-9.e l6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/libdhash-0.4.2-9.el6.x8 6_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/libevent-1.4.13-4.el6.x 86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/libgssglue-0.1-11.el6.x 86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/libini_config-0.6.1-9.e l6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/libipa_hbac-1.9.2-82.el 6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/libipa_hbac-python-1.9. 2-82.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/libldb-1.1.13-3.el6.x86 _64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/libnl-1.1-14.el6.x86_64 .rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/libpath_utils-0.2.1-9.e l6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/libref_array-0.1.1-9.el 6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/libsss_autofs-1.9.2-82. el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/libtalloc-2.0.7-2.el6.x 86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/libtasn1-2.3-3.el6_2.1. x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/libtdb-1.2.10-1.el6.x86 _64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/libtevent-0.9.17-1.el6. x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/libtiff-3.9.4-9.el6_3.x 86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/libtirpc-0.2.1-5.el6.x8 6_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/nfs-utils-1.2.3-36.el6. x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/nfs-utils-lib-1.1.5-6.e l6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/oddjob-0.30-5.el6.x86_6 4.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/oddjob-mkhomedir-0.30-5 .el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/pyOpenSSL-0.10-2.el6.x8 6_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/pytalloc-2.0.7-2.el6.x8 6_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/python-kerberos-1.1-6.2 .el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/python-krbV-1.0.90-3.el 6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/python-ldap-2.3.10-1.el 6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/python-lxml-2.2.3-1.1.e l6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/python-netaddr-0.7.5-4. el6.noarch.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/python-nss-0.13-1.el6.x 86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/rpcbind-0.2.0-11.el6.x8 6_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/samba4-libs-4.0.0-55.el 6.rc4.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/sssd-1.9.2-82.el6.x86_6 4.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/sssd-client-1.9.2-82.el 6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/xmlrpc-c-1.16.24-1209.1 840.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/xmlrpc-c-client-1.16.24 -1209.1840.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/cups-libs-1.4.2-48.el6_ 3.3.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/cyrus-sasl-gssapi-2.1.2 3-13.el6_3.1.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/avahi-libs-0.6.25-12.el 6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/gnutls-2.8.5-10.el6.x86 _64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/bind-libs-9.8.2-0.17.rc 1.el6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/libsss_idmap-1.9.2-82.e l6.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/libxslt-1.1.26-2.el6_3. 1.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/cyrus-sasl-lib-2.1.23-1 3.el6_3.1.x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/keyutils-libs-1.4-4.el6 .x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/krb5-libs-1.10.3-10.el6 .x86_64.rpm http://mirror.centos.org/centos/6/os/x86_64/Packages/c-ares-1.7.0-6.el6.x86_ 64.rpm # wget -i get.txt # rpm -ivh *.rpm --nodeps Get latest openssh from amazon repository to /opt # mkdir -p /opt/ssh # cd /opt/ssh # wget http://packages.us-east-1.amazonaws.com/2013.09/main/201309001984/x86_64/Pac kages/openssh-server-6.2p2-4.34.amzn1.x86_64.rpm # wget http://packages.us-east-1.amazonaws.com/2013.09/main/201309001984/x86_64/Pac kages/openssh-6.2p2-4.34.amzn1.x86_64.rpm # wget http://packages.us-east-1.amazonaws.com/2013.09/main/201309001984/x86_64/Pac kages/openssh-clients-6.2p2-4.34.amzn1.x86_64.rpm # rpm -Uvh *.rpm # yum update -y # ipa-client-install --server kdc1.iocs-systems.internal --server kdc2.iocs-systems.internal --domain IOCS-SYSTEMS.INTERNAL --fixed-primary --mkhomedir # vi /etc/ssh/sshd_config Add following lines at the end AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys AuthorizedKeysCommandUser nobody # service sshd restart # mkdir -p /etc/selinux/targeted/logins That's it. Regards, Mohan > -----Original Message----- > From: Rob Crittenden [mailto:rcritten at redhat.com] > Sent: Friday, October 04, 2013 2:03 PM > To: Mohan Cheema; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] FreeIPA client setup in AWS > > Mohan Cheema wrote: > > Hi, > > > > We are number of Amazon AMI (Amazon Linux) in AWS. As this is based > on > > RHEL we installed number of packages to enable user on those machine > to > > get authenticated against ipa. The client gets configured with below > > warning. > > > > ----------------------------------- > > WARNING Installed OpenSSH server does not support dynamically loading > > authorized user keys. Public key authentication of IPA users will not > be > > available. > > ----------------------------------- > > > > When user tries to authenticate the SSH connection is dropped, ipa > > server issues the authentication ticket to the machine. > > > > Packages that has been installed. > > > > ---------------------------------------------- > > ipa-python-3.0.0-25.el6.x86_64.rpm > > > > python-ldap-2.3.10-1.el6.x86_64.rpm > > > > cyrus-sasl-gssapi-2.1.23-13.el6_3.1.x86_64.rpm > > > > pam_krb5-2.3.11-9.el6.i686.rpm > > > > sssd-1.9.2-82.el6.x86_64.rpm > > > > certmonger-0.61-3.el6.x86_64.rpm > > > > oddjob-mkhomedir-0.30-5.el6.x86_64.rpm > > > > python-krbV-1.0.90-3.el6.x86_64.rpm > > > > libsss_autofs-1.9.2-82.el6.x86_64.rpm > > > > autofs-5.0.5-73.el6.x86_64.rpm > > > > nfs-utils-1.2.3-36.el6.x86_64.rpm > > > > sssd-client-1.9.2-82.el6.x86_64.rpm > > > > python-kerberos-1.1-6.2.el6.x86_64.rpm > > > > python-nss-0.13-1.el6.x86_64.rpm > > > > python-lxml-2.2.3-1.1.el6.x86_64.rpm > > > > python-netaddr-0.7.5-4.el6.noarch.rpm > > > > pyOpenSSL-0.10-2.el6.x86_64.rpm > > > > libipa_hbac-python-1.9.2-82.el6.x86_64.rpm > > > > libgssglue-0.1-11.el6.x86_64.rpm > > > > nfs-utils-lib-1.1.5-6.el6.x86_64.rpm > > > > rpcbind-0.2.0-11.el6.x86_64.rpm > > > > oddjob-0.30-5.el6.x86_64.rpm > > > > libipa_hbac-1.9.2-82.el6.x86_64.rpm > > > > libldb-1.1.13-3.el6.x86_64.rpm > > > > libsss_idmap-1.9.2-82.el6.x86_64.rpm > > > > libevent-1.4.13-4.el6.x86_64.rpm > > > > libtalloc-2.0.7-2.el6.x86_64.rpm > > > > keyutils-1.4-4.el6.x86_64.rpm > > > > libdhash-0.4.2-9.el6.x86_64.rpm > > > > libtirpc-0.2.1-5.el6.x86_64.rpm > > > > ipa-client-3.0.0-25.el6.x86_64.rpm > > > > libtevent-0.9.17-1.el6.x86_64.rpm > > > > libtdb-1.2.10-1.el6.x86_64.rpm > > > > libini_config-0.6.1-9.el6.x86_64.rpm > > > > libcollection-0.6.0-9.el6.x86_64.rpm > > > > libpath_utils-0.2.1-9.el6.x86_64.rpm > > > > libref_array-0.1.1-9.el6.x86_64.rpm > > > > c-ares-1.7.0-6.el6.x86_64.rpm > > > > samba4-libs-4.0.0-55.el6.rc4.x86_64.rpm > > > > libnl-1.1-14.el6.x86_64.rpm > > ---------------------------------------------- > > > > Are there any other package that need to be installed to make it > working. > > > > Below is the ssh version. > > > > # rpm -qa | grep ssh > > > > libssh2-1.4.2-1.10.amzn1.x86_64 > > > > openssh-6.2p2-4.34.amzn1.x86_64 > > > > openssh-clients-6.2p2-4.34.amzn1.x86_64 > > > > openssh-server-6.2p2-4.34.amzn1.x86_64 > > I'm guessing the problem is the Amazon-specific version of ssh. It > needs > to support one of these command combinations: > > AuthorizedKeysCommand and AuthorizedKeysCommandUser > AuthorizedKeysCommand and AuthorizedKeysCommandRunAs > PubKeyAgent and PubKeyAgentRunAs > > /var/log/ipaclient-install.log should contain the output of the probing > for this support. > > rob From glenn.l.jenkins at sm.uwtsd.ac.uk Wed Oct 9 08:20:00 2013 From: glenn.l.jenkins at sm.uwtsd.ac.uk (Glenn L. Jenkins) Date: Wed, 9 Oct 2013 08:20:00 +0000 (UTC) Subject: [Freeipa-users] Fwd: FreeIPA on Fedora 19 won't work References: <53DB8A94-C71C-45D2-86AD-004F7A13AA59@monkey.org> <51BB7971.1080001@RedHat.com> <20130617133324.GA24492@redhat.com> <524DF98A.2070808@redhat.com> <524EBAE5.6020203@redhat.com> Message-ID: > > Did we confirm that this is a bug? > > Was it filed? > > The user added this information to > https://bugzilla.redhat.com/show_bug.cgi?id=953488 last week. > > rob > > Bug still appears on F19 (ran into it again installing another FreeIPA server for my lab). Will look at re-creating in a virtual machine and filing a bug report when I can. This issues has existed for a while, I set up my first freeIPA server on F17 last year and had the problem then. I suspect its unusual for people using IPA to require HTTP_PROXY/HTTPS_PROXY to be set on their machines. My setup is unusual in that the University network info-structure is externally controlled and my freeIPA setup exists within it to provide authentication for our dual boot lab. G. From Johan.Petersson at sscspace.com Wed Oct 9 13:49:07 2013 From: Johan.Petersson at sscspace.com (Johan Petersson) Date: Wed, 9 Oct 2013 13:49:07 +0000 Subject: [Freeipa-users] Red Hat 6.4, IPA NFS 4 Home Dir State Manager Fail 10016 Message-ID: <558C15177F5E714F83334217C9A197DF010194562D@SSC-MBX1.ssc.internal> Hi, I am getting error: state manager failed on NFSv4 server ***** with error 10016 in my new IPA test environment using krb5 and autofs. The message keeps popping up when i try logging in with a IPA user. Home Directory is on a NFSv4 Server using iSCSI and Multipathd for storage. I can log in and access my Home Directory but keep getting this message and some times it takes a long time to get in. As far as i can see the Error Code 10016 means: NFS4ERR_WRONGSEC I have the right permissions in the Home Directory and can create files. The NFS Server is a Client to IPA through ipa-client-install and has a valid nfs service key. All clients are RED Hat 6.4 too and uses ipa-client-install and ipa-client-automount configuration Anyone have any idea on what the issue could be? Thank you for any help. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Wed Oct 9 14:43:39 2013 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 09 Oct 2013 10:43:39 -0400 Subject: [Freeipa-users] Red Hat 6.4, IPA NFS 4 Home Dir State Manager Fail 10016 In-Reply-To: <558C15177F5E714F83334217C9A197DF010194562D@SSC-MBX1.ssc.internal> References: <558C15177F5E714F83334217C9A197DF010194562D@SSC-MBX1.ssc.internal> Message-ID: <52556B9B.7060701@redhat.com> On 10/09/2013 09:49 AM, Johan Petersson wrote: > Hi, > > I am getting error: state manager failed on NFSv4 server ***** with > error 10016 in my new IPA test environment using krb5 and autofs. > The message keeps popping up when i try logging in with a IPA user. > Home Directory is on a NFSv4 Server using iSCSI and Multipathd for > storage. > I can log in and access my Home Directory but keep getting this > message and some times it takes a long time to get in. > As far as i can see the Error Code 10016 means: NFS4ERR_WRONGSEC I suggest you check with NFS guys what this really means. On the surface something seems to be mismatched or misconfigured but there is not enough information or NFS knowledge to drill down deeper. > I have the right permissions in the Home Directory and can create files. > > The NFS Server is a Client to IPA through ipa-client-install and has a > valid nfs service key. > All clients are RED Hat 6.4 too and uses ipa-client-install and > ipa-client-automount configuration > > Anyone have any idea on what the issue could be? > > Thank you for any help. > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From William.Adamson at netapp.com Wed Oct 9 15:06:45 2013 From: William.Adamson at netapp.com (Adamson, Andy) Date: Wed, 9 Oct 2013 15:06:45 +0000 Subject: [Freeipa-users] Red Hat 6.4, IPA NFS 4 Home Dir State Manager Fail 10016 In-Reply-To: <52556B9B.7060701@redhat.com> References: <558C15177F5E714F83334217C9A197DF010194562D@SSC-MBX1.ssc.internal> <52556B9B.7060701@redhat.com> Message-ID: <666BF2FD-FBE2-41A6-BB3F-736DA9BF57A9@netapp.com> On Oct 9, 2013, at 10:43 AM, Dmitri Pal wrote: > On 10/09/2013 09:49 AM, Johan Petersson wrote: >> Hi, >> >> I am getting error: state manager failed on NFSv4 server ***** with error 10016 in my new IPA test environment using krb5 and autofs. >> The message keeps popping up when i try logging in with a IPA user. >> Home Directory is on a NFSv4 Server using iSCSI and Multipathd for storage. >> I can log in and access my Home Directory but keep getting this message and some times it takes a long time to get in. >> As far as i can see the Error Code 10016 means: NFS4ERR_WRONGSEC > I suggest you check with NFS guys what this really means. Hi >From RFC5661 15.1.6.3. NFS4ERR_WRONGSEC (Error Code 10016) Indicates that the security mechanism being used by the client for the operation does not match the server's security policy. The client should change the security mechanism being used and re-send the operation (but not with the same slot ID and sequence ID; one or both MUST be different on the re-send). SECINFO and SECINFO_NO_NAME can be used to determine the appropriate mechanism. What is the client distro and kernel (uname -a output)? What is the mount command you are using? What is your server export? -->Andy > On the surface something seems to be mismatched or misconfigured but there is not enough information or NFS knowledge to drill down deeper. > >> I have the right permissions in the Home Directory and can create files. >> >> The NFS Server is a Client to IPA through ipa-client-install and has a valid nfs service key. >> All clients are RED Hat 6.4 too and uses ipa-client-install and ipa-client-automount configuration >> >> Anyone have any idea on what the issue could be? >> >> Thank you for any help. >> >> >> _______________________________________________ >> Freeipa-users mailing list >> >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > 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 loris at lgs.com.ve Wed Oct 9 18:28:43 2013 From: loris at lgs.com.ve (Loris Santamaria) Date: Wed, 09 Oct 2013 13:58:43 -0430 Subject: [Freeipa-users] IPA 3.0 RHEL 6.4 In-Reply-To: References: <524ED70E.1080906@redhat.com> <1381252534.2607.43.camel@toron.pzo.lgs.com.ve> Message-ID: <1381343323.2607.59.camel@toron.pzo.lgs.com.ve> El mar, 08-10-2013 a las 12:55 -0500, Zachary Musselman escribi?: > Hi Loris, > > > Thanks for the quick and informational response. > > > I'm going to ask for a little hand holding here. I'm not well versed > in LDAP or IPA. > ******************************************************************************************** > > > >>>>>>>> How would I use ldapsearch to check that this value is > correctly set already? I have already set "ldap passwd sync = only in > smb.conf" as recommended by our Red Hat Consultant. With a simple ldapsearch: ldapsearch -x -D "cn=Directory Manager" -W -b cn=config cn=ipa_pwd_extop > >>>>>>>> Where can I find that patch that is needed to correctly set > the sambaPwdLastSet attribute? Looking back at the code I see that ipa_pwd_extop already sets the sambaPwdLastSet attribute if the user has the sambaSamAccount objectClass, thus the patch is simply this: --- freeipa-2.1.3/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c.orig 2012-06-29 11:33:14.578905152 -0430 +++ freeipa-2.1.3/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c 2012-06-29 15:21:49.228789490 -0430 @@ -440,7 +440,7 @@ for (i = 0; i < krbcfg->num_passsync_mgrs; i++) { if (strcasecmp(krbcfg->passsync_mgrs[i], bindDN) == 0) { - pwdata.changetype = IPA_CHANGETYPE_DSMGR; + pwdata.changetype = IPA_CHANGETYPE_NORMAL; break; } } Please note that this patch is for ipa 2.2 but it shouldn't be difficult to adapt it to ipa 3.0. What the patch does is manage password changes by samba as normal user password changes as to enforce password policies. As the patch is (ab)using the "Passsync Managers" feature of ipa_pwd_extop I wouldn't recommend its use if you have a user synchronization agreement with Active Directory Best regards > To have some correspondence between IPA password policies and > samba > password policies you need to: > > 1. Create a sufficiently privileged "bind user" in ipa and have > samba connect to IPA using that "bind user". For example > uid=sambaadmin,cn=sysaccounts,cn=etc,dc=example,dc=com > 2. To have password changes in windows work as normal user > password > changes (instead of password resets) you must add the above > "bind user" to the "passsyncmanagersdn" attribute of the > ipa_pwd_extop plugin configuration. Similar to what is > explained > here: > > http://www.freeipa.org/docs/1.2/Installation_Deployment_Guide/en-US/html/sect-Installation_and_Deployment_Guide-Setting_up_Synchronization_Between_IPA_and_Active_Directory-Setting_up_Windows_Sync_on_the_IPA_Server.html > 3. Samba should not mess with password expiration attributes in > ldap, so you should set "ldap passwd sync = only" in smb.conf > 4. You need a small patch in the ipa_pwd_extop plugin to have it > set the sambaPwdLastSet attributes on password changes > 5. Samba password policies (Maximum password duration, minimum > password duration) should match the IPA password policies > > > > > > > > >>>>>>>>> Below are the patches I received from our Red Hat > consultant. Is this similar to what your talking about? > > > > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > > > --- group.js.orig 2012-06-25 11:59:02.789096058 -0700 > +++ group.js 2012-06-25 12:02:47.669143612 -0700 > @@ -37,7 +37,8 @@ > columns: [ > 'cn', > 'gidnumber', > - 'description' > + 'description', > + 'sambagrouptype' > ] > }). > details_facet({ > @@ -50,7 +51,8 @@ > type: 'textarea', > name: 'description' > }, > - 'gidnumber' > + 'gidnumber', > + 'sambagrouptype' > ] > } > ] > @@ -116,6 +118,14 @@ > label: IPA.messages.objects.group.posix, > checked: true > }, > + { > + factory: IPA.select_widget, > + name: 'sambagrouptype', > + label: IPA.messages.objects.group.sambagrouptype, > + options: [ > + {label: 'Domain', value: 2}, > + {label: 'Local', value: 4}] > + }, > 'gidnumber' > ] > }); > > > ---------------------------------------------------------------------------------------------------------------------------- > > --- group.py.orig 2012-06-25 12:06:13.265838223 -0700 > +++ group.py 2012-06-25 12:06:19.513906111 -0700 > @@ -102,7 +102,7 @@ > > takes_params = ( > Str('cn', > - pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', > + pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_. -]{0,252}[a-zA-Z0-9_.$-]?$', > pattern_errmsg='may only include letters, numbers, _, -, . and $', > maxlength=255, > cli_name='group_name', > @@ -121,6 +121,13 @@ > doc=_('GID (use this option to set it manually)'), > minvalue=1, > ), > + Int('sambagrouptype', > + cli_name='sgt', > + label=_('Samba Group Type'), > + doc=_('Samba Group Type (default is 2)'), > + default=2, > + autofill=True, > + ), > ) > > api.register(group) > > --------------------------------------------------------------------------------------------------------------------------------------- > > > > On Tue, Oct 8, 2013 at 12:15 PM, Loris Santamaria > wrote: > El mar, 08-10-2013 a las 09:25 -0500, Zachary Musselman > escribi?: > > Hello Dmitri, > > > > > > We are currently using Samba as a file server and a DC with > NT style > > domain for our Windows clients. IPA is the password backend > for > > Samba. > > > > > > Our Red Hat consultant originally had the following items > working when > > this system was installed last year. > > > > > > ** Ability to add groups in the IPA web interface for samba > > > > > > I have these patches and need to make sure that they work > with IPA 3.0 > > and RHEL 6.4 before I apply them. > > > Those patches surely could be adapted without much work. The > web > interface for groups has not changed much between IPA 2.2 and > 3.0 > > Anyway, there is not a real need to patch the web interface to > have IPA > add the objectClasses (sambaGroupMapping) and attributes > (sambaSID and > sambaGroupType) required by Samba. I've done this for some > customers > adding a DNA plugin configuration for sambaSID and extending > the IPA > group object to add the objectclass and sambagrouptype, as > explained in > http://abbra.fedorapeople.org/guide.html#sec-4. No need to > patch the Web > UI here. > > > ** We have a default password policy of 90 days expiration. > This > > policy also has complexity, history, length, etc. > > > > > > Early this year that 90 day expiration stopped working and > my Windows > > users were no longer receiving a "must change password" > notice. We > > were hoping the update to RHEL 6.4 and IPA 3.0 would fix > this but it > > has not. Currently my users are showing an EXPIRATION in > IPA of > > June/July or so time frame. Back in April we manually > changed all > > user's passwords to a temporary. That prompted them to > login and > > change their password, hoping this would kickstart the 90 > day > > expiration again. That was NOT successful. > > > > > > At a MINIMUM we are needing to correctly have IPA expire a > user's > > password and allow Samba to understand that as well based on > the > > password policy IPA shows for a given user. > > > To have some correspondence between IPA password policies and > samba > password policies you need to: > > 1. Create a sufficiently privileged "bind user" in ipa > and have > samba connect to IPA using that "bind user". For > example > uid=sambaadmin,cn=sysaccounts,cn=etc,dc=example,dc=com > 2. To have password changes in windows work as normal > user password > changes (instead of password resets) you must add the > above > "bind user" to the "passsyncmanagersdn" attribute of > the > ipa_pwd_extop plugin configuration. Similar to what is > explained > here: > > http://www.freeipa.org/docs/1.2/Installation_Deployment_Guide/en-US/html/sect-Installation_and_Deployment_Guide-Setting_up_Synchronization_Between_IPA_and_Active_Directory-Setting_up_Windows_Sync_on_the_IPA_Server.html > 3. Samba should not mess with password expiration > attributes in > ldap, so you should set "ldap passwd sync = only" in > smb.conf > 4. You need a small patch in the ipa_pwd_extop plugin to > have it > set the sambaPwdLastSet attributes on password changes > 5. Samba password policies (Maximum password duration, > minimum > password duration) should match the IPA password > policies > > At least that is the route we took with customers and it has > worked > fairly well. > > > I have a test user who has a 2nd password policy we > created. That > > users has 1 day expiration within IPA. When I change the > following > > value using ldapmodify, It CORRECTLY makes Samba prompt the > user to > > change their password when logging in the next time. When I > change > > this test password, IPA reset's the EXPIRATION DATE to 90 > days out and > > not 1 day from the time password was changed. > > > Probably samba is connecting to IPA with an admin user and > password > changes work end being don by IPA as password resets. See > point 2 above > > > A third item we need fixed if possible, is the ability to > enforce > > password complexity, history, length, etc. through Samba > based on what > > IPA shows for a user's password policy. I cannot confirm if > this WAS > > working or not after it was initially installed. I guess > you or Rob > > would be the individuals who could tell me what is possible > to enable > > this feature. > > > We've done it manually (with pdbedit -P) and after that > everything works > ok, password history, password length, password duration and > complexity, > all match between samba and IPA. > > Hope it helps. > > > > On Fri, Oct 4, 2013 at 9:56 AM, Rob Crittenden > > > wrote: > > Zach Musselman wrote: > > Hello, > > > > My company is having issues with our current > install > > of IPA on RHEL 6.4. > > > > ** We had group patches that worked with IPA > 2.2.0 and > > allowed us to > > enter samba groups directly in the IPA web > interface. > > Red Hat is unable > > to confirm these patches are updated for IPA > 3.0 RHEL > > 6.4 even though > > their Red Hat consultant created these a > year ago. > > > > I'm not clear what you mean by updated for IPA 3.0. > Are you > > asking the patches to be rebased? > > > > It is also unclear if things were working properly > with 2.2.0 > > and broke with 3.0, or if these things never worked, > or > > something else. > > > > > > ** IPA password policy (history, length, > complexity, > > etc.) enforcement > > > > Our current versions are not allowing the > IPA password > > policy to work > > with Samba. My Windows users are able to > change their > > password either > > MANUALLY or WHEN FORCED to reset via the IPA > > interface. However, non of > > the password history, length, complexity and > so on are > > enforced with > > Samba and users are able to either keep the > same > > password or change it > > to anything they want without restrictions. > > > > Can you be more specific about where the password > changes are > > happening? What do mean by manually? Changing it via > the UI > > should apply password policy because that is really > > independent of any Samba changes that have been > made. > > > > > > ** Samba password change also changing > correctly the > > IPA expiration date > > so IPA can successfully reset the > (sambaPwdLastSet: 0) > > value upon 90 > > days since last password change > > > > If we manually run ldapmodify and change the > value of > > sambaPwdLastSet to > > equal 0, this correctly forces the end user > to change > > their password in > > Windows. > > > > The issue though is their IPA password > expiration date > > listed in the > > interface isn't correctly showing the amount > of days > > to expire NEXT. I > > have a test user that has a password policy > of 1 day > > expiration. I > > would expect this user to show an expiration > date of > > the next day after > > password change but for some reason it > always keeps > > showing about 90 > > days out, which is my default policy for all > users. > > > > I need to be able to test that IPA is > correctly > > expiring the password > > after 1 day so that I know in 90 days my > other users > > will receive the > > same expiration. > > > > For most of this year password expiration > was not > > working and IPA is > > showing a password expiration of months ago > when their > > password should > > have expired (samba never prompted for this > change). > > Since we updated > > to IPA 3.0, I'm hoping that when I reset > their > > sambaPwdLastSet to 0 that > > IPA will start enforcing a 90 day expiration > again. > > > > I don't really know much about how Windows/Samba > does password > > expiration, but IPA has no process to look at the > last set > > date, compare that to the policy, and reset > sambaPwdLastSet. > > Is that what you're expecting? > > > > > > Any help you can provide on these issues > would be > > greatly appreciated! > > > > Also, what would you recommend for future > IPA versions > > and Samba? Will > > RHEL 6.5 include a newer version of IPA that > will work > > and integrate > > better with Samba? Or should we start > looking at > > other options that > > integrate our password features more as they > are > > needed, like Samba 4? > > > > There are no Samba integration changes made that I > know of. > > > > rob > > > > > > > > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-users > > -- > Loris Santamaria linux user #70506 xmpp:loris at lgs.com.ve > Links Global Services, C.A. http://www.lgs.com.ve > Tel: 0286 952.06.87 Cel: 0414 095.00.10 sip:103 at lgs.com.ve > ------------------------------------------------------------ > "If I'd asked my customers what they wanted, they'd have said > a faster horse" - Henry Ford > > -- Loris Santamaria linux user #70506 xmpp:loris at lgs.com.ve Links Global Services, C.A. http://www.lgs.com.ve Tel: 0286 952.06.87 Cel: 0414 095.00.10 sip:103 at lgs.com.ve ------------------------------------------------------------ "If I'd asked my customers what they wanted, they'd have said a faster horse" - Henry Ford -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5727 bytes Desc: not available URL: From mmarzantowicz at osdf.com.pl Thu Oct 10 10:44:34 2013 From: mmarzantowicz at osdf.com.pl (Mateusz Marzantowicz) Date: Thu, 10 Oct 2013 12:44:34 +0200 Subject: [Freeipa-users] Required services are not started after reboot In-Reply-To: <52543645.1080106@martos.bme.hu> References: <525433CF.4060905@osdf.com.pl> <52543645.1080106@martos.bme.hu> Message-ID: <52568512.7040405@osdf.com.pl> On 08.10.2013 18:43, Tamas Papp wrote: > > On 10/08/2013 06:33 PM, Mateusz Marzantowicz wrote: >> Finally, I've managed to install FreeIPA on Fedora 20 without any >> errors. I was even able to log in through web UI and make some changes. >> Sadly after system reboot, non of IPA related services were started and >> now nothing works as expected. >> >> What services need to be enabled (I need to enable manually) to make ipa >> server operational again? I'd be thankful for any links to official >> documentation that covers this topic. > > See: > https://bugzilla.redhat.com/show_bug.cgi?id=1008306 > > > t Thanks, It looks like this bug is fixed in fc19 [1] but it's not in fc20 [2] (please compare 'Bugs Fixed' sections (I haven't tested it on fc19)). How is it possible that same release of freeipa (3.3.2-1) fixes bug 996716 in fc19 and not in fc20? I'm currently testing newest available rpm on fc20 and this bug still occurs. I've found that bug 1008306 [3] is more relevant in this case than one in FreeIPA. I also have newest 389-ds-base (389-ds-base-1.3.2.0-1.fc20.x86_64) package released for fc20 and nothing has changed as I mentioned above. I'm trying to make sens out of this bug & rpm # spaghetti but it's not so easy. [1] https://admin.fedoraproject.org/updates/FEDORA-2013-18371/freeipa-3.3.2-1.fc19 [2] https://admin.fedoraproject.org/updates/FEDORA-2013-18542/freeipa-3.3.2-1.fc20 [3] https://bugzilla.redhat.com/show_bug.cgi?id=1008306 Mateusz Marzantowicz From rcritten at redhat.com Thu Oct 10 13:48:13 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 10 Oct 2013 09:48:13 -0400 Subject: [Freeipa-users] Required services are not started after reboot In-Reply-To: <52568512.7040405@osdf.com.pl> References: <525433CF.4060905@osdf.com.pl> <52543645.1080106@martos.bme.hu> <52568512.7040405@osdf.com.pl> Message-ID: <5256B01D.2000504@redhat.com> Mateusz Marzantowicz wrote: > On 08.10.2013 18:43, Tamas Papp wrote: >> >> On 10/08/2013 06:33 PM, Mateusz Marzantowicz wrote: >>> Finally, I've managed to install FreeIPA on Fedora 20 without any >>> errors. I was even able to log in through web UI and make some changes. >>> Sadly after system reboot, non of IPA related services were started and >>> now nothing works as expected. >>> >>> What services need to be enabled (I need to enable manually) to make ipa >>> server operational again? I'd be thankful for any links to official >>> documentation that covers this topic. >> >> See: >> https://bugzilla.redhat.com/show_bug.cgi?id=1008306 >> >> >> t > > Thanks, > > It looks like this bug is fixed in fc19 [1] but it's not in fc20 [2] > (please compare 'Bugs Fixed' sections (I haven't tested it on fc19)). > How is it possible that same release of freeipa (3.3.2-1) fixes bug > 996716 in fc19 and not in fc20? I'm currently testing newest available > rpm on fc20 and this bug still occurs. > > I've found that bug 1008306 [3] is more relevant in this case than one > in FreeIPA. I also have newest 389-ds-base > (389-ds-base-1.3.2.0-1.fc20.x86_64) package released for fc20 and > nothing has changed as I mentioned above. > > I'm trying to make sens out of this bug & rpm # spaghetti but it's not > so easy. > > [1] > https://admin.fedoraproject.org/updates/FEDORA-2013-18371/freeipa-3.3.2-1.fc19 > > [2] > https://admin.fedoraproject.org/updates/FEDORA-2013-18542/freeipa-3.3.2-1.fc20 > > [3] https://bugzilla.redhat.com/show_bug.cgi?id=1008306 I think this is because the fixed 389-ds package hasn't been built yet for F-20. I think the difference in bugs fixed in bohdi was an oversight. The F-19 bugs fixed upstream should have been included in the F-20 bohdi (and probably the other way around too). The changes made to IPA for BZ 996716 are basically just cosmetic, to be in compliance with packaging guidelines. rog From nkinder at redhat.com Thu Oct 10 22:50:20 2013 From: nkinder at redhat.com (Nathan Kinder) Date: Thu, 10 Oct 2013 15:50:20 -0700 Subject: [Freeipa-users] Required services are not started after reboot In-Reply-To: <5256B01D.2000504@redhat.com> References: <525433CF.4060905@osdf.com.pl> <52543645.1080106@martos.bme.hu> <52568512.7040405@osdf.com.pl> <5256B01D.2000504@redhat.com> Message-ID: <52572F2C.6080100@redhat.com> On 10/10/2013 06:48 AM, Rob Crittenden wrote: > Mateusz Marzantowicz wrote: >> On 08.10.2013 18:43, Tamas Papp wrote: >>> >>> On 10/08/2013 06:33 PM, Mateusz Marzantowicz wrote: >>>> Finally, I've managed to install FreeIPA on Fedora 20 without any >>>> errors. I was even able to log in through web UI and make some >>>> changes. >>>> Sadly after system reboot, non of IPA related services were started >>>> and >>>> now nothing works as expected. >>>> >>>> What services need to be enabled (I need to enable manually) to >>>> make ipa >>>> server operational again? I'd be thankful for any links to official >>>> documentation that covers this topic. >>> >>> See: >>> https://bugzilla.redhat.com/show_bug.cgi?id=1008306 >>> >>> >>> t >> >> Thanks, >> >> It looks like this bug is fixed in fc19 [1] but it's not in fc20 [2] >> (please compare 'Bugs Fixed' sections (I haven't tested it on fc19)). >> How is it possible that same release of freeipa (3.3.2-1) fixes bug >> 996716 in fc19 and not in fc20? I'm currently testing newest available >> rpm on fc20 and this bug still occurs. >> >> I've found that bug 1008306 [3] is more relevant in this case than one >> in FreeIPA. I also have newest 389-ds-base >> (389-ds-base-1.3.2.0-1.fc20.x86_64) package released for fc20 and >> nothing has changed as I mentioned above. >> >> I'm trying to make sens out of this bug & rpm # spaghetti but it's not >> so easy. >> >> [1] >> https://admin.fedoraproject.org/updates/FEDORA-2013-18371/freeipa-3.3.2-1.fc19 >> >> >> [2] >> https://admin.fedoraproject.org/updates/FEDORA-2013-18542/freeipa-3.3.2-1.fc20 >> >> >> [3] https://bugzilla.redhat.com/show_bug.cgi?id=1008306 > > I think this is because the fixed 389-ds package hasn't been built yet > for F-20. The fix for BZ 1008306 is in the 389-ds-base-1.3.2.0-1.fc20.x86_64 build. Are we sure that the issue that is occuring here is related to tmpfiles.d not creating /var/lock/dirsrv before dirsrv is started? Thanks, -NGK > > I think the difference in bugs fixed in bohdi was an oversight. The > F-19 bugs fixed upstream should have been included in the F-20 bohdi > (and probably the other way around too). > > The changes made to IPA for BZ 996716 are basically just cosmetic, to > be in compliance with packaging guidelines. > > rog > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From nkinder at redhat.com Thu Oct 10 23:11:18 2013 From: nkinder at redhat.com (Nathan Kinder) Date: Thu, 10 Oct 2013 16:11:18 -0700 Subject: [Freeipa-users] Required services are not started after reboot In-Reply-To: <52572F2C.6080100@redhat.com> References: <525433CF.4060905@osdf.com.pl> <52543645.1080106@martos.bme.hu> <52568512.7040405@osdf.com.pl> <5256B01D.2000504@redhat.com> <52572F2C.6080100@redhat.com> Message-ID: <52573416.2050808@redhat.com> On 10/10/2013 03:50 PM, Nathan Kinder wrote: > On 10/10/2013 06:48 AM, Rob Crittenden wrote: >> Mateusz Marzantowicz wrote: >>> On 08.10.2013 18:43, Tamas Papp wrote: >>>> >>>> On 10/08/2013 06:33 PM, Mateusz Marzantowicz wrote: >>>>> Finally, I've managed to install FreeIPA on Fedora 20 without any >>>>> errors. I was even able to log in through web UI and make some >>>>> changes. >>>>> Sadly after system reboot, non of IPA related services were >>>>> started and >>>>> now nothing works as expected. >>>>> >>>>> What services need to be enabled (I need to enable manually) to >>>>> make ipa >>>>> server operational again? I'd be thankful for any links to official >>>>> documentation that covers this topic. >>>> >>>> See: >>>> https://bugzilla.redhat.com/show_bug.cgi?id=1008306 >>>> >>>> >>>> t >>> >>> Thanks, >>> >>> It looks like this bug is fixed in fc19 [1] but it's not in fc20 [2] >>> (please compare 'Bugs Fixed' sections (I haven't tested it on fc19)). >>> How is it possible that same release of freeipa (3.3.2-1) fixes bug >>> 996716 in fc19 and not in fc20? I'm currently testing newest available >>> rpm on fc20 and this bug still occurs. >>> >>> I've found that bug 1008306 [3] is more relevant in this case than one >>> in FreeIPA. I also have newest 389-ds-base >>> (389-ds-base-1.3.2.0-1.fc20.x86_64) package released for fc20 and >>> nothing has changed as I mentioned above. >>> >>> I'm trying to make sens out of this bug & rpm # spaghetti but it's not >>> so easy. >>> >>> [1] >>> https://admin.fedoraproject.org/updates/FEDORA-2013-18371/freeipa-3.3.2-1.fc19 >>> >>> >>> [2] >>> https://admin.fedoraproject.org/updates/FEDORA-2013-18542/freeipa-3.3.2-1.fc20 >>> >>> >>> [3] https://bugzilla.redhat.com/show_bug.cgi?id=1008306 >> >> I think this is because the fixed 389-ds package hasn't been built >> yet for F-20. > The fix for BZ 1008306 is in the 389-ds-base-1.3.2.0-1.fc20.x86_64 > build. Are we sure that the issue that is occuring here is related to > tmpfiles.d not creating /var/lock/dirsrv before dirsrv is started? I just fired up a F20 VM, and there is definitely still a problem here in 389-ds-base. I see the following in my tmpfiles.d config for dirsrv: -------------------------------------------------------------- d /var/run/dirsrv 0770 nobody nobody d /var/lock/dirsrv 0770 nobody nobody d /var/lock/dirsrv/slapd-example 0770 nobody nobody -------------------------------------------------------------- We'll figure out what's going on and get a respin of 389-ds-base out. > > Thanks, > -NGK >> >> I think the difference in bugs fixed in bohdi was an oversight. The >> F-19 bugs fixed upstream should have been included in the F-20 bohdi >> (and probably the other way around too). >> >> The changes made to IPA for BZ 996716 are basically just cosmetic, to >> be in compliance with packaging guidelines. >> >> rog >> >> _______________________________________________ >> 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 nkinder at redhat.com Thu Oct 10 23:57:49 2013 From: nkinder at redhat.com (Nathan Kinder) Date: Thu, 10 Oct 2013 16:57:49 -0700 Subject: [Freeipa-users] Required services are not started after reboot In-Reply-To: <52573416.2050808@redhat.com> References: <525433CF.4060905@osdf.com.pl> <52543645.1080106@martos.bme.hu> <52568512.7040405@osdf.com.pl> <5256B01D.2000504@redhat.com> <52572F2C.6080100@redhat.com> <52573416.2050808@redhat.com> Message-ID: <52573EFD.8060003@redhat.com> On 10/10/2013 04:11 PM, Nathan Kinder wrote: > On 10/10/2013 03:50 PM, Nathan Kinder wrote: >> On 10/10/2013 06:48 AM, Rob Crittenden wrote: >>> Mateusz Marzantowicz wrote: >>>> On 08.10.2013 18:43, Tamas Papp wrote: >>>>> >>>>> On 10/08/2013 06:33 PM, Mateusz Marzantowicz wrote: >>>>>> Finally, I've managed to install FreeIPA on Fedora 20 without any >>>>>> errors. I was even able to log in through web UI and make some >>>>>> changes. >>>>>> Sadly after system reboot, non of IPA related services were >>>>>> started and >>>>>> now nothing works as expected. >>>>>> >>>>>> What services need to be enabled (I need to enable manually) to >>>>>> make ipa >>>>>> server operational again? I'd be thankful for any links to official >>>>>> documentation that covers this topic. >>>>> >>>>> See: >>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1008306 >>>>> >>>>> >>>>> t >>>> >>>> Thanks, >>>> >>>> It looks like this bug is fixed in fc19 [1] but it's not in fc20 [2] >>>> (please compare 'Bugs Fixed' sections (I haven't tested it on fc19)). >>>> How is it possible that same release of freeipa (3.3.2-1) fixes bug >>>> 996716 in fc19 and not in fc20? I'm currently testing newest available >>>> rpm on fc20 and this bug still occurs. >>>> >>>> I've found that bug 1008306 [3] is more relevant in this case than one >>>> in FreeIPA. I also have newest 389-ds-base >>>> (389-ds-base-1.3.2.0-1.fc20.x86_64) package released for fc20 and >>>> nothing has changed as I mentioned above. >>>> >>>> I'm trying to make sens out of this bug & rpm # spaghetti but it's not >>>> so easy. >>>> >>>> [1] >>>> https://admin.fedoraproject.org/updates/FEDORA-2013-18371/freeipa-3.3.2-1.fc19 >>>> >>>> >>>> [2] >>>> https://admin.fedoraproject.org/updates/FEDORA-2013-18542/freeipa-3.3.2-1.fc20 >>>> >>>> >>>> [3] https://bugzilla.redhat.com/show_bug.cgi?id=1008306 >>> >>> I think this is because the fixed 389-ds package hasn't been built >>> yet for F-20. >> The fix for BZ 1008306 is in the 389-ds-base-1.3.2.0-1.fc20.x86_64 >> build. Are we sure that the issue that is occuring here is related >> to tmpfiles.d not creating /var/lock/dirsrv before dirsrv is started? > I just fired up a F20 VM, and there is definitely still a problem here > in 389-ds-base. I see the following in my tmpfiles.d config for dirsrv: > > -------------------------------------------------------------- > d /var/run/dirsrv 0770 nobody nobody > d /var/lock/dirsrv 0770 nobody nobody > d /var/lock/dirsrv/slapd-example 0770 nobody nobody > -------------------------------------------------------------- > > We'll figure out what's going on and get a respin of 389-ds-base out. This appears to be a simple issue in 389-ds-base. We will get a new builds in Koji on F19 and F20 tomorrow. https://fedorahosted.org/389/ticket/47513 >> >> Thanks, >> -NGK >>> >>> I think the difference in bugs fixed in bohdi was an oversight. The >>> F-19 bugs fixed upstream should have been included in the F-20 bohdi >>> (and probably the other way around too). >>> >>> The changes made to IPA for BZ 996716 are basically just cosmetic, >>> to be in compliance with packaging guidelines. >>> >>> rog >>> >>> _______________________________________________ >>> 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 From avdusheff at gmail.com Fri Oct 11 09:22:22 2013 From: avdusheff at gmail.com (=?KOI8-R?B?7cnIwcnMIOE=?=) Date: Fri, 11 Oct 2013 13:22:22 +0400 Subject: [Freeipa-users] (no subject) Message-ID: Good afternoon. In each region, I have a couple of controllers (windows and ipa). With the authorization server in the logs ipa (sssd log) I find that the request is not for the neighbor by location windows server, and randomly throughout the forest. Tell me is there a way to explicitly specify the IPA server on windows DC. Logs attached. there somewhere documentation about? next to the IPA server pk529ad-dc01.sys.local IPA server and knocks pk429ad-dc01.sys.local to another region -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- [sssd[be[ipa.sys.local]]] [be_get_account_info] (0x0100): Got request for [4097][1][name=vccs] [sssd[be[ipa.sys.local]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'sys.local' [sssd[be[ipa.sys.local]]] [resolve_srv_send] (0x0200): The status of SRV lookup is neutral [sssd[be[ipa.sys.local]]] [resolv_getsrv_send] (0x0100): Trying to resolve SRV record of '_ldap._tcp.sys.local' [sssd[be[ipa.sys.local]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve A record of 'pk429ad-dc01.sys.local' in files [sssd[be[ipa.sys.local]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve AAAA record of 'pk429ad-dc01.sys.local' in files [sssd[be[ipa.sys.local]]] [resolv_gethostbyname_next] (0x0200): No more address families to retry [sssd[be[ipa.sys.local]]] [resolv_gethostbyname_dns_query] (0x0100): Trying to resolve A record of 'pk429ad-dc01.sys.local' in DNS [sssd[be[ipa.sys.local]]] [fo_resolve_service_timeout] (0x0080): Service resolving timeout reached [sssd[be[ipa.sys.local]]] [sdap_id_op_connect_done] (0x0020): Failed to connect, going offline (5 [Input/output error]) [sssd[be[ipa.sys.local]]] [be_run_offline_cb] (0x0080): Going offline. Running callbacks. [sssd[be[ipa.sys.local]]] [ipa_get_ad_acct_ad_part_done] (0x0040): AD lookup failed: 11 [sssd[be[ipa.sys.local]]] [ipa_account_info_error_text] (0x0020): Bug: dp_error is OK on failed request [sssd[be[ipa.sys.local]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,11,Account info lookup failed [sssd[be[ipa.sys.local]]] [remove_krb5_info_files] (0x0200): Could not remove [/var/lib/sss/pubconf/kpasswdinfo.IPA.SYS.LOCAL], [2][No such file or directory] -------------- next part -------------- WINDOWS [root at pk529ipa01 ~]# dig SRV _ldap._tcp.sys.local ; <<>> DiG 9.9.3-rl.13207.22-P2-RedHat-9.9.3-5.P2.fc19 <<>> SRV _ldap._tcp.sys.l ocal ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30812 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 14, AUTHORITY: 0, ADDITIONAL: 15 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4000 ;; QUESTION SECTION: ;_ldap._tcp.sys.local. IN SRV ;; ANSWER SECTION: _ldap._tcp.sys.local. 600 IN SRV 0 100 389 pk529ad-dc02.sys.local . _ldap._tcp.sys.local. 600 IN SRV 0 100 389 pk329ad-dc02.sys.local . _ldap._tcp.sys.local. 600 IN SRV 0 100 389 p0029ad-dc02.sys.local . _ldap._tcp.sys.local. 600 IN SRV 0 100 389 pk529ad-dc01.sys.local . _ldap._tcp.sys.local. 600 IN SRV 0 100 389 pk229ad-dc01.sys.local . _ldap._tcp.sys.local. 600 IN SRV 0 100 389 pk429ad-dc02.sys.local . _ldap._tcp.sys.local. 600 IN SRV 0 100 389 pk329ad-dc01.sys.local . _ldap._tcp.sys.local. 600 IN SRV 0 100 389 pk629ad-dc01.sys.local . _ldap._tcp.sys.local. 600 IN SRV 0 100 389 p0029ad-dc01.sys.local . _ldap._tcp.sys.local. 600 IN SRV 0 100 389 pk729ad-dc01.sys.local . _ldap._tcp.sys.local. 600 IN SRV 0 100 389 pk729ad-dc02.sys.local . _ldap._tcp.sys.local. 600 IN SRV 0 100 389 pk629ad-dc02.sys.local . _ldap._tcp.sys.local. 600 IN SRV 0 100 389 pk429ad-dc01.sys.local . _ldap._tcp.sys.local. 600 IN SRV 0 100 389 pk229ad-dc02.sys.local . ;; ADDITIONAL SECTION: pk529ad-dc02.sys.local. 3600 IN A 172.21.167.135 pk329ad-dc02.sys.local. 1200 IN A 172.21.71.135 p0029ad-dc02.sys.local. 3600 IN A 192.168.226.61 pk529ad-dc01.sys.local. 3600 IN A 172.21.167.134 pk229ad-dc01.sys.local. 3600 IN A 172.21.7.134 pk429ad-dc02.sys.local. 3600 IN A 172.21.135.135 pk329ad-dc01.sys.local. 3600 IN A 172.21.71.134 pk629ad-dc01.sys.local. 3600 IN A 172.21.39.134 p0029ad-dc01.sys.local. 3600 IN A 192.168.226.60 pk729ad-dc01.sys.local. 3600 IN A 172.21.103.134 pk729ad-dc02.sys.local. 3600 IN A 172.21.103.135 pk629ad-dc02.sys.local. 3600 IN A 172.21.39.135 pk429ad-dc01.sys.local. 3600 IN A 172.21.135.134 pk229ad-dc02.sys.local. 3600 IN A 172.21.7.135 ;; Query time: 8 msec ;; SERVER: 172.21.167.134#53(172.21.167.134) ;; WHEN: Fri Oct 11 13:21:05 MSK 2013 ;; MSG SIZE rcvd: 861 IPA [root at pk529ipa01 ~]# dig SRV _ldap._tcp.ipa.sys.local ; <<>> DiG 9.9.3-rl.13207.22-P2-RedHat-9.9.3-5.P2.fc19 <<>> SRV _ldap._tcp.ipa.sys.local ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22486 ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 5 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4000 ;; QUESTION SECTION: ;_ldap._tcp.ipa.sys.local. IN SRV ;; ANSWER SECTION: _ldap._tcp.ipa.sys.local. 77052 IN SRV 0 100 389 p0129ipa02.ipa.sys.local. _ldap._tcp.ipa.sys.local. 77052 IN SRV 0 100 389 p0029ipa01.ipa.sys.local. _ldap._tcp.ipa.sys.local. 77052 IN SRV 0 100 389 p0129ipa01.ipa.sys.local. _ldap._tcp.ipa.sys.local. 77052 IN SRV 0 100 389 p0029ipa02.ipa.sys.local. ;; ADDITIONAL SECTION: p0129ipa02.ipa.sys.local. 1182 IN A 10.65.1.199 p0029ipa01.ipa.sys.local. 1182 IN A 192.168.226.62 p0129ipa01.ipa.sys.local. 1182 IN A 10.65.1.198 p0029ipa02.ipa.sys.local. 1182 IN A 192.168.226.63 ;; Query time: 5 msec ;; SERVER: 172.21.167.134#53(172.21.167.134) ;; WHEN: Fri Oct 11 13:21:39 MSK 2013 ;; MSG SIZE rcvd: 293 From dpal at redhat.com Fri Oct 11 16:59:18 2013 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 11 Oct 2013 12:59:18 -0400 Subject: [Freeipa-users] (no subject) In-Reply-To: References: Message-ID: <52582E66.5070301@redhat.com> On 10/11/2013 05:22 AM, ?????? ? wrote: > Good afternoon. In each region, I have a couple of controllers > (windows and ipa). With the authorization server in the logs ipa (sssd > log) I find that the request is not for the neighbor by location > windows server, and randomly throughout the forest. Tell me is there a > way to explicitly specify the IPA server on windows DC. Logs attached. > there somewhere documentation about? I am not quite sure I understand you setup but I will try to give you some hints. If you want SSSD to access a specific IPA server or servers you can define primary and secondary servers explicitly in the SSSD configuration. See SSSD man pages. This can also be done via ipa-client-install command line starting IPA client 3.0 and SSSD 1.9 But that would sort of override the information coming from DNS. If you are looking for SSSD to support DNS sites then this functionality is available in SSSD in 1.11 if SSSD is joined directly to AD via AD provider. If you are looking for the same functionality when SSSD connects to IPA then it is still on the roadmap because IPA does not support sites. https://fedorahosted.org/freeipa/ticket/2008 > > > next to the IPA server pk529ad-dc01.sys.local > IPA server and knocks pk429ad-dc01.sys.local to another region > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nkinder at redhat.com Fri Oct 11 22:45:35 2013 From: nkinder at redhat.com (Nathan Kinder) Date: Fri, 11 Oct 2013 15:45:35 -0700 Subject: [Freeipa-users] Required services are not started after reboot In-Reply-To: <52573EFD.8060003@redhat.com> References: <525433CF.4060905@osdf.com.pl> <52543645.1080106@martos.bme.hu> <52568512.7040405@osdf.com.pl> <5256B01D.2000504@redhat.com> <52572F2C.6080100@redhat.com> <52573416.2050808@redhat.com> <52573EFD.8060003@redhat.com> Message-ID: <52587F8F.1010904@redhat.com> On 10/10/2013 04:57 PM, Nathan Kinder wrote: > On 10/10/2013 04:11 PM, Nathan Kinder wrote: >> On 10/10/2013 03:50 PM, Nathan Kinder wrote: >>> On 10/10/2013 06:48 AM, Rob Crittenden wrote: >>>> Mateusz Marzantowicz wrote: >>>>> On 08.10.2013 18:43, Tamas Papp wrote: >>>>>> >>>>>> On 10/08/2013 06:33 PM, Mateusz Marzantowicz wrote: >>>>>>> Finally, I've managed to install FreeIPA on Fedora 20 without any >>>>>>> errors. I was even able to log in through web UI and make some >>>>>>> changes. >>>>>>> Sadly after system reboot, non of IPA related services were >>>>>>> started and >>>>>>> now nothing works as expected. >>>>>>> >>>>>>> What services need to be enabled (I need to enable manually) to >>>>>>> make ipa >>>>>>> server operational again? I'd be thankful for any links to official >>>>>>> documentation that covers this topic. >>>>>> >>>>>> See: >>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1008306 >>>>>> >>>>>> >>>>>> t >>>>> >>>>> Thanks, >>>>> >>>>> It looks like this bug is fixed in fc19 [1] but it's not in fc20 [2] >>>>> (please compare 'Bugs Fixed' sections (I haven't tested it on fc19)). >>>>> How is it possible that same release of freeipa (3.3.2-1) fixes bug >>>>> 996716 in fc19 and not in fc20? I'm currently testing newest >>>>> available >>>>> rpm on fc20 and this bug still occurs. >>>>> >>>>> I've found that bug 1008306 [3] is more relevant in this case than >>>>> one >>>>> in FreeIPA. I also have newest 389-ds-base >>>>> (389-ds-base-1.3.2.0-1.fc20.x86_64) package released for fc20 and >>>>> nothing has changed as I mentioned above. >>>>> >>>>> I'm trying to make sens out of this bug & rpm # spaghetti but it's >>>>> not >>>>> so easy. >>>>> >>>>> [1] >>>>> https://admin.fedoraproject.org/updates/FEDORA-2013-18371/freeipa-3.3.2-1.fc19 >>>>> >>>>> >>>>> [2] >>>>> https://admin.fedoraproject.org/updates/FEDORA-2013-18542/freeipa-3.3.2-1.fc20 >>>>> >>>>> >>>>> [3] https://bugzilla.redhat.com/show_bug.cgi?id=1008306 >>>> >>>> I think this is because the fixed 389-ds package hasn't been built >>>> yet for F-20. >>> The fix for BZ 1008306 is in the 389-ds-base-1.3.2.0-1.fc20.x86_64 >>> build. Are we sure that the issue that is occuring here is related >>> to tmpfiles.d not creating /var/lock/dirsrv before dirsrv is started? >> I just fired up a F20 VM, and there is definitely still a problem >> here in 389-ds-base. I see the following in my tmpfiles.d config for >> dirsrv: >> >> -------------------------------------------------------------- >> d /var/run/dirsrv 0770 nobody nobody >> d /var/lock/dirsrv 0770 nobody nobody >> d /var/lock/dirsrv/slapd-example 0770 nobody nobody >> -------------------------------------------------------------- >> >> We'll figure out what's going on and get a respin of 389-ds-base out. > This appears to be a simple issue in 389-ds-base. We will get a new > builds in Koji on F19 and F20 tomorrow. Here's a new build for F20 that should resolve this: https://admin.fedoraproject.org/updates/389-ds-base-1.3.2.2-1.fc20 Please test it and provide karma. Thanks, -NGK > > https://fedorahosted.org/389/ticket/47513 >>> >>> Thanks, >>> -NGK >>>> >>>> I think the difference in bugs fixed in bohdi was an oversight. The >>>> F-19 bugs fixed upstream should have been included in the F-20 >>>> bohdi (and probably the other way around too). >>>> >>>> The changes made to IPA for BZ 996716 are basically just cosmetic, >>>> to be in compliance with packaging guidelines. >>>> >>>> rog >>>> >>>> _______________________________________________ >>>> 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 > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From deanhunter at comcast.net Sun Oct 13 21:19:09 2013 From: deanhunter at comcast.net (Dean Hunter) Date: Sun, 13 Oct 2013 16:19:09 -0500 Subject: [Freeipa-users] Public key is not installed Message-ID: <1381699149.2410.12.camel@host.hunter.org> Is it a bug that several packages required by freeipa-server and freeipa-client are not signed with the same key as everything else in the repositories? # yum install bind bind-dyndb-ldap freeipa-server --assumeyes Loaded plugins: langpacks, refresh-packagekit Resolving Dependencies --> Running transaction check ---> Package bind.x86_64 32:9.9.3-5.P2.fc19 will be installed ---> Package bind-dyndb-ldap.x86_64 0:3.5-1.fc19 will be installed ---> Package freeipa-server.x86_64 0:3.3.1-1.fc19 will be installed ... Downloading packages: warning: /var/cache/yum/x86_64/19/local-fedora/packages/aopalliance-1.0-5.fc19.noarch.rpm: Header V3 RSA/SHA256 Signature, key ID fb4b18e6: NOKEY Public key for aopalliance-1.0-5.fc19.noarch.rpm is not installed Public key for 389-ds-base-libs-1.3.1.11-1.fc19.x86_64.rpm is not installed -------------------------------------------------------------------------------- Total 9.4 MB/s | 58 MB 00:06 Retrieving key from file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-x86_64 Importing GPG key 0xFB4B18E6: Userid : "Fedora (19) " Fingerprint: ca81 b2c8 5e4f 4d4a 1a3f 7234 0747 7e65 fb4b 18e6 From : /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-x86_64 Running transaction check ... # yum install freeipa-client --assumeyes Loaded plugins: langpacks, refresh-packagekit Resolving Dependencies --> Running transaction check ---> Package freeipa-client.x86_64 0:3.3.1-1.fc19 will be installed ... Downloading packages: warning: /var/cache/yum/x86_64/19/local-updates/packages/autofs-5.0.7-28.fc19.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID fb4b18e6: NOKEY Public key for autofs-5.0.7-28.fc19.x86_64.rpm is not installed Public key for certmonger-0.67-1.fc19.x86_64.rpm is not installed -------------------------------------------------------------------------------- Total 6.3 MB/s | 6.2 MB 00:00 Retrieving key from file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-x86_64 Importing GPG key 0xFB4B18E6: Userid : "Fedora (19) " Fingerprint: ca81 b2c8 5e4f 4d4a 1a3f 7234 0747 7e65 fb4b 18e6 From : /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-x86_64 Running transaction check ... And the required key, RPM-GPG-KEY-fedora-x86_64, is not is the set created when Fedora is installed? # ls -l /etc/pki/rpm-gpg total 16 lrwxrwxrwx. 1 root root 29 Oct 13 15:55 RPM-GPG-KEY-19-fedora -> RPM-GPG-KEY-fedora-19-primary lrwxrwxrwx. 1 root root 31 Oct 13 15:55 RPM-GPG-KEY-fedora-19-aarch64 -> RPM-GPG-KEY-fedora-19-secondary lrwxrwxrwx. 1 root root 31 Oct 13 15:55 RPM-GPG-KEY-fedora-19-arm -> RPM-GPG-KEY-fedora-19-secondary lrwxrwxrwx. 1 root root 31 Oct 13 15:55 RPM-GPG-KEY-fedora-19-armhfp -> RPM-GPG-KEY-fedora-19-secondary lrwxrwxrwx. 1 root root 29 Oct 13 15:55 RPM-GPG-KEY-fedora-19-i386 -> RPM-GPG-KEY-fedora-19-primary lrwxrwxrwx. 1 root root 31 Oct 13 15:55 RPM-GPG-KEY-fedora-19-ppc -> RPM-GPG-KEY-fedora-19-secondary lrwxrwxrwx. 1 root root 31 Oct 13 15:55 RPM-GPG-KEY-fedora-19-ppc64 -> RPM-GPG-KEY-fedora-19-secondary -rw-r--r--. 1 root root 1658 Aug 30 15:32 RPM-GPG-KEY-fedora-19-primary lrwxrwxrwx. 1 root root 31 Oct 13 15:55 RPM-GPG-KEY-fedora-19-s390 -> RPM-GPG-KEY-fedora-19-secondary lrwxrwxrwx. 1 root root 31 Oct 13 15:55 RPM-GPG-KEY-fedora-19-s390x -> RPM-GPG-KEY-fedora-19-secondary -rw-r--r--. 1 root root 3819 Aug 30 15:32 RPM-GPG-KEY-fedora-19-secondary lrwxrwxrwx. 1 root root 29 Oct 13 15:55 RPM-GPG-KEY-fedora-19-x86_64 -> RPM-GPG-KEY-fedora-19-primary -rw-r--r--. 1 root root 1658 Aug 30 15:32 RPM-GPG-KEY-fedora-20-primary -rw-r--r--. 1 root root 3819 Aug 30 15:32 RPM-GPG-KEY-fedora-20-secondary -------------- next part -------------- An HTML attachment was scrubbed... URL: From avdusheff at gmail.com Mon Oct 14 09:24:58 2013 From: avdusheff at gmail.com (=?KOI8-R?B?7cnIwcnMIOE=?=) Date: Mon, 14 Oct 2013 13:24:58 +0400 Subject: [Freeipa-users] Fwd: (no subject) In-Reply-To: References: <52582E66.5070301@redhat.com> <52586BF8.8030505@redhat.com> Message-ID: ---------- Forwarded message ---------- From: ?????? ? Date: 2013/10/14 Subject: Re: [Freeipa-users] (no subject) To: dpal at redhat.com Simplify the circuit. I have a windows server DC, IPA replica server. My job is to authenticate the user windows to your account on the client fedora and redhat. As I understand it when logging on IPA server running windows account - there is a request for vigdovs DC, found on the SRV record in DNS. Because the forest I site section in which is1 windows server and 1 IPA server, but at the request IPA server is not always refers to the neighbor windows dealing center I found this in the log ssssd at debug level 5.We do not have network connectivity between sites, there is a single point-to-site, where network connectivity is available. Trust between the domains windows and IPA available. Log in to the central site, where there is network connectivity runs great, for example (ssh -l winuser at windomain ipa.client or ipa-replica-server -----OK) 2013/10/12 Dmitri Pal > On 10/11/2013 02:07 PM, ?????? ? wrote: > > Maybe I have to explicitly specify the windows server which will address > my IPA server to authenticate windows user on ipa-client? For example there > is the IPA server p0129ipa01.ipa.sys local and Win DC > p0129ad-dc01.sys.local. How do I specify that a request for authorization > obviously gone to windows server or to any windows in the DC area? Because > I do not have network connectivity to ports in other regions. A DNS-request > is sent to all SRV-windows servers in a random order, depending can not > compute. > WIN DC in the subnet that corresponds to and authorizes the windows users > outside of DC who, in a different subnet is not responsible for > authorization (id winuser at windomain, getent passwd winuser at windomain, ssh > -l winuser at windomain ipa-client) > IPA-server fedora 19, ipa-client fedora19 and RedHat 6.x > > > The configuration still puzzles me. > Can you share your sanitized sssd.conf? > Based on you description you have: > > Windows DCs > IPAs > Clients that are configured to use IPA and DC (at the same time? how?) > Users coming from AD authenticating on the client > > My point is that you need to either: > * Connect your SSSD to AD directly, then there is no IPA in picture > * Connect you SSSD to IPA. In this case you can authenticate users that > are native to IPA, synced to IPA from AD or you can use trusted users from > AD accessing system if IPA and AD is in trust relationship > * Connect your SSSD to AD as one domain to allow AD users to authenticate > and create another domain that would connect SSSD to IPA. This is for non > overlapping user sets between AD and IPA > > If you running some other configuration it is probably something that we > do not recommend. > > We know people try to use one configuration to force user authentication > against AD while other information including user setup comes from IPA, but > we do not recommend this setup because we can't upgrade from it cleanly. > > > > > > > > 2013/10/11 Dmitri Pal > >> On 10/11/2013 05:22 AM, ?????? ? wrote: >> >> Good afternoon. In each region, I have a couple of controllers (windows >> and ipa). With the authorization server in the logs ipa (sssd log) I find >> that the request is not for the neighbor by location windows server, and >> randomly throughout the forest. Tell me is there a way to explicitly >> specify the IPA server on windows DC. Logs attached. >> there somewhere documentation about? >> >> >> I am not quite sure I understand you setup but I will try to give you >> some hints. >> >> If you want SSSD to access a specific IPA server or servers you can >> define primary and secondary servers explicitly in the SSSD configuration. >> See SSSD man pages. >> This can also be done via ipa-client-install command line starting IPA >> client 3.0 and SSSD 1.9 >> >> But that would sort of override the information coming from DNS. >> >> If you are looking for SSSD to support DNS sites then this functionality >> is available in SSSD in 1.11 if SSSD is joined directly to AD via AD >> provider. If you are looking for the same functionality when SSSD connects >> to IPA then it is still on the roadmap because IPA does not support sites. >> https://fedorahosted.org/freeipa/ticket/2008 >> >> >> >> next to the IPA server pk529ad-dc01.sys.local >> IPA server and knocks pk429ad-dc01.sys.local to another region >> >> >> >> _______________________________________________ >> Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users >> >> >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager for IdM portfolio >> 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 >> > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs?www.redhat.com/carveoutcosts/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: sssd.conf Type: application/octet-stream Size: 472 bytes Desc: not available URL: From mmarzantowicz at osdf.com.pl Mon Oct 14 09:46:57 2013 From: mmarzantowicz at osdf.com.pl (Mateusz Marzantowicz) Date: Mon, 14 Oct 2013 11:46:57 +0200 Subject: [Freeipa-users] Default shell for new users Message-ID: <525BBD91.4010000@osdf.com.pl> Is there any particular reason why /bin/sh is default shell for new domain users and not /bin/bash is? I know that /bin/sh is symlink to /bin/bash on Fedora but local user accounts are created with /bin/bash as default shell. Is it related to other supported UNIX-like systems that might not include bash or there is some other reason for such default vaule? Mateusz Marzantowicz From mkosek at redhat.com Mon Oct 14 11:38:02 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 14 Oct 2013 13:38:02 +0200 Subject: [Freeipa-users] Default shell for new users In-Reply-To: <525BBD91.4010000@osdf.com.pl> References: <525BBD91.4010000@osdf.com.pl> Message-ID: <525BD79A.8080504@redhat.com> On 10/14/2013 11:46 AM, Mateusz Marzantowicz wrote: > Is there any particular reason why /bin/sh is default shell for new > domain users and not /bin/bash is? I know that /bin/sh is symlink to > /bin/bash on Fedora but local user accounts are created with /bin/bash > as default shell. > > Is it related to other supported UNIX-like systems that might not > include bash or there is some other reason for such default vaule? This is exactly the reason. /bin/sh is just the most common denominator when talking about shells on various client systems. But feel free to change the default to /bin/bash if you like: $ kinit admin $ ipa config-mod --defaultshell=/bin/bash HTH, Martin From avdusheff at gmail.com Mon Oct 14 11:46:57 2013 From: avdusheff at gmail.com (=?KOI8-R?B?7cnIwcnMIOE=?=) Date: Mon, 14 Oct 2013 15:46:57 +0400 Subject: [Freeipa-users] Default shell for new users In-Reply-To: <525BD79A.8080504@redhat.com> References: <525BBD91.4010000@osdf.com.pl> <525BD79A.8080504@redhat.com> Message-ID: ipa config-mod --defaultshell=/bin/bash ipa: ERROR: no modifications to be performed 2013/10/14 Martin Kosek > On 10/14/2013 11:46 AM, Mateusz Marzantowicz wrote: > > Is there any particular reason why /bin/sh is default shell for new > > domain users and not /bin/bash is? I know that /bin/sh is symlink to > > /bin/bash on Fedora but local user accounts are created with /bin/bash > > as default shell. > > > > Is it related to other supported UNIX-like systems that might not > > include bash or there is some other reason for such default vaule? > > This is exactly the reason. /bin/sh is just the most common denominator > when > talking about shells on various client systems. > > But feel free to change the default to /bin/bash if you like: > > $ kinit admin > $ ipa config-mod --defaultshell=/bin/bash > > HTH, > Martin > > _______________________________________________ > 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 mkosek at redhat.com Mon Oct 14 11:50:12 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 14 Oct 2013 13:50:12 +0200 Subject: [Freeipa-users] Default shell for new users In-Reply-To: References: <525BBD91.4010000@osdf.com.pl> <525BD79A.8080504@redhat.com> Message-ID: <525BDA74.5020008@redhat.com> Then you probably have /bin/bash already set. Use # ipa config-show to verify. Martin On 10/14/2013 01:46 PM, ?????? ? wrote: > ipa config-mod --defaultshell=/bin/bash > ipa: ERROR: no modifications to be performed > > > > 2013/10/14 Martin Kosek > >> On 10/14/2013 11:46 AM, Mateusz Marzantowicz wrote: >>> Is there any particular reason why /bin/sh is default shell for new >>> domain users and not /bin/bash is? I know that /bin/sh is symlink to >>> /bin/bash on Fedora but local user accounts are created with /bin/bash >>> as default shell. >>> >>> Is it related to other supported UNIX-like systems that might not >>> include bash or there is some other reason for such default vaule? >> >> This is exactly the reason. /bin/sh is just the most common denominator >> when >> talking about shells on various client systems. >> >> But feel free to change the default to /bin/bash if you like: >> >> $ kinit admin >> $ ipa config-mod --defaultshell=/bin/bash >> >> HTH, >> Martin >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> > From avdusheff at gmail.com Mon Oct 14 13:52:22 2013 From: avdusheff at gmail.com (=?KOI8-R?B?7cnIwcnMIOE=?=) Date: Mon, 14 Oct 2013 17:52:22 +0400 Subject: [Freeipa-users] (no subject) In-Reply-To: References: <52582E66.5070301@redhat.com> <52586BF8.8030505@redhat.com> Message-ID: https://fedorahosted.org/freeipa/ticket/2008 is there a possibility to do the same for the SRV records windows servers? 2013/10/14 ?????? ? > > > ---------- Forwarded message ---------- > From: ?????? ? > Date: 2013/10/14 > Subject: Re: [Freeipa-users] (no subject) > To: dpal at redhat.com > > > Simplify the circuit. I have a windows server DC, IPA replica server. My > job is to authenticate the user windows to your account on the client > fedora and redhat. As I understand it when logging on IPA server running > windows account - there is a request for vigdovs DC, found on the SRV > record in DNS. Because the forest I site section in which is1 windows > server and 1 IPA server, but at the request IPA server is not always refers > to the neighbor windows dealing center I found this in the log ssssd at > debug level 5.We do not have network connectivity between sites, there is a > single point-to-site, where network connectivity is available. > Trust between the domains windows and IPA available. Log in to the central > site, where there is network connectivity runs great, for example (ssh -l > winuser at windomain ipa.client or ipa-replica-server -----OK) > > > > 2013/10/12 Dmitri Pal > >> On 10/11/2013 02:07 PM, ?????? ? wrote: >> >> Maybe I have to explicitly specify the windows server which will address >> my IPA server to authenticate windows user on ipa-client? For example there >> is the IPA server p0129ipa01.ipa.sys local and Win DC >> p0129ad-dc01.sys.local. How do I specify that a request for authorization >> obviously gone to windows server or to any windows in the DC area? Because >> I do not have network connectivity to ports in other regions. A DNS-request >> is sent to all SRV-windows servers in a random order, depending can not >> compute. >> WIN DC in the subnet that corresponds to and authorizes the windows users >> outside of DC who, in a different subnet is not responsible for >> authorization (id winuser at windomain, getent passwd winuser at windomain, >> ssh -l winuser at windomain ipa-client) >> IPA-server fedora 19, ipa-client fedora19 and RedHat 6.x >> >> >> The configuration still puzzles me. >> Can you share your sanitized sssd.conf? >> Based on you description you have: >> >> Windows DCs >> IPAs >> Clients that are configured to use IPA and DC (at the same time? how?) >> Users coming from AD authenticating on the client >> >> My point is that you need to either: >> * Connect your SSSD to AD directly, then there is no IPA in picture >> * Connect you SSSD to IPA. In this case you can authenticate users that >> are native to IPA, synced to IPA from AD or you can use trusted users from >> AD accessing system if IPA and AD is in trust relationship >> * Connect your SSSD to AD as one domain to allow AD users to authenticate >> and create another domain that would connect SSSD to IPA. This is for non >> overlapping user sets between AD and IPA >> >> If you running some other configuration it is probably something that we >> do not recommend. >> >> We know people try to use one configuration to force user authentication >> against AD while other information including user setup comes from IPA, but >> we do not recommend this setup because we can't upgrade from it cleanly. >> >> >> >> >> >> >> >> 2013/10/11 Dmitri Pal >> >>> On 10/11/2013 05:22 AM, ?????? ? wrote: >>> >>> Good afternoon. In each region, I have a couple of controllers (windows >>> and ipa). With the authorization server in the logs ipa (sssd log) I find >>> that the request is not for the neighbor by location windows server, and >>> randomly throughout the forest. Tell me is there a way to explicitly >>> specify the IPA server on windows DC. Logs attached. >>> there somewhere documentation about? >>> >>> >>> I am not quite sure I understand you setup but I will try to give you >>> some hints. >>> >>> If you want SSSD to access a specific IPA server or servers you can >>> define primary and secondary servers explicitly in the SSSD configuration. >>> See SSSD man pages. >>> This can also be done via ipa-client-install command line starting IPA >>> client 3.0 and SSSD 1.9 >>> >>> But that would sort of override the information coming from DNS. >>> >>> If you are looking for SSSD to support DNS sites then this functionality >>> is available in SSSD in 1.11 if SSSD is joined directly to AD via AD >>> provider. If you are looking for the same functionality when SSSD connects >>> to IPA then it is still on the roadmap because IPA does not support sites. >>> https://fedorahosted.org/freeipa/ticket/2008 >>> >>> >>> >>> next to the IPA server pk529ad-dc01.sys.local >>> IPA server and knocks pk429ad-dc01.sys.local to another region >>> >>> >>> >>> _______________________________________________ >>> Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users >>> >>> >>> >>> -- >>> Thank you, >>> Dmitri Pal >>> >>> Sr. Engineering Manager for IdM portfolio >>> 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 >>> >> >> >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager for IdM portfolio >> Red Hat Inc. >> >> >> ------------------------------- >> Looking to carve out IT costs?www.redhat.com/carveoutcosts/ >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iconeb at yahoo.it Mon Oct 14 14:45:29 2013 From: iconeb at yahoo.it (Federico Nebiolo) Date: Mon, 14 Oct 2013 16:45:29 +0200 Subject: [Freeipa-users] Subsystem certs not renewed Message-ID: <525C0389.4060905@yahoo.it> Dear IPA users, My IPA 3.0 installation on CentOS 6.4 (coming from a 2.2 upgrade) suddenly stopped working for the CA part. I'm not sure this is the root of all the issues, but subsystem certificates was expired and not renewed: getcert list gives a similar output for all of them, and I don't know how to proceed. []# getcert list -c dogtag-ipa-renew-agent Request ID '20130902075915': status: MONITORING ca-error: No end-entity URL (-E) given, and no default known. stuck: no key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O=XXXX subject: CN=RA Subsystem,O=XXXX expires: 2013-10-11 07:44:12 UTC eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: /usr/lib64/ipa/certmonger/renew_ra_cert track: yes auto-renew: yes Do you have any hints on how to solve? Many thanks in advance federico From rcritten at redhat.com Mon Oct 14 15:01:14 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 14 Oct 2013 11:01:14 -0400 Subject: [Freeipa-users] Subsystem certs not renewed In-Reply-To: <525C0389.4060905@yahoo.it> References: <525C0389.4060905@yahoo.it> Message-ID: <525C073A.3030409@redhat.com> Federico Nebiolo wrote: > Dear IPA users, > > My IPA 3.0 installation on CentOS 6.4 (coming from a 2.2 upgrade) > suddenly stopped working for the CA part. > I'm not sure this is the root of all the issues, but subsystem > certificates was expired and not renewed: getcert list gives a similar > output for all of them, and I don't know how to proceed. > > []# getcert list -c dogtag-ipa-renew-agent > > Request ID '20130902075915': > status: MONITORING > ca-error: No end-entity URL (-E) given, and no default known. > stuck: no > key pair storage: > type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > certificate: > type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS > Certificate DB' > CA: dogtag-ipa-renew-agent > issuer: CN=Certificate Authority,O=XXXX > subject: CN=RA Subsystem,O=XXXX > expires: 2013-10-11 07:44:12 UTC > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: /usr/lib64/ipa/certmonger/renew_ra_cert > track: yes > auto-renew: yes > > Do you have any hints on how to solve? Try adding a host= to the [global] section in /etc/ipa/default.conf where host is the fqdn of your IPA master. I think you'll need to temporarily go back in time to the 11th for the renewal to succeed. You can force certmonger to try the renewal again with: # getcert resubmit -i 20130902075915 You'll want to do this for all certs affected by this. If this works please let us know and we'll make sure that host exists in default.conf when upgrades happen. rob From erinn.looneytriggs at gmail.com Mon Oct 14 16:06:05 2013 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Mon, 14 Oct 2013 10:06:05 -0600 Subject: [Freeipa-users] Renewing CA certificate Message-ID: <525C166D.8080900@gmail.com> Folks, I wanted to touch base with y'all about how/if work is progressing on the ability to replace the CA certificate. My certificate is a subordinate of an AD CS instance and will be expiring in December, after two years. Some how, some way, without rebuilding I would like to be able to replace this subordinate CA. There is a ticket open for this, last I checked not much was said in the ticket: https://fedorahosted.org/freeipa/ticket/3304 -Erinn -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 555 bytes Desc: OpenPGP digital signature URL: From rcritten at redhat.com Mon Oct 14 16:26:58 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 14 Oct 2013 12:26:58 -0400 Subject: [Freeipa-users] Renewing CA certificate In-Reply-To: <525C166D.8080900@gmail.com> References: <525C166D.8080900@gmail.com> Message-ID: <525C1B52.7090906@redhat.com> Erinn Looney-Triggs wrote: > Folks, > I wanted to touch base with y'all about how/if work is progressing on > the ability to replace the CA certificate. My certificate is a > subordinate of an AD CS instance and will be expiring in December, after > two years. Some how, some way, without rebuilding I would like to be > able to replace this subordinate CA. > > There is a ticket open for this, last I checked not much was said in the > ticket: https://fedorahosted.org/freeipa/ticket/3304 > http://www.freeipa.org/page/V3/CA_certificate_renewal There was a discussion of this proposal on freeipa-devel, https://www.redhat.com/archives/freeipa-devel/2013-October/msg00073.html rob From dpal at redhat.com Mon Oct 14 18:54:14 2013 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 14 Oct 2013 14:54:14 -0400 Subject: [Freeipa-users] (no subject) In-Reply-To: References: <52582E66.5070301@redhat.com> <52586BF8.8030505@redhat.com> Message-ID: <525C3DD6.2080608@redhat.com> On 10/14/2013 09:52 AM, ?????? ? wrote: > https://fedorahosted.org/freeipa/ticket/2008 > is there a possibility to do the same for the SRV records windows servers? Yes, if you use latest SSSD against AD without IPA. If you want to use IPA with AD then SSSD is connected to IPA and IPA needs to provide this functionality. It is not implemented yet and not a high priority so far. Help and patches are definitely welcome. > > > 2013/10/14 ?????? ? > > > > > ---------- Forwarded message ---------- > From: *?????? ?* > > Date: 2013/10/14 > Subject: Re: [Freeipa-users] (no subject) > To: dpal at redhat.com > > > Simplify the circuit. I have a windows server DC, IPA replica > server. My job is to authenticate the user windows to your account > on the client fedora and redhat. As I understand it when logging > on IPA server running windows account - there is a request for > vigdovs DC, found on the SRV record in DNS. Because the forest I > site section in which is1 windows server and 1 IPA server, but at > the request IPA server is not always refers to the neighbor > windows dealing center I found this in the log ssssd at debug > level 5.We do not have network connectivity between sites, there > is a single point-to-site, where network connectivity is available. > Trust between the domains windows and IPA available. Log in to the > central site, where there is network connectivity runs great, for > example (ssh -l winuser at windomain ipa.client or ipa-replica-server > -----OK) > > > > 2013/10/12 Dmitri Pal > > > On 10/11/2013 02:07 PM, ?????? ? wrote: >> Maybe I have to explicitly specify the windows server which >> will address my IPA server to authenticate windows user on >> ipa-client? For example there is the IPA server >> p0129ipa01.ipa.sys local and Win DC >> p0129ad-dc01.sys.local. How do I specify that a request for >> authorization obviously gone to windows server or to any >> windows in the DC area? Because I do not have network >> connectivity to ports in other regions. A DNS-request is sent >> to all SRV-windows servers in a random order, depending can >> not compute. >> WIN DC in the subnet that corresponds to and authorizes the >> windows users outside of DC who, in a different subnet is not >> responsible for authorization (id winuser at windomain, getent >> passwd winuser at windomain, ssh -l winuser at windomain ipa-client) >> IPA-server fedora 19, ipa-client fedora19 and RedHat 6.x > > The configuration still puzzles me. > Can you share your sanitized sssd.conf? > Based on you description you have: > > Windows DCs > IPAs > Clients that are configured to use IPA and DC (at the same > time? how?) > Users coming from AD authenticating on the client > > My point is that you need to either: > * Connect your SSSD to AD directly, then there is no IPA in > picture > * Connect you SSSD to IPA. In this case you can authenticate > users that are native to IPA, synced to IPA from AD or you can > use trusted users from AD accessing system if IPA and AD is in > trust relationship > * Connect your SSSD to AD as one domain to allow AD users to > authenticate and create another domain that would connect SSSD > to IPA. This is for non overlapping user sets between AD and IPA > > If you running some other configuration it is probably > something that we do not recommend. > > We know people try to use one configuration to force user > authentication against AD while other information including > user setup comes from IPA, but we do not recommend this setup > because we can't upgrade from it cleanly. > > > > > >> >> >> 2013/10/11 Dmitri Pal > >> >> On 10/11/2013 05:22 AM, ?????? ? wrote: >>> Good afternoon. In each region, I have a couple of >>> controllers (windows and ipa). With the authorization >>> server in the logs ipa (sssd log) I find that the >>> request is not for the neighbor by location windows >>> server, and randomly throughout the forest. Tell me is >>> there a way to explicitly specify the IPA server on >>> windows DC. Logs attached. >>> there somewhere documentation about? >> >> I am not quite sure I understand you setup but I will try >> to give you some hints. >> >> If you want SSSD to access a specific IPA server or >> servers you can define primary and secondary servers >> explicitly in the SSSD configuration. See SSSD man pages. >> This can also be done via ipa-client-install command line >> starting IPA client 3.0 and SSSD 1.9 >> >> But that would sort of override the information coming >> from DNS. >> >> If you are looking for SSSD to support DNS sites then >> this functionality is available in SSSD in 1.11 if SSSD >> is joined directly to AD via AD provider. If you are >> looking for the same functionality when SSSD connects to >> IPA then it is still on the roadmap because IPA does not >> support sites. >> https://fedorahosted.org/freeipa/ticket/2008 >> >>> >>> >>> next to the IPA server pk529ad-dc01.sys.local >>> IPA server and knocks pk429ad-dc01.sys.local to another >>> region >>> >>> >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager for IdM portfolio >> 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 >> >> > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > 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 -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Mon Oct 14 19:19:31 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 14 Oct 2013 21:19:31 +0200 Subject: [Freeipa-users] Default shell for new users In-Reply-To: References: <525BBD91.4010000@osdf.com.pl> <525BD79A.8080504@redhat.com> <525BDA74.5020008@redhat.com> Message-ID: <525C43C3.6060008@redhat.com> Adding freeipa-users list back to CC. Note that the default shell applies only for new users. To modify shell for a current user, use # ipa user-mod --shell=/bin/bash Martin On 10/14/2013 01:55 PM, ?????? ? wrote: > [root at pk529ipa01 ~]# ipa config-show ... > Default shell: /bin/bash ... > > > but in new session > -sh-4.2$ echo $SHELL > /bin/sh > -sh-4.2$ > > > > > 2013/10/14 Martin Kosek > > > Then you probably have /bin/bash already set. Use > > # ipa config-show > > to verify. > > Martin > > On 10/14/2013 01:46 PM, ?????? ? wrote: > > ipa config-mod --defaultshell=/bin/bash > > ipa: ERROR: no modifications to be performed > > > > > > > > 2013/10/14 Martin Kosek > > > > >> On 10/14/2013 11:46 AM, Mateusz Marzantowicz wrote: > >>> Is there any particular reason why /bin/sh is default shell for new > >>> domain users and not /bin/bash is? I know that /bin/sh is symlink to > >>> /bin/bash on Fedora but local user accounts are created with /bin/bash > >>> as default shell. > >>> > >>> Is it related to other supported UNIX-like systems that might not > >>> include bash or there is some other reason for such default vaule? > >> > >> This is exactly the reason. /bin/sh is just the most common denominator > >> when > >> talking about shells on various client systems. > >> > >> But feel free to change the default to /bin/bash if you like: > >> > >> $ kinit admin > >> $ ipa config-mod --defaultshell=/bin/bash > >> > >> HTH, > >> Martin > >> > >> _______________________________________________ > >> Freeipa-users mailing list > >> Freeipa-users at redhat.com > >> https://www.redhat.com/mailman/listinfo/freeipa-users > >> > > > > From erinn.looneytriggs at gmail.com Mon Oct 14 19:32:32 2013 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Mon, 14 Oct 2013 13:32:32 -0600 Subject: [Freeipa-users] Renewing CA certificate In-Reply-To: <525C1B52.7090906@redhat.com> References: <525C166D.8080900@gmail.com> <525C1B52.7090906@redhat.com> Message-ID: <525C46D0.6060404@gmail.com> On 10/14/2013 10:26 AM, Rob Crittenden wrote: > Erinn Looney-Triggs wrote: >> Folks, >> I wanted to touch base with y'all about how/if work is progressing on >> the ability to replace the CA certificate. My certificate is a >> subordinate of an AD CS instance and will be expiring in December, after >> two years. Some how, some way, without rebuilding I would like to be >> able to replace this subordinate CA. >> >> There is a ticket open for this, last I checked not much was said in the >> ticket: https://fedorahosted.org/freeipa/ticket/3304 >> > > http://www.freeipa.org/page/V3/CA_certificate_renewal > > There was a discussion of this proposal on freeipa-devel, > https://www.redhat.com/archives/freeipa-devel/2013-October/msg00073.html > > rob Rob, Brilliant, thanks for the pointers to the info and the discussion. -Erinn -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 555 bytes Desc: OpenPGP digital signature URL: From janice.psyop at gmail.com Tue Oct 15 03:26:27 2013 From: janice.psyop at gmail.com (janice.psyop) Date: Mon, 14 Oct 2013 23:26:27 -0400 Subject: [Freeipa-users] ipa sync agreement to AD DC is taking a very long time Message-ID: Hi, I've been setting up an IPA server (centos 6.4) with AD trust (2008R2 domain) following the FC18 freeipa guide. Everything has gone smoothly until I ran the ipa-replica-manage connect command to the AD DC and it seems to be running (no errors on std out and ps says it is still running), but it has been running for six hours! We do have ~2000 user entries, but I didn't think it would take this long to sync up. The command I ran was this (see below) and the screen now just displays repeating "Update in progress". I'm very tempted to kill it in case something is going horribly wrong (with the AD user accounts...) /usr/sbin/ipa-replica-manage connect --winsync --passsync=MySecretPass --binddn=CN=myipasyncuser,CN=Users,DC=domain,DC=com --bindpw=MySecretPass --cacert=/etc/openldap/cacerts/DC-CA.cer -v dc.domain.com Update in progress Update in progress Update in progress Update in progress Update in progress Update in progress Update in progress Is there any way to check the progress of this in case it is in fact hung up? The last few entries in the ipa/default.log is from six hours ago: 2013-10-14T21:32:45Z 2706 MainThread ipa INFO Added new sync agreement, waiting for it to become ready . . . 2013-10-14T21:32:46Z 2706 MainThread ipa INFO Replication Update in progress: FALSE: status: 0 Replica acquired successfully: Incremental update started: start: 0: end: 0 2013-10-14T21:32:46Z 2706 MainThread ipa INFO Agreement is ready, starting replication . . . thanks much, -J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nkinder at redhat.com Tue Oct 15 04:29:54 2013 From: nkinder at redhat.com (Nathan Kinder) Date: Mon, 14 Oct 2013 21:29:54 -0700 Subject: [Freeipa-users] ipa sync agreement to AD DC is taking a very long time In-Reply-To: References: Message-ID: <525CC4C2.8040805@redhat.com> On 10/14/2013 08:26 PM, janice.psyop wrote: > Hi, > > I've been setting up an IPA server (centos 6.4) with AD trust (2008R2 > domain) following the FC18 freeipa guide. > > Everything has gone smoothly until I ran the ipa-replica-manage > connect command to the AD DC and it seems to be running (no errors on > std out and ps says it is still running), but it has been running for > six hours! We do have ~2000 user entries, but I didn't think it > would take this long to sync up. It's definitely hung up. 2k users should be very quick to sync. > > The command I ran was this (see below) and the screen now just > displays repeating "Update in progress". I'm very tempted to kill it > in case something is going horribly wrong (with the AD user accounts...) > > /usr/sbin/ipa-replica-manage connect --winsync > --passsync=MySecretPass > --binddn=CN=myipasyncuser,CN=Users,DC=domain,DC=com > --bindpw=MySecretPass > --cacert=/etc/openldap/cacerts/DC-CA.cer > -v dc.domain.com > > > Update in progress > Update in progress > Update in progress > Update in progress > Update in progress > Update in progress > Update in progress > > > Is there any way to check the progress of this in case it is in fact > hung up? The last few entries in the ipa/default.log is from six > hours ago: Is there anything of interest in the 389 DS errors log? It's located at /var/log/dirsrv/slapd-/errors. Thanks, -NGK > > > 2013-10-14T21:32:45Z 2706 MainThread ipa INFO Added new > sync agreement, waiting for it to become ready . . . > 2013-10-14T21:32:46Z 2706 MainThread ipa INFO > Replication Update in progress: FALSE: status: 0 Replica acquired > successfully: Incremental update started: start: 0: end: 0 > 2013-10-14T21:32:46Z 2706 MainThread ipa INFO Agreement > is ready, starting replication . . . > > > thanks much, > -J. > > > _______________________________________________ > 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 mkosek at redhat.com Tue Oct 15 06:33:28 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 15 Oct 2013 08:33:28 +0200 Subject: [Freeipa-users] Renewing CA certificate In-Reply-To: <525C46D0.6060404@gmail.com> References: <525C166D.8080900@gmail.com> <525C1B52.7090906@redhat.com> <525C46D0.6060404@gmail.com> Message-ID: <525CE1B8.7090400@redhat.com> On 10/14/2013 09:32 PM, Erinn Looney-Triggs wrote: > On 10/14/2013 10:26 AM, Rob Crittenden wrote: >> Erinn Looney-Triggs wrote: >>> Folks, I wanted to touch base with y'all about how/if work is >>> progressing on the ability to replace the CA certificate. My >>> certificate is a subordinate of an AD CS instance and will be expiring >>> in December, after two years. Some how, some way, without rebuilding I >>> would like to be able to replace this subordinate CA. >>> >>> There is a ticket open for this, last I checked not much was said in >>> the ticket: https://fedorahosted.org/freeipa/ticket/3304 >>> >> >> http://www.freeipa.org/page/V3/CA_certificate_renewal >> >> There was a discussion of this proposal on freeipa-devel, >> https://www.redhat.com/archives/freeipa-devel/2013-October/msg00073.html >> >> >> rob > > Rob, > > Brilliant, thanks for the pointers to the info and the discussion. > > -Erinn > Erinn, I will be talking to my colleague (Jan Cholasta) and even if the referred feature is not released until December, we will provide you either with a tool to do the renewal, or a manual procedure how to do it if the tool is not ready until that time. So, keep in touch. -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. From abokovoy at redhat.com Tue Oct 15 07:22:40 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 15 Oct 2013 10:22:40 +0300 Subject: [Freeipa-users] ipa sync agreement to AD DC is taking a very long time In-Reply-To: References: Message-ID: <20131015072240.GJ30236@redhat.com> On Mon, 14 Oct 2013, janice.psyop wrote: >Hi, > >I've been setting up an IPA server (centos 6.4) with AD trust (2008R2 >domain) following the FC18 freeipa guide. AD trusts is different from AD sync agreement. What you describe below is use of passsync/winsync (AD sync), not AD trusts. Just to make sure we are on the same level here. > >Everything has gone smoothly until I ran the ipa-replica-manage connect >command to the AD DC and it seems to be running (no errors on std out and >ps says it is still running), but it has been running for six hours! We do >have ~2000 user entries, but I didn't think it would take this long to >sync up. > >The command I ran was this (see below) and the screen now just displays >repeating "Update in progress". I'm very tempted to kill it in case >something is going horribly wrong (with the AD user accounts...) > >/usr/sbin/ipa-replica-manage connect --winsync >--passsync=MySecretPass >--binddn=CN=myipasyncuser,CN=Users,DC=domain,DC=com >--bindpw=MySecretPass >--cacert=/etc/openldap/cacerts/DC-CA.cer >-v dc.domain.com > > >Update in progress >Update in progress >Update in progress >Update in progress >Update in progress >Update in progress >Update in progress > > >Is there any way to check the progress of this in case it is in fact hung >up? The last few entries in the ipa/default.log is from six hours ago: > > >2013-10-14T21:32:45Z 2706 MainThread ipa INFO Added new >sync agreement, waiting for it to become ready . . . >2013-10-14T21:32:46Z 2706 MainThread ipa INFO Replication >Update in progress: FALSE: status: 0 Replica acquired successfully: >Incremental update started: start: 0: end: 0 >2013-10-14T21:32:46Z 2706 MainThread ipa INFO Agreement >is ready, starting replication . . . Try to change some user data on AD side, it would trigger update of the IPA side. -- / Alexander Bokovoy From iconeb at yahoo.it Tue Oct 15 08:32:38 2013 From: iconeb at yahoo.it (Federico Nebiolo) Date: Tue, 15 Oct 2013 10:32:38 +0200 Subject: [Freeipa-users] Subsystem certs not renewed In-Reply-To: <525C073A.3030409@redhat.com> References: <525C0389.4060905@yahoo.it> <525C073A.3030409@redhat.com> Message-ID: <525CFDA6.2000404@yahoo.it> Il 14/10/2013 17:01, Rob Crittenden ha scritto: > Federico Nebiolo wrote: >> Dear IPA users, >> >> My IPA 3.0 installation on CentOS 6.4 (coming from a 2.2 upgrade) >> suddenly stopped working for the CA part. >> I'm not sure this is the root of all the issues, but subsystem >> certificates was expired and not renewed: getcert list gives a similar >> output for all of them, and I don't know how to proceed. >> >> []# getcert list -c dogtag-ipa-renew-agent >> >> Request ID '20130902075915': >> status: MONITORING >> ca-error: No end-entity URL (-E) given, and no default known. >> stuck: no >> key pair storage: >> type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS >> Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >> certificate: >> type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS >> Certificate DB' >> CA: dogtag-ipa-renew-agent >> issuer: CN=Certificate Authority,O=XXXX >> subject: CN=RA Subsystem,O=XXXX >> expires: 2013-10-11 07:44:12 UTC >> eku: id-kp-serverAuth,id-kp-clientAuth >> pre-save command: >> post-save command: /usr/lib64/ipa/certmonger/renew_ra_cert >> track: yes >> auto-renew: yes >> >> Do you have any hints on how to solve? > > Try adding a host= to the [global] section in > /etc/ipa/default.conf where host is the fqdn of your IPA master. > > I think you'll need to temporarily go back in time to the 11th for the > renewal to succeed. > > You can force certmonger to try the renewal again with: > > # getcert resubmit -i 20130902075915 > > You'll want to do this for all certs affected by this. > > If this works please let us know and we'll make sure that host exists in > default.conf when upgrades happen. > > rob Rob, adding host= and moving the clock backward partially worked. Now both "CN=RA Subsystem" and "CN=" certificates are renewed, but certmonger is unable to renew "CN=CA Subsystem", "CN=CA Audit" and "CN=OCSP Subsystem". Certmonger error is an "Error 35 connecting to https://:9443/ca/agent/ca/profileReview: SSL connect error": it seems to me that selfsigned CA certificate in chain is not accepted by certmonger, thus certificates are not renewed. Is there another parameter I can specify to make dogtag-ipa-renew-agent accept its CA? Many thanks again federico From rmeggins at redhat.com Tue Oct 15 13:26:49 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 15 Oct 2013 07:26:49 -0600 Subject: [Freeipa-users] ipa sync agreement to AD DC is taking a very long time In-Reply-To: <20131015072240.GJ30236@redhat.com> References: <20131015072240.GJ30236@redhat.com> Message-ID: <525D4299.4070909@redhat.com> On 10/15/2013 01:22 AM, Alexander Bokovoy wrote: > On Mon, 14 Oct 2013, janice.psyop wrote: > >> Hi, >> >> I've been setting up an IPA server (centos 6.4) with AD trust (2008R2 >> domain) following the FC18 freeipa guide. > AD trusts is different from AD sync agreement. > > What you describe below is use of passsync/winsync (AD sync), not AD > trusts. Just to make sure we are on the same level here. >> >> Everything has gone smoothly until I ran the ipa-replica-manage connect >> command to the AD DC and it seems to be running (no errors on std out >> and >> ps says it is still running), but it has been running for six hours! >> We do >> have ~2000 user entries, but I didn't think it would take this long to >> sync up. >> >> The command I ran was this (see below) and the screen now just displays >> repeating "Update in progress". I'm very tempted to kill it in case >> something is going horribly wrong (with the AD user accounts...) >> >> /usr/sbin/ipa-replica-manage connect --winsync >> --passsync=MySecretPass >> --binddn=CN=myipasyncuser,CN=Users,DC=domain,DC=com >> --bindpw=MySecretPass >> --cacert=/etc/openldap/cacerts/DC-CA.cer >> -v dc.domain.com >> >> >> Update in progress >> Update in progress >> Update in progress >> Update in progress >> Update in progress >> Update in progress >> Update in progress >> >> >> Is there any way to check the progress of this in case it is in fact >> hung >> up? The last few entries in the ipa/default.log is from six hours ago: >> >> >> 2013-10-14T21:32:45Z 2706 MainThread ipa INFO Added new >> sync agreement, waiting for it to become ready . . . >> 2013-10-14T21:32:46Z 2706 MainThread ipa INFO Replication >> Update in progress: FALSE: status: 0 Replica acquired successfully: >> Incremental update started: start: 0: end: 0 >> 2013-10-14T21:32:46Z 2706 MainThread ipa INFO Agreement >> is ready, starting replication . . . > Try to change some user data on AD side, it would trigger update of the > IPA side. > Take a look at the 389 errors log - /var/log/dirsrv/slapd-YOUR-DOMAIN/errors - anything in there? If not, then you can turn on replication/sync error logging http://port389.org/wiki/FAQ#Troubleshooting From janice.psyop at gmail.com Tue Oct 15 15:51:42 2013 From: janice.psyop at gmail.com (janice.psyop) Date: Tue, 15 Oct 2013 11:51:42 -0400 Subject: [Freeipa-users] ipa sync agreement to AD DC is taking a very long time In-Reply-To: <525D4299.4070909@redhat.com> References: <20131015072240.GJ30236@redhat.com> <525D4299.4070909@redhat.com> Message-ID: Thanks for the replies. I checked this morning and it was still hung up on "Update in progess" so I killed it. @Alexander: Yes, I had already established a trust with our AD DC. I was doing step " 9.4.2. Creating Synchronization Agreements" (FreeIPA_Guide/managing-sync-agmt.html) I've been following the guide step-by-step. Here is the slapd-REALM/errors log (I truncated most of the repeating missing attribute errors, but the last line is really the last line in the log). I don't see any glaring errors: # cat /var/log/dirsrv/slapd-IPANY/errors 389-Directory/1.2.11.15 B2013.240.174 nymipa.ipany.domain.com:636 (/etc/dirsrv/slapd-IPANY) [14/Oct/2013:17:32:43 -0400] - 389-Directory/1.2.11.15 B2013.240.174 starting up [14/Oct/2013:17:32:43 -0400] schema-compat-plugin - warning: no entries set up under cn=computers, cn=compat,dc=ipany [14/Oct/2013:17:32:43 -0400] schema-compat-plugin - warning: no entries set up under cn=ng, cn=compat,dc=ipany [14/Oct/2013:17:32:43 -0400] schema-compat-plugin - warning: no entries set up under ou=sudoers,dc=ipany [14/Oct/2013:17:32:44 -0400] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=ipany--no CoS Templates found, which should be added before the CoS Definition. [14/Oct/2013:17:32:44 -0400] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=ipany--no CoS Templates found, which should be added before the CoS Definition. [14/Oct/2013:17:32:44 -0400] - slapd started. Listening on All Interfaces port 389 for LDAP requests [14/Oct/2013:17:32:44 -0400] - Listening on All Interfaces port 636 for LDAPS requests [14/Oct/2013:17:32:44 -0400] - Listening on /var/run/slapd-IPANY.socket for LDAPI requests [14/Oct/2013:17:32:45 -0400] - Entry "cn=meTodc02.domain.com,cn=replica,cn=dc\3Dipany,cn=mapping tree,cn=config" -- attribute "nsDS5ReplicatedAttributeListTotal" not allowed [14/Oct/2013:17:32:45 -0400] NSMMReplicationPlugin - agmt="cn=meTodc02.domain.com" (dc02:389): Replica has no update vector. It has never been initialized. [14/Oct/2013:17:32:45 -0400] NSMMReplicationPlugin - agmt="cn=meTodc02.domain.com" (dc02:389): Replica has no update vector. It has never been initialized. [14/Oct/2013:17:32:45 -0400] NSMMReplicationPlugin - agmt="cn=meTodc02.domain.com" (dc02:389): Replica has no update vector. It has never been initialized. [14/Oct/2013:17:32:47 -0400] NSMMReplicationPlugin - Beginning total update of replica "agmt="cn=meTodc02.domain.com" (dc02:389)". [14/Oct/2013:17:32:49 -0400] - Entry "uid=nfsuser,cn=users,cn=accounts,dc=ipany" missing attribute "sn" required by object class "person" [14/Oct/2013:17:32:49 -0400] - Entry "uid=tapeop,cn=users,cn=accounts,dc=ipany" missing attribute "sn" required by object class "person" [14/Oct/2013:17:33:14 -0400] - Entry "uid=nfsuserevs,cn=users,cn=accounts,dc=ipany" missing attribute "sn" required by object class "person" [14/Oct/2013:17:33:14 -0400] - Entry "uid=nfsuserbk01,cn=users,cn=accounts,dc=ipany" missing attribute "sn" required by object class "person" Should I go ahead and enable a more verbose log level (8192) and re-run the ipa-replica-manage connect --winsync .... again? I killed the process this morning so would I need to do any type of "clean up" before re-running? thanks, -J. On Tue, Oct 15, 2013 at 9:26 AM, Rich Megginson wrote: > On 10/15/2013 01:22 AM, Alexander Bokovoy wrote: >> >> On Mon, 14 Oct 2013, janice.psyop wrote: >> >>> Hi, >>> >>> I've been setting up an IPA server (centos 6.4) with AD trust (2008R2 >>> domain) following the FC18 freeipa guide. >> >> AD trusts is different from AD sync agreement. >> >> What you describe below is use of passsync/winsync (AD sync), not AD >> trusts. Just to make sure we are on the same level here. >>> >>> >>> Everything has gone smoothly until I ran the ipa-replica-manage connect >>> command to the AD DC and it seems to be running (no errors on std out and >>> ps says it is still running), but it has been running for six hours! We >>> do >>> have ~2000 user entries, but I didn't think it would take this long to >>> sync up. >>> >>> The command I ran was this (see below) and the screen now just displays >>> repeating "Update in progress". I'm very tempted to kill it in case >>> something is going horribly wrong (with the AD user accounts...) >>> >>> /usr/sbin/ipa-replica-manage connect --winsync >>> --passsync=MySecretPass >>> --binddn=CN=myipasyncuser,CN=Users,DC=domain,DC=com >>> --bindpw=MySecretPass >>> --cacert=/etc/openldap/cacerts/DC-CA.cer >>> -v dc.domain.com >>> >>> >>> Update in progress >>> Update in progress >>> Update in progress >>> Update in progress >>> Update in progress >>> Update in progress >>> Update in progress >>> >>> >>> Is there any way to check the progress of this in case it is in fact hung >>> up? The last few entries in the ipa/default.log is from six hours ago: >>> >>> >>> 2013-10-14T21:32:45Z 2706 MainThread ipa INFO Added new >>> sync agreement, waiting for it to become ready . . . >>> 2013-10-14T21:32:46Z 2706 MainThread ipa INFO Replication >>> Update in progress: FALSE: status: 0 Replica acquired successfully: >>> Incremental update started: start: 0: end: 0 >>> 2013-10-14T21:32:46Z 2706 MainThread ipa INFO Agreement >>> is ready, starting replication . . . >> >> Try to change some user data on AD side, it would trigger update of the >> IPA side. >> > Take a look at the 389 errors log - /var/log/dirsrv/slapd-YOUR-DOMAIN/errors > - anything in there? > If not, then you can turn on replication/sync error logging > http://port389.org/wiki/FAQ#Troubleshooting From rmeggins at redhat.com Tue Oct 15 15:58:22 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 15 Oct 2013 09:58:22 -0600 Subject: [Freeipa-users] ipa sync agreement to AD DC is taking a very long time In-Reply-To: References: <20131015072240.GJ30236@redhat.com> <525D4299.4070909@redhat.com> Message-ID: <525D661E.4080603@redhat.com> On 10/15/2013 09:51 AM, janice.psyop wrote: > Thanks for the replies. > > I checked this morning and it was still hung up on "Update in progess" > so I killed it. > > @Alexander: Yes, I had already established a trust with our AD DC. I > was doing step " 9.4.2. Creating Synchronization Agreements" > (FreeIPA_Guide/managing-sync-agmt.html) I've been following the > guide step-by-step. > > > Here is the slapd-REALM/errors log (I truncated most of the repeating > missing attribute errors, but the last line is really the last line in > the log). I don't see any glaring errors: > > > # cat /var/log/dirsrv/slapd-IPANY/errors > 389-Directory/1.2.11.15 B2013.240.174 > nymipa.ipany.domain.com:636 (/etc/dirsrv/slapd-IPANY) > > > [14/Oct/2013:17:32:43 -0400] - 389-Directory/1.2.11.15 B2013.240.174 starting up > [14/Oct/2013:17:32:43 -0400] schema-compat-plugin - warning: no > entries set up under cn=computers, cn=compat,dc=ipany > [14/Oct/2013:17:32:43 -0400] schema-compat-plugin - warning: no > entries set up under cn=ng, cn=compat,dc=ipany > [14/Oct/2013:17:32:43 -0400] schema-compat-plugin - warning: no > entries set up under ou=sudoers,dc=ipany > [14/Oct/2013:17:32:44 -0400] - Skipping CoS Definition cn=Password > Policy,cn=accounts,dc=ipany--no CoS Templates found, which should be > added before the CoS Definition. > [14/Oct/2013:17:32:44 -0400] - Skipping CoS Definition cn=Password > Policy,cn=accounts,dc=ipany--no CoS Templates found, which should be > added before the CoS Definition. > [14/Oct/2013:17:32:44 -0400] - slapd started. Listening on All > Interfaces port 389 for LDAP requests > [14/Oct/2013:17:32:44 -0400] - Listening on All Interfaces port 636 > for LDAPS requests > [14/Oct/2013:17:32:44 -0400] - Listening on > /var/run/slapd-IPANY.socket for LDAPI requests > [14/Oct/2013:17:32:45 -0400] - Entry > "cn=meTodc02.domain.com,cn=replica,cn=dc\3Dipany,cn=mapping > tree,cn=config" -- attribute "nsDS5ReplicatedAttributeListTotal" not > allowed This is odd. Looks like fractional replication is not supported by winsync, but ipa-replica-manage is trying to use it. But this should not cause any problems. > [14/Oct/2013:17:32:45 -0400] NSMMReplicationPlugin - > agmt="cn=meTodc02.domain.com" (dc02:389): Replica has no update > vector. It has never been initialized. > [14/Oct/2013:17:32:45 -0400] NSMMReplicationPlugin - > agmt="cn=meTodc02.domain.com" (dc02:389): Replica has no update > vector. It has never been initialized. > [14/Oct/2013:17:32:45 -0400] NSMMReplicationPlugin - > agmt="cn=meTodc02.domain.com" (dc02:389): Replica has no update > vector. It has never been initialized. This is normal when you first create the winsync agreement but have not yet initialized it. > [14/Oct/2013:17:32:47 -0400] NSMMReplicationPlugin - Beginning total > update of replica "agmt="cn=meTodc02.domain.com" (dc02:389)". > [14/Oct/2013:17:32:49 -0400] - Entry > "uid=nfsuser,cn=users,cn=accounts,dc=ipany" missing attribute "sn" > required by object class "person" > [14/Oct/2013:17:32:49 -0400] - Entry > "uid=tapeop,cn=users,cn=accounts,dc=ipany" missing attribute "sn" > required by object class "person" > [14/Oct/2013:17:33:14 -0400] - Entry > "uid=nfsuserevs,cn=users,cn=accounts,dc=ipany" missing attribute "sn" > required by object class "person" > [14/Oct/2013:17:33:14 -0400] - Entry > "uid=nfsuserbk01,cn=users,cn=accounts,dc=ipany" missing attribute "sn" > required by object class "person" > > > Should I go ahead and enable a more verbose log level (8192) and > re-run the ipa-replica-manage connect --winsync .... again? I killed > the process this morning so would I need to do any type of "clean up" > before re-running? I'm not sure if this winsync update finished - please turn on the 8192 log level and see what it is doing. If that shows nothing, then try ipa-replica-manage re-initialize .... It looks like winsync is already "connected". > > > thanks, > -J. > > On Tue, Oct 15, 2013 at 9:26 AM, Rich Megginson wrote: >> On 10/15/2013 01:22 AM, Alexander Bokovoy wrote: >>> On Mon, 14 Oct 2013, janice.psyop wrote: >>> >>>> Hi, >>>> >>>> I've been setting up an IPA server (centos 6.4) with AD trust (2008R2 >>>> domain) following the FC18 freeipa guide. >>> AD trusts is different from AD sync agreement. >>> >>> What you describe below is use of passsync/winsync (AD sync), not AD >>> trusts. Just to make sure we are on the same level here. >>>> >>>> Everything has gone smoothly until I ran the ipa-replica-manage connect >>>> command to the AD DC and it seems to be running (no errors on std out and >>>> ps says it is still running), but it has been running for six hours! We >>>> do >>>> have ~2000 user entries, but I didn't think it would take this long to >>>> sync up. >>>> >>>> The command I ran was this (see below) and the screen now just displays >>>> repeating "Update in progress". I'm very tempted to kill it in case >>>> something is going horribly wrong (with the AD user accounts...) >>>> >>>> /usr/sbin/ipa-replica-manage connect --winsync >>>> --passsync=MySecretPass >>>> --binddn=CN=myipasyncuser,CN=Users,DC=domain,DC=com >>>> --bindpw=MySecretPass >>>> --cacert=/etc/openldap/cacerts/DC-CA.cer >>>> -v dc.domain.com >>>> >>>> >>>> Update in progress >>>> Update in progress >>>> Update in progress >>>> Update in progress >>>> Update in progress >>>> Update in progress >>>> Update in progress >>>> >>>> >>>> Is there any way to check the progress of this in case it is in fact hung >>>> up? The last few entries in the ipa/default.log is from six hours ago: >>>> >>>> >>>> 2013-10-14T21:32:45Z 2706 MainThread ipa INFO Added new >>>> sync agreement, waiting for it to become ready . . . >>>> 2013-10-14T21:32:46Z 2706 MainThread ipa INFO Replication >>>> Update in progress: FALSE: status: 0 Replica acquired successfully: >>>> Incremental update started: start: 0: end: 0 >>>> 2013-10-14T21:32:46Z 2706 MainThread ipa INFO Agreement >>>> is ready, starting replication . . . >>> Try to change some user data on AD side, it would trigger update of the >>> IPA side. >>> >> Take a look at the 389 errors log - /var/log/dirsrv/slapd-YOUR-DOMAIN/errors >> - anything in there? >> If not, then you can turn on replication/sync error logging >> http://port389.org/wiki/FAQ#Troubleshooting > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From rcritten at redhat.com Tue Oct 15 17:37:49 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 15 Oct 2013 13:37:49 -0400 Subject: [Freeipa-users] Subsystem certs not renewed In-Reply-To: <525CFDA6.2000404@yahoo.it> References: <525C0389.4060905@yahoo.it> <525C073A.3030409@redhat.com> <525CFDA6.2000404@yahoo.it> Message-ID: <525D7D6D.9080602@redhat.com> Federico Nebiolo wrote: > Il 14/10/2013 17:01, Rob Crittenden ha scritto: >> Federico Nebiolo wrote: >>> Dear IPA users, >>> >>> My IPA 3.0 installation on CentOS 6.4 (coming from a 2.2 upgrade) >>> suddenly stopped working for the CA part. >>> I'm not sure this is the root of all the issues, but subsystem >>> certificates was expired and not renewed: getcert list gives a similar >>> output for all of them, and I don't know how to proceed. >>> >>> []# getcert list -c dogtag-ipa-renew-agent >>> >>> Request ID '20130902075915': >>> status: MONITORING >>> ca-error: No end-entity URL (-E) given, and no default known. >>> stuck: no >>> key pair storage: >>> type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS >>> Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >>> certificate: >>> type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS >>> Certificate DB' >>> CA: dogtag-ipa-renew-agent >>> issuer: CN=Certificate Authority,O=XXXX >>> subject: CN=RA Subsystem,O=XXXX >>> expires: 2013-10-11 07:44:12 UTC >>> eku: id-kp-serverAuth,id-kp-clientAuth >>> pre-save command: >>> post-save command: /usr/lib64/ipa/certmonger/renew_ra_cert >>> track: yes >>> auto-renew: yes >>> >>> Do you have any hints on how to solve? >> >> Try adding a host= to the [global] section in >> /etc/ipa/default.conf where host is the fqdn of your IPA master. >> >> I think you'll need to temporarily go back in time to the 11th for the >> renewal to succeed. >> >> You can force certmonger to try the renewal again with: >> >> # getcert resubmit -i 20130902075915 >> >> You'll want to do this for all certs affected by this. >> >> If this works please let us know and we'll make sure that host exists in >> default.conf when upgrades happen. >> >> rob > > Rob, > adding host= and moving the clock backward partially worked. > > Now both "CN=RA Subsystem" and "CN=" certificates are renewed, but > certmonger is unable to renew "CN=CA Subsystem", "CN=CA Audit" and > "CN=OCSP Subsystem". > > Certmonger error is an "Error 35 connecting to > https://:9443/ca/agent/ca/profileReview: SSL connect error": it > seems to me that selfsigned CA certificate in chain is not accepted by > certmonger, thus certificates are not renewed. Is there another > parameter I can specify to make dogtag-ipa-renew-agent accept its CA? I'm not sure why it wouldn't accept the connection. Could it be that you didn't set time back far enough? I think you can simulate things with something like: # echo "" > /tmp/pw # sslget -v -d /etc/pki/nssdb/ -w /tmp/pw -r /ca/ee/ca/getCertChain ipa.example.com:9443 You might try a similar command with curl, you just need to create the sqlite equivalent first: # certutil -A -d sql:/etc/pki/nssdb -n 'IPA CA' -t CT,CT, -a -i /etc/ipa/ca.crt # curl -v https://ipa.example.com:9443/ca/ee/ca/getCertChain Hopefully you'll get a more specific error message out of one of those. rob From janice.psyop at gmail.com Tue Oct 15 18:32:34 2013 From: janice.psyop at gmail.com (janice.psyop) Date: Tue, 15 Oct 2013 14:32:34 -0400 Subject: [Freeipa-users] ipa sync agreement to AD DC is taking a very long time In-Reply-To: <525D661E.4080603@redhat.com> References: <20131015072240.GJ30236@redhat.com> <525D4299.4070909@redhat.com> <525D661E.4080603@redhat.com> Message-ID: Found out that ns-slapd was not running/was dead ("No such process not running, but pid file exists") -- discovered that when I tried to do the ldapmodify and got the "ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)" error. Anyway, I started dirsrv and did the ldapmodify with more verbosity and this is the error log: [15/Oct/2013:14:04:12 -0400] - 389-Directory/1.2.11.15 B2013.240.174 starting up [15/Oct/2013:14:04:12 -0400] - WARNING: userRoot: entry cache size 10485760B is less than db size 10706944B; We recommend to increase the entry cache size nsslapd-cachememsize. [15/Oct/2013:14:04:12 -0400] - Detected Disorderly Shutdown last time Directory Server was running, recovering database. [15/Oct/2013:14:04:12 -0400] schema-compat-plugin - warning: no entries set up under cn=computers, cn=compat,dc=ipany [15/Oct/2013:14:04:13 -0400] schema-compat-plugin - warning: no entries set up under cn=ng, cn=compat,dc=ipany [15/Oct/2013:14:04:13 -0400] schema-compat-plugin - warning: no entries set up under ou=sudoers,dc=ipany [15/Oct/2013:14:04:13 -0400] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=ipany--no CoS Templates found, which should be added before the CoS Definition. [15/Oct/2013:14:04:14 -0400] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=ipany--no CoS Templates found, which should be added before the CoS Definition. [15/Oct/2013:14:04:14 -0400] - slapd started. Listening on All Interfaces port 389 for LDAP requests [15/Oct/2013:14:04:14 -0400] - Listening on All Interfaces port 636 for LDAPS requests [15/Oct/2013:14:04:14 -0400] - Listening on /var/run/slapd-IPAPSYOP.socket for LDAPI requests [15/Oct/2013:14:04:14 -0400] NSMMReplicationPlugin - Beginning total update of replica "agmt="cn=meTodc02.domain.com" (dc02:389)". [15/Oct/2013:14:04:30 -0400] - Entry "uid=nfsusercrenshaw,cn=users,cn=accounts,dc=ipany" missing attribute "sn" required by object class "person" [snip] this is a tail of the slapd-IPNY/access log: [15/Oct/2013:14:24:08 -0400] conn=10 op=2 BIND dn="" method=sasl version=3 mech=GSSAPI [15/Oct/2013:14:24:08 -0400] conn=10 op=0 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress [15/Oct/2013:14:24:08 -0400] conn=10 op=3 SRCH base="" scope=0 filter="(objectClass=*)" attrs="supportedControl" [15/Oct/2013:14:24:08 -0400] conn=10 op=3 RESULT err=0 tag=101 nentries=1 etime=0 [15/Oct/2013:14:24:08 -0400] conn=10 op=4 SRCH base="cn=ad,cn=trusts,dc=ipany" scope=2 filter="(objectClass=ipaNTTrustedDomain)" attrs=ALL [15/Oct/2013:14:24:08 -0400] conn=10 op=4 RESULT err=0 tag=101 nentries=1 etime=0 [15/Oct/2013:14:24:08 -0400] conn=10 op=2 RESULT err=0 tag=97 nentries=0 etime=0 dn="krbprincipalname=cifs/nymipa.ipany.domain.com at ipany,cn=services,cn=accounts,dc=ipany" How can I tell if the winsync update finished? Is there a query command or other log file? Thanks very much for all the help! -J. On Tue, Oct 15, 2013 at 11:58 AM, Rich Megginson wrote: > On 10/15/2013 09:51 AM, janice.psyop wrote: >> >> Thanks for the replies. >> >> I checked this morning and it was still hung up on "Update in progess" >> so I killed it. >> >> @Alexander: Yes, I had already established a trust with our AD DC. I >> was doing step " 9.4.2. Creating Synchronization Agreements" >> (FreeIPA_Guide/managing-sync-agmt.html) I've been following the >> guide step-by-step. >> >> >> Here is the slapd-REALM/errors log (I truncated most of the repeating >> missing attribute errors, but the last line is really the last line in >> the log). I don't see any glaring errors: >> >> >> # cat /var/log/dirsrv/slapd-IPANY/errors >> 389-Directory/1.2.11.15 B2013.240.174 >> nymipa.ipany.domain.com:636 (/etc/dirsrv/slapd-IPANY) >> >> >> [14/Oct/2013:17:32:43 -0400] - 389-Directory/1.2.11.15 B2013.240.174 >> starting up >> [14/Oct/2013:17:32:43 -0400] schema-compat-plugin - warning: no >> entries set up under cn=computers, cn=compat,dc=ipany >> [14/Oct/2013:17:32:43 -0400] schema-compat-plugin - warning: no >> entries set up under cn=ng, cn=compat,dc=ipany >> [14/Oct/2013:17:32:43 -0400] schema-compat-plugin - warning: no >> entries set up under ou=sudoers,dc=ipany >> [14/Oct/2013:17:32:44 -0400] - Skipping CoS Definition cn=Password >> Policy,cn=accounts,dc=ipany--no CoS Templates found, which should be >> added before the CoS Definition. >> [14/Oct/2013:17:32:44 -0400] - Skipping CoS Definition cn=Password >> Policy,cn=accounts,dc=ipany--no CoS Templates found, which should be >> added before the CoS Definition. >> [14/Oct/2013:17:32:44 -0400] - slapd started. Listening on All >> Interfaces port 389 for LDAP requests >> [14/Oct/2013:17:32:44 -0400] - Listening on All Interfaces port 636 >> for LDAPS requests >> [14/Oct/2013:17:32:44 -0400] - Listening on >> /var/run/slapd-IPANY.socket for LDAPI requests >> [14/Oct/2013:17:32:45 -0400] - Entry >> "cn=meTodc02.domain.com,cn=replica,cn=dc\3Dipany,cn=mapping >> tree,cn=config" -- attribute "nsDS5ReplicatedAttributeListTotal" not >> allowed > > > This is odd. Looks like fractional replication is not supported by winsync, > but ipa-replica-manage is trying to use it. But this should not cause any > problems. > > >> [14/Oct/2013:17:32:45 -0400] NSMMReplicationPlugin - >> agmt="cn=meTodc02.domain.com" (dc02:389): Replica has no update >> vector. It has never been initialized. >> [14/Oct/2013:17:32:45 -0400] NSMMReplicationPlugin - >> agmt="cn=meTodc02.domain.com" (dc02:389): Replica has no update >> vector. It has never been initialized. >> [14/Oct/2013:17:32:45 -0400] NSMMReplicationPlugin - >> agmt="cn=meTodc02.domain.com" (dc02:389): Replica has no update >> vector. It has never been initialized. > > > This is normal when you first create the winsync agreement but have not yet > initialized it. > > >> [14/Oct/2013:17:32:47 -0400] NSMMReplicationPlugin - Beginning total >> update of replica "agmt="cn=meTodc02.domain.com" (dc02:389)". >> [14/Oct/2013:17:32:49 -0400] - Entry >> "uid=nfsuser,cn=users,cn=accounts,dc=ipany" missing attribute "sn" >> required by object class "person" >> [14/Oct/2013:17:32:49 -0400] - Entry >> "uid=tapeop,cn=users,cn=accounts,dc=ipany" missing attribute "sn" >> required by object class "person" >> [14/Oct/2013:17:33:14 -0400] - Entry >> "uid=nfsuserevs,cn=users,cn=accounts,dc=ipany" missing attribute "sn" >> required by object class "person" >> [14/Oct/2013:17:33:14 -0400] - Entry >> "uid=nfsuserbk01,cn=users,cn=accounts,dc=ipany" missing attribute "sn" >> required by object class "person" >> >> >> Should I go ahead and enable a more verbose log level (8192) and >> re-run the ipa-replica-manage connect --winsync .... again? I killed >> the process this morning so would I need to do any type of "clean up" >> before re-running? > > > I'm not sure if this winsync update finished - please turn on the 8192 log > level and see what it is doing. If that shows nothing, then try > ipa-replica-manage re-initialize .... It looks like winsync is already > "connected". > >> >> >> thanks, >> -J. >> >> On Tue, Oct 15, 2013 at 9:26 AM, Rich Megginson >> wrote: >>> >>> On 10/15/2013 01:22 AM, Alexander Bokovoy wrote: >>>> >>>> On Mon, 14 Oct 2013, janice.psyop wrote: >>>> >>>>> Hi, >>>>> >>>>> I've been setting up an IPA server (centos 6.4) with AD trust (2008R2 >>>>> domain) following the FC18 freeipa guide. >>>> >>>> AD trusts is different from AD sync agreement. >>>> >>>> What you describe below is use of passsync/winsync (AD sync), not AD >>>> trusts. Just to make sure we are on the same level here. >>>>> >>>>> >>>>> Everything has gone smoothly until I ran the ipa-replica-manage connect >>>>> command to the AD DC and it seems to be running (no errors on std out >>>>> and >>>>> ps says it is still running), but it has been running for six hours! >>>>> We >>>>> do >>>>> have ~2000 user entries, but I didn't think it would take this long to >>>>> sync up. >>>>> >>>>> The command I ran was this (see below) and the screen now just displays >>>>> repeating "Update in progress". I'm very tempted to kill it in case >>>>> something is going horribly wrong (with the AD user accounts...) >>>>> >>>>> /usr/sbin/ipa-replica-manage connect --winsync >>>>> --passsync=MySecretPass >>>>> --binddn=CN=myipasyncuser,CN=Users,DC=domain,DC=com >>>>> --bindpw=MySecretPass >>>>> --cacert=/etc/openldap/cacerts/DC-CA.cer >>>>> -v dc.domain.com >>>>> >>>>> >>>>> Update in progress >>>>> Update in progress >>>>> Update in progress >>>>> Update in progress >>>>> Update in progress >>>>> Update in progress >>>>> Update in progress >>>>> >>>>> >>>>> Is there any way to check the progress of this in case it is in fact >>>>> hung >>>>> up? The last few entries in the ipa/default.log is from six hours ago: >>>>> >>>>> >>>>> 2013-10-14T21:32:45Z 2706 MainThread ipa INFO Added new >>>>> sync agreement, waiting for it to become ready . . . >>>>> 2013-10-14T21:32:46Z 2706 MainThread ipa INFO >>>>> Replication >>>>> Update in progress: FALSE: status: 0 Replica acquired successfully: >>>>> Incremental update started: start: 0: end: 0 >>>>> 2013-10-14T21:32:46Z 2706 MainThread ipa INFO Agreement >>>>> is ready, starting replication . . . >>>> >>>> Try to change some user data on AD side, it would trigger update of the >>>> IPA side. >>>> >>> Take a look at the 389 errors log - >>> /var/log/dirsrv/slapd-YOUR-DOMAIN/errors >>> - anything in there? >>> If not, then you can turn on replication/sync error logging >>> http://port389.org/wiki/FAQ#Troubleshooting >> >> _______________________________________________ >> >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > From rmeggins at redhat.com Tue Oct 15 18:42:50 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 15 Oct 2013 12:42:50 -0600 Subject: [Freeipa-users] ipa sync agreement to AD DC is taking a very long time In-Reply-To: References: <20131015072240.GJ30236@redhat.com> <525D4299.4070909@redhat.com> <525D661E.4080603@redhat.com> Message-ID: <525D8CAA.2090402@redhat.com> On 10/15/2013 12:32 PM, janice.psyop wrote: > Found out that ns-slapd was not running/was dead ("No such process not > running, but pid file exists") -- discovered that when I tried to do > the ldapmodify and got the "ldap_sasl_bind(SIMPLE): Can't contact LDAP > server (-1)" error. > > > Anyway, I started dirsrv and did the ldapmodify with more verbosity > and this is the error log: > > [15/Oct/2013:14:04:12 -0400] - 389-Directory/1.2.11.15 B2013.240.174 starting up > [15/Oct/2013:14:04:12 -0400] - WARNING: userRoot: entry cache size > 10485760B is less than db size 10706944B; We recommend to increase the > entry cache size nsslapd-cachememsize. > [15/Oct/2013:14:04:12 -0400] - Detected Disorderly Shutdown last time > Directory Server was running, recovering database. Hmm - this usually happens after a crash. Please read http://port389.org/wiki/FAQ#Debugging_Crashes to enable the system to produce core files, and to get a stack trace. > [15/Oct/2013:14:04:12 -0400] schema-compat-plugin - warning: no > entries set up under cn=computers, cn=compat,dc=ipany > [15/Oct/2013:14:04:13 -0400] schema-compat-plugin - warning: no > entries set up under cn=ng, cn=compat,dc=ipany > [15/Oct/2013:14:04:13 -0400] schema-compat-plugin - warning: no > entries set up under ou=sudoers,dc=ipany > [15/Oct/2013:14:04:13 -0400] - Skipping CoS Definition cn=Password > Policy,cn=accounts,dc=ipany--no CoS Templates found, which should be > added before the CoS Definition. > [15/Oct/2013:14:04:14 -0400] - Skipping CoS Definition cn=Password > Policy,cn=accounts,dc=ipany--no CoS Templates found, which should be > added before the CoS Definition. > [15/Oct/2013:14:04:14 -0400] - slapd started. Listening on All > Interfaces port 389 for LDAP requests > [15/Oct/2013:14:04:14 -0400] - Listening on All Interfaces port 636 > for LDAPS requests > [15/Oct/2013:14:04:14 -0400] - Listening on > /var/run/slapd-IPAPSYOP.socket for LDAPI requests > [15/Oct/2013:14:04:14 -0400] NSMMReplicationPlugin - Beginning total > update of replica "agmt="cn=meTodc02.domain.com" (dc02:389)". > [15/Oct/2013:14:04:30 -0400] - Entry > "uid=nfsusercrenshaw,cn=users,cn=accounts,dc=ipany" missing attribute > "sn" required by object class "person" > [snip] > > > this is a tail of the slapd-IPNY/access log: > > [15/Oct/2013:14:24:08 -0400] conn=10 op=2 BIND dn="" method=sasl > version=3 mech=GSSAPI > [15/Oct/2013:14:24:08 -0400] conn=10 op=0 RESULT err=14 tag=97 > nentries=0 etime=0, SASL bind in progress > [15/Oct/2013:14:24:08 -0400] conn=10 op=3 SRCH base="" scope=0 > filter="(objectClass=*)" attrs="supportedControl" > [15/Oct/2013:14:24:08 -0400] conn=10 op=3 RESULT err=0 tag=101 > nentries=1 etime=0 > [15/Oct/2013:14:24:08 -0400] conn=10 op=4 SRCH > base="cn=ad,cn=trusts,dc=ipany" scope=2 > filter="(objectClass=ipaNTTrustedDomain)" attrs=ALL > [15/Oct/2013:14:24:08 -0400] conn=10 op=4 RESULT err=0 tag=101 > nentries=1 etime=0 > [15/Oct/2013:14:24:08 -0400] conn=10 op=2 RESULT err=0 tag=97 > nentries=0 etime=0 > dn="krbprincipalname=cifs/nymipa.ipany.domain.com at ipany,cn=services,cn=accounts,dc=ipany" > > > How can I tell if the winsync update finished? Is there a query > command or other log file? If you use the repl (8192) log level, it should tell you. > > > Thanks very much for all the help! > -J. > > > > On Tue, Oct 15, 2013 at 11:58 AM, Rich Megginson wrote: >> On 10/15/2013 09:51 AM, janice.psyop wrote: >>> Thanks for the replies. >>> >>> I checked this morning and it was still hung up on "Update in progess" >>> so I killed it. >>> >>> @Alexander: Yes, I had already established a trust with our AD DC. I >>> was doing step " 9.4.2. Creating Synchronization Agreements" >>> (FreeIPA_Guide/managing-sync-agmt.html) I've been following the >>> guide step-by-step. >>> >>> >>> Here is the slapd-REALM/errors log (I truncated most of the repeating >>> missing attribute errors, but the last line is really the last line in >>> the log). I don't see any glaring errors: >>> >>> >>> # cat /var/log/dirsrv/slapd-IPANY/errors >>> 389-Directory/1.2.11.15 B2013.240.174 >>> nymipa.ipany.domain.com:636 (/etc/dirsrv/slapd-IPANY) >>> >>> >>> [14/Oct/2013:17:32:43 -0400] - 389-Directory/1.2.11.15 B2013.240.174 >>> starting up >>> [14/Oct/2013:17:32:43 -0400] schema-compat-plugin - warning: no >>> entries set up under cn=computers, cn=compat,dc=ipany >>> [14/Oct/2013:17:32:43 -0400] schema-compat-plugin - warning: no >>> entries set up under cn=ng, cn=compat,dc=ipany >>> [14/Oct/2013:17:32:43 -0400] schema-compat-plugin - warning: no >>> entries set up under ou=sudoers,dc=ipany >>> [14/Oct/2013:17:32:44 -0400] - Skipping CoS Definition cn=Password >>> Policy,cn=accounts,dc=ipany--no CoS Templates found, which should be >>> added before the CoS Definition. >>> [14/Oct/2013:17:32:44 -0400] - Skipping CoS Definition cn=Password >>> Policy,cn=accounts,dc=ipany--no CoS Templates found, which should be >>> added before the CoS Definition. >>> [14/Oct/2013:17:32:44 -0400] - slapd started. Listening on All >>> Interfaces port 389 for LDAP requests >>> [14/Oct/2013:17:32:44 -0400] - Listening on All Interfaces port 636 >>> for LDAPS requests >>> [14/Oct/2013:17:32:44 -0400] - Listening on >>> /var/run/slapd-IPANY.socket for LDAPI requests >>> [14/Oct/2013:17:32:45 -0400] - Entry >>> "cn=meTodc02.domain.com,cn=replica,cn=dc\3Dipany,cn=mapping >>> tree,cn=config" -- attribute "nsDS5ReplicatedAttributeListTotal" not >>> allowed >> >> This is odd. Looks like fractional replication is not supported by winsync, >> but ipa-replica-manage is trying to use it. But this should not cause any >> problems. >> >> >>> [14/Oct/2013:17:32:45 -0400] NSMMReplicationPlugin - >>> agmt="cn=meTodc02.domain.com" (dc02:389): Replica has no update >>> vector. It has never been initialized. >>> [14/Oct/2013:17:32:45 -0400] NSMMReplicationPlugin - >>> agmt="cn=meTodc02.domain.com" (dc02:389): Replica has no update >>> vector. It has never been initialized. >>> [14/Oct/2013:17:32:45 -0400] NSMMReplicationPlugin - >>> agmt="cn=meTodc02.domain.com" (dc02:389): Replica has no update >>> vector. It has never been initialized. >> >> This is normal when you first create the winsync agreement but have not yet >> initialized it. >> >> >>> [14/Oct/2013:17:32:47 -0400] NSMMReplicationPlugin - Beginning total >>> update of replica "agmt="cn=meTodc02.domain.com" (dc02:389)". >>> [14/Oct/2013:17:32:49 -0400] - Entry >>> "uid=nfsuser,cn=users,cn=accounts,dc=ipany" missing attribute "sn" >>> required by object class "person" >>> [14/Oct/2013:17:32:49 -0400] - Entry >>> "uid=tapeop,cn=users,cn=accounts,dc=ipany" missing attribute "sn" >>> required by object class "person" >>> [14/Oct/2013:17:33:14 -0400] - Entry >>> "uid=nfsuserevs,cn=users,cn=accounts,dc=ipany" missing attribute "sn" >>> required by object class "person" >>> [14/Oct/2013:17:33:14 -0400] - Entry >>> "uid=nfsuserbk01,cn=users,cn=accounts,dc=ipany" missing attribute "sn" >>> required by object class "person" >>> >>> >>> Should I go ahead and enable a more verbose log level (8192) and >>> re-run the ipa-replica-manage connect --winsync .... again? I killed >>> the process this morning so would I need to do any type of "clean up" >>> before re-running? >> >> I'm not sure if this winsync update finished - please turn on the 8192 log >> level and see what it is doing. If that shows nothing, then try >> ipa-replica-manage re-initialize .... It looks like winsync is already >> "connected". >> >>> >>> thanks, >>> -J. >>> >>> On Tue, Oct 15, 2013 at 9:26 AM, Rich Megginson >>> wrote: >>>> On 10/15/2013 01:22 AM, Alexander Bokovoy wrote: >>>>> On Mon, 14 Oct 2013, janice.psyop wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I've been setting up an IPA server (centos 6.4) with AD trust (2008R2 >>>>>> domain) following the FC18 freeipa guide. >>>>> AD trusts is different from AD sync agreement. >>>>> >>>>> What you describe below is use of passsync/winsync (AD sync), not AD >>>>> trusts. Just to make sure we are on the same level here. >>>>>> >>>>>> Everything has gone smoothly until I ran the ipa-replica-manage connect >>>>>> command to the AD DC and it seems to be running (no errors on std out >>>>>> and >>>>>> ps says it is still running), but it has been running for six hours! >>>>>> We >>>>>> do >>>>>> have ~2000 user entries, but I didn't think it would take this long to >>>>>> sync up. >>>>>> >>>>>> The command I ran was this (see below) and the screen now just displays >>>>>> repeating "Update in progress". I'm very tempted to kill it in case >>>>>> something is going horribly wrong (with the AD user accounts...) >>>>>> >>>>>> /usr/sbin/ipa-replica-manage connect --winsync >>>>>> --passsync=MySecretPass >>>>>> --binddn=CN=myipasyncuser,CN=Users,DC=domain,DC=com >>>>>> --bindpw=MySecretPass >>>>>> --cacert=/etc/openldap/cacerts/DC-CA.cer >>>>>> -v dc.domain.com >>>>>> >>>>>> >>>>>> Update in progress >>>>>> Update in progress >>>>>> Update in progress >>>>>> Update in progress >>>>>> Update in progress >>>>>> Update in progress >>>>>> Update in progress >>>>>> >>>>>> >>>>>> Is there any way to check the progress of this in case it is in fact >>>>>> hung >>>>>> up? The last few entries in the ipa/default.log is from six hours ago: >>>>>> >>>>>> >>>>>> 2013-10-14T21:32:45Z 2706 MainThread ipa INFO Added new >>>>>> sync agreement, waiting for it to become ready . . . >>>>>> 2013-10-14T21:32:46Z 2706 MainThread ipa INFO >>>>>> Replication >>>>>> Update in progress: FALSE: status: 0 Replica acquired successfully: >>>>>> Incremental update started: start: 0: end: 0 >>>>>> 2013-10-14T21:32:46Z 2706 MainThread ipa INFO Agreement >>>>>> is ready, starting replication . . . >>>>> Try to change some user data on AD side, it would trigger update of the >>>>> IPA side. >>>>> >>>> Take a look at the 389 errors log - >>>> /var/log/dirsrv/slapd-YOUR-DOMAIN/errors >>>> - anything in there? >>>> If not, then you can turn on replication/sync error logging >>>> http://port389.org/wiki/FAQ#Troubleshooting >>> _______________________________________________ >>> >>> 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 Mike.Calautti at genesyslab.com Tue Oct 15 19:39:45 2013 From: Mike.Calautti at genesyslab.com (Mike Calautti) Date: Tue, 15 Oct 2013 19:39:45 +0000 Subject: [Freeipa-users] stupid question Message-ID: <37D7774D237F0F4FA1CC50B5FE41FBD503E768@GENSJZMBX03.msg.int.genesyslab.com> Newbie I see a lot about DNS built into freeIPA. Im installing via yum on centos6.4 Do I just ignore the DNS part since we have our own DNS servers? Or does freeIPA still need local DNS entries? Also, im not sure I follow "clients" I see it explains that you can add clients so services and use IPA.. However, does any client that is supposed to authenticate users to freeIPA, need to be added as a client? Or is there just an ldap.conf file that tells the client to auth a user against the freeIPA server. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue Oct 15 19:52:22 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 15 Oct 2013 15:52:22 -0400 Subject: [Freeipa-users] stupid question In-Reply-To: <37D7774D237F0F4FA1CC50B5FE41FBD503E768@GENSJZMBX03.msg.int.genesyslab.com> References: <37D7774D237F0F4FA1CC50B5FE41FBD503E768@GENSJZMBX03.msg.int.genesyslab.com> Message-ID: <525D9CF6.2050000@redhat.com> Mike Calautti wrote: > Newbie > > I see a lot about DNS built into freeIPA. > > Im installing via yum on centos6.4 > > Do I just ignore the DNS part since we have our own DNS servers? Or does > freeIPA still need local DNS entries? You don't need to run an IPA-specific DNS server, it just makes certain things somewhat easier. > Also, im not sure I follow ?clients? I see it explains that you can add > clients so services and use IPA.. > > However, does any client that is supposed to authenticate users to > freeIPA, need to be added as a client? A client is any machine you want to use the IPA server for authentication (and authorization). A separate enrollment script is provided, ipa-client-install, that is used to provision and configure the client to work against IPA, by default using sssd. > Or is there just an ldap.conf file that tells the client to auth a user > against the freeIPA server. You are best off using our install script. You can opt to not use sssd if you really want, or you can configure things manually. We recommend sticking with the defaults, and using sssd. rob From Mike.Calautti at genesyslab.com Tue Oct 15 19:54:17 2013 From: Mike.Calautti at genesyslab.com (Mike Calautti) Date: Tue, 15 Oct 2013 19:54:17 +0000 Subject: [Freeipa-users] stupid question In-Reply-To: <525D9CF6.2050000@redhat.com> References: <37D7774D237F0F4FA1CC50B5FE41FBD503E768@GENSJZMBX03.msg.int.genesyslab.com> <525D9CF6.2050000@redhat.com> Message-ID: <37D7774D237F0F4FA1CC50B5FE41FBD503E7A7@GENSJZMBX03.msg.int.genesyslab.com> Yes.. thanks !! I just saw that myself.. So I need to install the ipa-client.x86_64 package on the client I take it.. Thanks for the quick response !!! Mike -----Original Message----- From: Rob Crittenden [mailto:rcritten at redhat.com] Sent: Tuesday, October 15, 2013 3:52 PM To: Mike Calautti; freeipa-users at redhat.com Subject: Re: [Freeipa-users] stupid question Mike Calautti wrote: > Newbie > > I see a lot about DNS built into freeIPA. > > Im installing via yum on centos6.4 > > Do I just ignore the DNS part since we have our own DNS servers? Or > does freeIPA still need local DNS entries? You don't need to run an IPA-specific DNS server, it just makes certain things somewhat easier. > Also, im not sure I follow "clients" I see it explains that you can > add clients so services and use IPA.. > > However, does any client that is supposed to authenticate users to > freeIPA, need to be added as a client? A client is any machine you want to use the IPA server for authentication (and authorization). A separate enrollment script is provided, ipa-client-install, that is used to provision and configure the client to work against IPA, by default using sssd. > Or is there just an ldap.conf file that tells the client to auth a > user against the freeIPA server. You are best off using our install script. You can opt to not use sssd if you really want, or you can configure things manually. We recommend sticking with the defaults, and using sssd. rob From abokovoy at redhat.com Tue Oct 15 20:01:11 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 15 Oct 2013 16:01:11 -0400 (EDT) Subject: [Freeipa-users] ipa sync agreement to AD DC is taking a very long time In-Reply-To: References: <20131015072240.GJ30236@redhat.com> <525D4299.4070909@redhat.com> Message-ID: <1721764361.2211860.1381867271307.JavaMail.root@redhat.com> ----- Original Message ----- > From: "janice.psyop" > To: freeipa-users at redhat.com > Sent: Tuesday, October 15, 2013 6:51:42 PM > Subject: Re: [Freeipa-users] ipa sync agreement to AD DC is taking a very long time > > Thanks for the replies. > > I checked this morning and it was still hung up on "Update in progess" > so I killed it. > > @Alexander: Yes, I had already established a trust with our AD DC. I > was doing step " 9.4.2. Creating Synchronization Agreements" > (FreeIPA_Guide/managing-sync-agmt.html) I've been following the > guide step-by-step. What I was trying to say is that you have misunderstood instructions and are doing wrong configuration that is not supported and never was meant to exist. AD trusts are configured with 'ipa-adtrust-install' tool and trust is established with 'ipa trust-add' command. We don't replicate any user and group related information from AD to IPA LDAP when using AD trusts. AD replication is a totally separate technique and should not be combined with AD trusts. This combination makes no sense, was not designed to be used together, and is not supported. Therefore, your attempt to add AD replication to already configured AD trusts is wrong. You need to chose what approach to take: either trusts or replication. Dmitri Pal presented AD integration options at DevConf.cz this year. His talk is recorded and available at youtube: http://www.youtube.com/watch?v=cS6EJ1L7fRI and slides are here: http://www.devconf.cz/slides/Linux-AD-Integration-Options.odp I'd recommend to watch this talk as it is most detailed explanation of various options how to integrate POSIX and AD environments. -- / Alexander Bokovoy From Mike.Calautti at genesyslab.com Tue Oct 15 20:02:17 2013 From: Mike.Calautti at genesyslab.com (Mike Calautti) Date: Tue, 15 Oct 2013 20:02:17 +0000 Subject: [Freeipa-users] stupid question In-Reply-To: <37D7774D237F0F4FA1CC50B5FE41FBD503E7A7@GENSJZMBX03.msg.int.genesyslab.com> References: <37D7774D237F0F4FA1CC50B5FE41FBD503E768@GENSJZMBX03.msg.int.genesyslab.com> <525D9CF6.2050000@redhat.com> <37D7774D237F0F4FA1CC50B5FE41FBD503E7A7@GENSJZMBX03.msg.int.genesyslab.com> Message-ID: <37D7774D237F0F4FA1CC50B5FE41FBD503E7C8@GENSJZMBX03.msg.int.genesyslab.com> I installed ipa-client.. I get this now. ipa-client-install Traceback (most recent call last): File "/usr/sbin/ipa-client-install", line 2323, in sys.exit(main()) File "/usr/sbin/ipa-client-install", line 2309, in main rval = install(options, env, fstore, statestore) File "/usr/sbin/ipa-client-install", line 1684, in install ret = ds.search(domain=options.domain, servers=options.server, hostname=hostname, ca_cert_path=get_cert_path(options.ca_cert_file)) File "/usr/lib/python2.6/site-packages/ipaclient/ipadiscovery.py", line 242, in search ldapret = self.ipacheckldap(server, self.realm, ca_cert_path=ca_cert_path) File "/usr/lib/python2.6/site-packages/ipaclient/ipadiscovery.py", line 339, in ipacheckldap basedn = get_ipa_basedn(lh) File "/usr/lib/python2.6/site-packages/ipapython/ipautil.py", line 817, in get_ipa_basedn contexts = entries[0][1]['namingcontexts'] cat /etc/redhat-release CentOS release 6.4 (Final) Linux freeipatest01.dev.com 3.4.61-9.el6.centos.alt.x86_64 #1 SMP Wed Sep 11 15:34:17 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux -----Original Message----- From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Mike Calautti Sent: Tuesday, October 15, 2013 3:54 PM To: Rob Crittenden; freeipa-users at redhat.com Subject: Re: [Freeipa-users] stupid question Yes.. thanks !! I just saw that myself.. So I need to install the ipa-client.x86_64 package on the client I take it.. Thanks for the quick response !!! Mike -----Original Message----- From: Rob Crittenden [mailto:rcritten at redhat.com] Sent: Tuesday, October 15, 2013 3:52 PM To: Mike Calautti; freeipa-users at redhat.com Subject: Re: [Freeipa-users] stupid question Mike Calautti wrote: > Newbie > > I see a lot about DNS built into freeIPA. > > Im installing via yum on centos6.4 > > Do I just ignore the DNS part since we have our own DNS servers? Or > does freeIPA still need local DNS entries? You don't need to run an IPA-specific DNS server, it just makes certain things somewhat easier. > Also, im not sure I follow "clients" I see it explains that you can > add clients so services and use IPA.. > > However, does any client that is supposed to authenticate users to > freeIPA, need to be added as a client? A client is any machine you want to use the IPA server for authentication (and authorization). A separate enrollment script is provided, ipa-client-install, that is used to provision and configure the client to work against IPA, by default using sssd. > Or is there just an ldap.conf file that tells the client to auth a > user against the freeIPA server. You are best off using our install script. You can opt to not use sssd if you really want, or you can configure things manually. We recommend sticking with the defaults, and using sssd. rob _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users From rcritten at redhat.com Tue Oct 15 20:10:48 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 15 Oct 2013 16:10:48 -0400 Subject: [Freeipa-users] stupid question In-Reply-To: <37D7774D237F0F4FA1CC50B5FE41FBD503E7C8@GENSJZMBX03.msg.int.genesyslab.com> References: <37D7774D237F0F4FA1CC50B5FE41FBD503E768@GENSJZMBX03.msg.int.genesyslab.com> <525D9CF6.2050000@redhat.com> <37D7774D237F0F4FA1CC50B5FE41FBD503E7A7@GENSJZMBX03.msg.int.genesyslab.com> <37D7774D237F0F4FA1CC50B5FE41FBD503E7C8@GENSJZMBX03.msg.int.genesyslab.com> Message-ID: <525DA148.5070706@redhat.com> Mike Calautti wrote: > I installed ipa-client.. > > I get this now. > > ipa-client-install > Traceback (most recent call last): > File "/usr/sbin/ipa-client-install", line 2323, in > sys.exit(main()) > File "/usr/sbin/ipa-client-install", line 2309, in main > rval = install(options, env, fstore, statestore) > File "/usr/sbin/ipa-client-install", line 1684, in install > ret = ds.search(domain=options.domain, servers=options.server, hostname=hostname, ca_cert_path=get_cert_path(options.ca_cert_file)) > File "/usr/lib/python2.6/site-packages/ipaclient/ipadiscovery.py", line 242, in search > ldapret = self.ipacheckldap(server, self.realm, ca_cert_path=ca_cert_path) > File "/usr/lib/python2.6/site-packages/ipaclient/ipadiscovery.py", line 339, in ipacheckldap > basedn = get_ipa_basedn(lh) > File "/usr/lib/python2.6/site-packages/ipapython/ipautil.py", line 817, in get_ipa_basedn > contexts = entries[0][1]['namingcontexts'] > > cat /etc/redhat-release > CentOS release 6.4 (Final) Hmm. I'd take a look at /var/log/ipaclient-install.log to see what host it is trying to enroll against. I have the feeling it is finding another host. We fixed a bug post-6.4 related to case insensitivity and namingcontents. I have the feeling the LDAP server you're connecting to isn't return it all as lower case as we expect. rob From janice.psyop at gmail.com Tue Oct 15 20:23:20 2013 From: janice.psyop at gmail.com (janice.psyop) Date: Tue, 15 Oct 2013 16:23:20 -0400 Subject: [Freeipa-users] ipa sync agreement to AD DC is taking a very long time In-Reply-To: <1721764361.2211860.1381867271307.JavaMail.root@redhat.com> References: <20131015072240.GJ30236@redhat.com> <525D4299.4070909@redhat.com> <1721764361.2211860.1381867271307.JavaMail.root@redhat.com> Message-ID: Ah, well that makes sense then! I couldn't understand why the freeipa.org doc (http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup) ends at at cross realm trust -- plus everything was working fine at that point, but I thought the FC18 docs had further instructions for sync agreements --> it was ID10T error on my part! -- just blindly clicking "next"... So I'm just going to "disconnect" and delete the agreement and certs..... Actually, I may just start from scratch. It was easy enough to do up until the point I mixed up the instructions. thanks very much clearing up my misunderstanding / pointing out the obvious!!! And thanks for the link -- probably should watch that first.... LOL. -J. On Tue, Oct 15, 2013 at 4:01 PM, Alexander Bokovoy wrote: > > > ----- Original Message ----- >> From: "janice.psyop" >> To: freeipa-users at redhat.com >> Sent: Tuesday, October 15, 2013 6:51:42 PM >> Subject: Re: [Freeipa-users] ipa sync agreement to AD DC is taking a very long time >> >> Thanks for the replies. >> >> I checked this morning and it was still hung up on "Update in progess" >> so I killed it. >> >> @Alexander: Yes, I had already established a trust with our AD DC. I >> was doing step " 9.4.2. Creating Synchronization Agreements" >> (FreeIPA_Guide/managing-sync-agmt.html) I've been following the >> guide step-by-step. > What I was trying to say is that you have misunderstood instructions and > are doing wrong configuration that is not supported and never was meant to exist. > > AD trusts are configured with 'ipa-adtrust-install' tool and trust is established with 'ipa trust-add' command. > We don't replicate any user and group related information from AD to IPA LDAP when using AD trusts. > > AD replication is a totally separate technique and should not be combined with AD trusts. > This combination makes no sense, was not designed to be used together, and is not supported. > > Therefore, your attempt to add AD replication to already configured AD trusts is wrong. > You need to chose what approach to take: either trusts or replication. > > Dmitri Pal presented AD integration options at DevConf.cz this year. His talk is recorded > and available at youtube: http://www.youtube.com/watch?v=cS6EJ1L7fRI and slides are here: > http://www.devconf.cz/slides/Linux-AD-Integration-Options.odp > > I'd recommend to watch this talk as it is most detailed explanation of various options > how to integrate POSIX and AD environments. > -- > / Alexander Bokovoy From Mike.Calautti at genesyslab.com Tue Oct 15 20:24:47 2013 From: Mike.Calautti at genesyslab.com (Mike Calautti) Date: Tue, 15 Oct 2013 20:24:47 +0000 Subject: [Freeipa-users] stupid question In-Reply-To: <525DA148.5070706@redhat.com> References: <37D7774D237F0F4FA1CC50B5FE41FBD503E768@GENSJZMBX03.msg.int.genesyslab.com> <525D9CF6.2050000@redhat.com> <37D7774D237F0F4FA1CC50B5FE41FBD503E7A7@GENSJZMBX03.msg.int.genesyslab.com> <37D7774D237F0F4FA1CC50B5FE41FBD503E7C8@GENSJZMBX03.msg.int.genesyslab.com> <525DA148.5070706@redhat.com> Message-ID: <37D7774D237F0F4FA1CC50B5FE41FBD503E7FE@GENSJZMBX03.msg.int.genesyslab.com> Your awesome !!!! Interesting.. Well for one its claiming it cant contact the LDAP server... But its calling a machine in our domain that I didn't know existed and furthermore never mentioned in the ipa setup.. So I see it was searching the network... Also..when doing research on installing, I saw that someone said to paste the entries form the example DNS file to your existing DNS db file. I didn't do that because I am just testing.. Would that affect it ? Dns is correct for both IPA master/replica Here is the log. cat /var/log/ipaclient-install.log 2013-10-15T20:18:11Z DEBUG /usr/sbin/ipa-client-install was invoked with options: {'domain': None, 'force': False, 'krb5_offline_passwords': True, 'primary': False, 'mkhomedir': False, 'create_sshfp': True, 'conf_sshd': True, 'on_master': False, 'conf_ntp': True, 'ca_cert_file': None, 'ntp_server': None, 'principal': None, 'hostname': None, 'no_ac': False, 'unattended': None, 'sssd': True, 'trust_sshfp': False, 'dns_updates': False, 'realm_name': None, 'conf_ssh': True, 'server': None, 'prompt_password': False, 'permit': False, 'debug': False, 'preserve_sssd': False, 'uninstall': False} 2013-10-15T20:18:11Z DEBUG missing options might be asked for interactively later 2013-10-15T20:18:11Z DEBUG Loading Index file from '/var/lib/ipa-client/sysrestore/sysrestore.index' 2013-10-15T20:18:11Z DEBUG Loading StateFile from '/var/lib/ipa-client/sysrestore/sysrestore.state' 2013-10-15T20:18:11Z DEBUG [IPA Discovery] 2013-10-15T20:18:11Z DEBUG Starting IPA discovery with domain=None, servers=None, hostname=freeiptest01.dev.com 2013-10-15T20:18:11Z DEBUG Start searching for LDAP SRV record in "dev.com" (domain of the hostname) and its sub-domains 2013-10-15T20:18:11Z DEBUG Search DNS for SRV record of _ldap._tcp.dev.com. 2013-10-15T20:18:11Z DEBUG No DNS record found 2013-10-15T20:18:11Z DEBUG Search DNS for SRV record of _ldap._tcp.dev.com. 2013-10-15T20:18:11Z DEBUG DNS record found: DNSResult::name:_ldap._tcp.dev.com.,type:33,class:1,rdata={priority:0,port:389,weight:100,server:hqdc02.dev.com.} 2013-10-15T20:18:11Z DEBUG DNS record found: DNSResult::name:_ldap._tcp.dev.com.,type:33,class:1,rdata={priority:0,port:389,weight:100,server:hqdc.dev.com.} 2013-10-15T20:18:11Z DEBUG DNS record found: DNSResult::name:_ldap._tcp.dev.com.,type:33,class:1,rdata={priority:0,port:389,weight:100,server:drdc01.dev.com.} 2013-10-15T20:18:11Z DEBUG [Kerberos realm search] 2013-10-15T20:18:11Z DEBUG Search DNS for TXT record of _kerberos.dev.com. 2013-10-15T20:18:11Z DEBUG No DNS record found 2013-10-15T20:18:11Z DEBUG [LDAP server check] 2013-10-15T20:18:11Z DEBUG Verifying that hqdc02.dev.com (realm None) is an IPA server 2013-10-15T20:18:11Z DEBUG Init LDAP connection with: ldap://hqdc02.dev.com:389 2013-10-15T20:18:11Z DEBUG Search LDAP server for IPA base DN If I specify --server=rdsdev01 --domain=dev.com I get Failed to verify that rdsdev01 is an IPA Server. This may mean that the remote server is not up or is not reachable due to network or firewall settings. Please make sure the following ports are opened in the firewall settings: TCP: 80, 88, 389 UDP: 88 (at least one of TCP/UDP ports 88 has to be open) Also note that following ports are necessary for ipa-client working properly after enrollment: TCP: 464 UDP: 464, 123 (if NTP enabled) Installation failed. Rolling back changes. IPA client is not configured on this system. However there is no FW>. Iptables is not running.. and I can telnet to each of those ports. -----Original Message----- From: Rob Crittenden [mailto:rcritten at redhat.com] Sent: Tuesday, October 15, 2013 4:11 PM To: Mike Calautti; freeipa-users at redhat.com Subject: Re: [Freeipa-users] stupid question Mike Calautti wrote: > I installed ipa-client.. > > I get this now. > > ipa-client-install > Traceback (most recent call last): > File "/usr/sbin/ipa-client-install", line 2323, in > sys.exit(main()) > File "/usr/sbin/ipa-client-install", line 2309, in main > rval = install(options, env, fstore, statestore) > File "/usr/sbin/ipa-client-install", line 1684, in install > ret = ds.search(domain=options.domain, servers=options.server, hostname=hostname, ca_cert_path=get_cert_path(options.ca_cert_file)) > File "/usr/lib/python2.6/site-packages/ipaclient/ipadiscovery.py", line 242, in search > ldapret = self.ipacheckldap(server, self.realm, ca_cert_path=ca_cert_path) > File "/usr/lib/python2.6/site-packages/ipaclient/ipadiscovery.py", line 339, in ipacheckldap > basedn = get_ipa_basedn(lh) > File "/usr/lib/python2.6/site-packages/ipapython/ipautil.py", line 817, in get_ipa_basedn > contexts = entries[0][1]['namingcontexts'] > > cat /etc/redhat-release > CentOS release 6.4 (Final) Hmm. I'd take a look at /var/log/ipaclient-install.log to see what host it is trying to enroll against. I have the feeling it is finding another host. We fixed a bug post-6.4 related to case insensitivity and namingcontents. I have the feeling the LDAP server you're connecting to isn't return it all as lower case as we expect. rob From Mike.Calautti at genesyslab.com Tue Oct 15 20:34:53 2013 From: Mike.Calautti at genesyslab.com (Mike Calautti) Date: Tue, 15 Oct 2013 20:34:53 +0000 Subject: [Freeipa-users] stupid question In-Reply-To: <37D7774D237F0F4FA1CC50B5FE41FBD503E7FE@GENSJZMBX03.msg.int.genesyslab.com> References: <37D7774D237F0F4FA1CC50B5FE41FBD503E768@GENSJZMBX03.msg.int.genesyslab.com> <525D9CF6.2050000@redhat.com> <37D7774D237F0F4FA1CC50B5FE41FBD503E7A7@GENSJZMBX03.msg.int.genesyslab.com> <37D7774D237F0F4FA1CC50B5FE41FBD503E7C8@GENSJZMBX03.msg.int.genesyslab.com> <525DA148.5070706@redhat.com> <37D7774D237F0F4FA1CC50B5FE41FBD503E7FE@GENSJZMBX03.msg.int.genesyslab.com> Message-ID: <37D7774D237F0F4FA1CC50B5FE41FBD503E836@GENSJZMBX03.msg.int.genesyslab.com> Ok.. So I did ad the kerberos stuff to the DNS server.. Then I got further.. But got this.. 2013-10-15T20:31:31Z DEBUG Init LDAP connection with: ldap://rdsdev01:389 2013-10-15T20:31:31Z DEBUG LDAP Error: server down So then I added the fqdn and shortname to the clients host file.. And get this., ipa-client-install --server=rdsdev01 --domain=dev.com Autodiscovery of servers for failover cannot work with this configuration. If you proceed with the installation, services will be configured to always access the discovered server for all operations and will not fail over to other servers in case of failure. Proceed with fixed values and no DNS discovery? [no]: -----Original Message----- From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Mike Calautti Sent: Tuesday, October 15, 2013 4:25 PM To: Rob Crittenden; freeipa-users at redhat.com Subject: Re: [Freeipa-users] stupid question Your awesome !!!! Interesting.. Well for one its claiming it cant contact the LDAP server... But its calling a machine in our domain that I didn't know existed and furthermore never mentioned in the ipa setup.. So I see it was searching the network... Also..when doing research on installing, I saw that someone said to paste the entries form the example DNS file to your existing DNS db file. I didn't do that because I am just testing.. Would that affect it ? Dns is correct for both IPA master/replica Here is the log. cat /var/log/ipaclient-install.log 2013-10-15T20:18:11Z DEBUG /usr/sbin/ipa-client-install was invoked with options: {'domain': None, 'force': False, 'krb5_offline_passwords': True, 'primary': False, 'mkhomedir': False, 'create_sshfp': True, 'conf_sshd': True, 'on_master': False, 'conf_ntp': True, 'ca_cert_file': None, 'ntp_server': None, 'principal': None, 'hostname': None, 'no_ac': False, 'unattended': None, 'sssd': True, 'trust_sshfp': False, 'dns_updates': False, 'realm_name': None, 'conf_ssh': True, 'server': None, 'prompt_password': False, 'permit': False, 'debug': False, 'preserve_sssd': False, 'uninstall': False} 2013-10-15T20:18:11Z DEBUG missing options might be asked for interactively later 2013-10-15T20:18:11Z DEBUG Loading Index file from '/var/lib/ipa-client/sysrestore/sysrestore.index' 2013-10-15T20:18:11Z DEBUG Loading StateFile from '/var/lib/ipa-client/sysrestore/sysrestore.state' 2013-10-15T20:18:11Z DEBUG [IPA Discovery] 2013-10-15T20:18:11Z DEBUG Starting IPA discovery with domain=None, servers=None, hostname=freeiptest01.dev.com 2013-10-15T20:18:11Z DEBUG Start searching for LDAP SRV record in "dev.com" (domain of the hostname) and its sub-domains 2013-10-15T20:18:11Z DEBUG Search DNS for SRV record of _ldap._tcp.dev.com. 2013-10-15T20:18:11Z DEBUG No DNS record found 2013-10-15T20:18:11Z DEBUG Search DNS for SRV record of _ldap._tcp.dev.com. 2013-10-15T20:18:11Z DEBUG DNS record found: DNSResult::name:_ldap._tcp.dev.com.,type:33,class:1,rdata={priority:0,port:389,weight:100,server:hqdc02.dev.com.} 2013-10-15T20:18:11Z DEBUG DNS record found: DNSResult::name:_ldap._tcp.dev.com.,type:33,class:1,rdata={priority:0,port:389,weight:100,server:hqdc.dev.com.} 2013-10-15T20:18:11Z DEBUG DNS record found: DNSResult::name:_ldap._tcp.dev.com.,type:33,class:1,rdata={priority:0,port:389,weight:100,server:drdc01.dev.com.} 2013-10-15T20:18:11Z DEBUG [Kerberos realm search] 2013-10-15T20:18:11Z DEBUG Search DNS for TXT record of _kerberos.dev.com. 2013-10-15T20:18:11Z DEBUG No DNS record found 2013-10-15T20:18:11Z DEBUG [LDAP server check] 2013-10-15T20:18:11Z DEBUG Verifying that hqdc02.dev.com (realm None) is an IPA server 2013-10-15T20:18:11Z DEBUG Init LDAP connection with: ldap://hqdc02.dev.com:389 2013-10-15T20:18:11Z DEBUG Search LDAP server for IPA base DN If I specify --server=rdsdev01 --domain=dev.com I get Failed to verify that rdsdev01 is an IPA Server. This may mean that the remote server is not up or is not reachable due to network or firewall settings. Please make sure the following ports are opened in the firewall settings: TCP: 80, 88, 389 UDP: 88 (at least one of TCP/UDP ports 88 has to be open) Also note that following ports are necessary for ipa-client working properly after enrollment: TCP: 464 UDP: 464, 123 (if NTP enabled) Installation failed. Rolling back changes. IPA client is not configured on this system. However there is no FW>. Iptables is not running.. and I can telnet to each of those ports. -----Original Message----- From: Rob Crittenden [mailto:rcritten at redhat.com] Sent: Tuesday, October 15, 2013 4:11 PM To: Mike Calautti; freeipa-users at redhat.com Subject: Re: [Freeipa-users] stupid question Mike Calautti wrote: > I installed ipa-client.. > > I get this now. > > ipa-client-install > Traceback (most recent call last): > File "/usr/sbin/ipa-client-install", line 2323, in > sys.exit(main()) > File "/usr/sbin/ipa-client-install", line 2309, in main > rval = install(options, env, fstore, statestore) > File "/usr/sbin/ipa-client-install", line 1684, in install > ret = ds.search(domain=options.domain, servers=options.server, hostname=hostname, ca_cert_path=get_cert_path(options.ca_cert_file)) > File "/usr/lib/python2.6/site-packages/ipaclient/ipadiscovery.py", line 242, in search > ldapret = self.ipacheckldap(server, self.realm, ca_cert_path=ca_cert_path) > File "/usr/lib/python2.6/site-packages/ipaclient/ipadiscovery.py", line 339, in ipacheckldap > basedn = get_ipa_basedn(lh) > File "/usr/lib/python2.6/site-packages/ipapython/ipautil.py", line 817, in get_ipa_basedn > contexts = entries[0][1]['namingcontexts'] > > cat /etc/redhat-release > CentOS release 6.4 (Final) Hmm. I'd take a look at /var/log/ipaclient-install.log to see what host it is trying to enroll against. I have the feeling it is finding another host. We fixed a bug post-6.4 related to case insensitivity and namingcontents. I have the feeling the LDAP server you're connecting to isn't return it all as lower case as we expect. rob _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users From rcritten at redhat.com Tue Oct 15 20:55:26 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 15 Oct 2013 16:55:26 -0400 Subject: [Freeipa-users] stupid question In-Reply-To: <37D7774D237F0F4FA1CC50B5FE41FBD503E836@GENSJZMBX03.msg.int.genesyslab.com> References: <37D7774D237F0F4FA1CC50B5FE41FBD503E768@GENSJZMBX03.msg.int.genesyslab.com> <525D9CF6.2050000@redhat.com> <37D7774D237F0F4FA1CC50B5FE41FBD503E7A7@GENSJZMBX03.msg.int.genesyslab.com> <37D7774D237F0F4FA1CC50B5FE41FBD503E7C8@GENSJZMBX03.msg.int.genesyslab.com> <525DA148.5070706@redhat.com> <37D7774D237F0F4FA1CC50B5FE41FBD503E7FE@GENSJZMBX03.msg.int.genesyslab.com> <37D7774D237F0F4FA1CC50B5FE41FBD503E836@GENSJZMBX03.msg.int.genesyslab.com> Message-ID: <525DABBE.8060004@redhat.com> Mike Calautti wrote: > Ok.. > So I did ad the kerberos stuff to the DNS server.. > > Then I got further.. > But got this.. > > 2013-10-15T20:31:31Z DEBUG Init LDAP connection with: ldap://rdsdev01:389 > 2013-10-15T20:31:31Z DEBUG LDAP Error: server down You need to use FQDNs for things to work properly. > So then I added the fqdn and shortname to the clients host file.. > > And get this., > > ipa-client-install --server=rdsdev01 --domain=dev.com > Autodiscovery of servers for failover cannot work with this configuration. > If you proceed with the installation, services will be configured to always access the discovered server for all operations and will not fail over to other servers in case of failure. > Proceed with fixed values and no DNS discovery? [no]: By passing in --server you are overriding discovery so we're warning that you will have manual changes to make in the future if your network configuration changes. rob > > -----Original Message----- > From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Mike Calautti > Sent: Tuesday, October 15, 2013 4:25 PM > To: Rob Crittenden; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] stupid question > > Your awesome !!!! > > Interesting.. > Well for one its claiming it cant contact the LDAP server... > But its calling a machine in our domain that I didn't know existed and furthermore never mentioned in the ipa setup.. > So I see it was searching the network... > > Also..when doing research on installing, I saw that someone said to paste the entries form the example DNS file to your existing DNS db file. > I didn't do that because I am just testing.. > Would that affect it ? > > Dns is correct for both IPA master/replica > > Here is the log. > > cat /var/log/ipaclient-install.log > 2013-10-15T20:18:11Z DEBUG /usr/sbin/ipa-client-install was invoked with options: {'domain': None, 'force': False, 'krb5_offline_passwords': True, 'primary': False, 'mkhomedir': False, 'create_sshfp': True, 'conf_sshd': True, 'on_master': False, 'conf_ntp': True, 'ca_cert_file': None, 'ntp_server': None, 'principal': None, 'hostname': None, 'no_ac': False, 'unattended': None, 'sssd': True, 'trust_sshfp': False, 'dns_updates': False, 'realm_name': None, 'conf_ssh': True, 'server': None, 'prompt_password': False, 'permit': False, 'debug': False, 'preserve_sssd': False, 'uninstall': False} 2013-10-15T20:18:11Z DEBUG missing options might be asked for interactively later 2013-10-15T20:18:11Z DEBUG Loading Index file from '/var/lib/ipa-client/sysrestore/sysrestore.index' > 2013-10-15T20:18:11Z DEBUG Loading StateFile from '/var/lib/ipa-client/sysrestore/sysrestore.state' > 2013-10-15T20:18:11Z DEBUG [IPA Discovery] 2013-10-15T20:18:11Z DEBUG Starting IPA discovery with domain=None, servers=None, hostname=freeiptest01.dev.com 2013-10-15T20:18:11Z DEBUG Start searching for LDAP SRV record in "dev.com" (domain of the hostname) and its sub-domains 2013-10-15T20:18:11Z DEBUG Search DNS for SRV record of _ldap._tcp.dev.com. > 2013-10-15T20:18:11Z DEBUG No DNS record found 2013-10-15T20:18:11Z DEBUG Search DNS for SRV record of _ldap._tcp.dev.com. > 2013-10-15T20:18:11Z DEBUG DNS record found: DNSResult::name:_ldap._tcp.dev.com.,type:33,class:1,rdata={priority:0,port:389,weight:100,server:hqdc02.dev.com.} > 2013-10-15T20:18:11Z DEBUG DNS record found: DNSResult::name:_ldap._tcp.dev.com.,type:33,class:1,rdata={priority:0,port:389,weight:100,server:hqdc.dev.com.} > 2013-10-15T20:18:11Z DEBUG DNS record found: DNSResult::name:_ldap._tcp.dev.com.,type:33,class:1,rdata={priority:0,port:389,weight:100,server:drdc01.dev.com.} > 2013-10-15T20:18:11Z DEBUG [Kerberos realm search] 2013-10-15T20:18:11Z DEBUG Search DNS for TXT record of _kerberos.dev.com. > 2013-10-15T20:18:11Z DEBUG No DNS record found 2013-10-15T20:18:11Z DEBUG [LDAP server check] 2013-10-15T20:18:11Z DEBUG Verifying that hqdc02.dev.com (realm None) is an IPA server 2013-10-15T20:18:11Z DEBUG Init LDAP connection with: ldap://hqdc02.dev.com:389 2013-10-15T20:18:11Z DEBUG Search LDAP server for IPA base DN > > If I specify --server=rdsdev01 --domain=dev.com > > I get > > Failed to verify that rdsdev01 is an IPA Server. > This may mean that the remote server is not up or is not reachable due to network or firewall settings. > Please make sure the following ports are opened in the firewall settings: > TCP: 80, 88, 389 > UDP: 88 (at least one of TCP/UDP ports 88 has to be open) Also note that following ports are necessary for ipa-client working properly after enrollment: > TCP: 464 > UDP: 464, 123 (if NTP enabled) > Installation failed. Rolling back changes. > IPA client is not configured on this system. > > However there is no FW>. Iptables is not running.. and I can telnet to each of those ports. > > > > -----Original Message----- > From: Rob Crittenden [mailto:rcritten at redhat.com] > Sent: Tuesday, October 15, 2013 4:11 PM > To: Mike Calautti; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] stupid question > > Mike Calautti wrote: >> I installed ipa-client.. >> >> I get this now. >> >> ipa-client-install >> Traceback (most recent call last): >> File "/usr/sbin/ipa-client-install", line 2323, in >> sys.exit(main()) >> File "/usr/sbin/ipa-client-install", line 2309, in main >> rval = install(options, env, fstore, statestore) >> File "/usr/sbin/ipa-client-install", line 1684, in install >> ret = ds.search(domain=options.domain, servers=options.server, hostname=hostname, ca_cert_path=get_cert_path(options.ca_cert_file)) >> File "/usr/lib/python2.6/site-packages/ipaclient/ipadiscovery.py", line 242, in search >> ldapret = self.ipacheckldap(server, self.realm, ca_cert_path=ca_cert_path) >> File "/usr/lib/python2.6/site-packages/ipaclient/ipadiscovery.py", line 339, in ipacheckldap >> basedn = get_ipa_basedn(lh) >> File "/usr/lib/python2.6/site-packages/ipapython/ipautil.py", line 817, in get_ipa_basedn >> contexts = entries[0][1]['namingcontexts'] >> >> cat /etc/redhat-release >> CentOS release 6.4 (Final) > > Hmm. I'd take a look at /var/log/ipaclient-install.log to see what host it is trying to enroll against. I have the feeling it is finding another host. > > We fixed a bug post-6.4 related to case insensitivity and namingcontents. I have the feeling the LDAP server you're connecting to isn't return it all as lower case as we expect. > > rob > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From arthur at deus.pro Wed Oct 16 05:20:43 2013 From: arthur at deus.pro (Arthur Faizullin) Date: Wed, 16 Oct 2013 11:20:43 +0600 Subject: [Freeipa-users] Redhat IPA as a SSL CA In-Reply-To: <51E8CE03.80007@redhat.com> References: <20130719012709.GA28052@noboost.org> <51E8CE03.80007@redhat.com> Message-ID: <1381900843.2993.0.camel@coruscant.bashnl.ru> Is it http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP about the same? ? ??, 19/07/2013 ? 10:56 +0530, M.R Niranjan ?????: > On 07/19/2013 06:57 AM, craig.freeipa at noboost.org wrote: > > Hi, > > > > I've been using Redhat IPA 2.2 as our internal CA quite successfully > > for a while and managing in it from the IPA management website. > > > > I'm struggling to find precise information about the SSL certs and > > management at a CLI level. > > > > 1) Can I submit SSL CSR via cli? > Yes, you could using ipa cert-request command > > Example: > > 1. Add the host for which you are generating request. > > # ipa host-add webserver1.example.org > > 2. Create a CSR (i.e private key and certificate request using openssl > command) > > A. Generate private key: > > [root at test1 certs]# openssl genrsa 1024 > server.key > > B. Generate CSR: > > [root at test1 certs]# openssl req -new -key server.key -out server.csr > > 3. Submit the certificate request: > > # ipa cert-request /etc/pki/tls/certs/server.csr > > 4. Get the signed Certificate out using ipa cert-show command > > Example: > [root at test1 certs]# ipa cert-show 12 --out=/etc/pki/tls/certs/server.crt > > > 2) Where are the approved client SSL certs kept in IPA? > > > > They are stored in Directory Server in 2 places > > 1. Domain Suffix tree > dn:fqdn=webserver1.example.org,cn=computers,cn=accounts,dc=example,dc=org > > 2. CA store in DS. Certificate system of IPA stores certificate in it's > ldap store (ou=certificateRepository,ou=ca,o=ipaca) > > > > > > 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 From sylvainangers at gmail.com Wed Oct 16 19:45:42 2013 From: sylvainangers at gmail.com (Sylvain Angers) Date: Wed, 16 Oct 2013 15:45:42 -0400 Subject: [Freeipa-users] AIX vs HBAC Message-ID: Hello freeipa-users mailling list, Whenever we configure AIX client on Redhat IPA, every IPA users can login on AIX, we have not found a way to restrict access them. We are wondering if there is been some success story with managing HBAC on AIX? Thanks in advance Sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Thu Oct 17 02:51:13 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 16 Oct 2013 22:51:13 -0400 Subject: [Freeipa-users] AIX vs HBAC In-Reply-To: References: Message-ID: <525F50A1.3020901@redhat.com> Sylvain Angers wrote: > Hello freeipa-users mailling list, > > Whenever we configure AIX client on Redhat IPA, every IPA users can > login on AIX, we have not found a way to restrict access them. > > We are wondering if there is been some success story with managing HBAC > on AIX? pam_access is a good place to start. It won't be centrally managed by IPA but it seems to be a decent solution. rob From rcritten at redhat.com Thu Oct 17 02:56:24 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 16 Oct 2013 22:56:24 -0400 Subject: [Freeipa-users] Redhat IPA as a SSL CA In-Reply-To: <1381900843.2993.0.camel@coruscant.bashnl.ru> References: <20130719012709.GA28052@noboost.org> <51E8CE03.80007@redhat.com> <1381900843.2993.0.camel@coruscant.bashnl.ru> Message-ID: <525F51D8.2070206@redhat.com> Arthur Faizullin wrote: > Is it > http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP > about the same? No, that is for another purpose. That replaces IPA service certs with those from a 3rd party CA (and it doesn't work well at all in 2.2 or 3.0). I'd recommend certmonger so you can auto-renewing certs, http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/certmongerX.html Or manually at http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/managing-services.html#request-service-service rob > > ? ??, 19/07/2013 ? 10:56 +0530, M.R Niranjan ?????: >> On 07/19/2013 06:57 AM, craig.freeipa at noboost.org wrote: >>> Hi, >>> >>> I've been using Redhat IPA 2.2 as our internal CA quite successfully >>> for a while and managing in it from the IPA management website. >>> >>> I'm struggling to find precise information about the SSL certs and >>> management at a CLI level. >>> >>> 1) Can I submit SSL CSR via cli? >> Yes, you could using ipa cert-request command >> >> Example: >> >> 1. Add the host for which you are generating request. >> >> # ipa host-add webserver1.example.org >> >> 2. Create a CSR (i.e private key and certificate request using openssl >> command) >> >> A. Generate private key: >> >> [root at test1 certs]# openssl genrsa 1024 > server.key >> >> B. Generate CSR: >> >> [root at test1 certs]# openssl req -new -key server.key -out server.csr >> >> 3. Submit the certificate request: >> >> # ipa cert-request /etc/pki/tls/certs/server.csr >> >> 4. Get the signed Certificate out using ipa cert-show command >> >> Example: >> [root at test1 certs]# ipa cert-show 12 --out=/etc/pki/tls/certs/server.crt >> >>> 2) Where are the approved client SSL certs kept in IPA? >>> >> >> They are stored in Directory Server in 2 places >> >> 1. Domain Suffix tree >> dn:fqdn=webserver1.example.org,cn=computers,cn=accounts,dc=example,dc=org >> >> 2. CA store in DS. Certificate system of IPA stores certificate in it's >> ldap store (ou=certificateRepository,ou=ca,o=ipaca) >> >> >>> >>> 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 > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From dpal at redhat.com Thu Oct 17 02:59:25 2013 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 16 Oct 2013 22:59:25 -0400 Subject: [Freeipa-users] ipa sync agreement to AD DC is taking a very long time In-Reply-To: References: <20131015072240.GJ30236@redhat.com> <525D4299.4070909@redhat.com> <1721764361.2211860.1381867271307.JavaMail.root@redhat.com> Message-ID: <525F528D.7030307@redhat.com> On 10/15/2013 04:23 PM, janice.psyop wrote: > Ah, well that makes sense then! > > I couldn't understand why the freeipa.org doc > (http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup) ends at at > cross realm trust -- plus everything was working fine at that point, > but I thought the FC18 docs had further instructions for sync agreements --> it > was ID10T error on my part! -- just blindly clicking "next"... > > So I'm just going to "disconnect" and delete the agreement and > certs..... Actually, I may just start from scratch. It was easy > enough to do up until the point I mixed up the instructions. > > thanks very much clearing up my misunderstanding / pointing out the obvious!!! > > And thanks for the link -- probably should watch that first.... LOL. > > -J. > > > > > On Tue, Oct 15, 2013 at 4:01 PM, Alexander Bokovoy wrote: >> >> ----- Original Message ----- >>> From: "janice.psyop" >>> To: freeipa-users at redhat.com >>> Sent: Tuesday, October 15, 2013 6:51:42 PM >>> Subject: Re: [Freeipa-users] ipa sync agreement to AD DC is taking a very long time >>> >>> Thanks for the replies. >>> >>> I checked this morning and it was still hung up on "Update in progess" >>> so I killed it. >>> >>> @Alexander: Yes, I had already established a trust with our AD DC. I >>> was doing step " 9.4.2. Creating Synchronization Agreements" >>> (FreeIPA_Guide/managing-sync-agmt.html) I've been following the >>> guide step-by-step. >> What I was trying to say is that you have misunderstood instructions and >> are doing wrong configuration that is not supported and never was meant to exist. >> >> AD trusts are configured with 'ipa-adtrust-install' tool and trust is established with 'ipa trust-add' command. >> We don't replicate any user and group related information from AD to IPA LDAP when using AD trusts. >> >> AD replication is a totally separate technique and should not be combined with AD trusts. >> This combination makes no sense, was not designed to be used together, and is not supported. >> >> Therefore, your attempt to add AD replication to already configured AD trusts is wrong. >> You need to chose what approach to take: either trusts or replication. >> >> Dmitri Pal presented AD integration options at DevConf.cz this year. His talk is recorded >> and available at youtube: http://www.youtube.com/watch?v=cS6EJ1L7fRI and slides are here: >> http://www.devconf.cz/slides/Linux-AD-Integration-Options.odp >> >> I'd recommend to watch this talk as it is most detailed explanation of various options >> how to integrate POSIX and AD environments. >> -- >> / Alexander Bokovoy I do not think it is stupid. I think we need to make sure that winsync is no mixed with trusts. IMO we should open two tickets: a) Add a check to trust-add to see if there is a sync agreement with AD and not try to create trust when sync agreement exists b) Add a check to replica manage tool to prevent sync agreement creation when there is a trust. We might in future have to support some interim state when we define a migration procedure which we currently do not have. > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From mkosek at redhat.com Thu Oct 17 10:18:27 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 17 Oct 2013 12:18:27 +0200 Subject: [Freeipa-users] ipa sync agreement to AD DC is taking a very long time In-Reply-To: <525F528D.7030307@redhat.com> References: <20131015072240.GJ30236@redhat.com> <525D4299.4070909@redhat.com> <1721764361.2211860.1381867271307.JavaMail.root@redhat.com> <525F528D.7030307@redhat.com> Message-ID: <525FB973.3050707@redhat.com> On 10/17/2013 04:59 AM, Dmitri Pal wrote: > On 10/15/2013 04:23 PM, janice.psyop wrote: >> Ah, well that makes sense then! >> >> I couldn't understand why the freeipa.org doc >> (http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup) ends at at >> cross realm trust -- plus everything was working fine at that point, >> but I thought the FC18 docs had further instructions for sync agreements --> it >> was ID10T error on my part! -- just blindly clicking "next"... >> >> So I'm just going to "disconnect" and delete the agreement and >> certs..... Actually, I may just start from scratch. It was easy >> enough to do up until the point I mixed up the instructions. >> >> thanks very much clearing up my misunderstanding / pointing out the obvious!!! >> >> And thanks for the link -- probably should watch that first.... LOL. >> >> -J. >> >> >> >> >> On Tue, Oct 15, 2013 at 4:01 PM, Alexander Bokovoy wrote: >>> >>> ----- Original Message ----- >>>> From: "janice.psyop" >>>> To: freeipa-users at redhat.com >>>> Sent: Tuesday, October 15, 2013 6:51:42 PM >>>> Subject: Re: [Freeipa-users] ipa sync agreement to AD DC is taking a very long time >>>> >>>> Thanks for the replies. >>>> >>>> I checked this morning and it was still hung up on "Update in progess" >>>> so I killed it. >>>> >>>> @Alexander: Yes, I had already established a trust with our AD DC. I >>>> was doing step " 9.4.2. Creating Synchronization Agreements" >>>> (FreeIPA_Guide/managing-sync-agmt.html) I've been following the >>>> guide step-by-step. >>> What I was trying to say is that you have misunderstood instructions and >>> are doing wrong configuration that is not supported and never was meant to exist. >>> >>> AD trusts are configured with 'ipa-adtrust-install' tool and trust is established with 'ipa trust-add' command. >>> We don't replicate any user and group related information from AD to IPA LDAP when using AD trusts. >>> >>> AD replication is a totally separate technique and should not be combined with AD trusts. >>> This combination makes no sense, was not designed to be used together, and is not supported. >>> >>> Therefore, your attempt to add AD replication to already configured AD trusts is wrong. >>> You need to chose what approach to take: either trusts or replication. >>> >>> Dmitri Pal presented AD integration options at DevConf.cz this year. His talk is recorded >>> and available at youtube: http://www.youtube.com/watch?v=cS6EJ1L7fRI and slides are here: >>> http://www.devconf.cz/slides/Linux-AD-Integration-Options.odp >>> >>> I'd recommend to watch this talk as it is most detailed explanation of various options >>> how to integrate POSIX and AD environments. >>> -- >>> / Alexander Bokovoy > > I do not think it is stupid. > I think we need to make sure that winsync is no mixed with trusts. > IMO we should open two tickets: > a) Add a check to trust-add to see if there is a sync agreement with AD > and not try to create trust when sync agreement exists > b) Add a check to replica manage tool to prevent sync agreement creation > when there is a trust. One ticket is sufficient, IMO. I filed it: https://fedorahosted.org/freeipa/ticket/3976 I am just thinking if we want to make the check per AD domain - like havinf trusts established with one AD forrest, but allow having winsync for another forrest. Probably not... Martin From trevor.t.kates at dom.com Thu Oct 17 14:35:40 2013 From: trevor.t.kates at dom.com (Trevor T Kates (Services - 6)) Date: Thu, 17 Oct 2013 14:35:40 +0000 Subject: [Freeipa-users] Using IPA on Two Completely Different Domains Message-ID: Greetings, I?m looking for some advice with respect to implementing an IPA solution on two different domains. Both domains have names that are completely distinct from each other and are out of my control to change. I have IdM 3.0 under CentOS 6.4 supporting one domain and I?d like to put together another IdM instance for the other domain. There is some overlap of users between the two domains. As such, I was wondering if the best solution would be to just treat the domains as completely distinct and manage the IdM instances separately or if there is a way to link them together such that for the users that overlap, modifications only need to be made once and in one place. Thanks, Trevor T. Kates CONFIDENTIALITY NOTICE: This electronic message contains information which may be legally confidential and/or privileged and does not in any case represent a firm ENERGY COMMODITY bid or offer relating thereto which binds the sender without an additional express written confirmation to that effect. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you. From abokovoy at redhat.com Thu Oct 17 14:49:30 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 17 Oct 2013 17:49:30 +0300 Subject: [Freeipa-users] Using IPA on Two Completely Different Domains In-Reply-To: References: Message-ID: <20131017144930.GH25335@redhat.com> On Thu, 17 Oct 2013, Trevor T Kates (Services - 6) wrote: >Greetings, > >I?m looking for some advice with respect to implementing an IPA >solution on two different domains. Both domains have names that are >completely distinct from each other and are out of my control to >change. I have IdM 3.0 under CentOS 6.4 supporting one domain and I?d >like to put together another IdM instance for the other domain. There >is some overlap of users between the two domains. As such, I was >wondering if the best solution would be to just treat the domains as >completely distinct and manage the IdM instances separately or if there >is a way to link them together such that for the users that overlap, >modifications only need to be made once and in one place. Can you put machines from both DNS domains into the same IPA domain? Is there a need to physically separate the information between the two? It is OK for IPA to have machines in different DNS domains. -- / Alexander Bokovoy From trevor.t.kates at dom.com Thu Oct 17 14:56:18 2013 From: trevor.t.kates at dom.com (Trevor T Kates (Services - 6)) Date: Thu, 17 Oct 2013 14:56:18 +0000 Subject: [Freeipa-users] Using IPA on Two Completely Different Domains In-Reply-To: <20131017144930.GH25335@redhat.com> References: <20131017144930.GH25335@redhat.com> Message-ID: > -----Original Message----- > From: Alexander Bokovoy [mailto:abokovoy at redhat.com] > Sent: Thursday, October 17, 2013 10:50 AM > To: Trevor T Kates (Services - 6) > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Using IPA on Two Completely Different Domains > > On Thu, 17 Oct 2013, Trevor T Kates (Services - 6) wrote: > >Greetings, > > > >I?m looking for some advice with respect to implementing an IPA > >solution on two different domains. Both domains have names that are > >completely distinct from each other and are out of my control to > >change. I have IdM 3.0 under CentOS 6.4 supporting one domain and I?d > >like to put together another IdM instance for the other domain. There > >is some overlap of users between the two domains. As such, I was > >wondering if the best solution would be to just treat the domains as > >completely distinct and manage the IdM instances separately or if there > >is a way to link them together such that for the users that overlap, > >modifications only need to be made once and in one place. > Can you put machines from both DNS domains into the same IPA domain? > Is there a need to physically separate the information between the two? I can. The information should not need to be separated. I was concerned due to an erroneous assumption that the different domain names would make IPA reject the hosts from the other domain. > > It is OK for IPA to have machines in different DNS domains. Thanks! I'll give it a shot. > -- > / Alexander Bokovoy Trevor T. Kates CONFIDENTIALITY NOTICE: This electronic message contains information which may be legally confidential and/or privileged and does not in any case represent a firm ENERGY COMMODITY bid or offer relating thereto which binds the sender without an additional express written confirmation to that effect. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you. From andrew.holway at gmail.com Thu Oct 17 20:51:09 2013 From: andrew.holway at gmail.com (Andrew Holway) Date: Thu, 17 Oct 2013 21:51:09 +0100 Subject: [Freeipa-users] Authenticating sudo with ipa on Centos Message-ID: Hello, I have set up IPA on a private network and have hit some bumps configuring sudo access for the clients. kinit seems to work fine for both client and server, user and root. When I load the edited /etc/sssd/sssd.conf and try to change user passwords I get "System is offline, password change not possible" Also posted in the centos mailing list: http://lists.centos.org/pipermail/centos/2013-October/137683.html Thanks, Andrew ## I see the following in my clients /var/log/messages after starting sssd on the client. Oct 17 17:35:46 zabbix sssd: Starting up Oct 17 17:35:46 zabbix sssd[be[192-168-0-100.local]]: Starting up Oct 17 17:35:46 zabbix sssd[nss]: Starting up Oct 17 17:35:46 zabbix [sssd[ldap_child[6659]]]: Error processing keytab file [default]: Principal [host/192-168-0-100.local at LOCAL] was not found. Unable to create GSSAPI-encrypted LDAP connection. Oct 17 17:35:46 zabbix sssd[sudo]: Starting up Oct 17 17:35:46 zabbix sssd[ssh]: Starting up Oct 17 17:35:46 zabbix sssd[pac]: Starting up Oct 17 17:35:46 zabbix [sssd[ldap_child[6659]]]: Error writing to key table Oct 17 17:35:46 zabbix sssd[pam]: Starting up ## And the following when user "andrew" tries to sudo on the client. Oct 17 17:37:10 zabbix [sssd[ldap_child[6667]]]: Error processing keytab file [default]: Principal [host/192-168-0-100.local at LOCAL] was not found. Unable to create GSSAPI-encrypted LDAP connection. Oct 17 17:37:10 zabbix [sssd[ldap_child[6667]]]: Error writing to key table ## The user and sudo rules in ipa. [root at 192-168-0-100 ~]# ipa sudorule-show add_sudo Rule name: add_sudo Enabled: TRUE Host category: all Command category: all RunAs User category: all RunAs Group category: all Users: andrew [root at 192-168-0-100 ~]# ipa user-show andrew User login: andrew First name: Andrew Last name: Holway Home directory: /home/andrew Login shell: /bin/bash Email address: andrew at local.com UID: 1876600003 GID: 1876600003 Account disabled: False Password: True Member of groups: admins, ipausers, trust admins Member of Sudo rule: add_sudo Kerberos keys available: True SSH public key fingerprint: 35:08:9D:5E:F7:96:2A:FA:E4:60:76:4E:8A:12:FE:15 (ssh-dss) ## /etc/sssd/sssd.conf on the client [domain/192-168-0-100.local] cache_credentials = True krb5_store_password_if_offline = True krb5_realm = LOCAL ipa_domain = 192-168-0-100.local id_provider = ipa auth_provider = ipa access_provider = ipa ldap_tls_cacert = /etc/ipa/ca.crt ipa_hostname = 192-168-0-110.local chpass_provider = ipa ipa_server = _srv_, 192-168-0-100.local dns_discovery_domain = 192-168-0-100.local sudo_provider = ldap ldap_uri = ldap://192-168-0-100.local ldap_sudo_search_base = ou=sudoers,dc=local ldap_sasl_mech = GSSAPI ldap_sasl_authid = host/192-168-0-100.local at LOCAL ldap_sasl_realm = local krb5_server = 192-168-0-100.local [sssd] services = nss, pam, ssh, sudo config_file_version = 2 domains = 192-168-0-100.local [nss] [pam] [sudo] [autofs] [ssh] [pac] ## /etc/nsswitch.conf on client # # An example Name Service Switch config file. This file should be # sorted with the most-used services at the beginning. # # The entry '[NOTFOUND=return]' means that the search for an # entry should stop if the search in the previous entry turned # up nothing. Note that if the search failed due to some other reason # (like no NIS server responding) then the search continues with the # next entry. # # Valid entries include: # # nisplus Use NIS+ (NIS version 3) # nis Use NIS (NIS version 2), also called YP # dns Use DNS (Domain Name Service) # files Use the local files # db Use the local database (.db) files # compat Use NIS on compat mode # hesiod Use Hesiod for user lookups # [NOTFOUND=return] Stop searching if not found so far # # To use db, put the "db" in front of "files" for entries you want to be # looked up first in the databases # # Example: #passwd: db files nisplus nis #shadow: db files nisplus nis #group: db files nisplus nis passwd: files sss shadow: files sss group: files sss #hosts: db files nisplus nis dns hosts: files dns # Example - obey only what nisplus tells us... #services: nisplus [NOTFOUND=return] files #networks: nisplus [NOTFOUND=return] files #protocols: nisplus [NOTFOUND=return] files #rpc: nisplus [NOTFOUND=return] files #ethers: nisplus [NOTFOUND=return] files #netmasks: nisplus [NOTFOUND=return] files bootparams: nisplus [NOTFOUND=return] files ethers: files netmasks: files networks: files protocols: files rpc: files services: files sss netgroup: files sss publickey: nisplus automount: files aliases: files nisplus sudoers: files sss ## selinux SELinux status: disabled on both client and server ## /etc/krb5.conf on the client #File modified by ipa-client-install includedir /var/lib/sss/pubconf/krb5.include.d/ [libdefaults] default_realm = LOCAL dns_lookup_realm = false dns_lookup_kdc = false rdns = false ticket_lifetime = 24h forwardable = yes [realms] LOCAL = { kdc = 192-168-0-100.local:88 master_kdc = 192-168-0-100.local:88 admin_server = 192-168-0-100.local:749 default_domain = 192-168-0-100.local pkinit_anchors = FILE:/etc/ipa/ca.crt } [domain_realm] .192-168-0-100.local = LOCAL 192-168-0-100.local = LOCAL .local = LOCAL local = LOCAL From rcritten at redhat.com Thu Oct 17 21:16:18 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 17 Oct 2013 17:16:18 -0400 Subject: [Freeipa-users] Authenticating sudo with ipa on Centos In-Reply-To: References: Message-ID: <526053A2.9080205@redhat.com> Andrew Holway wrote: > Hello, > > I have set up IPA on a private network and have hit some bumps > configuring sudo access for the clients. > kinit seems to work fine for both client and server, user and root. > When I load the edited /etc/sssd/sssd.conf and try to change user > passwords I get "System is offline, password change not possible" > > Also posted in the centos mailing list: > http://lists.centos.org/pipermail/centos/2013-October/137683.html It is a bit strange that your ipa_domain and ipa_hostname are the same. I think the domain should be just local. I'd run klist -kt /etc/krb5.keytab to see what principals are in there. > > Thanks, > Andrew > > > ## I see the following in my clients /var/log/messages after starting > sssd on the client. > > Oct 17 17:35:46 zabbix sssd: Starting up > Oct 17 17:35:46 zabbix sssd[be[192-168-0-100.local]]: Starting up > Oct 17 17:35:46 zabbix sssd[nss]: Starting up > Oct 17 17:35:46 zabbix [sssd[ldap_child[6659]]]: Error processing > keytab file [default]: Principal [host/192-168-0-100.local at LOCAL] was > not found. Unable to create GSSAPI-encrypted LDAP connection. > Oct 17 17:35:46 zabbix sssd[sudo]: Starting up > Oct 17 17:35:46 zabbix sssd[ssh]: Starting up > Oct 17 17:35:46 zabbix sssd[pac]: Starting up > Oct 17 17:35:46 zabbix [sssd[ldap_child[6659]]]: Error writing to key table > Oct 17 17:35:46 zabbix sssd[pam]: Starting up > > ## And the following when user "andrew" tries to sudo on the client. > > Oct 17 17:37:10 zabbix [sssd[ldap_child[6667]]]: Error processing > keytab file [default]: Principal [host/192-168-0-100.local at LOCAL] was > not found. Unable to create GSSAPI-encrypted LDAP connection. > Oct 17 17:37:10 zabbix [sssd[ldap_child[6667]]]: Error writing to key table > > ## The user and sudo rules in ipa. > > [root at 192-168-0-100 ~]# ipa sudorule-show add_sudo > Rule name: add_sudo > Enabled: TRUE > Host category: all > Command category: all > RunAs User category: all > RunAs Group category: all > Users: andrew > [root at 192-168-0-100 ~]# ipa user-show andrew > User login: andrew > First name: Andrew > Last name: Holway > Home directory: /home/andrew > Login shell: /bin/bash > Email address: andrew at local.com > UID: 1876600003 > GID: 1876600003 > Account disabled: False > Password: True > Member of groups: admins, ipausers, trust admins > Member of Sudo rule: add_sudo > Kerberos keys available: True > SSH public key fingerprint: > 35:08:9D:5E:F7:96:2A:FA:E4:60:76:4E:8A:12:FE:15 (ssh-dss) > > ## /etc/sssd/sssd.conf on the client > > > [domain/192-168-0-100.local] > > cache_credentials = True > krb5_store_password_if_offline = True > krb5_realm = LOCAL > ipa_domain = 192-168-0-100.local > id_provider = ipa > auth_provider = ipa > access_provider = ipa > ldap_tls_cacert = /etc/ipa/ca.crt > ipa_hostname = 192-168-0-110.local > chpass_provider = ipa > ipa_server = _srv_, 192-168-0-100.local > dns_discovery_domain = 192-168-0-100.local > > sudo_provider = ldap > ldap_uri = ldap://192-168-0-100.local > ldap_sudo_search_base = ou=sudoers,dc=local > ldap_sasl_mech = GSSAPI > ldap_sasl_authid = host/192-168-0-100.local at LOCAL > ldap_sasl_realm = local > krb5_server = 192-168-0-100.local > > [sssd] > services = nss, pam, ssh, sudo > config_file_version = 2 > > domains = 192-168-0-100.local > [nss] > > [pam] > > [sudo] > > [autofs] > > [ssh] > > [pac] > > > ## /etc/nsswitch.conf on client > > # > # An example Name Service Switch config file. This file should be > # sorted with the most-used services at the beginning. > # > # The entry '[NOTFOUND=return]' means that the search for an > # entry should stop if the search in the previous entry turned > # up nothing. Note that if the search failed due to some other reason > # (like no NIS server responding) then the search continues with the > # next entry. > # > # Valid entries include: > # > # nisplus Use NIS+ (NIS version 3) > # nis Use NIS (NIS version 2), also called YP > # dns Use DNS (Domain Name Service) > # files Use the local files > # db Use the local database (.db) files > # compat Use NIS on compat mode > # hesiod Use Hesiod for user lookups > # [NOTFOUND=return] Stop searching if not found so far > # > > # To use db, put the "db" in front of "files" for entries you want to be > # looked up first in the databases > # > # Example: > #passwd: db files nisplus nis > #shadow: db files nisplus nis > #group: db files nisplus nis > > passwd: files sss > shadow: files sss > group: files sss > > #hosts: db files nisplus nis dns > hosts: files dns > > # Example - obey only what nisplus tells us... > #services: nisplus [NOTFOUND=return] files > #networks: nisplus [NOTFOUND=return] files > #protocols: nisplus [NOTFOUND=return] files > #rpc: nisplus [NOTFOUND=return] files > #ethers: nisplus [NOTFOUND=return] files > #netmasks: nisplus [NOTFOUND=return] files > > bootparams: nisplus [NOTFOUND=return] files > > ethers: files > netmasks: files > networks: files > protocols: files > rpc: files > services: files sss > > netgroup: files sss > > publickey: nisplus > > automount: files > aliases: files nisplus > sudoers: files sss > > ## selinux > > SELinux status: disabled on both client and server > > ## /etc/krb5.conf on the client > > #File modified by ipa-client-install > > includedir /var/lib/sss/pubconf/krb5.include.d/ > > [libdefaults] > default_realm = LOCAL > dns_lookup_realm = false > dns_lookup_kdc = false > rdns = false > ticket_lifetime = 24h > forwardable = yes > > [realms] > LOCAL = { > kdc = 192-168-0-100.local:88 > master_kdc = 192-168-0-100.local:88 > admin_server = 192-168-0-100.local:749 > default_domain = 192-168-0-100.local > pkinit_anchors = FILE:/etc/ipa/ca.crt > } > > [domain_realm] > .192-168-0-100.local = LOCAL > 192-168-0-100.local = LOCAL > .local = LOCAL > local = LOCAL > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From tommi at tommi.org Wed Oct 16 23:56:57 2013 From: tommi at tommi.org (=?utf-8?Q?T=C3=B3mas?= Edwardsson) Date: Wed, 16 Oct 2013 23:56:57 +0000 (GMT) Subject: [Freeipa-users] Problems with expired certificates Message-ID: <30417997.11254.1381967817247.JavaMail.root@tommi.org> I'm having issues with expired certificates in /var/lib/pki-ca/alias which I'm quite unsure on how to fix. The ones that have expired are: subsystemCert cert-pki-ca Server-Cert cert-pki-ca According to "getcert list" the following 2 requests are stuck Request ID '20130415234030': status: CA_UNREACHABLE ca-error: Error 60 connecting to https://auth.d.lan:9443/ca/agent/ca/profileReview: Peer certificate cannot be authenticated with known CA certificates. stuck: yes key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB',pin='502532376322' certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O=D.LAN subject: CN=CA Subsystem,O=D.LAN expires: 2013-07-10 14:24:34 UTC eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert "subsystemCert cert-pki-ca" track: yes auto-renew: yes Request ID '20130415234032': status: CA_UNREACHABLE ca-error: Error 60 connecting to https://auth.d.lan:9443/ca/agent/ca/profileReview: Peer certificate cannot be authenticated with known CA certificates. stuck: yes key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert cert-pki-ca',token='NSS Certificate DB',pin='502532376322' certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O=D.LAN subject: CN=auth.d.lan,O=D.LAN expires: 2013-07-10 14:24:33 UTC eku: id-kp-serverAuth pre-save command: post-save command: track: yes auto-renew: yes Here is what I could find from some browsing with certutil: [root at auth ~]# certutil -d /var/lib/pki-ca/alias -L Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI subsystemCert cert-pki-ca u,u,u ocspSigningCert cert-pki-ca u,u,u caSigningCert cert-pki-ca CTu,Cu,Cu Server-Cert cert-pki-ca u,u,u auditSigningCert cert-pki-ca u,u,Pu [root at auth ~]# certutil -d /var/lib/pki-ca/alias -L -n "subsystemCert cert-pki-ca"|grep "Not After" Not After : Wed Jul 10 14:24:34 2013 [root at auth ~]# certutil -d /var/lib/pki-ca/alias -L -n "ocspSigningCert cert-pki-ca"|grep "Not After" Not After : Mon Jun 29 00:00:55 2015 [root at auth ~]# certutil -d /var/lib/pki-ca/alias -L -n "caSigningCert cert-pki-ca"|grep "Not After" Not After : Sun Jul 21 14:24:32 2019 [root at auth ~]# certutil -d /var/lib/pki-ca/alias -L -n "Server-Cert cert-pki-ca"|grep "Not After" Not After : Wed Jul 10 14:24:33 2013 [root at auth ~]# certutil -d /var/lib/pki-ca/alias -L -n "auditSigningCert cert-pki-ca"|grep "Not After" Not After : Mon Jun 29 00:01:55 2015 How can I renew the affected certificates? --- Tomas Edwardsson From andrew.holway at gmail.com Fri Oct 18 08:05:27 2013 From: andrew.holway at gmail.com (Andrew Holway) Date: Fri, 18 Oct 2013 09:05:27 +0100 Subject: [Freeipa-users] Authenticating sudo with ipa on Centos In-Reply-To: <526053A2.9080205@redhat.com> References: <526053A2.9080205@redhat.com> Message-ID: > It is a bit strange that your ipa_domain and ipa_hostname are the same. I > think the domain should be just local. > > I'd run klist -kt /etc/krb5.keytab to see what principals are in there. ipa_hostname = 192-168-0-110.local ipa_server = _srv_, 192-168-0-100.local Hi, I'm a little confused. They are not the same and these values were created by the "ipa-client-install" utility. I think there is some extra magic needed so that I get get sudo working with ipa...The redhat docs are a little bit lacking for the less advanced... https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/sssd-ldap-sudo.html > > >> >> Thanks, >> Andrew >> >> >> ## I see the following in my clients /var/log/messages after starting >> sssd on the client. >> >> Oct 17 17:35:46 zabbix sssd: Starting up >> Oct 17 17:35:46 zabbix sssd[be[192-168-0-100.local]]: Starting up >> Oct 17 17:35:46 zabbix sssd[nss]: Starting up >> Oct 17 17:35:46 zabbix [sssd[ldap_child[6659]]]: Error processing >> keytab file [default]: Principal [host/192-168-0-100.local at LOCAL] was >> not found. Unable to create GSSAPI-encrypted LDAP connection. >> Oct 17 17:35:46 zabbix sssd[sudo]: Starting up >> Oct 17 17:35:46 zabbix sssd[ssh]: Starting up >> Oct 17 17:35:46 zabbix sssd[pac]: Starting up >> Oct 17 17:35:46 zabbix [sssd[ldap_child[6659]]]: Error writing to key >> table >> Oct 17 17:35:46 zabbix sssd[pam]: Starting up >> >> ## And the following when user "andrew" tries to sudo on the client. >> >> Oct 17 17:37:10 zabbix [sssd[ldap_child[6667]]]: Error processing >> keytab file [default]: Principal [host/192-168-0-100.local at LOCAL] was >> not found. Unable to create GSSAPI-encrypted LDAP connection. >> Oct 17 17:37:10 zabbix [sssd[ldap_child[6667]]]: Error writing to key >> table >> >> ## The user and sudo rules in ipa. >> >> [root at 192-168-0-100 ~]# ipa sudorule-show add_sudo >> Rule name: add_sudo >> Enabled: TRUE >> Host category: all >> Command category: all >> RunAs User category: all >> RunAs Group category: all >> Users: andrew >> [root at 192-168-0-100 ~]# ipa user-show andrew >> User login: andrew >> First name: Andrew >> Last name: Holway >> Home directory: /home/andrew >> Login shell: /bin/bash >> Email address: andrew at local.com >> UID: 1876600003 >> GID: 1876600003 >> Account disabled: False >> Password: True >> Member of groups: admins, ipausers, trust admins >> Member of Sudo rule: add_sudo >> Kerberos keys available: True >> SSH public key fingerprint: >> 35:08:9D:5E:F7:96:2A:FA:E4:60:76:4E:8A:12:FE:15 (ssh-dss) >> >> ## /etc/sssd/sssd.conf on the client >> >> >> [domain/192-168-0-100.local] >> >> cache_credentials = True >> krb5_store_password_if_offline = True >> krb5_realm = LOCAL >> ipa_domain = 192-168-0-100.local >> id_provider = ipa >> auth_provider = ipa >> access_provider = ipa >> ldap_tls_cacert = /etc/ipa/ca.crt >> ipa_hostname = 192-168-0-110.local >> chpass_provider = ipa >> ipa_server = _srv_, 192-168-0-100.local >> dns_discovery_domain = 192-168-0-100.local >> >> sudo_provider = ldap >> ldap_uri = ldap://192-168-0-100.local >> ldap_sudo_search_base = ou=sudoers,dc=local >> ldap_sasl_mech = GSSAPI >> ldap_sasl_authid = host/192-168-0-100.local at LOCAL >> ldap_sasl_realm = local >> krb5_server = 192-168-0-100.local >> >> [sssd] >> services = nss, pam, ssh, sudo >> config_file_version = 2 >> >> domains = 192-168-0-100.local >> [nss] >> >> [pam] >> >> [sudo] >> >> [autofs] >> >> [ssh] >> >> [pac] >> >> >> ## /etc/nsswitch.conf on client >> >> # >> # An example Name Service Switch config file. This file should be >> # sorted with the most-used services at the beginning. >> # >> # The entry '[NOTFOUND=return]' means that the search for an >> # entry should stop if the search in the previous entry turned >> # up nothing. Note that if the search failed due to some other reason >> # (like no NIS server responding) then the search continues with the >> # next entry. >> # >> # Valid entries include: >> # >> # nisplus Use NIS+ (NIS version 3) >> # nis Use NIS (NIS version 2), also called YP >> # dns Use DNS (Domain Name Service) >> # files Use the local files >> # db Use the local database (.db) files >> # compat Use NIS on compat mode >> # hesiod Use Hesiod for user lookups >> # [NOTFOUND=return] Stop searching if not found so far >> # >> >> # To use db, put the "db" in front of "files" for entries you want to be >> # looked up first in the databases >> # >> # Example: >> #passwd: db files nisplus nis >> #shadow: db files nisplus nis >> #group: db files nisplus nis >> >> passwd: files sss >> shadow: files sss >> group: files sss >> >> #hosts: db files nisplus nis dns >> hosts: files dns >> >> # Example - obey only what nisplus tells us... >> #services: nisplus [NOTFOUND=return] files >> #networks: nisplus [NOTFOUND=return] files >> #protocols: nisplus [NOTFOUND=return] files >> #rpc: nisplus [NOTFOUND=return] files >> #ethers: nisplus [NOTFOUND=return] files >> #netmasks: nisplus [NOTFOUND=return] files >> >> bootparams: nisplus [NOTFOUND=return] files >> >> ethers: files >> netmasks: files >> networks: files >> protocols: files >> rpc: files >> services: files sss >> >> netgroup: files sss >> >> publickey: nisplus >> >> automount: files >> aliases: files nisplus >> sudoers: files sss >> >> ## selinux >> >> SELinux status: disabled on both client and server >> >> ## /etc/krb5.conf on the client >> >> #File modified by ipa-client-install >> >> includedir /var/lib/sss/pubconf/krb5.include.d/ >> >> [libdefaults] >> default_realm = LOCAL >> dns_lookup_realm = false >> dns_lookup_kdc = false >> rdns = false >> ticket_lifetime = 24h >> forwardable = yes >> >> [realms] >> LOCAL = { >> kdc = 192-168-0-100.local:88 >> master_kdc = 192-168-0-100.local:88 >> admin_server = 192-168-0-100.local:749 >> default_domain = 192-168-0-100.local >> pkinit_anchors = FILE:/etc/ipa/ca.crt >> } >> >> [domain_realm] >> .192-168-0-100.local = LOCAL >> 192-168-0-100.local = LOCAL >> .local = LOCAL >> local = LOCAL >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> > From sbingram at gmail.com Fri Oct 18 19:44:05 2013 From: sbingram at gmail.com (Stephen Ingram) Date: Fri, 18 Oct 2013 12:44:05 -0700 Subject: [Freeipa-users] TTL in individual DNS records Message-ID: I'm using IPA 3.0.x on RHEL 6.4 and trying to setup other zones in DNS. I notice that regardless of the TTL set in the SOA for the zone, the individual records default to 86400. I see there has been previous discussion on the list ( https://www.redhat.com/archives/freeipa-users/2012-November/msg00158.html) saying that the 86400 value is hard-coded into bind-dyndb-ldap. It appears as though it might be rectified sometime in the 3.3.x series, however, I'm wondering if there is a workaround for now. Is there a way to just delete this value such that the individual records will default to the value in the SOA until a real fix comes along? Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Sat Oct 19 21:17:15 2013 From: dpal at redhat.com (Dmitri Pal) Date: Sat, 19 Oct 2013 17:17:15 -0400 Subject: [Freeipa-users] Problems with expired certificates In-Reply-To: <30417997.11254.1381967817247.JavaMail.root@tommi.org> References: <30417997.11254.1381967817247.JavaMail.root@tommi.org> Message-ID: <5262F6DB.9080405@redhat.com> On 10/16/2013 07:56 PM, T?mas Edwardsson wrote: > I'm having issues with expired certificates in /var/lib/pki-ca/alias which I'm quite unsure on how to fix. The ones that have expired are: > > subsystemCert cert-pki-ca > Server-Cert cert-pki-ca Please search this list for some recommendations. There have been some recently. They will give you some hints. The general path is to set the time into the past and then force the certificate rotation. The specific steps depend on the version of IPA you have. > > According to "getcert list" the following 2 requests are stuck > > > Request ID '20130415234030': > status: CA_UNREACHABLE > ca-error: Error 60 connecting to https://auth.d.lan:9443/ca/agent/ca/profileReview: Peer certificate cannot be authenticated with known CA certificates. > stuck: yes > key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB',pin='502532376322' > certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB' > CA: dogtag-ipa-renew-agent > issuer: CN=Certificate Authority,O=D.LAN > subject: CN=CA Subsystem,O=D.LAN > expires: 2013-07-10 14:24:34 UTC > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad > post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert "subsystemCert cert-pki-ca" > track: yes > auto-renew: yes > > Request ID '20130415234032': > status: CA_UNREACHABLE > ca-error: Error 60 connecting to https://auth.d.lan:9443/ca/agent/ca/profileReview: Peer certificate cannot be authenticated with known CA certificates. > stuck: yes > key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert cert-pki-ca',token='NSS Certificate DB',pin='502532376322' > certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert cert-pki-ca',token='NSS Certificate DB' > CA: dogtag-ipa-renew-agent > issuer: CN=Certificate Authority,O=D.LAN > subject: CN=auth.d.lan,O=D.LAN > expires: 2013-07-10 14:24:33 UTC > eku: id-kp-serverAuth > pre-save command: > post-save command: > track: yes > auto-renew: yes > > > Here is what I could find from some browsing with certutil: > > [root at auth ~]# certutil -d /var/lib/pki-ca/alias -L > Certificate Nickname Trust Attributes > SSL,S/MIME,JAR/XPI > > subsystemCert cert-pki-ca u,u,u > ocspSigningCert cert-pki-ca u,u,u > caSigningCert cert-pki-ca CTu,Cu,Cu > Server-Cert cert-pki-ca u,u,u > auditSigningCert cert-pki-ca u,u,Pu > > > > [root at auth ~]# certutil -d /var/lib/pki-ca/alias -L -n "subsystemCert cert-pki-ca"|grep "Not After" > Not After : Wed Jul 10 14:24:34 2013 > [root at auth ~]# certutil -d /var/lib/pki-ca/alias -L -n "ocspSigningCert cert-pki-ca"|grep "Not After" > Not After : Mon Jun 29 00:00:55 2015 > [root at auth ~]# certutil -d /var/lib/pki-ca/alias -L -n "caSigningCert cert-pki-ca"|grep "Not After" > Not After : Sun Jul 21 14:24:32 2019 > [root at auth ~]# certutil -d /var/lib/pki-ca/alias -L -n "Server-Cert cert-pki-ca"|grep "Not After" > Not After : Wed Jul 10 14:24:33 2013 > [root at auth ~]# certutil -d /var/lib/pki-ca/alias -L -n "auditSigningCert cert-pki-ca"|grep "Not After" > Not After : Mon Jun 29 00:01:55 2015 > > > > How can I renew the affected certificates? > > --- > Tomas Edwardsson > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From pspacek at redhat.com Mon Oct 21 06:44:45 2013 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 21 Oct 2013 08:44:45 +0200 Subject: [Freeipa-users] TTL in individual DNS records In-Reply-To: References: Message-ID: <5264CD5D.2000008@redhat.com> On 18.10.2013 21:44, Stephen Ingram wrote: > I'm using IPA 3.0.x on RHEL 6.4 and trying to setup other zones in DNS. I > notice that regardless of the TTL set in the SOA for the zone, the > individual records default to 86400. I see there has been previous > discussion on the list ( > https://www.redhat.com/archives/freeipa-users/2012-November/msg00158.html) > saying that the 86400 value is hard-coded into bind-dyndb-ldap. It appears > as though it might be rectified sometime in the 3.3.x series, however, I'm > wondering if there is a workaround for now. Is there a way to just delete > this value such that the individual records will default to the value in > the SOA until a real fix comes along? For now, the only workaround is to set TTL explicitly for all affected DNS names. Sorry! $ ipa dnsrecord-mod --help | grep ttl --ttl=INT Time to live The most important thing is that SOA TTL is not related to default record TTL by definition. Some details are described here: https://www.redhat.com/archives/freeipa-users/2012-November/msg00160.html Have a nice day. -- Petr^2 Spacek From sbingram at gmail.com Mon Oct 21 15:58:01 2013 From: sbingram at gmail.com (Stephen Ingram) Date: Mon, 21 Oct 2013 08:58:01 -0700 Subject: [Freeipa-users] TTL in individual DNS records In-Reply-To: <5264CD5D.2000008@redhat.com> References: <5264CD5D.2000008@redhat.com> Message-ID: On Sun, Oct 20, 2013 at 11:44 PM, Petr Spacek wrote: > On 18.10.2013 21:44, Stephen Ingram wrote: > >> I'm using IPA 3.0.x on RHEL 6.4 and trying to setup other zones in DNS. I >> notice that regardless of the TTL set in the SOA for the zone, the >> individual records default to 86400. I see there has been previous >> discussion on the list ( >> https://www.redhat.com/**archives/freeipa-users/2012-** >> November/msg00158.html >> ) >> saying that the 86400 value is hard-coded into bind-dyndb-ldap. It appears >> as though it might be rectified sometime in the 3.3.x series, however, I'm >> wondering if there is a workaround for now. Is there a way to just delete >> this value such that the individual records will default to the value in >> the SOA until a real fix comes along? >> > > For now, the only workaround is to set TTL explicitly for all affected DNS > names. Sorry! > > $ ipa dnsrecord-mod --help | grep ttl > --ttl=INT Time to live > > The most important thing is that SOA TTL is not related to default record > TTL by definition. > > Some details are described here: > https://www.redhat.com/**archives/freeipa-users/2012-** > November/msg00160.html Am I reading this correctly then that you have to set for each *record* vs the *zone*. If so, this makes the DNS part of IPA almost unusable except to those willing to stick with the default 86400 or write a script to handle each record in the zone. I've been following the list for some time, but haven't heard much about usage of the DNS component. And, among the users I speak with no one uses the DNS component. Perhaps this is the reason why? I haven't looked at the code yet, but would this be that difficult to fix? I would love to get this working as I think IPA would be great for DNS, especially with distributed management through the UI. Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian_lee1 at jabil.com Mon Oct 21 16:25:17 2013 From: brian_lee1 at jabil.com (Brian Lee) Date: Mon, 21 Oct 2013 12:25:17 -0400 Subject: [Freeipa-users] RHEL 5.x client functionality with ipa-server 3.0 Message-ID: Hello All, We have a mixed RHEL environment (5.x, 6.x, x86, and x86_64). Our FreeIPA server is running RHEL 6.4 x86_64 with ipa-server 3.0. My question is what are the hurdles or feature limitations should I expect to encounter in this mixed environment, especially in regards to the RHEL 5.x systems? I appreciate any feedback or experience provided. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Mon Oct 21 16:37:38 2013 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 21 Oct 2013 18:37:38 +0200 Subject: [Freeipa-users] TTL in individual DNS records In-Reply-To: References: <5264CD5D.2000008@redhat.com> Message-ID: <52655852.2000302@redhat.com> On 21.10.2013 17:58, Stephen Ingram wrote: > On Sun, Oct 20, 2013 at 11:44 PM, Petr Spacek wrote: > >> On 18.10.2013 21:44, Stephen Ingram wrote: >> >>> I'm using IPA 3.0.x on RHEL 6.4 and trying to setup other zones in DNS. I >>> notice that regardless of the TTL set in the SOA for the zone, the >>> individual records default to 86400. I see there has been previous >>> discussion on the list ( >>> https://www.redhat.com/**archives/freeipa-users/2012-** >>> November/msg00158.html >>> ) >>> saying that the 86400 value is hard-coded into bind-dyndb-ldap. It appears >>> as though it might be rectified sometime in the 3.3.x series, however, I'm >>> wondering if there is a workaround for now. Is there a way to just delete >>> this value such that the individual records will default to the value in >>> the SOA until a real fix comes along? >>> >> >> For now, the only workaround is to set TTL explicitly for all affected DNS >> names. Sorry! >> >> $ ipa dnsrecord-mod --help | grep ttl >> --ttl=INT Time to live >> >> The most important thing is that SOA TTL is not related to default record >> TTL by definition. >> >> Some details are described here: >> https://www.redhat.com/**archives/freeipa-users/2012-** >> November/msg00160.html > > > Am I reading this correctly then that you have to set for each *record* vs I really meant *name*. "ipa dnsrecord-mod" operates on whole DNS name. (It also means that all records under single *name* share the same TTL value.) > the *zone*. If so, this makes the DNS part of IPA almost unusable except to > those willing to stick with the default 86400 or write a script to handle > each record in the zone. I've been following the list for some time, but > haven't heard much about usage of the DNS component. And, among the users I > speak with no one uses the DNS component. Perhaps this is the reason why? I Up to now, nobody have told us that 'DNS part of IPA almost unusable' without configuration option for default TTL, so it simply didn't get the priority. We have seen stroger demand for DNS views, for example :-) > haven't looked at the code yet, but would this be that difficult to fix? I If you are okay with statically configured TTL for all zones, then it is five-minute fix. (Simply change the current value and recompile or add a new parameter to /etc/named.conf.) If you want to define default TTL per-zone in LDAP, then you have to define new attribute in LDAP schema, store the default TTL value in zone_register and push it to record parser as necessary. In https://fedorahosted.org/bind-dyndb-ldap/ticket/70#comment:7 you can see that we are trying to cooperate with schema/OID space owner to find & standardize some solution. Any contribution is more than welcome! Join us in the ticket and we can discuss various propsals. Have a nice day. -- Petr^2 Spacek From pspacek at redhat.com Mon Oct 21 16:48:34 2013 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 21 Oct 2013 18:48:34 +0200 Subject: [Freeipa-users] DNS views: request for comments In-Reply-To: <524AE614.8090808@redhat.com> References: <524AE614.8090808@redhat.com> Message-ID: <52655AE2.7010207@redhat.com> On 1.10.2013 17:11, Petr Spacek wrote: > Hello list, > > we would like to get more details about DNS views and how you use them in real > life. Also, any idea how user a interface should work is more than welcome! > > (If you don't know views, read it as "differentiate answer to a DNS query on > client's IP address basics".) > > > Questions are: > - For what purpose do you use views? > E.g. handling clients inside/outside of company network (e.g. hiding internal > names); Selecting nearest server in a big network; Some other weird 'Cloud' > scenarios etc. etc. > > - How many views do you use? > > - Do you share some data between views? How did you solve that? Do you use > some user interface for that? > > - Do you use DNS updates? (nsupdate/RFC 2136/RFC 3007) > > Previous discussions about DNS views: > https://www.redhat.com/archives/freeipa-users/2012-April/msg00070.html > https://www.redhat.com/archives/freeipa-devel/2012-May/msg00208.html > > Related tickets & bugs: > https://fedorahosted.org/freeipa/ticket/2802 > https://bugzilla.redhat.com/show_bug.cgi?id=815621 > https://fedorahosted.org/freeipa/ticket/3725 > https://fedorahosted.org/bind-dyndb-ldap/ticket/69 > > > The next step will be to design LDAP schema for DNS data with views ... > > I can see three basic options: > > 1) Resign from any data sharing, which will make the thing pretty easy :-) > In that case 'view1' will be represented by one sub-tree in LDAP, 'view2' will > be another sub-tree etc. > > 2) Select one sub-tree which will be 'the base' containing all shared records. > All other views will inherit and override data from the shared 'base'. > > 3) Make it as general as possible and allow multiple levels of inheritance. > View3 inherits from View2 and it inherits from Base. > (View3 <- View2 <- Base) > > It is basically generalized variant (2), but it could require different LDAP > schema. > > > Please post your opinions! I spent some time investigating how DNS views work in various DNS servers. I hope that it will help us to find some balance between real world requirements and complexity. The next section discusses possible LDAP schema and semantics for our DNS views implementation. Feel free to jump directly to the proposal if you have some particular idea how it should work. Support for DNS views in server software ======================================== I have tried to find how widely DNS views are supported by various software packages. Open Source software -------------------- PowerDNS - only specialized backend for Geo->something mapping - no inheritance - no dynamic updates - http://wiki.powerdns.com/trac/browser/trunk/pdns/modules/geobackend/README Djbdns/tinydns - no inheritance - non-standard dynamic updates (?? via external tools, I'm not 100 % sure) - can differentiate answers on IP-prefix basics: http://cr.yp.to/djbdns/tinydns-data.html (search for "ipprefix") Dnsmasq - subnet-based selection for A records only (based on client's subnet) - no inheritance - dynamic update only from built-in DHCP server http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html (see option --localise-queries) BIND 9 - full support for DNS views - each view can be totally independent on other views - inheritance is done via $INCLUDE directive in zone file - in any case, a update affects only DNS view where the update was received - limitations: -- inherited data can be modified only via addition; modification/deletion to the inherited data is not possible (you have to break inheritance if you have to modify/delete inherited data) -- any dynamic update breaks inheritance BIND 9 examples: Example external view is subset of company-internal view. zone file external.db: mail A 192.0.2.1 zone file internal.db: $INCLUDE external.db shell A 10.1.2.3 Imagine that internal view was updated via DNS update, a record for name "git" was added. The resulting zone file internal.db will look like: git A 10.3.3.33 mail A 192.0.2.1 shell A 10.1.1.1 You can see that inheritance from the external view was broken and all records from external view were copied to the internal view. It is possible to use multiple levels of $INCLUDE, but then thigs become twisted. Proprietary software -------------------- Simple DNS Plus - only special handling "for NAT": "In DNS responses to DNS requests from LAN clients only, this function changes host records which are pointing to a public IP address of the NAT router to point to the corresponding private IP address of a local server." - http://www.simpledns.com/help/v52/wd_opt_dnsnatlan.htm InfoBlox - full support for DNS views - each view can be totally independent on other views - DNS object hierarchy: 1. one view = set of zones 2. one zone = set of records + set of shared record groups 3. shared record group = set of records shared between DNS zones - inheritance is realized via "Shared Record Groups" (see page 465): -- records are grouped to named group called "Shared Record Group" -- the group is associated with one or more DNS *zones* -- there is single-level inheritance only -- E.g. the same set of MX records can be present in DNS zone example.com and eshop.example.com. I.e. mail server addresses are managed from single place, it is not necessary to change MX records separelly for example.com and eshop.example.com. -- In case of FreeIPA it could be group of all SRV or NS records so all records for a new replica have to be created only on single place and the change will affect all FreeIPA-managed DNS zones. - only one DNS view can receive the dynamic DNS updates (page 388) - it is unclear if the same limitations for inheritance apply or not - http://dloads.infoblox.com/direct/appliance/NIOS/NIOS_AdminGuide_6.5.pdf Nominum Vantio - caching only (I guess) - listed as an extreme example - there is not much public details about that, but this is what they claim: "Lightweight Views take the ?view? concept of the server to the ultimate extent, where each individual user can have their own view. Policies defining how queries are handled can be applied to each view, effectively enabling a personal Internet for each subscriber." - http://nominum.com/assets/Documents/Datasheets/vantio-datasheet.pdf Proposal - variant A ("classical" views) ==================== - keep it simple :-) - single level inheritance, all views inherit from 'base' (Base is our current cn=dns subtree, so old and new plugins can co-exist. The base can be empty.) - the data in views can be modified via DNS updates, a change done to inherited data creates an override (BIND9 does the same): e.g. name 'r1.z.' is shared between View1 and View2. Value change in View1 doesn't affect View2. - particular record from the 'base' can be overriden (deleted/replaced) in any view - changes done to the base are propagated to all views LDAP schema ----------- My goal is to maintain 1:1 mapping between "name+view" pair and LDAP DN. This is crucial for DNS updates. The other option is to maintain some 'record->LDAP DN database' or do a LDAP search before each DNS update - I would like to avoid that. Each view is stored as separate object under cn=dns. DN: idnsView=view1, cn=dns - this object stores settings specific to particular view (allowed clients, recursion ...) Zone in particular view is stored inside view container: DN: idnsName=zone1, idnsView=view1, dn=dns - this object can be empty container - attributes without explicit configuration are inherited from the base - a zone doesn't appear in the DNS view if the container is not present (i.e. it is possible to hide the zone from particular view) 'Override' records for particular name in zone and view are stored as: DN: idnsName=name1, idnsName=zone1, idnsView=view1, cn=dns - values added on top of inherited set are represented as normal DNS attributes: e.g. aRecord: 192.0.2.1 - values deleted from inherited set - *are open question*: It would be great if we could store it under the same object as additions, it would make implementation a bit simpler. - Would it be acceptable to store override 'delete TXT record "hello"' as attribute 'tXTRecord;x-deleted: test'? - The other option is to store deleted attributes in separate object: DN: cn=deleted, idnsName=record1, idnsName=zone1, idnsView=view1, cn=dns Proposal - variant B (shared record groups) ==================== - not so simple to implement, especially update-performance could be an issue - multiple zones can share the same record group - each view can contain arbitrary zones anf those zones can inherit arbitrary record groups - inheritance is fully configurable - the data in views can be modified via DNS updates, a change done to inherited data creates an override (BIND9 does the same): e.g. name 'r1.z.' is shared between View1 and View2. Value change in View1 doesn't affect View2. - particular record from any shared record group can be overriden (deleted/replaced) in any zone in any view - changes done to the shared record group are propagated to all views (this is the hard part!) LDAP schema ----------- Group of shared records - container: DN: idnsRecordGroup=group1, cn=dns One shared name: DN: idnsName=record1, idnsRecordGroup=group1, cn=dns - contains DNS records for that name as usual Each view is stored as separate object under cn=dns. DN: idnsView=view1, cn=dns Zone in particular view is stored inside view container: DN: idnsName=zone1, idnsView=view1, dn=dns - zone has a attribute with DNs of inherited record groups 'Override' records for particular name in zone and view are stored as: DN: idnsName=name1, idnsName=zone1, idnsView=view1, cn=dns After each change to any data we have to compute new resulting value. It means to combine the data for particular name from all record groups and then apply overrides for particular instance. It means a lot of bookkeeping after each change ... Proposal - variant 0 ==================== Do not implement it in bind-dyndb-ldap and wait if Martin Basti succeeds with his thesis. He is trying to design and implement some generic/pluggable LDAP<->DNS synchronization mechanism. Personally, I think that variant "0" is the best one! :-D One of side effects is that our depedency on BIND 9 will be lowered and most of the work will be deferred to the real DNS server. -- Petr^2 Spacek From rcritten at redhat.com Mon Oct 21 17:34:17 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 21 Oct 2013 13:34:17 -0400 Subject: [Freeipa-users] Authenticating sudo with ipa on Centos In-Reply-To: References: <526053A2.9080205@redhat.com> Message-ID: <52656599.40406@redhat.com> Andrew Holway wrote: >> It is a bit strange that your ipa_domain and ipa_hostname are the same. I >> think the domain should be just local. >> >> I'd run klist -kt /etc/krb5.keytab to see what principals are in there. > > ipa_hostname = 192-168-0-110.local > ipa_server = _srv_, 192-168-0-100.local > > Hi, > > I'm a little confused. They are not the same and these values were > created by the "ipa-client-install" utility. > > I think there is some extra magic needed so that I get get sudo > working with ipa...The redhat docs are a little bit lacking for the > less advanced... > > https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/sssd-ldap-sudo.html Sure, but first we need to make sssd talk to IPA at all, which it isn't. Like I said, it looks like your sssd configuration is wrong. You can always un-enroll and re-enroll the client in order to reset things. rob > > > > >> >> >>> >>> Thanks, >>> Andrew >>> >>> >>> ## I see the following in my clients /var/log/messages after starting >>> sssd on the client. >>> >>> Oct 17 17:35:46 zabbix sssd: Starting up >>> Oct 17 17:35:46 zabbix sssd[be[192-168-0-100.local]]: Starting up >>> Oct 17 17:35:46 zabbix sssd[nss]: Starting up >>> Oct 17 17:35:46 zabbix [sssd[ldap_child[6659]]]: Error processing >>> keytab file [default]: Principal [host/192-168-0-100.local at LOCAL] was >>> not found. Unable to create GSSAPI-encrypted LDAP connection. >>> Oct 17 17:35:46 zabbix sssd[sudo]: Starting up >>> Oct 17 17:35:46 zabbix sssd[ssh]: Starting up >>> Oct 17 17:35:46 zabbix sssd[pac]: Starting up >>> Oct 17 17:35:46 zabbix [sssd[ldap_child[6659]]]: Error writing to key >>> table >>> Oct 17 17:35:46 zabbix sssd[pam]: Starting up >>> >>> ## And the following when user "andrew" tries to sudo on the client. >>> >>> Oct 17 17:37:10 zabbix [sssd[ldap_child[6667]]]: Error processing >>> keytab file [default]: Principal [host/192-168-0-100.local at LOCAL] was >>> not found. Unable to create GSSAPI-encrypted LDAP connection. >>> Oct 17 17:37:10 zabbix [sssd[ldap_child[6667]]]: Error writing to key >>> table >>> >>> ## The user and sudo rules in ipa. >>> >>> [root at 192-168-0-100 ~]# ipa sudorule-show add_sudo >>> Rule name: add_sudo >>> Enabled: TRUE >>> Host category: all >>> Command category: all >>> RunAs User category: all >>> RunAs Group category: all >>> Users: andrew >>> [root at 192-168-0-100 ~]# ipa user-show andrew >>> User login: andrew >>> First name: Andrew >>> Last name: Holway >>> Home directory: /home/andrew >>> Login shell: /bin/bash >>> Email address: andrew at local.com >>> UID: 1876600003 >>> GID: 1876600003 >>> Account disabled: False >>> Password: True >>> Member of groups: admins, ipausers, trust admins >>> Member of Sudo rule: add_sudo >>> Kerberos keys available: True >>> SSH public key fingerprint: >>> 35:08:9D:5E:F7:96:2A:FA:E4:60:76:4E:8A:12:FE:15 (ssh-dss) >>> >>> ## /etc/sssd/sssd.conf on the client >>> >>> >>> [domain/192-168-0-100.local] >>> >>> cache_credentials = True >>> krb5_store_password_if_offline = True >>> krb5_realm = LOCAL >>> ipa_domain = 192-168-0-100.local >>> id_provider = ipa >>> auth_provider = ipa >>> access_provider = ipa >>> ldap_tls_cacert = /etc/ipa/ca.crt >>> ipa_hostname = 192-168-0-110.local >>> chpass_provider = ipa >>> ipa_server = _srv_, 192-168-0-100.local >>> dns_discovery_domain = 192-168-0-100.local >>> >>> sudo_provider = ldap >>> ldap_uri = ldap://192-168-0-100.local >>> ldap_sudo_search_base = ou=sudoers,dc=local >>> ldap_sasl_mech = GSSAPI >>> ldap_sasl_authid = host/192-168-0-100.local at LOCAL >>> ldap_sasl_realm = local >>> krb5_server = 192-168-0-100.local >>> >>> [sssd] >>> services = nss, pam, ssh, sudo >>> config_file_version = 2 >>> >>> domains = 192-168-0-100.local >>> [nss] >>> >>> [pam] >>> >>> [sudo] >>> >>> [autofs] >>> >>> [ssh] >>> >>> [pac] >>> >>> >>> ## /etc/nsswitch.conf on client >>> >>> # >>> # An example Name Service Switch config file. This file should be >>> # sorted with the most-used services at the beginning. >>> # >>> # The entry '[NOTFOUND=return]' means that the search for an >>> # entry should stop if the search in the previous entry turned >>> # up nothing. Note that if the search failed due to some other reason >>> # (like no NIS server responding) then the search continues with the >>> # next entry. >>> # >>> # Valid entries include: >>> # >>> # nisplus Use NIS+ (NIS version 3) >>> # nis Use NIS (NIS version 2), also called YP >>> # dns Use DNS (Domain Name Service) >>> # files Use the local files >>> # db Use the local database (.db) files >>> # compat Use NIS on compat mode >>> # hesiod Use Hesiod for user lookups >>> # [NOTFOUND=return] Stop searching if not found so far >>> # >>> >>> # To use db, put the "db" in front of "files" for entries you want to be >>> # looked up first in the databases >>> # >>> # Example: >>> #passwd: db files nisplus nis >>> #shadow: db files nisplus nis >>> #group: db files nisplus nis >>> >>> passwd: files sss >>> shadow: files sss >>> group: files sss >>> >>> #hosts: db files nisplus nis dns >>> hosts: files dns >>> >>> # Example - obey only what nisplus tells us... >>> #services: nisplus [NOTFOUND=return] files >>> #networks: nisplus [NOTFOUND=return] files >>> #protocols: nisplus [NOTFOUND=return] files >>> #rpc: nisplus [NOTFOUND=return] files >>> #ethers: nisplus [NOTFOUND=return] files >>> #netmasks: nisplus [NOTFOUND=return] files >>> >>> bootparams: nisplus [NOTFOUND=return] files >>> >>> ethers: files >>> netmasks: files >>> networks: files >>> protocols: files >>> rpc: files >>> services: files sss >>> >>> netgroup: files sss >>> >>> publickey: nisplus >>> >>> automount: files >>> aliases: files nisplus >>> sudoers: files sss >>> >>> ## selinux >>> >>> SELinux status: disabled on both client and server >>> >>> ## /etc/krb5.conf on the client >>> >>> #File modified by ipa-client-install >>> >>> includedir /var/lib/sss/pubconf/krb5.include.d/ >>> >>> [libdefaults] >>> default_realm = LOCAL >>> dns_lookup_realm = false >>> dns_lookup_kdc = false >>> rdns = false >>> ticket_lifetime = 24h >>> forwardable = yes >>> >>> [realms] >>> LOCAL = { >>> kdc = 192-168-0-100.local:88 >>> master_kdc = 192-168-0-100.local:88 >>> admin_server = 192-168-0-100.local:749 >>> default_domain = 192-168-0-100.local >>> pkinit_anchors = FILE:/etc/ipa/ca.crt >>> } >>> >>> [domain_realm] >>> .192-168-0-100.local = LOCAL >>> 192-168-0-100.local = LOCAL >>> .local = LOCAL >>> local = LOCAL >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> >> From sbingram at gmail.com Mon Oct 21 17:50:50 2013 From: sbingram at gmail.com (Stephen Ingram) Date: Mon, 21 Oct 2013 10:50:50 -0700 Subject: [Freeipa-users] TTL in individual DNS records In-Reply-To: <52655852.2000302@redhat.com> References: <5264CD5D.2000008@redhat.com> <52655852.2000302@redhat.com> Message-ID: On Mon, Oct 21, 2013 at 9:37 AM, Petr Spacek wrote: > On 21.10.2013 17:58, Stephen Ingram wrote: > >> On Sun, Oct 20, 2013 at 11:44 PM, Petr Spacek wrote: >> >> On 18.10.2013 21:44, Stephen Ingram wrote: >>> >>> I'm using IPA 3.0.x on RHEL 6.4 and trying to setup other zones in DNS. >>>> I >>>> notice that regardless of the TTL set in the SOA for the zone, the >>>> individual records default to 86400. I see there has been previous >>>> discussion on the list ( >>>> https://www.redhat.com/****archives/freeipa-users/2012-** >>>> November/msg00158.html>>> freeipa-users/2012-November/**msg00158.html >>>> > >>>> >>>> ) >>>> saying that the 86400 value is hard-coded into bind-dyndb-ldap. It >>>> appears >>>> as though it might be rectified sometime in the 3.3.x series, however, >>>> I'm >>>> wondering if there is a workaround for now. Is there a way to just >>>> delete >>>> this value such that the individual records will default to the value in >>>> the SOA until a real fix comes along? >>>> >>>> >>> For now, the only workaround is to set TTL explicitly for all affected >>> DNS >>> names. Sorry! >>> >>> $ ipa dnsrecord-mod --help | grep ttl >>> --ttl=INT Time to live >>> >>> The most important thing is that SOA TTL is not related to default record >>> TTL by definition. >>> >>> Some details are described here: >>> https://www.redhat.com/****archives/freeipa-users/2012-** >>> November/msg00160.html>> freeipa-users/2012-November/**msg00160.html >>> > >>> >> >> >> Am I reading this correctly then that you have to set for each *record* vs >> > I really meant *name*. "ipa dnsrecord-mod" operates on whole DNS name. (It > also means that all records under single *name* share the same TTL value.) That's what I thought. I was referring to a name as a record. > the *zone*. If so, this makes the DNS part of IPA almost unusable except >> to >> those willing to stick with the default 86400 or write a script to handle >> each record in the zone. I've been following the list for some time, but >> haven't heard much about usage of the DNS component. And, among the users >> I >> speak with no one uses the DNS component. Perhaps this is the reason why? >> I >> > Up to now, nobody have told us that 'DNS part of IPA almost unusable' > without configuration option for default TTL, so it simply didn't get the > priority. We have seen stroger demand for DNS views, for example :-) Understood. Perhaps my use case is different than most. If I were using scripts, I don't think this would be much of an issue, however, with several UI users with varying levels of experience, it is difficult if you want to vary TTL per zone instead of per name. After reading the RFC referenced in the ticket I see now that the default TTL I was thinking was part of the SOA is actually a separate entity. And, thus, I now see why IPA needs to also make this distinction. > > haven't looked at the code yet, but would this be that difficult to fix? >> I >> > If you are okay with statically configured TTL for all zones, then it is > five-minute fix. (Simply change the current value and recompile or add a > new parameter to /etc/named.conf.) > Could you please point me to the code where this static definition happens? > > If you want to define default TTL per-zone in LDAP, then you have to > define new attribute in LDAP schema, store the default TTL value in > zone_register and push it to record parser as necessary. > > In https://fedorahosted.org/bind-**dyndb-ldap/ticket/70#comment:7you can see that we are trying to cooperate with schema/OID space owner to > find & standardize some solution. > > Any contribution is more than welcome! Join us in the ticket and we can > discuss various propsals. I see now why this is not a quick solution. I was unaware that the attribute to handle this default TTL didn't exist. It looks there are two ideas on the table (JHogarth and JCholasta) right now. But, from the ticket discussion, it looks like maybe the new attribute is being added instead and already in progress? Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Mon Oct 21 19:09:42 2013 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 21 Oct 2013 15:09:42 -0400 Subject: [Freeipa-users] RHEL 5.x client functionality with ipa-server 3.0 In-Reply-To: References: Message-ID: <52657BF6.7020307@redhat.com> On 10/21/2013 12:25 PM, Brian Lee wrote: > Hello All, > > We have a mixed RHEL environment (5.x, 6.x, x86, and x86_64). Our > FreeIPA server is running RHEL 6.4 x86_64 with ipa-server 3.0. My > question is what are the hurdles or feature limitations should I > expect to encounter in this mixed environment, especially in regards > to the RHEL 5.x systems? I appreciate any feedback or experience provided. > > Thanks, > Brian > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users The client and underlying SSSD component have evolved quite a bit since they were introduced in RHEL 5.6. The details would depend on different factors, for example which DNS you use. Later versions of SSSD and ipa-client can be told to not rely on the DNS auto-discovery for LDAP/Kerberos services. Later versions of SSSD also have integration with sudo, automount etc. So the bottom line is that you might have to do more manual/scripted configuration of the client on top of ipa-client in earlier versions of SSSD and ipa-client and some features just would not be available on RHEL5 systems. But basic authentication and identity lookups would work everywhere. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Mon Oct 21 19:13:21 2013 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 21 Oct 2013 15:13:21 -0400 Subject: [Freeipa-users] DNS views: request for comments In-Reply-To: <52655AE2.7010207@redhat.com> References: <524AE614.8090808@redhat.com> <52655AE2.7010207@redhat.com> Message-ID: <52657CD1.7080801@redhat.com> On 10/21/2013 12:48 PM, Petr Spacek wrote: > On 1.10.2013 17:11, Petr Spacek wrote: >> Hello list, >> >> we would like to get more details about DNS views and how you use >> them in real >> life. Also, any idea how user a interface should work is more than >> welcome! >> >> (If you don't know views, read it as "differentiate answer to a DNS >> query on >> client's IP address basics".) >> >> >> Questions are: >> - For what purpose do you use views? >> E.g. handling clients inside/outside of company network (e.g. hiding >> internal >> names); Selecting nearest server in a big network; Some other weird >> 'Cloud' >> scenarios etc. etc. >> >> - How many views do you use? >> >> - Do you share some data between views? How did you solve that? Do >> you use >> some user interface for that? >> >> - Do you use DNS updates? (nsupdate/RFC 2136/RFC 3007) >> >> Previous discussions about DNS views: >> https://www.redhat.com/archives/freeipa-users/2012-April/msg00070.html >> https://www.redhat.com/archives/freeipa-devel/2012-May/msg00208.html >> >> Related tickets & bugs: >> https://fedorahosted.org/freeipa/ticket/2802 >> https://bugzilla.redhat.com/show_bug.cgi?id=815621 >> https://fedorahosted.org/freeipa/ticket/3725 >> https://fedorahosted.org/bind-dyndb-ldap/ticket/69 >> >> >> The next step will be to design LDAP schema for DNS data with views ... >> >> I can see three basic options: >> >> 1) Resign from any data sharing, which will make the thing pretty >> easy :-) >> In that case 'view1' will be represented by one sub-tree in LDAP, >> 'view2' will >> be another sub-tree etc. >> >> 2) Select one sub-tree which will be 'the base' containing all shared >> records. >> All other views will inherit and override data from the shared 'base'. >> >> 3) Make it as general as possible and allow multiple levels of >> inheritance. >> View3 inherits from View2 and it inherits from Base. >> (View3 <- View2 <- Base) >> >> It is basically generalized variant (2), but it could require >> different LDAP >> schema. >> >> >> Please post your opinions! > > I spent some time investigating how DNS views work in various DNS > servers. I hope that it will help us to find some balance between real > world requirements and complexity. > > The next section discusses possible LDAP schema and semantics for our > DNS views implementation. Feel free to jump directly to the proposal > if you have some particular idea how it should work. > > > Support for DNS views in server software > ======================================== > I have tried to find how widely DNS views are supported by various > software packages. > > Open Source software > -------------------- > PowerDNS > - only specialized backend for Geo->something mapping > - no inheritance > - no dynamic updates > - > http://wiki.powerdns.com/trac/browser/trunk/pdns/modules/geobackend/README > > Djbdns/tinydns > - no inheritance > - non-standard dynamic updates (?? via external tools, I'm not 100 % > sure) > - can differentiate answers on IP-prefix basics: > http://cr.yp.to/djbdns/tinydns-data.html (search for "ipprefix") > > Dnsmasq > - subnet-based selection for A records only (based on client's subnet) > - no inheritance > - dynamic update only from built-in DHCP server > http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html (see option > --localise-queries) > > > BIND 9 > - full support for DNS views > - each view can be totally independent on other views > - inheritance is done via $INCLUDE directive in zone file > - in any case, a update affects only DNS view where the update was > received > - limitations: > -- inherited data can be modified only via addition; > modification/deletion to the inherited data is not possible (you have > to break inheritance if you have to modify/delete inherited data) > -- any dynamic update breaks inheritance > > BIND 9 examples: > Example external view is subset of company-internal view. > > zone file external.db: > mail A 192.0.2.1 > > zone file internal.db: > $INCLUDE external.db > shell A 10.1.2.3 > > Imagine that internal view was updated via DNS update, a record for > name "git" was added. The resulting zone file internal.db will look like: > git A 10.3.3.33 > mail A 192.0.2.1 > shell A 10.1.1.1 > > You can see that inheritance from the external view was broken and all > records from external view were copied to the internal view. > > It is possible to use multiple levels of $INCLUDE, but then thigs > become twisted. > > > Proprietary software > -------------------- > Simple DNS Plus > - only special handling "for NAT": > "In DNS responses to DNS requests from LAN clients only, this function > changes host records which are pointing to a public IP address of the > NAT router to point to the corresponding private IP address of a local > server." > - http://www.simpledns.com/help/v52/wd_opt_dnsnatlan.htm > > InfoBlox > - full support for DNS views > - each view can be totally independent on other views > - DNS object hierarchy: > 1. one view = set of zones > 2. one zone = set of records + set of shared record groups > 3. shared record group = set of records shared between DNS zones > - inheritance is realized via "Shared Record Groups" (see page 465): > -- records are grouped to named group called "Shared Record Group" > -- the group is associated with one or more DNS *zones* > -- there is single-level inheritance only > -- E.g. the same set of MX records can be present in DNS zone > example.com and eshop.example.com. I.e. mail server addresses are > managed from single place, it is not necessary to change MX records > separelly for example.com and eshop.example.com. > -- In case of FreeIPA it could be group of all SRV or NS records so > all records for a new replica have to be created only on single place > and the change will affect all FreeIPA-managed DNS zones. > - only one DNS view can receive the dynamic DNS updates (page 388) > - it is unclear if the same limitations for inheritance apply or not > - > http://dloads.infoblox.com/direct/appliance/NIOS/NIOS_AdminGuide_6.5.pdf > > Nominum Vantio > - caching only (I guess) - listed as an extreme example > - there is not much public details about that, but this is what they > claim: > "Lightweight Views take the ?view? concept of the server to > the ultimate extent, where each individual user can have their own > view. Policies defining how queries are handled can be applied to each > view, effectively enabling a personal Internet for each subscriber." > - http://nominum.com/assets/Documents/Datasheets/vantio-datasheet.pdf > > > Proposal - variant A ("classical" views) > ==================== > - keep it simple :-) > - single level inheritance, all views inherit from 'base' (Base is our > current cn=dns subtree, so old and new plugins can co-exist. The base > can be empty.) > - the data in views can be modified via DNS updates, a change done to > inherited data creates an override (BIND9 does the same): e.g. name > 'r1.z.' is shared between View1 and View2. Value change in View1 > doesn't affect View2. > - particular record from the 'base' can be overriden > (deleted/replaced) in any view > - changes done to the base are propagated to all views > > LDAP schema > ----------- > My goal is to maintain 1:1 mapping between "name+view" pair and LDAP > DN. This is crucial for DNS updates. The other option is to maintain > some 'record->LDAP DN database' or do a LDAP search before each DNS > update - I would like to avoid that. > > Each view is stored as separate object under cn=dns. > DN: idnsView=view1, cn=dns > - this object stores settings specific to particular view (allowed > clients, recursion ...) > > Zone in particular view is stored inside view container: > DN: idnsName=zone1, idnsView=view1, dn=dns > - this object can be empty container > - attributes without explicit configuration are inherited from the base > - a zone doesn't appear in the DNS view if the container is not > present (i.e. it is possible to hide the zone from particular view) > > 'Override' records for particular name in zone and view are stored as: > DN: idnsName=name1, idnsName=zone1, idnsView=view1, cn=dns > - values added on top of inherited set are represented as normal DNS > attributes: e.g. aRecord: 192.0.2.1 > - values deleted from inherited set - *are open question*: It would be > great if we could store it under the same object as additions, it > would make implementation a bit simpler. > - Would it be acceptable to store override 'delete TXT record "hello"' > as attribute 'tXTRecord;x-deleted: test'? > - The other option is to store deleted attributes in separate object: > DN: cn=deleted, idnsName=record1, idnsName=zone1, idnsView=view1, cn=dns > > > Proposal - variant B (shared record groups) > ==================== > - not so simple to implement, especially update-performance could be > an issue > - multiple zones can share the same record group > - each view can contain arbitrary zones anf those zones can inherit > arbitrary record groups - inheritance is fully configurable > - the data in views can be modified via DNS updates, a change done to > inherited data creates an override (BIND9 does the same): e.g. name > 'r1.z.' is shared between View1 and View2. Value change in View1 > doesn't affect View2. > - particular record from any shared record group can be overriden > (deleted/replaced) in any zone in any view > - changes done to the shared record group are propagated to all views > (this is the hard part!) > > > LDAP schema > ----------- > Group of shared records - container: > DN: idnsRecordGroup=group1, cn=dns > > One shared name: > DN: idnsName=record1, idnsRecordGroup=group1, cn=dns > - contains DNS records for that name as usual > > Each view is stored as separate object under cn=dns. > DN: idnsView=view1, cn=dns > > Zone in particular view is stored inside view container: > DN: idnsName=zone1, idnsView=view1, dn=dns > - zone has a attribute with DNs of inherited record groups > > 'Override' records for particular name in zone and view are stored as: > DN: idnsName=name1, idnsName=zone1, idnsView=view1, cn=dns > > > After each change to any data we have to compute new resulting value. > It means to combine the data for particular name from all record > groups and then apply overrides for particular instance. > > It means a lot of bookkeeping after each change ... > > > Proposal - variant 0 > ==================== > Do not implement it in bind-dyndb-ldap and wait if Martin Basti > succeeds with his thesis. He is trying to design and implement some > generic/pluggable LDAP<->DNS synchronization mechanism. > > Personally, I think that variant "0" is the best one! :-D One of side > effects is that our depedency on BIND 9 will be lowered and most of > the work will be deferred to the real DNS server. > What is the time line for this thesis? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Mon Oct 21 19:40:43 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 21 Oct 2013 15:40:43 -0400 Subject: [Freeipa-users] Problems with expired certificates In-Reply-To: <30417997.11254.1381967817247.JavaMail.root@tommi.org> References: <30417997.11254.1381967817247.JavaMail.root@tommi.org> Message-ID: <5265833B.4010500@redhat.com> T?mas Edwardsson wrote: > I'm having issues with expired certificates in /var/lib/pki-ca/alias which I'm quite unsure on how to fix. The ones that have expired are: > > subsystemCert cert-pki-ca > Server-Cert cert-pki-ca > > According to "getcert list" the following 2 requests are stuck The error code translates to: CURLE_SSL_CACERT (60) Peer certificate cannot be authenticated with known CA certificates. Which is odd considering that other certificates in the same database were renewed ok. I suppose I'd rewind time to the day before expiration and run: getcert resubmit -i for each of these and see if it goes through. rob > > > Request ID '20130415234030': > status: CA_UNREACHABLE > ca-error: Error 60 connecting to https://auth.d.lan:9443/ca/agent/ca/profileReview: Peer certificate cannot be authenticated with known CA certificates. > stuck: yes > key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB',pin='502532376322' > certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB' > CA: dogtag-ipa-renew-agent > issuer: CN=Certificate Authority,O=D.LAN > subject: CN=CA Subsystem,O=D.LAN > expires: 2013-07-10 14:24:34 UTC > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad > post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert "subsystemCert cert-pki-ca" > track: yes > auto-renew: yes > > Request ID '20130415234032': > status: CA_UNREACHABLE > ca-error: Error 60 connecting to https://auth.d.lan:9443/ca/agent/ca/profileReview: Peer certificate cannot be authenticated with known CA certificates. > stuck: yes > key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert cert-pki-ca',token='NSS Certificate DB',pin='502532376322' > certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert cert-pki-ca',token='NSS Certificate DB' > CA: dogtag-ipa-renew-agent > issuer: CN=Certificate Authority,O=D.LAN > subject: CN=auth.d.lan,O=D.LAN > expires: 2013-07-10 14:24:33 UTC > eku: id-kp-serverAuth > pre-save command: > post-save command: > track: yes > auto-renew: yes > > > Here is what I could find from some browsing with certutil: > > [root at auth ~]# certutil -d /var/lib/pki-ca/alias -L > Certificate Nickname Trust Attributes > SSL,S/MIME,JAR/XPI > > subsystemCert cert-pki-ca u,u,u > ocspSigningCert cert-pki-ca u,u,u > caSigningCert cert-pki-ca CTu,Cu,Cu > Server-Cert cert-pki-ca u,u,u > auditSigningCert cert-pki-ca u,u,Pu > > > > [root at auth ~]# certutil -d /var/lib/pki-ca/alias -L -n "subsystemCert cert-pki-ca"|grep "Not After" > Not After : Wed Jul 10 14:24:34 2013 > [root at auth ~]# certutil -d /var/lib/pki-ca/alias -L -n "ocspSigningCert cert-pki-ca"|grep "Not After" > Not After : Mon Jun 29 00:00:55 2015 > [root at auth ~]# certutil -d /var/lib/pki-ca/alias -L -n "caSigningCert cert-pki-ca"|grep "Not After" > Not After : Sun Jul 21 14:24:32 2019 > [root at auth ~]# certutil -d /var/lib/pki-ca/alias -L -n "Server-Cert cert-pki-ca"|grep "Not After" > Not After : Wed Jul 10 14:24:33 2013 > [root at auth ~]# certutil -d /var/lib/pki-ca/alias -L -n "auditSigningCert cert-pki-ca"|grep "Not After" > Not After : Mon Jun 29 00:01:55 2015 > > > > How can I renew the affected certificates? > > --- > Tomas Edwardsson > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From jhrozek at redhat.com Mon Oct 21 20:03:23 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 21 Oct 2013 22:03:23 +0200 Subject: [Freeipa-users] Authenticating sudo with ipa on Centos In-Reply-To: <52656599.40406@redhat.com> References: <526053A2.9080205@redhat.com> <52656599.40406@redhat.com> Message-ID: <20131021200323.GB5574@hendrix.redhat.com> On Mon, Oct 21, 2013 at 01:34:17PM -0400, Rob Crittenden wrote: > Andrew Holway wrote: > >>It is a bit strange that your ipa_domain and ipa_hostname are the same. I > >>think the domain should be just local. > >> > >>I'd run klist -kt /etc/krb5.keytab to see what principals are in there. > > > >ipa_hostname = 192-168-0-110.local > >ipa_server = _srv_, 192-168-0-100.local > > > >Hi, > > > >I'm a little confused. They are not the same and these values were > >created by the "ipa-client-install" utility. > > > >I think there is some extra magic needed so that I get get sudo > >working with ipa...The redhat docs are a little bit lacking for the > >less advanced... > > > >https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/sssd-ldap-sudo.html > > Sure, but first we need to make sssd talk to IPA at all, which it isn't. > > Like I said, it looks like your sssd configuration is wrong. You can > always un-enroll and re-enroll the client in order to reset things. > > rob Sorry I didn't notice the sssd keyword until now. I think Rob is right, ipa_domain and ipa_hostname being the same seems wrong. Was this config generated by ipa-client-install at all? If you put debug_level=6 into the [domain] section of sssd.conf and restart the sssd, you'd be able to inspect more verbose debugging in /var/log/sssd/*.log But first I'd try re-enrolling the client as Rob says. You should end up with a valid sssd.conf From simo at redhat.com Mon Oct 21 20:57:55 2013 From: simo at redhat.com (Simo Sorce) Date: Mon, 21 Oct 2013 16:57:55 -0400 Subject: [Freeipa-users] DNS views: request for comments In-Reply-To: <52655AE2.7010207@redhat.com> References: <524AE614.8090808@redhat.com> <52655AE2.7010207@redhat.com> Message-ID: <1382389075.9794.15.camel@willson.li.ssimo.org> Comments inline. On Mon, 2013-10-21 at 18:48 +0200, Petr Spacek wrote: > On 1.10.2013 17:11, Petr Spacek wrote: [trim] > Proposal - variant A ("classical" views) > ==================== > - keep it simple :-) > - single level inheritance, all views inherit from 'base' (Base is our current > cn=dns subtree, so old and new plugins can co-exist. The base can be empty.) > - the data in views can be modified via DNS updates, a change done to > inherited data creates an override (BIND9 does the same): e.g. name 'r1.z.' is > shared between View1 and View2. Value change in View1 doesn't affect View2. > - particular record from the 'base' can be overriden (deleted/replaced) in any > view > - changes done to the base are propagated to all views > > LDAP schema > ----------- > My goal is to maintain 1:1 mapping between "name+view" pair and LDAP DN. This > is crucial for DNS updates. The other option is to maintain some 'record->LDAP > DN database' or do a LDAP search before each DNS update - I would like to > avoid that. > > Each view is stored as separate object under cn=dns. > DN: idnsView=view1, cn=dns > - this object stores settings specific to particular view (allowed clients, > recursion ...) > > Zone in particular view is stored inside view container: > DN: idnsName=zone1, idnsView=view1, dn=dns > - this object can be empty container > - attributes without explicit configuration are inherited from the base > - a zone doesn't appear in the DNS view if the container is not present (i.e. > it is possible to hide the zone from particular view) > 'Override' records for particular name in zone and view are stored as: > DN: idnsName=name1, idnsName=zone1, idnsView=view1, cn=dns Doesn't this scheme means you always have to do 2 searches ? One to find if the object is in the view and one to the base ? We could use multivalued RDNs to achieve something similar but that will require you only one search (assuming it matters). > - values added on top of inherited set are represented as normal DNS > attributes: e.g. aRecord: 192.0.2.1 > - values deleted from inherited set - *are open question*: It would be great > if we could store it under the same object as additions, it would make > implementation a bit simpler. > - Would it be acceptable to store override 'delete TXT record "hello"' as > attribute 'tXTRecord;x-deleted: test'? I think this would be acceptable, however what happens if then someone deletes the base object and later on again recreates it ? Will the view still 'mask' it ? Is this the actual desired outcome maybe ? Should we allow Dynamic Updates in Views at all ? > - The other option is to store deleted attributes in separate object: > DN: cn=deleted, idnsName=record1, idnsName=zone1, idnsView=view1, cn=dns This sound cumbersome and require a 3rd search for every query, nack :) I like variant A, I think it is the most sensible and the only one really needed. People have an internal view and want to 'filter' it some for the external world or similar. > Proposal - variant B (shared record groups) > ==================== > - not so simple to implement, especially update-performance could be an issue > - multiple zones can share the same record group > - each view can contain arbitrary zones anf those zones can inherit arbitrary > record groups - inheritance is fully configurable > - the data in views can be modified via DNS updates, a change done to > inherited data creates an override (BIND9 does the same): e.g. name 'r1.z.' is > shared between View1 and View2. Value change in View1 doesn't affect View2. > - particular record from any shared record group can be overriden > (deleted/replaced) in any zone in any view > - changes done to the shared record group are propagated to all views (this is > the hard part!) Sound very complex not only to build, but to explain to admins as well, is anyone actually going to need this level of complexity, what scenario would really benefit from this that can't be done with A ? > LDAP schema > ----------- > Group of shared records - container: > DN: idnsRecordGroup=group1, cn=dns > > One shared name: > DN: idnsName=record1, idnsRecordGroup=group1, cn=dns > - contains DNS records for that name as usual > > Each view is stored as separate object under cn=dns. > DN: idnsView=view1, cn=dns > > Zone in particular view is stored inside view container: > DN: idnsName=zone1, idnsView=view1, dn=dns > - zone has a attribute with DNs of inherited record groups > > 'Override' records for particular name in zone and view are stored as: > DN: idnsName=name1, idnsName=zone1, idnsView=view1, cn=dns > > > After each change to any data we have to compute new resulting value. It means > to combine the data for particular name from all record groups and then apply > overrides for particular instance. > > It means a lot of bookkeeping after each change ... > > > Proposal - variant 0 > ==================== > Do not implement it in bind-dyndb-ldap and wait if Martin Basti succeeds with > his thesis. He is trying to design and implement some generic/pluggable > LDAP<->DNS synchronization mechanism. > > Personally, I think that variant "0" is the best one! :-D One of side effects > is that our depedency on BIND 9 will be lowered and most of the work will be > deferred to the real DNS server. Synchronization is always very, very hard, especially when you throw in the word 'generic'. Especially problematic are races. I would proceed with A unless there is solid evidence this can work with all corner cases and in a short period of time. Simo. -- Simo Sorce * Red Hat, Inc * New York From andrew.holway at gmail.com Mon Oct 21 21:20:28 2013 From: andrew.holway at gmail.com (Andrew Holway) Date: Mon, 21 Oct 2013 22:20:28 +0100 Subject: [Freeipa-users] Authenticating sudo with ipa on Centos In-Reply-To: <20131021200323.GB5574@hendrix.redhat.com> References: <526053A2.9080205@redhat.com> <52656599.40406@redhat.com> <20131021200323.GB5574@hendrix.redhat.com> Message-ID: Hi, ipa_domain and ipa_hostname was indeed a config error. Also, using a .local domain caused all manner of problems. Thanks all for your help! Andrew On 21 October 2013 21:03, Jakub Hrozek wrote: > On Mon, Oct 21, 2013 at 01:34:17PM -0400, Rob Crittenden wrote: >> Andrew Holway wrote: >> >>It is a bit strange that your ipa_domain and ipa_hostname are the same. I >> >>think the domain should be just local. >> >> >> >>I'd run klist -kt /etc/krb5.keytab to see what principals are in there. >> > >> >ipa_hostname = 192-168-0-110.local >> >ipa_server = _srv_, 192-168-0-100.local >> > >> >Hi, >> > >> >I'm a little confused. They are not the same and these values were >> >created by the "ipa-client-install" utility. >> > >> >I think there is some extra magic needed so that I get get sudo >> >working with ipa...The redhat docs are a little bit lacking for the >> >less advanced... >> > >> >https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/sssd-ldap-sudo.html >> >> Sure, but first we need to make sssd talk to IPA at all, which it isn't. >> >> Like I said, it looks like your sssd configuration is wrong. You can >> always un-enroll and re-enroll the client in order to reset things. >> >> rob > > Sorry I didn't notice the sssd keyword until now. > > I think Rob is right, ipa_domain and ipa_hostname being the same seems > wrong. Was this config generated by ipa-client-install at all? > > If you put debug_level=6 into the [domain] section of sssd.conf and > restart the sssd, you'd be able to inspect more verbose debugging in > /var/log/sssd/*.log > > But first I'd try re-enrolling the client as Rob says. You should end up > with a valid sssd.conf > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From ryan.thomson at ubc.ca Mon Oct 21 22:27:58 2013 From: ryan.thomson at ubc.ca (Thomson, Ryan) Date: Mon, 21 Oct 2013 22:27:58 +0000 Subject: [Freeipa-users] Failure decoding Certificate Signing Request Message-ID: <3fc2cb83-f64c-450b-a9d9-d4612966bbc1@S-ITSV-HUB01P.ead.ubc.ca> Hello FreeIPA users and developers, I'm facing a problem with expired certificates in FreeIPA. I have searched through the list archives and found advice to stop the IPA service, roll back the system clock to a time when the certs were valid but nearly expired, start IPA and then use certmonger to renew the certs as it normally should (getcert resubmit -i ). This appears to have worked as expected for the dogtag/CA certificates signed with the "dogtag-ipa-renew-agent" CA but is failing for the HTTP and dirsrv certificates signed with the "IPA" CA. Certmonger reports the following error (ipa-getcert list): Server failed request, will retry: 4301 (RPC failed at server. Certificate operation cannot be completed: Failure decoding Certificate Signing Request). I turned on IPA debugging to acquire the following error in /var/log/httpd/error_log when resubmitting to certmonger: [Mon Oct 07 00:03:22 2013] [error] ipa: DEBUG: WSGI wsgi_dispatch.__call__: [Mon Oct 07 00:03:22 2013] [error] ipa: DEBUG: WSGI xmlserver.__call__: [Mon Oct 07 00:03:22 2013] [error] ipa: DEBUG: Created connection context.ldap2 [Mon Oct 07 00:03:22 2013] [error] ipa: DEBUG: WSGI WSGIExecutioner.__call__: [Mon Oct 07 00:03:22 2013] [error] ipa: DEBUG: raw: cert_request(u'MIIDcDCCAlgCAQAwNjEUMBIGA1UEChMLRk1SSS5VQkMuQ0ExHjAcBgNVBAMTFXNoYW1yb2NrLmJyYWluLnViYy5jYTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKCzypT3oNmPx90Tevn/vv8FUouT8UL2d8qmhxK0AUVPxJwoZPtkbQBWzUNxkTBkhWV/5s0hN19VBb5ruHTbeSv7KBX8P+CwopQbbjpaqpwvi3dso1NSnT3kU+cNYY1j4tvyKkwPVS7FrP4oELX+aEEOuGF8eyOPK78UlZtDrY0Npje5l8MsUrRMKqQAjhIFc4EzTb2tqcR8Ch+OzBHugcFXcmXGmFnHkK29z2f7Aq1ynk0SqWC0r7nZXw/17jI1OEeD9pagGH1OLEzMrJUQTrvQGH/W+XPt2+ZvJ3UtF4ltw2ViStiG958b32OQvGnbQVJjaIgjpOSiorfnhM0wCPcCAwEAAaCB9DAaBgkqhkiG9w0BCRQxDRMLU2VydmVyLUNlcnQwgdUGCSqGSIb3DQEJDjGBxzCBxDAOBgNVHQ8BAQAEBAMCBPAwgZkGA1UdEQEBAASBjjCBi6A8BgorBgEEAYI3FAIDoC4MLGRvZ3RhZ2xkYXAvc2hhbXJvY2suYnJhaW4udWJjLmNhQEZNUkkuVUJDLkNBoEsGBisGAQUCAqBBMD+gDRsLRk1SSS5VQkMuQ0GhLjAsoAMCAQGhJTAjGwpkb2d0YWdsZGFwGxVzaGFtcm9jay5icmFpbi51YmMuY2EwFgYDVR0lAQEABAwwCgYIKwYBBQUHAwEwDQYJKoZIhvcNAQELBQADggEBAIP+0+O/COqFwbqUCJ+LJiE8aAmP01SRvfJx/RSE9huquDd2XdHVIQ6lQj6qnQYTtCw2NKRq77R3VmUAiCMpQwI9/x/QaaI4MBvV9iYA8b1H/weyvZAMw1mGkdgY55KWPhBtCqLuxHcGRblrtsy2PGp9wm/834s5YamQky+InQFlDy4o5ox+5U5iZS+pvKm52d0TQTozvZ/gSTAqEc+gpwlGAU4U0VaC+7PYnwkYJ98jLDaALm2OCWnSvw/02NLlc+h02mTjumAQ/YnWYNXiAtUbiA8BAkjT0UGV79Vi/aUKxpBTZQXbldrHN/cAmUtSMxebNNQjyUdzAHEV+TUUP2o=', principal=u'dogtagldap/HOSTNAME.DOMAIN at FULLY.QUALIFIED.DOMAIN', add=True) [Mon Oct 07 00:03:22 2013] [error] ipa: DEBUG: cert_request(u'MIIDcDCCAlgCAQAwNjEUMBIGA1UEChMLRk1SSS5VQkMuQ0ExHjAcBgNVBAMTFXNoYW1yb2NrLmJyYWluLnViYy5jYTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKCzypT3oNmPx90Tevn/vv8FUouT8UL2d8qmhxK0AUVPxJwoZPtkbQBWzUNxkTBkhWV/5s0hN19VBb5ruHTbeSv7KBX8P+CwopQbbjpaqpwvi3dso1NSnT3kU+cNYY1j4tvyKkwPVS7FrP4oELX+aEEOuGF8eyOPK78UlZtDrY0Npje5l8MsUrRMKqQAjhIFc4EzTb2tqcR8Ch+OzBHugcFXcmXGmFnHkK29z2f7Aq1ynk0SqWC0r7nZXw/17jI1OEeD9pagGH1OLEzMrJUQTrvQGH/W+XPt2+ZvJ3UtF4ltw2ViStiG958b32OQvGnbQVJjaIgjpOSiorfnhM0wCPcCAwEAAaCB9DAaBgkqhkiG9w0BCRQxDRMLU2VydmVyLUNlcnQwgdUGCSqGSIb3DQEJDjGBxzCBxDAOBgNVHQ8BAQAEBAMCBPAwgZkGA1UdEQEBAASBjjCBi6A8BgorBgEEAYI3FAIDoC4MLGRvZ3RhZ2xkYXAvc2hhbXJvY2suYnJhaW4udWJjLmNhQEZNUkkuVUJDLkNBoEsGBisGAQUCAqBBMD+gDRsLRk1SSS5VQkMuQ0GhLjAsoAMCAQGhJTAjGwpkb2d0YWdsZGFwGxVzaGFtcm9jay5icmFpbi51YmMuY2EwFgYDVR0lAQEABAwwCgYIKwYBBQUHAwEwDQYJKoZIhvcNAQELBQADggEBAIP+0+O/COqFwbqUCJ+LJiE8aAmP01SRvfJx/RSE9huquDd2XdHVIQ6lQj6qnQYTtCw2NKRq77R3VmUAiCMpQwI9/x/QaaI4MBvV9iYA8b1H/weyvZAMw1mGkdgY55KWPhBtCqLuxHcGRblrtsy2PGp9wm/834s5YamQky+InQFlDy4o5ox+5U5iZS+pvKm52d0TQTozvZ/gSTAqEc+gpwlGAU4U0VaC+7PYnwkYJ98jLDaALm2OCWnSvw/02NLlc+h02mTjumAQ/YnWYNXiAtUbiA8BAkjT0UGV79Vi/aUKxpBTZQXbldrHN/cAmUtSMxebNNQjyUdzAHEV+TUUP2o=', principal=u'dogtagldap/HOSTNAME.DOMAIN at FULLY.QUALIFIED.DOMAIN', request_type=u'pkcs10', add=True) [Mon Oct 07 00:03:22 2013] [error] ipa: INFO: host/HOSTNAME.DOMAIN at FULLY.QUALIFIED.DOMAIN: cert_request(u'MIIDcDCCAlgCAQAwNjEUMBIGA1UEChMLRk1SSS5VQkMuQ0ExHjAcBgNVBAMTFXNoYW1yb2NrLmJyYWluLnViYy5jYTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKCzypT3oNmPx90Tevn/vv8FUouT8UL2d8qmhxK0AUVPxJwoZPtkbQBWzUNxkTBkhWV/5s0hN19VBb5ruHTbeSv7KBX8P+CwopQbbjpaqpwvi3dso1NSnT3kU+cNYY1j4tvyKkwPVS7FrP4oELX+aEEOuGF8eyOPK78UlZtDrY0Npje5l8MsUrRMKqQAjhIFc4EzTb2tqcR8Ch+OzBHugcFXcmXGmFnHkK29z2f7Aq1ynk0SqWC0r7nZXw/17jI1OEeD9pagGH1OLEzMrJUQTrvQGH/W+XPt2+ZvJ3UtF4ltw2ViStiG958b32OQvGnbQVJjaIgjpOSiorfnhM0wCPcCAwEAAaCB9DAaBgkqhkiG9w0BCRQxDRMLU2VydmVyLUNlcnQwgdUGCSqGSIb3DQEJDjGBxzCBxDAOBgNVHQ8BAQAEBAMCBPAwgZkGA1UdEQEBAASBjjCBi6A8BgorBgEEAYI3FAIDoC4MLGRvZ3RhZ2xkYXAvc2hhbXJvY2suYnJhaW4udWJjLmNhQEZNUkkuVUJDLkNBoEsGBisGAQUCAqBBMD+gDRsLRk1SSS5VQkMuQ0GhLjAsoAMCAQGhJTAjGwpkb2d0YWdsZGFwGxVzaGFtcm9jay5icmFpbi51YmMuY2EwFgYDVR0lAQEABAwwCgYIKwYBBQUHAwEwDQYJKoZIhvcNAQELBQADggEBAIP+0+O/COqFwbqUCJ+LJiE8aAmP01SRvfJx/RSE9huquDd2XdHVIQ6lQj6qnQYTtCw2NKRq77R3VmUAiCMpQwI9/x/QaaI4MBvV9iYA8b1H/weyvZAMw1mGkdgY55KWPhBtCqLuxHcGRblrtsy2PGp9wm/834s5YamQky+InQFlDy4o5ox+5U5iZS+pvKm52d0TQTozvZ/gSTAqEc+gpwlGAU4U0VaC+7PYnwkYJ98jLDaALm2OCWnSvw/02NLlc+h02mTjumAQ/YnWYNXiAtUbiA8BAkjT0UGV79Vi/aUKxpBTZQXbldrHN/cAmUtSMxebNNQjyUdzAHEV+TUUP2o=', principal=u'dogtagldap/HOSTNAME.DOMAIN at FULLY.QUALIFIED.DOMAIN', add=True): CertificateOperationError [Mon Oct 07 00:03:22 2013] [error] ipa: DEBUG: response: CertificateOperationError: Certificate operation cannot be completed: Gettext('3 - Failure decoding Certificate Signing Request', domain='ipa', localedir=None) [Mon Oct 07 00:03:22 2013] [error] ipa: DEBUG: no session id in request, generating empty session data with id=e943ef07ef510b4519a6f7658d96ae51 [Mon Oct 07 00:03:22 2013] [error] ipa: DEBUG: store session: session_id=e943ef07ef510b4519a6f7658d96ae51 start_timestamp=2013-10-07T00:03:22 access_timestamp=2013-10-07T00:03:22 expiration_timestamp=1969-12-31T16:00:00 [Mon Oct 07 00:03:22 2013] [error] ipa: DEBUG: finalize_kerberos_acquisition: xmlserver ccache_name="FILE:/tmp/krb5cc_apache_fWDfep" session_id="e943ef07ef510b4519a6f7658d96ae51" [Mon Oct 07 00:03:22 2013] [error] ipa: DEBUG: reading ccache data from file "/tmp/krb5cc_apache_fWDfep" [Mon Oct 07 00:03:22 2013] [error] ipa: DEBUG: get_credential_times: principal=krbtgt/FULLY.QUALIFIED.DOMAIN at FULLY.QUALIFIED.DOMAIN, authtime=10/07/13 00:03:22, starttime=10/07/13 00:03:22, endtime=10/08/13 00:03:22, renew_till=12/31/69 16:00:00 [Mon Oct 07 00:03:22 2013] [error] ipa: DEBUG: KRB5_CCache FILE:/tmp/krb5cc_apache_fWDfep endtime=1381215802 (10/08/13 00:03:22) [Mon Oct 07 00:03:22 2013] [error] ipa: DEBUG: set_session_expiration_time: duration_type=inactivity_timeout duration=1200 max_age=1381215502 expiration=1381130602.32 (2013-10-07T00:23:22) [Mon Oct 07 00:03:22 2013] [error] ipa: DEBUG: store session: session_id=e943ef07ef510b4519a6f7658d96ae51 start_timestamp=2013-10-07T00:03:22 access_timestamp=2013-10-07T00:03:22 expiration_timestamp=2013-10-07T00:23:22 [Mon Oct 07 00:03:22 2013] [error] ipa: DEBUG: Destroyed connection context.ldap2 I briefly spoke with Rob on #freeipa last week and he suggested trying to manually load the certificate signing request in a python shell, roughly as follows: from ipalib import pkcs10 with open ("req.csr", "r") as myreq: csr=myreq.read() request = pkcs10.load_certificate_request(csr) print request print pkcs10.get_subject(request) print pkcs10.get_subjectaltname(request) I was able to do this and see the CSR info on stdout, including subject and alt name. The system is RHEL6.4, fully updated as of today. Any ideas on where to go from here? --Ryan From pspacek at redhat.com Tue Oct 22 07:02:14 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 22 Oct 2013 09:02:14 +0200 Subject: [Freeipa-users] Default TTL for DNS records In-Reply-To: References: <5264CD5D.2000008@redhat.com> <52655852.2000302@redhat.com> Message-ID: <526622F6.3020409@redhat.com> On 21.10.2013 19:50, Stephen Ingram wrote: > On Mon, Oct 21, 2013 at 9:37 AM, Petr Spacek wrote: >> On 21.10.2013 17:58, Stephen Ingram wrote: >>> On Sun, Oct 20, 2013 at 11:44 PM, Petr Spacek wrote: >>> On 18.10.2013 21:44, Stephen Ingram wrote: >>>> >>>> I'm using IPA 3.0.x on RHEL 6.4 and trying to setup other zones in DNS. >>>>> I >>>>> notice that regardless of the TTL set in the SOA for the zone, the >>>>> individual records default to 86400. I see there has been previous >>>>> discussion on the list ( >>>>> https://www.redhat.com/****archives/freeipa-users/2012-** >>>>> November/msg00158.html>>>> freeipa-users/2012-November/**msg00158.html >>>>>> >>>>> >>>>> ) >>>>> saying that the 86400 value is hard-coded into bind-dyndb-ldap. It >>>>> appears >>>>> as though it might be rectified sometime in the 3.3.x series, however, >>>>> I'm >>>>> wondering if there is a workaround for now. Is there a way to just >>>>> delete >>>>> this value such that the individual records will default to the value in >>>>> the SOA until a real fix comes along? >>>>> >>>>> >>>> For now, the only workaround is to set TTL explicitly for all affected >>>> DNS >>>> names. Sorry! >>>> >>>> $ ipa dnsrecord-mod --help | grep ttl >>>> --ttl=INT Time to live >>>> >>>> The most important thing is that SOA TTL is not related to default record >>>> TTL by definition. >>>> >>>> Some details are described here: >>>> https://www.redhat.com/****archives/freeipa-users/2012-** >>>> November/msg00160.html>>> freeipa-users/2012-November/**msg00160.html >>>>> >>>> >>> >>> >>> Am I reading this correctly then that you have to set for each *record* vs >>> >> I really meant *name*. "ipa dnsrecord-mod" operates on whole DNS name. (It >> also means that all records under single *name* share the same TTL value.) > > > That's what I thought. I was referring to a name as a record. > > >> the *zone*. If so, this makes the DNS part of IPA almost unusable except >>> to >>> those willing to stick with the default 86400 or write a script to handle >>> each record in the zone. I've been following the list for some time, but >>> haven't heard much about usage of the DNS component. And, among the users >>> I >>> speak with no one uses the DNS component. Perhaps this is the reason why? >>> I >>> >> Up to now, nobody have told us that 'DNS part of IPA almost unusable' >> without configuration option for default TTL, so it simply didn't get the >> priority. We have seen stroger demand for DNS views, for example :-) > > > Understood. Perhaps my use case is different than most. If I were using > scripts, I don't think this would be much of an issue, however, with > several UI users with varying levels of experience, it is difficult if you > want to vary TTL per zone instead of per name. After reading the RFC > referenced in the ticket I see now that the default TTL I was thinking was > part of the SOA is actually a separate entity. And, thus, I now see why IPA > needs to also make this distinction. > >> >> haven't looked at the code yet, but would this be that difficult to fix? >>> I >>> >> If you are okay with statically configured TTL for all zones, then it is >> five-minute fix. (Simply change the current value and recompile or add a >> new parameter to /etc/named.conf.) >> > Could you please point me to the code where this static definition happens? Sure, look for "86400" in the sources :-) Now seriously, you can change "#define DEFAULT_TTL 86400" in file src/ldap_entry.c and recompile the plugin. >> If you want to define default TTL per-zone in LDAP, then you have to >> define new attribute in LDAP schema, store the default TTL value in >> zone_register and push it to record parser as necessary. >> >> In https://fedorahosted.org/bind-**dyndb-ldap/ticket/70#comment:7you can see that we are trying to cooperate with schema/OID space owner to >> find & standardize some solution. >> >> Any contribution is more than welcome! Join us in the ticket and we can >> discuss various propsals. > > > I see now why this is not a quick solution. I was unaware that the > attribute to handle this default TTL didn't exist. It looks there are two > ideas on the table (JHogarth and JCholasta) right now. But, from the ticket > discussion, it looks like maybe the new attribute is being added instead > and already in progress? Yes, it is. We are trying to reach mutual agreement with schema/OID space owner. -- Petr^2 Spacek From pspacek at redhat.com Tue Oct 22 07:29:26 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 22 Oct 2013 09:29:26 +0200 Subject: [Freeipa-users] DNS views: request for comments In-Reply-To: <52657CD1.7080801@redhat.com> References: <524AE614.8090808@redhat.com> <52655AE2.7010207@redhat.com> <52657CD1.7080801@redhat.com> Message-ID: <52662956.3050904@redhat.com> On 21.10.2013 21:13, Dmitri Pal wrote: > On 10/21/2013 12:48 PM, Petr Spacek wrote: >> On 1.10.2013 17:11, Petr Spacek wrote: >>> Hello list, >>> >>> we would like to get more details about DNS views and how you use >>> them in real >>> life. Also, any idea how user a interface should work is more than >>> welcome! >>> >>> (If you don't know views, read it as "differentiate answer to a DNS >>> query on >>> client's IP address basics".) >>> >>> >>> Questions are: >>> - For what purpose do you use views? >>> E.g. handling clients inside/outside of company network (e.g. hiding >>> internal >>> names); Selecting nearest server in a big network; Some other weird >>> 'Cloud' >>> scenarios etc. etc. >>> >>> - How many views do you use? >>> >>> - Do you share some data between views? How did you solve that? Do >>> you use >>> some user interface for that? >>> >>> - Do you use DNS updates? (nsupdate/RFC 2136/RFC 3007) >>> >>> Previous discussions about DNS views: >>> https://www.redhat.com/archives/freeipa-users/2012-April/msg00070.html >>> https://www.redhat.com/archives/freeipa-devel/2012-May/msg00208.html >>> >>> Related tickets & bugs: >>> https://fedorahosted.org/freeipa/ticket/2802 >>> https://bugzilla.redhat.com/show_bug.cgi?id=815621 >>> https://fedorahosted.org/freeipa/ticket/3725 >>> https://fedorahosted.org/bind-dyndb-ldap/ticket/69 >>> >>> >>> The next step will be to design LDAP schema for DNS data with views ... >>> >>> I can see three basic options: >>> >>> 1) Resign from any data sharing, which will make the thing pretty >>> easy :-) >>> In that case 'view1' will be represented by one sub-tree in LDAP, >>> 'view2' will >>> be another sub-tree etc. >>> >>> 2) Select one sub-tree which will be 'the base' containing all shared >>> records. >>> All other views will inherit and override data from the shared 'base'. >>> >>> 3) Make it as general as possible and allow multiple levels of >>> inheritance. >>> View3 inherits from View2 and it inherits from Base. >>> (View3 <- View2 <- Base) >>> >>> It is basically generalized variant (2), but it could require >>> different LDAP >>> schema. >>> >>> >>> Please post your opinions! >> >> I spent some time investigating how DNS views work in various DNS >> servers. I hope that it will help us to find some balance between real >> world requirements and complexity. >> >> The next section discusses possible LDAP schema and semantics for our >> DNS views implementation. Feel free to jump directly to the proposal >> if you have some particular idea how it should work. >> >> >> Support for DNS views in server software >> ======================================== >> I have tried to find how widely DNS views are supported by various >> software packages. >> >> Open Source software >> -------------------- >> PowerDNS >> - only specialized backend for Geo->something mapping >> - no inheritance >> - no dynamic updates >> - >> http://wiki.powerdns.com/trac/browser/trunk/pdns/modules/geobackend/README >> >> Djbdns/tinydns >> - no inheritance >> - non-standard dynamic updates (?? via external tools, I'm not 100 % >> sure) >> - can differentiate answers on IP-prefix basics: >> http://cr.yp.to/djbdns/tinydns-data.html (search for "ipprefix") >> >> Dnsmasq >> - subnet-based selection for A records only (based on client's subnet) >> - no inheritance >> - dynamic update only from built-in DHCP server >> http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html (see option >> --localise-queries) >> >> >> BIND 9 >> - full support for DNS views >> - each view can be totally independent on other views >> - inheritance is done via $INCLUDE directive in zone file >> - in any case, a update affects only DNS view where the update was >> received >> - limitations: >> -- inherited data can be modified only via addition; >> modification/deletion to the inherited data is not possible (you have >> to break inheritance if you have to modify/delete inherited data) >> -- any dynamic update breaks inheritance >> >> BIND 9 examples: >> Example external view is subset of company-internal view. >> >> zone file external.db: >> mail A 192.0.2.1 >> >> zone file internal.db: >> $INCLUDE external.db >> shell A 10.1.2.3 >> >> Imagine that internal view was updated via DNS update, a record for >> name "git" was added. The resulting zone file internal.db will look like: >> git A 10.3.3.33 >> mail A 192.0.2.1 >> shell A 10.1.1.1 >> >> You can see that inheritance from the external view was broken and all >> records from external view were copied to the internal view. >> >> It is possible to use multiple levels of $INCLUDE, but then thigs >> become twisted. >> >> >> Proprietary software >> -------------------- >> Simple DNS Plus >> - only special handling "for NAT": >> "In DNS responses to DNS requests from LAN clients only, this function >> changes host records which are pointing to a public IP address of the >> NAT router to point to the corresponding private IP address of a local >> server." >> - http://www.simpledns.com/help/v52/wd_opt_dnsnatlan.htm >> >> InfoBlox >> - full support for DNS views >> - each view can be totally independent on other views >> - DNS object hierarchy: >> 1. one view = set of zones >> 2. one zone = set of records + set of shared record groups >> 3. shared record group = set of records shared between DNS zones >> - inheritance is realized via "Shared Record Groups" (see page 465): >> -- records are grouped to named group called "Shared Record Group" >> -- the group is associated with one or more DNS *zones* >> -- there is single-level inheritance only >> -- E.g. the same set of MX records can be present in DNS zone >> example.com and eshop.example.com. I.e. mail server addresses are >> managed from single place, it is not necessary to change MX records >> separelly for example.com and eshop.example.com. >> -- In case of FreeIPA it could be group of all SRV or NS records so >> all records for a new replica have to be created only on single place >> and the change will affect all FreeIPA-managed DNS zones. >> - only one DNS view can receive the dynamic DNS updates (page 388) >> - it is unclear if the same limitations for inheritance apply or not >> - >> http://dloads.infoblox.com/direct/appliance/NIOS/NIOS_AdminGuide_6.5.pdf >> >> Nominum Vantio >> - caching only (I guess) - listed as an extreme example >> - there is not much public details about that, but this is what they >> claim: >> "Lightweight Views take the ?view? concept of the server to >> the ultimate extent, where each individual user can have their own >> view. Policies defining how queries are handled can be applied to each >> view, effectively enabling a personal Internet for each subscriber." >> - http://nominum.com/assets/Documents/Datasheets/vantio-datasheet.pdf >> >> >> Proposal - variant A ("classical" views) >> ==================== >> - keep it simple :-) >> - single level inheritance, all views inherit from 'base' (Base is our >> current cn=dns subtree, so old and new plugins can co-exist. The base >> can be empty.) >> - the data in views can be modified via DNS updates, a change done to >> inherited data creates an override (BIND9 does the same): e.g. name >> 'r1.z.' is shared between View1 and View2. Value change in View1 >> doesn't affect View2. >> - particular record from the 'base' can be overriden >> (deleted/replaced) in any view >> - changes done to the base are propagated to all views >> >> LDAP schema >> ----------- >> My goal is to maintain 1:1 mapping between "name+view" pair and LDAP >> DN. This is crucial for DNS updates. The other option is to maintain >> some 'record->LDAP DN database' or do a LDAP search before each DNS >> update - I would like to avoid that. >> >> Each view is stored as separate object under cn=dns. >> DN: idnsView=view1, cn=dns >> - this object stores settings specific to particular view (allowed >> clients, recursion ...) >> >> Zone in particular view is stored inside view container: >> DN: idnsName=zone1, idnsView=view1, dn=dns >> - this object can be empty container >> - attributes without explicit configuration are inherited from the base >> - a zone doesn't appear in the DNS view if the container is not >> present (i.e. it is possible to hide the zone from particular view) >> >> 'Override' records for particular name in zone and view are stored as: >> DN: idnsName=name1, idnsName=zone1, idnsView=view1, cn=dns >> - values added on top of inherited set are represented as normal DNS >> attributes: e.g. aRecord: 192.0.2.1 >> - values deleted from inherited set - *are open question*: It would be >> great if we could store it under the same object as additions, it >> would make implementation a bit simpler. >> - Would it be acceptable to store override 'delete TXT record "hello"' >> as attribute 'tXTRecord;x-deleted: test'? >> - The other option is to store deleted attributes in separate object: >> DN: cn=deleted, idnsName=record1, idnsName=zone1, idnsView=view1, cn=dns >> >> >> Proposal - variant B (shared record groups) >> ==================== >> - not so simple to implement, especially update-performance could be >> an issue >> - multiple zones can share the same record group >> - each view can contain arbitrary zones anf those zones can inherit >> arbitrary record groups - inheritance is fully configurable >> - the data in views can be modified via DNS updates, a change done to >> inherited data creates an override (BIND9 does the same): e.g. name >> 'r1.z.' is shared between View1 and View2. Value change in View1 >> doesn't affect View2. >> - particular record from any shared record group can be overriden >> (deleted/replaced) in any zone in any view >> - changes done to the shared record group are propagated to all views >> (this is the hard part!) >> >> >> LDAP schema >> ----------- >> Group of shared records - container: >> DN: idnsRecordGroup=group1, cn=dns >> >> One shared name: >> DN: idnsName=record1, idnsRecordGroup=group1, cn=dns >> - contains DNS records for that name as usual >> >> Each view is stored as separate object under cn=dns. >> DN: idnsView=view1, cn=dns >> >> Zone in particular view is stored inside view container: >> DN: idnsName=zone1, idnsView=view1, dn=dns >> - zone has a attribute with DNs of inherited record groups >> >> 'Override' records for particular name in zone and view are stored as: >> DN: idnsName=name1, idnsName=zone1, idnsView=view1, cn=dns >> >> >> After each change to any data we have to compute new resulting value. >> It means to combine the data for particular name from all record >> groups and then apply overrides for particular instance. >> >> It means a lot of bookkeeping after each change ... >> >> >> Proposal - variant 0 >> ==================== >> Do not implement it in bind-dyndb-ldap and wait if Martin Basti >> succeeds with his thesis. He is trying to design and implement some >> generic/pluggable LDAP<->DNS synchronization mechanism. >> >> Personally, I think that variant "0" is the best one! :-D One of side >> effects is that our depedency on BIND 9 will be lowered and most of >> the work will be deferred to the real DNS server. >> > What is the time line for this thesis? It should be finished by the end of May 2014. (I assume the Martin^2 doesn't want to spent another year with this thesis ... :-)) -- Petr^2 Spacek From mbasti at redhat.com Tue Oct 22 08:20:36 2013 From: mbasti at redhat.com (Martin Basti) Date: Tue, 22 Oct 2013 10:20:36 +0200 Subject: [Freeipa-users] DNS views: request for comments In-Reply-To: <52657CD1.7080801@redhat.com> References: <524AE614.8090808@redhat.com> <52655AE2.7010207@redhat.com> <52657CD1.7080801@redhat.com> Message-ID: <1382430036.2237.11.camel@unused-4-145.brq.redhat.com> On Mon, 2013-10-21 at 15:13 -0400, Dmitri Pal wrote: > On 10/21/2013 12:48 PM, Petr Spacek wrote: > > On 1.10.2013 17:11, Petr Spacek wrote: > >> Hello list, > >> > >> we would like to get more details about DNS views and how you use > >> them in real > >> life. Also, any idea how user a interface should work is more than > >> welcome! > >> > >> (If you don't know views, read it as "differentiate answer to a DNS > >> query on > >> client's IP address basics".) > >> > >> > >> Questions are: > >> - For what purpose do you use views? > >> E.g. handling clients inside/outside of company network (e.g. hiding > >> internal > >> names); Selecting nearest server in a big network; Some other weird > >> 'Cloud' > >> scenarios etc. etc. > >> > >> - How many views do you use? > >> > >> - Do you share some data between views? How did you solve that? Do > >> you use > >> some user interface for that? > >> > >> - Do you use DNS updates? (nsupdate/RFC 2136/RFC 3007) > >> > >> Previous discussions about DNS views: > >> https://www.redhat.com/archives/freeipa-users/2012-April/msg00070.html > >> https://www.redhat.com/archives/freeipa-devel/2012-May/msg00208.html > >> > >> Related tickets & bugs: > >> https://fedorahosted.org/freeipa/ticket/2802 > >> https://bugzilla.redhat.com/show_bug.cgi?id=815621 > >> https://fedorahosted.org/freeipa/ticket/3725 > >> https://fedorahosted.org/bind-dyndb-ldap/ticket/69 > >> > >> > >> The next step will be to design LDAP schema for DNS data with views ... > >> > >> I can see three basic options: > >> > >> 1) Resign from any data sharing, which will make the thing pretty > >> easy :-) > >> In that case 'view1' will be represented by one sub-tree in LDAP, > >> 'view2' will > >> be another sub-tree etc. > >> > >> 2) Select one sub-tree which will be 'the base' containing all shared > >> records. > >> All other views will inherit and override data from the shared 'base'. > >> > >> 3) Make it as general as possible and allow multiple levels of > >> inheritance. > >> View3 inherits from View2 and it inherits from Base. > >> (View3 <- View2 <- Base) > >> > >> It is basically generalized variant (2), but it could require > >> different LDAP > >> schema. > >> > >> > >> Please post your opinions! > > > > I spent some time investigating how DNS views work in various DNS > > servers. I hope that it will help us to find some balance between real > > world requirements and complexity. > > > > The next section discusses possible LDAP schema and semantics for our > > DNS views implementation. Feel free to jump directly to the proposal > > if you have some particular idea how it should work. > > > > > > Support for DNS views in server software > > ======================================== > > I have tried to find how widely DNS views are supported by various > > software packages. > > > > Open Source software > > -------------------- > > PowerDNS > > - only specialized backend for Geo->something mapping > > - no inheritance > > - no dynamic updates > > - > > http://wiki.powerdns.com/trac/browser/trunk/pdns/modules/geobackend/README > > > > Djbdns/tinydns > > - no inheritance > > - non-standard dynamic updates (?? via external tools, I'm not 100 % > > sure) > > - can differentiate answers on IP-prefix basics: > > http://cr.yp.to/djbdns/tinydns-data.html (search for "ipprefix") > > > > Dnsmasq > > - subnet-based selection for A records only (based on client's subnet) > > - no inheritance > > - dynamic update only from built-in DHCP server > > http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html (see option > > --localise-queries) > > > > > > BIND 9 > > - full support for DNS views > > - each view can be totally independent on other views > > - inheritance is done via $INCLUDE directive in zone file > > - in any case, a update affects only DNS view where the update was > > received > > - limitations: > > -- inherited data can be modified only via addition; > > modification/deletion to the inherited data is not possible (you have > > to break inheritance if you have to modify/delete inherited data) > > -- any dynamic update breaks inheritance > > > > BIND 9 examples: > > Example external view is subset of company-internal view. > > > > zone file external.db: > > mail A 192.0.2.1 > > > > zone file internal.db: > > $INCLUDE external.db > > shell A 10.1.2.3 > > > > Imagine that internal view was updated via DNS update, a record for > > name "git" was added. The resulting zone file internal.db will look like: > > git A 10.3.3.33 > > mail A 192.0.2.1 > > shell A 10.1.1.1 > > > > You can see that inheritance from the external view was broken and all > > records from external view were copied to the internal view. > > > > It is possible to use multiple levels of $INCLUDE, but then thigs > > become twisted. > > > > > > Proprietary software > > -------------------- > > Simple DNS Plus > > - only special handling "for NAT": > > "In DNS responses to DNS requests from LAN clients only, this function > > changes host records which are pointing to a public IP address of the > > NAT router to point to the corresponding private IP address of a local > > server." > > - http://www.simpledns.com/help/v52/wd_opt_dnsnatlan.htm > > > > InfoBlox > > - full support for DNS views > > - each view can be totally independent on other views > > - DNS object hierarchy: > > 1. one view = set of zones > > 2. one zone = set of records + set of shared record groups > > 3. shared record group = set of records shared between DNS zones > > - inheritance is realized via "Shared Record Groups" (see page 465): > > -- records are grouped to named group called "Shared Record Group" > > -- the group is associated with one or more DNS *zones* > > -- there is single-level inheritance only > > -- E.g. the same set of MX records can be present in DNS zone > > example.com and eshop.example.com. I.e. mail server addresses are > > managed from single place, it is not necessary to change MX records > > separelly for example.com and eshop.example.com. > > -- In case of FreeIPA it could be group of all SRV or NS records so > > all records for a new replica have to be created only on single place > > and the change will affect all FreeIPA-managed DNS zones. > > - only one DNS view can receive the dynamic DNS updates (page 388) > > - it is unclear if the same limitations for inheritance apply or not > > - > > http://dloads.infoblox.com/direct/appliance/NIOS/NIOS_AdminGuide_6.5.pdf > > > > Nominum Vantio > > - caching only (I guess) - listed as an extreme example > > - there is not much public details about that, but this is what they > > claim: > > "Lightweight Views take the ?view? concept of the server to > > the ultimate extent, where each individual user can have their own > > view. Policies defining how queries are handled can be applied to each > > view, effectively enabling a personal Internet for each subscriber." > > - http://nominum.com/assets/Documents/Datasheets/vantio-datasheet.pdf > > > > > > Proposal - variant A ("classical" views) > > ==================== > > - keep it simple :-) > > - single level inheritance, all views inherit from 'base' (Base is our > > current cn=dns subtree, so old and new plugins can co-exist. The base > > can be empty.) > > - the data in views can be modified via DNS updates, a change done to > > inherited data creates an override (BIND9 does the same): e.g. name > > 'r1.z.' is shared between View1 and View2. Value change in View1 > > doesn't affect View2. > > - particular record from the 'base' can be overriden > > (deleted/replaced) in any view > > - changes done to the base are propagated to all views > > > > LDAP schema > > ----------- > > My goal is to maintain 1:1 mapping between "name+view" pair and LDAP > > DN. This is crucial for DNS updates. The other option is to maintain > > some 'record->LDAP DN database' or do a LDAP search before each DNS > > update - I would like to avoid that. > > > > Each view is stored as separate object under cn=dns. > > DN: idnsView=view1, cn=dns > > - this object stores settings specific to particular view (allowed > > clients, recursion ...) > > > > Zone in particular view is stored inside view container: > > DN: idnsName=zone1, idnsView=view1, dn=dns > > - this object can be empty container > > - attributes without explicit configuration are inherited from the base > > - a zone doesn't appear in the DNS view if the container is not > > present (i.e. it is possible to hide the zone from particular view) > > > > 'Override' records for particular name in zone and view are stored as: > > DN: idnsName=name1, idnsName=zone1, idnsView=view1, cn=dns > > - values added on top of inherited set are represented as normal DNS > > attributes: e.g. aRecord: 192.0.2.1 > > - values deleted from inherited set - *are open question*: It would be > > great if we could store it under the same object as additions, it > > would make implementation a bit simpler. > > - Would it be acceptable to store override 'delete TXT record "hello"' > > as attribute 'tXTRecord;x-deleted: test'? > > - The other option is to store deleted attributes in separate object: > > DN: cn=deleted, idnsName=record1, idnsName=zone1, idnsView=view1, cn=dns > > > > > > Proposal - variant B (shared record groups) > > ==================== > > - not so simple to implement, especially update-performance could be > > an issue > > - multiple zones can share the same record group > > - each view can contain arbitrary zones anf those zones can inherit > > arbitrary record groups - inheritance is fully configurable > > - the data in views can be modified via DNS updates, a change done to > > inherited data creates an override (BIND9 does the same): e.g. name > > 'r1.z.' is shared between View1 and View2. Value change in View1 > > doesn't affect View2. > > - particular record from any shared record group can be overriden > > (deleted/replaced) in any zone in any view > > - changes done to the shared record group are propagated to all views > > (this is the hard part!) > > > > > > LDAP schema > > ----------- > > Group of shared records - container: > > DN: idnsRecordGroup=group1, cn=dns > > > > One shared name: > > DN: idnsName=record1, idnsRecordGroup=group1, cn=dns > > - contains DNS records for that name as usual > > > > Each view is stored as separate object under cn=dns. > > DN: idnsView=view1, cn=dns > > > > Zone in particular view is stored inside view container: > > DN: idnsName=zone1, idnsView=view1, dn=dns > > - zone has a attribute with DNs of inherited record groups > > > > 'Override' records for particular name in zone and view are stored as: > > DN: idnsName=name1, idnsName=zone1, idnsView=view1, cn=dns > > > > > > After each change to any data we have to compute new resulting value. > > It means to combine the data for particular name from all record > > groups and then apply overrides for particular instance. > > > > It means a lot of bookkeeping after each change ... > > > > > > Proposal - variant 0 > > ==================== > > Do not implement it in bind-dyndb-ldap and wait if Martin Basti > > succeeds with his thesis. He is trying to design and implement some > > generic/pluggable LDAP<->DNS synchronization mechanism. > > > > Personally, I think that variant "0" is the best one! :-D One of side > > effects is that our depedency on BIND 9 will be lowered and most of > > the work will be deferred to the real DNS server. > > > What is the time line for this thesis? > Hello, deadline is 2014-05-28. But I hope, I will have my thesis useful earlier. :) -- Martin Basti From rcritten at redhat.com Tue Oct 22 12:30:31 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 22 Oct 2013 08:30:31 -0400 Subject: [Freeipa-users] Failure decoding Certificate Signing Request In-Reply-To: <3fc2cb83-f64c-450b-a9d9-d4612966bbc1@S-ITSV-HUB01P.ead.ubc.ca> References: <3fc2cb83-f64c-450b-a9d9-d4612966bbc1@S-ITSV-HUB01P.ead.ubc.ca> Message-ID: <52666FE7.4060406@redhat.com> Thomson, Ryan wrote: > Hello FreeIPA users and developers, > > I'm facing a problem with expired certificates in FreeIPA. > > I have searched through the list archives and found advice to stop the IPA service, roll back the system clock to a time when the certs were valid but nearly expired, start IPA and then use certmonger to renew the certs as it normally should (getcert resubmit -i ). This appears to have worked as expected for the dogtag/CA certificates signed with the "dogtag-ipa-renew-agent" CA but is failing for the HTTP and dirsrv certificates signed with the "IPA" CA. > > Certmonger reports the following error (ipa-getcert list): > > Server failed request, will retry: 4301 (RPC failed at server. Certificate operation cannot be completed: Failure decoding Certificate Signing Request). > > I turned on IPA debugging to acquire the following error in /var/log/httpd/error_log when resubmitting to certmonger: > > [Mon Oct 07 00:03:22 2013] [error] ipa: DEBUG: WSGI wsgi_dispatch.__call__: > [Mon Oct 07 00:03:22 2013] [error] ipa: DEBUG: WSGI xmlserver.__call__: > [Mon Oct 07 00:03:22 2013] [error] ipa: DEBUG: Created connection context.ldap2 > [Mon Oct 07 00:03:22 2013] [error] ipa: DEBUG: WSGI WSGIExecutioner.__call__: > [Mon Oct 07 00:03:22 2013] [error] ipa: DEBUG: raw: cert_request(u'MIIDcDCCAlgCAQAwNjEUMBIGA1UEChMLRk1SSS5VQkMuQ0ExHjAcBgNVBAMTFXNoYW1yb2NrLmJyYWluLnViYy5jYTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKCzypT3oNmPx90Tevn/vv8FUouT8UL2d8qmhxK0AUVPxJwoZPtkbQBWzUNxkTBkhWV/5s0hN19VBb5ruHTbeSv7KBX8P+CwopQbbjpaqpwvi3dso1NSnT3kU+cNYY1j4tvyKkwPVS7FrP4oELX+aEEOuGF8eyOPK78UlZtDrY0Npje5l8MsUrRMKqQAjhIFc4EzTb2tqcR8Ch+OzBHugcFXcmXGmFnHkK29z2f7Aq1ynk0SqWC0r7nZXw/17jI1OEeD9pagGH1OLEzMrJUQTrvQGH/W+XPt2+ZvJ3UtF4ltw2ViStiG958b32OQvGnbQVJjaIgjpOSiorfnhM0wCPcCAwEAAaCB9DAaBgkqhkiG9w0BCRQxDRMLU2VydmVyLUNlcnQwgdUGCSqGSIb3DQEJDjGBxzCBxDAOBgNVHQ8BAQAEBAMCBPAwgZkGA1UdEQEBAASBjjCBi6A8BgorBgEEAYI3FAIDoC4MLGRvZ3RhZ2xkYXAvc2hhbXJvY2suYnJhaW4udWJjLmNhQEZNUkkuVUJDLkNBoEsGBisGAQUCAqBBMD+gDRsLRk1SSS5VQkMuQ0GhLjAsoAMCAQGhJTAjGwpkb2d0YWdsZGFwGxVzaGFtcm9jay5icmFpbi51YmMuY2EwFgYDVR0lAQEABAwwCgYIKwYBBQUHAwEwDQYJKoZIhvcNAQELBQADggEBAIP+0+O/COqFwbqUCJ+LJiE8aAmP01SRvfJx/RSE9huquDd2XdHVIQ6lQj6qnQYTtCw2NKRq77R3VmUAiCMp! Qw! > I9/x/QaaI4MBvV9iYA8b1H/weyvZAMw1mGkdgY55KWPhBtCqLuxHcGRblrtsy2PGp9wm/834s5YamQky+InQFlDy4o5ox+5U5iZS+pvKm52d0TQTozvZ/gSTAqEc+gpwlGAU4U0VaC+7PYnwkYJ98jLDaALm2OCWnSvw/02NLlc+h02mTjumAQ/YnWYNXiAtUbiA8BAkjT0UGV79Vi/aUKxpBTZQXbldrHN/cAmUtSMxebNNQjyUdzAHEV+TUUP2o=', principal=u'dogtagldap/HOSTNAME.DOMAIN at FULLY.QUALIFIED.DOMAIN', add=True) > [Mon Oct 07 00:03:22 2013] [error] ipa: DEBUG: cert_request(u'MIIDcDCCAlgCAQAwNjEUMBIGA1UEChMLRk1SSS5VQkMuQ0ExHjAcBgNVBAMTFXNoYW1yb2NrLmJyYWluLnViYy5jYTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKCzypT3oNmPx90Tevn/vv8FUouT8UL2d8qmhxK0AUVPxJwoZPtkbQBWzUNxkTBkhWV/5s0hN19VBb5ruHTbeSv7KBX8P+CwopQbbjpaqpwvi3dso1NSnT3kU+cNYY1j4tvyKkwPVS7FrP4oELX+aEEOuGF8eyOPK78UlZtDrY0Npje5l8MsUrRMKqQAjhIFc4EzTb2tqcR8Ch+OzBHugcFXcmXGmFnHkK29z2f7Aq1ynk0SqWC0r7nZXw/17jI1OEeD9pagGH1OLEzMrJUQTrvQGH/W+XPt2+ZvJ3UtF4ltw2ViStiG958b32OQvGnbQVJjaIgjpOSiorfnhM0wCPcCAwEAAaCB9DAaBgkqhkiG9w0BCRQxDRMLU2VydmVyLUNlcnQwgdUGCSqGSIb3DQEJDjGBxzCBxDAOBgNVHQ8BAQAEBAMCBPAwgZkGA1UdEQEBAASBjjCBi6A8BgorBgEEAYI3FAIDoC4MLGRvZ3RhZ2xkYXAvc2hhbXJvY2suYnJhaW4udWJjLmNhQEZNUkkuVUJDLkNBoEsGBisGAQUCAqBBMD+gDRsLRk1SSS5VQkMuQ0GhLjAsoAMCAQGhJTAjGwpkb2d0YWdsZGFwGxVzaGFtcm9jay5icmFpbi51YmMuY2EwFgYDVR0lAQEABAwwCgYIKwYBBQUHAwEwDQYJKoZIhvcNAQELBQADggEBAIP+0+O/COqFwbqUCJ+LJiE8aAmP01SRvfJx/RSE9huquDd2XdHVIQ6lQj6qnQYTtCw2NKRq77R3VmUAiCMpQwI9/! x/! > QaaI4MBvV9iYA8b1H/weyvZAMw1mGkdgY55KWPhBtCqLuxHcGRblrtsy2PGp9wm/834s5YamQky+InQFlDy4o5ox+5U5iZS+pvKm52d0TQTozvZ/gSTAqEc+gpwlGAU4U0VaC+7PYnwkYJ98jLDaALm2OCWnSvw/02NLlc+h02mTjumAQ/YnWYNXiAtUbiA8BAkjT0UGV79Vi/aUKxpBTZQXbldrHN/cAmUtSMxebNNQjyUdzAHEV+TUUP2o=', principal=u'dogtagldap/HOSTNAME.DOMAIN at FULLY.QUALIFIED.DOMAIN', request_type=u'pkcs10', add=True) > [Mon Oct 07 00:03:22 2013] [error] ipa: INFO: host/HOSTNAME.DOMAIN at FULLY.QUALIFIED.DOMAIN: cert_request(u'MIIDcDCCAlgCAQAwNjEUMBIGA1UEChMLRk1SSS5VQkMuQ0ExHjAcBgNVBAMTFXNoYW1yb2NrLmJyYWluLnViYy5jYTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKCzypT3oNmPx90Tevn/vv8FUouT8UL2d8qmhxK0AUVPxJwoZPtkbQBWzUNxkTBkhWV/5s0hN19VBb5ruHTbeSv7KBX8P+CwopQbbjpaqpwvi3dso1NSnT3kU+cNYY1j4tvyKkwPVS7FrP4oELX+aEEOuGF8eyOPK78UlZtDrY0Npje5l8MsUrRMKqQAjhIFc4EzTb2tqcR8Ch+OzBHugcFXcmXGmFnHkK29z2f7Aq1ynk0SqWC0r7nZXw/17jI1OEeD9pagGH1OLEzMrJUQTrvQGH/W+XPt2+ZvJ3UtF4ltw2ViStiG958b32OQvGnbQVJjaIgjpOSiorfnhM0wCPcCAwEAAaCB9DAaBgkqhkiG9w0BCRQxDRMLU2VydmVyLUNlcnQwgdUGCSqGSIb3DQEJDjGBxzCBxDAOBgNVHQ8BAQAEBAMCBPAwgZkGA1UdEQEBAASBjjCBi6A8BgorBgEEAYI3FAIDoC4MLGRvZ3RhZ2xkYXAvc2hhbXJvY2suYnJhaW4udWJjLmNhQEZNUkkuVUJDLkNBoEsGBisGAQUCAqBBMD+gDRsLRk1SSS5VQkMuQ0GhLjAsoAMCAQGhJTAjGwpkb2d0YWdsZGFwGxVzaGFtcm9jay5icmFpbi51YmMuY2EwFgYDVR0lAQEABAwwCgYIKwYBBQUHAwEwDQYJKoZIhvcNAQELBQADggEBAIP+0+O/COqFwbqUCJ+LJiE8aAmP01SRvfJx/RSE9huqu! Dd! > 2XdHVIQ6lQj6qnQYTtCw2NKRq77R3VmUAiCMpQwI9/x/QaaI4MBvV9iYA8b1H/weyvZAMw1mGkdgY55KWPhBtCqLuxHcGRblrtsy2PGp9wm/834s5YamQky+InQFlDy4o5ox+5U5iZS+pvKm52d0TQTozvZ/gSTAqEc+gpwlGAU4U0VaC+7PYnwkYJ98jLDaALm2OCWnSvw/02NLlc+h02mTjumAQ/YnWYNXiAtUbiA8BAkjT0UGV79Vi/aUKxpBTZQXbldrHN/cAmUtSMxebNNQjyUdzAHEV+TUUP2o=', principal=u'dogtagldap/HOSTNAME.DOMAIN at FULLY.QUALIFIED.DOMAIN', add=True): CertificateOperationError > [Mon Oct 07 00:03:22 2013] [error] ipa: DEBUG: response: CertificateOperationError: Certificate operation cannot be completed: Gettext('3 - Failure decoding Certificate Signing Request', domain='ipa', localedir=None) > [Mon Oct 07 00:03:22 2013] [error] ipa: DEBUG: no session id in request, generating empty session data with id=e943ef07ef510b4519a6f7658d96ae51 > [Mon Oct 07 00:03:22 2013] [error] ipa: DEBUG: store session: session_id=e943ef07ef510b4519a6f7658d96ae51 start_timestamp=2013-10-07T00:03:22 access_timestamp=2013-10-07T00:03:22 expiration_timestamp=1969-12-31T16:00:00 > [Mon Oct 07 00:03:22 2013] [error] ipa: DEBUG: finalize_kerberos_acquisition: xmlserver ccache_name="FILE:/tmp/krb5cc_apache_fWDfep" session_id="e943ef07ef510b4519a6f7658d96ae51" > [Mon Oct 07 00:03:22 2013] [error] ipa: DEBUG: reading ccache data from file "/tmp/krb5cc_apache_fWDfep" > [Mon Oct 07 00:03:22 2013] [error] ipa: DEBUG: get_credential_times: principal=krbtgt/FULLY.QUALIFIED.DOMAIN at FULLY.QUALIFIED.DOMAIN, authtime=10/07/13 00:03:22, starttime=10/07/13 00:03:22, endtime=10/08/13 00:03:22, renew_till=12/31/69 16:00:00 > [Mon Oct 07 00:03:22 2013] [error] ipa: DEBUG: KRB5_CCache FILE:/tmp/krb5cc_apache_fWDfep endtime=1381215802 (10/08/13 00:03:22) > [Mon Oct 07 00:03:22 2013] [error] ipa: DEBUG: set_session_expiration_time: duration_type=inactivity_timeout duration=1200 max_age=1381215502 expiration=1381130602.32 (2013-10-07T00:23:22) > [Mon Oct 07 00:03:22 2013] [error] ipa: DEBUG: store session: session_id=e943ef07ef510b4519a6f7658d96ae51 start_timestamp=2013-10-07T00:03:22 access_timestamp=2013-10-07T00:03:22 expiration_timestamp=2013-10-07T00:23:22 > [Mon Oct 07 00:03:22 2013] [error] ipa: DEBUG: Destroyed connection context.ldap2 > > I briefly spoke with Rob on #freeipa last week and he suggested trying to manually load the certificate signing request in a python shell, roughly as follows: > > from ipalib import pkcs10 > with open ("req.csr", "r") as myreq: > csr=myreq.read() > request = pkcs10.load_certificate_request(csr) > print request > print pkcs10.get_subject(request) > print pkcs10.get_subjectaltname(request) > > I was able to do this and see the CSR info on stdout, including subject and alt name. > > The system is RHEL6.4, fully updated as of today. > > Any ideas on where to go from here? > > --Ryan There is some duplication in the error strings (ticket https://fedorahosted.org/freeipa/ticket/3988). Did you add a number prefix to yours, I see a 3 -in the error. If so, by my calculation, this works out to be an NSPRError. It would be helpful to know what exception is being raised, which we don't do. Either way, if you could enhance each occurrence of 'Failure decoding Certificate Signing Request' in /usr/lib/python*/site-packages/ipalib/plugins/cert.py to something like: except NSPEError, nsprerr: raise errors.CertificateOperationError(error=_('Failure decoding Certificate Signing Request" %s') % nsprerr) You'll need to restart the httpd process afterwards. This should give us the real reason for the failure. This failure seems unrelated to the CSR itself, which looks fine. rob From bpk678 at gmail.com Tue Oct 22 14:26:14 2013 From: bpk678 at gmail.com (Brendan Kearney) Date: Tue, 22 Oct 2013 10:26:14 -0400 Subject: [Freeipa-users] No $ORIGIN directive in bind-dyndb-ldap Message-ID: <1382451974.19960.6.camel@desktop.bpk2.com> list, i am trying to setup BIND to use the DynDB LDAP backend, and have found that the $ORIGIN directive is not used or documented for use with the backend. the use case is the for the $ORIGIN directive is to handle unqualified queries. Below is an example of what happens without the $ORIGIN directive set in a zone: [brendan at test ~]$ nslookup server 127.0.0.1 Server: 127.0.0.1 Address: 127.0.0.1#53 ** server can't find server: SERVFAIL [brendan at test ~]$ nslookup server.my-domain.com 127.0.0.1 Server: 127.0.0.1 Address: 127.0.0.1#53 Name: server.my-domain.com Address: 192.168.1.1 the below is the BIND Admin Reference Manual entry for the $ORIGIN directive. The $ORIGIN Directive Syntax: $ORIGIN domain-name [comment] $ORIGIN sets the domain name that will be appended to any unqualified records. When a zone is first read in there is an implicit $ORIGIN . (followed by trailing dot). The current $ORIGIN is appended to the domain specified in the $ORIGIN argument if it is not absolute. $ORIGIN example.com. WWW CNAME MAIN-SERVER is equivalent to WWW.EXAMPLE.COM. CNAME MAIN-SERVER.EXAMPLE.COM. would a Request For Enhancement be needed or should a bug be filed for this missing functionality? thank you, brendan kearney From mkosek at redhat.com Tue Oct 22 14:44:12 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 22 Oct 2013 16:44:12 +0200 Subject: [Freeipa-users] DNS views: request for comments In-Reply-To: <1382389075.9794.15.camel@willson.li.ssimo.org> References: <524AE614.8090808@redhat.com> <52655AE2.7010207@redhat.com> <1382389075.9794.15.camel@willson.li.ssimo.org> Message-ID: <52668F3C.4010204@redhat.com> On 10/21/2013 10:57 PM, Simo Sorce wrote: > Comments inline. > > On Mon, 2013-10-21 at 18:48 +0200, Petr Spacek wrote: >> On 1.10.2013 17:11, Petr Spacek wrote: > > [trim] > >> Proposal - variant A ("classical" views) >> ==================== >> - keep it simple :-) >> - single level inheritance, all views inherit from 'base' (Base is our current >> cn=dns subtree, so old and new plugins can co-exist. The base can be empty.) >> - the data in views can be modified via DNS updates, a change done to >> inherited data creates an override (BIND9 does the same): e.g. name 'r1.z.' is >> shared between View1 and View2. Value change in View1 doesn't affect View2. >> - particular record from the 'base' can be overriden (deleted/replaced) in any >> view >> - changes done to the base are propagated to all views >> >> LDAP schema >> ----------- >> My goal is to maintain 1:1 mapping between "name+view" pair and LDAP DN. This >> is crucial for DNS updates. The other option is to maintain some 'record->LDAP >> DN database' or do a LDAP search before each DNS update - I would like to >> avoid that. >> >> Each view is stored as separate object under cn=dns. >> DN: idnsView=view1, cn=dns >> - this object stores settings specific to particular view (allowed clients, >> recursion ...) >> >> Zone in particular view is stored inside view container: >> DN: idnsName=zone1, idnsView=view1, dn=dns >> - this object can be empty container >> - attributes without explicit configuration are inherited from the base >> - a zone doesn't appear in the DNS view if the container is not present (i.e. >> it is possible to hide the zone from particular view) >> 'Override' records for particular name in zone and view are stored as: >> DN: idnsName=name1, idnsName=zone1, idnsView=view1, cn=dns > > Doesn't this scheme means you always have to do 2 searches ? One to find > if the object is in the view and one to the base ? > > We could use multivalued RDNs to achieve something similar but that will > require you only one search (assuming it matters). > >> - values added on top of inherited set are represented as normal DNS >> attributes: e.g. aRecord: 192.0.2.1 >> - values deleted from inherited set - *are open question*: It would be great >> if we could store it under the same object as additions, it would make >> implementation a bit simpler. >> - Would it be acceptable to store override 'delete TXT record "hello"' as >> attribute 'tXTRecord;x-deleted: test'? > > I think this would be acceptable, however what happens if then someone > deletes the base object and later on again recreates it ? > > Will the view still 'mask' it ? > Is this the actual desired outcome maybe ? > > Should we allow Dynamic Updates in Views at all ? > >> - The other option is to store deleted attributes in separate object: >> DN: cn=deleted, idnsName=record1, idnsName=zone1, idnsView=view1, cn=dns > > This sound cumbersome and require a 3rd search for every query, nack :) > > > I like variant A, I think it is the most sensible and the only one > really needed. People have an internal view and want to 'filter' it some > for the external world or similar. > > >> Proposal - variant B (shared record groups) >> ==================== >> - not so simple to implement, especially update-performance could be an issue >> - multiple zones can share the same record group >> - each view can contain arbitrary zones anf those zones can inherit arbitrary >> record groups - inheritance is fully configurable >> - the data in views can be modified via DNS updates, a change done to >> inherited data creates an override (BIND9 does the same): e.g. name 'r1.z.' is >> shared between View1 and View2. Value change in View1 doesn't affect View2. >> - particular record from any shared record group can be overriden >> (deleted/replaced) in any zone in any view >> - changes done to the shared record group are propagated to all views (this is >> the hard part!) > > Sound very complex not only to build, but to explain to admins as well, > is anyone actually going to need this level of complexity, what scenario > would really benefit from this that can't be done with A ? > > >> LDAP schema >> ----------- >> Group of shared records - container: >> DN: idnsRecordGroup=group1, cn=dns >> >> One shared name: >> DN: idnsName=record1, idnsRecordGroup=group1, cn=dns >> - contains DNS records for that name as usual >> >> Each view is stored as separate object under cn=dns. >> DN: idnsView=view1, cn=dns >> >> Zone in particular view is stored inside view container: >> DN: idnsName=zone1, idnsView=view1, dn=dns >> - zone has a attribute with DNs of inherited record groups >> >> 'Override' records for particular name in zone and view are stored as: >> DN: idnsName=name1, idnsName=zone1, idnsView=view1, cn=dns >> >> >> After each change to any data we have to compute new resulting value. It means >> to combine the data for particular name from all record groups and then apply >> overrides for particular instance. >> >> It means a lot of bookkeeping after each change ... >> >> >> Proposal - variant 0 >> ==================== >> Do not implement it in bind-dyndb-ldap and wait if Martin Basti succeeds with >> his thesis. He is trying to design and implement some generic/pluggable >> LDAP<->DNS synchronization mechanism. >> >> Personally, I think that variant "0" is the best one! :-D One of side effects >> is that our depedency on BIND 9 will be lowered and most of the work will be >> deferred to the real DNS server. > > > Synchronization is always very, very hard, especially when you throw in > the word 'generic'. Especially problematic are races. I would proceed > with A unless there is solid evidence this can work with all corner > cases and in a short period of time. > > Simo. I read all the proposals, I would personally stick with variant A as this is something that is doable in near future. Variant 0 seems a bit utopic to me, especially when speaking about synchronization corner cases. Martin's thesis may prove me wrong, we will see. Martin From pspacek at redhat.com Tue Oct 22 15:04:30 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 22 Oct 2013 17:04:30 +0200 Subject: [Freeipa-users] No $ORIGIN directive in bind-dyndb-ldap In-Reply-To: <1382451974.19960.6.camel@desktop.bpk2.com> References: <1382451974.19960.6.camel@desktop.bpk2.com> Message-ID: <526693FE.6080105@redhat.com> Hello! On 22.10.2013 16:26, Brendan Kearney wrote: > list, > > i am trying to setup BIND to use the DynDB LDAP backend, and have found > that the $ORIGIN directive is not used or documented for use with the > backend. > > the use case is the for the $ORIGIN directive is to handle unqualified > queries. Below is an example of what happens without the $ORIGIN > directive set in a zone: > > [brendan at test ~]$ nslookup server 127.0.0.1 > Server: 127.0.0.1 > Address: 127.0.0.1#53 > > ** server can't find server: SERVFAIL > > [brendan at test ~]$ nslookup server.my-domain.com 127.0.0.1 > Server: 127.0.0.1 > Address: 127.0.0.1#53 > > Name: server.my-domain.com > Address: 192.168.1.1 Could you please describe your configuration and what you are trying to achieve? I would like to see example zone file for BIND9 and description of desired outcome. Maybe that I'm wrong, but AFAIK $ORIGIN is just shorthand for use *inside* zone files. It has no effect outside zone parser: http://www.zytrax.com/books/dns/ch8/origin.html IMHO it does not affect query processing in any way. > the below is the BIND Admin Reference Manual entry for the $ORIGIN > directive. > > The $ORIGIN Directive > > Syntax: $ORIGIN domain-name [comment] > > $ORIGIN sets the domain name that will be appended to any unqualified > records. When a zone is first read in there is an implicit $ORIGIN > . (followed by trailing dot). The current $ORIGIN is appended > to the domain specified in the $ORIGIN argument if it is not absolute. > > $ORIGIN example.com. > WWW CNAME MAIN-SERVER > > is equivalent to > > WWW.EXAMPLE.COM. CNAME MAIN-SERVER.EXAMPLE.COM. > > would a Request For Enhancement be needed or should a bug be filed for this missing functionality? Please let us clarify what you are trying to achieve, then we can open RFE. Have a nice day! -- Petr^2 Spacek From mcaubet at pic.es Tue Oct 22 15:10:17 2013 From: mcaubet at pic.es (Marc Caubet) Date: Tue, 22 Oct 2013 17:10:17 +0200 Subject: [Freeipa-users] OpenLDAP+TLS to IPA Message-ID: Hi, we are trying to import user accounts from OpenLDAP+TLS service to IPA. Current ipa packages are: [root at ipa01 alias]# rpm -qa | grep ipa ipa-server-3.0.0-25.el6.x86_64 python-iniparse-0.3.1-2.1.el6.noarch ipa-pki-ca-theme-9.0.3-7.el6.noarch libipa_hbac-1.9.2-82.4.el6_4.x86_64 libipa_hbac-python-1.9.2-82.4.el6_4.x86_64 ipa-admintools-3.0.0-25.el6.x86_64 ipa-server-selinux-3.0.0-25.el6.x86_64 ipa-pki-common-theme-9.0.3-7.el6.noarch ipa-python-3.0.0-25.el6.x86_64 ipa-client-3.0.0-25.el6.x86_64 And we have started the process by configuring the IPA server and enabling migration as follows: ipa-server-install kinit admin ipa config-mod --enable-migration=TRUE But after this, we have problems when importing the LDAP information from ldap1-test.pic.es (which is the OpenLDAP+TLS server): [root at ipa01 alias]# ipa migrate-ds --bind-dn='cn=authenticate,ou=System,dc=pic,dc=es' --base-dn='dc=pic,dc=es' --user-container='ou=People,dc=pic,dc=es' --group-container='ou=Group,dc=pic,dc=es' ldap://ldap1-test.pic.es:389 Password: ipa: ERROR: Confidentiality required: confidentiality required [root at ipa01 alias]# ipa migrate-ds --bind-dn='cn=authenticate,ou=System,dc=pic,dc=es' --base-dn='dc=pic,dc=es' --user-container='ou=People,dc=pic,dc=es' --group-container='ou=Group,dc=pic,dc=es' ldaps://ldap1-test.pic.es Password: ipa: ERROR: cannot connect to u'ldaps://ldap1-test.pic.es': LDAP Server Down Both, 389 and 636 ports, are running and working and available for diferent clients. I also tried by importing the TLS certificate to the httpd service and restarting the services: certutil -A -d /etc/httpd/alias -n 'TERENASSLCA' -t CT,C,C -a < /etc/ssl/certs/TERENASSLCA.crt service httpd restart /etc/ssl/certs/TERENASSLCA.crt is the certificate used in all server machines accessing to the LDAP service, so the one configured in the OpenLDAP+TLS server. Any idea what's wrong? How can I import OpenLDAP+TLS accounts to IPA? Thanks a lot and best regards, -- Marc Caubet Serrabou PIC (Port d'Informaci? Cient?fica) Campus UAB, Edificio D E-08193 Bellaterra, Barcelona Tel: +34 93 581 33 22 Fax: +34 93 581 41 10 http://www.pic.es Avis - Aviso - Legal Notice: http://www.ifae.es/legal.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue Oct 22 15:36:42 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 22 Oct 2013 11:36:42 -0400 Subject: [Freeipa-users] OpenLDAP+TLS to IPA In-Reply-To: References: Message-ID: <52669B8A.10209@redhat.com> Marc Caubet wrote: > Hi, > > we are trying to import user accounts from OpenLDAP+TLS service to IPA. > > Current ipa packages are: > > [root at ipa01 alias]# rpm -qa | grep ipa > ipa-server-3.0.0-25.el6.x86_64 > python-iniparse-0.3.1-2.1.el6.noarch > ipa-pki-ca-theme-9.0.3-7.el6.noarch > libipa_hbac-1.9.2-82.4.el6_4.x86_64 > libipa_hbac-python-1.9.2-82.4.el6_4.x86_64 > ipa-admintools-3.0.0-25.el6.x86_64 > ipa-server-selinux-3.0.0-25.el6.x86_64 > ipa-pki-common-theme-9.0.3-7.el6.noarch > ipa-python-3.0.0-25.el6.x86_64 > ipa-client-3.0.0-25.el6.x86_64 > > And we have started the process by configuring the IPA server and > enabling migration as follows: > > ipa-server-install > kinit admin > ipa config-mod --enable-migration=TRUE > > But after this, we have problems when importing the LDAP information > from ldap1-test.pic.es (which is the > OpenLDAP+TLS server): > > [root at ipa01 alias]# ipa migrate-ds > --bind-dn='cn=authenticate,ou=System,dc=pic,dc=es' > --base-dn='dc=pic,dc=es' --user-container='ou=People,dc=pic,dc=es' > --group-container='ou=Group,dc=pic,dc=es' ldap://ldap1-test.pic.es:389 > > Password: > ipa: ERROR: Confidentiality required: confidentiality required > > [root at ipa01 alias]# ipa migrate-ds > --bind-dn='cn=authenticate,ou=System,dc=pic,dc=es' > --base-dn='dc=pic,dc=es' --user-container='ou=People,dc=pic,dc=es' > --group-container='ou=Group,dc=pic,dc=es' ldaps://ldap1-test.pic.es > > Password: > ipa: ERROR: cannot connect to u'ldaps://ldap1-test.pic.es > ': LDAP Server Down > > Both, 389 and 636 ports, are running and working and available for > diferent clients. > > I also tried by importing the TLS certificate to the httpd service and > restarting the services: > > certutil -A -d /etc/httpd/alias -n 'TERENASSLCA' -t CT,C,C -a < > /etc/ssl/certs/TERENASSLCA.crt > service httpd restart > > /etc/ssl/certs/TERENASSLCA.crt is the certificate used in all server > machines accessing to the LDAP service, so the one configured in the > OpenLDAP+TLS server. > > Any idea what's wrong? How can I import OpenLDAP+TLS accounts to IPA? > > Thanks a lot and best regards, The ldap library is returning LDAP_SERVER_DOWN which is a basic connectivity problem, though I suppose it could be masking an SSL connection issue. You might want to try: LDAPTLS_CACERT=/etc/ssl/certs/TERENASSLCA.crt ldapsearch -x -H ldaps://ldap1-test.pic.es -b ou=System,dc=pic,dc=es cn=authenticate Another option would be to check the OpenLDAP logs to see it if is rejecting a connection from the IPA server. rob From pspacek at redhat.com Tue Oct 22 16:14:51 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 22 Oct 2013 18:14:51 +0200 Subject: [Freeipa-users] DNS views: request for comments In-Reply-To: <52668F3C.4010204@redhat.com> References: <524AE614.8090808@redhat.com> <52655AE2.7010207@redhat.com> <1382389075.9794.15.camel@willson.li.ssimo.org> <52668F3C.4010204@redhat.com> Message-ID: <5266A47B.4000203@redhat.com> On 22.10.2013 16:44, Martin Kosek wrote: > On 10/21/2013 10:57 PM, Simo Sorce wrote: >> Comments inline. >> >> On Mon, 2013-10-21 at 18:48 +0200, Petr Spacek wrote: >>> On 1.10.2013 17:11, Petr Spacek wrote: >> >> [trim] I should make one thing clear: We already do two-way synchronization between LDAP and DNS server (run-time). Persistent search (and now syncrepl) dumps content of LDAP database to a internal database in DNS server and the bind-dyndb-ldap plugin operates on this internal database. I.e. changes done in LDAP are asynchronously applied to internal database and vice versa, changes done via DNS protocol are written back to LDAP. This is why we are able to apply any change in LDAP almost immediatelly to DNS data. It is true that there are nasty corner cases, but up to now we didn't receive many complains about data inconsistency. (This will change after the major refactoring in bind-dyndb-ldap 4.0 :-)) >>> Proposal - variant A ("classical" views) >>> ==================== >>> - keep it simple :-) >>> - single level inheritance, all views inherit from 'base' (Base is our current >>> cn=dns subtree, so old and new plugins can co-exist. The base can be empty.) >>> - the data in views can be modified via DNS updates, a change done to >>> inherited data creates an override (BIND9 does the same): e.g. name 'r1.z.' is >>> shared between View1 and View2. Value change in View1 doesn't affect View2. >>> - particular record from the 'base' can be overriden (deleted/replaced) in any >>> view >>> - changes done to the base are propagated to all views >>> >>> LDAP schema >>> ----------- >>> My goal is to maintain 1:1 mapping between "name+view" pair and LDAP DN. This >>> is crucial for DNS updates. The other option is to maintain some 'record->LDAP >>> DN database' or do a LDAP search before each DNS update - I would like to >>> avoid that. >>> >>> Each view is stored as separate object under cn=dns. >>> DN: idnsView=view1, cn=dns >>> - this object stores settings specific to particular view (allowed clients, >>> recursion ...) >>> >>> Zone in particular view is stored inside view container: >>> DN: idnsName=zone1, idnsView=view1, dn=dns >>> - this object can be empty container >>> - attributes without explicit configuration are inherited from the base >>> - a zone doesn't appear in the DNS view if the container is not present (i.e. >>> it is possible to hide the zone from particular view) >>> 'Override' records for particular name in zone and view are stored as: >>> DN: idnsName=name1, idnsName=zone1, idnsView=view1, cn=dns >> >> Doesn't this scheme means you always have to do 2 searches ? One to find >> if the object is in the view and one to the base ? >> >> We could use multivalued RDNs to achieve something similar but that will >> require you only one search (assuming it matters). Reading = 0 searches :-D Psearch/SyncRepl delivers the data from LDAP asynchronously to the plugin, almost immediatelly after each change in LDAP. >>> - values added on top of inherited set are represented as normal DNS >>> attributes: e.g. aRecord: 192.0.2.1 >>> - values deleted from inherited set - *are open question*: It would be great >>> if we could store it under the same object as additions, it would make >>> implementation a bit simpler. >>> - Would it be acceptable to store override 'delete TXT record "hello"' as >>> attribute 'tXTRecord;x-deleted: test'? >> >> I think this would be acceptable, however what happens if then someone >> deletes the base object and later on again recreates it ? >> >> Will the view still 'mask' it ? My original idea was: "Yes, it will." The main reason is that user can have some tools which do LDAP delete/add instead of replace/modify, so some data from the base could be accidentally exposed if we delete 'override' automatically with base object. >> Is this the actual desired outcome maybe ? This is a good question :-) This is most generic/powerful mechanism but it could create some nasty surprises. One drawback is that you have to go and add 'mask'/'delete' record to affected views (if necessary) when you add a record to the base. Another variants: aa) Do overrides on name-level instead of record level. I.e. records for particular name will not be inherited if the override is present. Example: Base definition: - gateway.example.com. A 203.0.113.66 - gateway.example.com. TXT "this record came from base" - example.com MX 10 gateway.example.com. View definition: - gateway.example.com. A 10.1.1.1 Result - view: - gateway.example.com. A 10.1.1.1 - example.com MX 10 gateway.example.com. => A and TXT records from base were not inherited because override for the name 'gateway' was present in the view. => MX record for name 'example.com' was inherited because there is no override with this name in the view. => Modification done in 'base' will not affect view in any way if the override is present, so there can't be information leak. => This approach doesn't require ;x-deleted or cn=deleted trick. ab) No inheritance at all. This is what BIND9 does if dynamic updates are enabled. After first update the inheritance relationship is broken and views operate independently. Obviously, this is simplest and clearest solution. Maybe that it is enough for most users, look at the support in open source software ... Maybe that some UI support for copying from one view to the other would be enough? >> Should we allow Dynamic Updates in Views at all ? It would be too simple without dynamic updates :-) I think that we should allow updates, otherwise we can drop all the code for DNS updates from SSSD, ipa-client-install etc. Of course, we can implement first version without support for updates and add it later, if there is a demand. We just need to keep it in mind during design. >>> - The other option is to store deleted attributes in separate object: >>> DN: cn=deleted, idnsName=record1, idnsName=zone1, idnsView=view1, cn=dns >> >> This sound cumbersome and require a 3rd search for every query, nack :) Again, 0 searches because of syncrepl :-) >> I like variant A, I think it is the most sensible and the only one >> really needed. People have an internal view and want to 'filter' it some >> for the external world or similar. >> >> >>> Proposal - variant B (shared record groups) >>> ==================== >>> - not so simple to implement, especially update-performance could be an issue >>> - multiple zones can share the same record group >>> - each view can contain arbitrary zones anf those zones can inherit arbitrary >>> record groups - inheritance is fully configurable >>> - the data in views can be modified via DNS updates, a change done to >>> inherited data creates an override (BIND9 does the same): e.g. name 'r1.z.' is >>> shared between View1 and View2. Value change in View1 doesn't affect View2. >>> - particular record from any shared record group can be overriden >>> (deleted/replaced) in any zone in any view >>> - changes done to the shared record group are propagated to all views (this is >>> the hard part!) >> >> Sound very complex not only to build, but to explain to admins as well, >> is anyone actually going to need this level of complexity, what scenario >> would really benefit from this that can't be done with A ? I can see one use case: Domains 'flower-eshop.com' and 'parfums-eshop.com' are hosted in 'data centre 1', while domains 'car-eshop.com' and 'software-eshop.com' are hosted in 'data centre 2'. Typically it means that sites in one DC/group share the same set of NS records, MX records etc. So the admin will define record group "DC1": NS ns1.dc1.examplewebhoster.com. NS ns2.backup.examplewebhoster.com. MX 10 mx1.dc1.examplewebhoster.com. MX 20 mx1.dc2.examplewebhoster.com. Record group "DC2": NS ns1.dc2.examplewebhoster.com. NS ns1.backup.examplewebhoster.com. MX 20 mx1.dc1.examplewebhoster.com. MX 10 mx1.dc2.examplewebhoster.com. Now record group DC1 is assigned to servers hosted at DC1 and so on. Result = new mail server for DC1 has to be added to single place (the record group DC1) and all domains hosted at DC1 will automagically pick up the new server. So you don't need to construct cycles over all servers in DC1, modify each record by hand etc. This sounds nice 'on the paper', but I don't know how big the real demand is ... >>> LDAP schema >>> ----------- >>> Group of shared records - container: >>> DN: idnsRecordGroup=group1, cn=dns >>> >>> One shared name: >>> DN: idnsName=record1, idnsRecordGroup=group1, cn=dns >>> - contains DNS records for that name as usual >>> >>> Each view is stored as separate object under cn=dns. >>> DN: idnsView=view1, cn=dns >>> >>> Zone in particular view is stored inside view container: >>> DN: idnsName=zone1, idnsView=view1, dn=dns >>> - zone has a attribute with DNs of inherited record groups >>> >>> 'Override' records for particular name in zone and view are stored as: >>> DN: idnsName=name1, idnsName=zone1, idnsView=view1, cn=dns >>> >>> >>> After each change to any data we have to compute new resulting value. It means >>> to combine the data for particular name from all record groups and then apply >>> overrides for particular instance. >>> >>> It means a lot of bookkeeping after each change ... >>> >>> >>> Proposal - variant 0 >>> ==================== >>> Do not implement it in bind-dyndb-ldap and wait if Martin Basti succeeds with >>> his thesis. He is trying to design and implement some generic/pluggable >>> LDAP<->DNS synchronization mechanism. >>> >>> Personally, I think that variant "0" is the best one! :-D One of side effects >>> is that our depedency on BIND 9 will be lowered and most of the work will be >>> deferred to the real DNS server. >> >> >> Synchronization is always very, very hard, especially when you throw in >> the word 'generic'. Especially problematic are races. I would proceed >> with A unless there is solid evidence this can work with all corner >> cases and in a short period of time. >> >> Simo. > > > I read all the proposals, I would personally stick with variant A as this is > something that is doable in near future. Variant 0 seems a bit utopic to me, One year, may be. Views are pretty complex thing - don't forget to integration with DNSSEC ... > especially when speaking about synchronization corner cases. Martin's thesis Please see the note at the beginning of my e-mail. We already do two-way synchronization in bind-dyndb-ldap. > may prove me wrong, we will see. Sure. Stand-alone daemon usually has some specific problems which are not so problematic for plug-ins, we will see. -- Petr^2 Spacek From ryan.thomson at ubc.ca Tue Oct 22 15:58:25 2013 From: ryan.thomson at ubc.ca (Thomson, Ryan) Date: Tue, 22 Oct 2013 15:58:25 +0000 Subject: [Freeipa-users] Failure decoding Certificate Signing Request In-Reply-To: <52666FE7.4060406@redhat.com> References: <3fc2cb83-f64c-450b-a9d9-d4612966bbc1@S-ITSV-HUB01P.ead.ubc.ca> <52666FE7.4060406@redhat.com> Message-ID: <4236DE1EFED4374EA69B197EB5AC275735147A7B@S-ITSV-MBX02P.ead.ubc.ca> Hi Rob, > There is some duplication in the error strings (ticket > https://fedorahosted.org/freeipa/ticket/3988). Did you add a number prefix > to yours, I see a 3 -in the error. If so, by my calculation, this works out to be > an NSPRError. It would be helpful to know what exception is being raised, > which we don't do. I did prefix numbers to the various error strings. > Either way, if you could enhance each occurrence of 'Failure decoding > Certificate Signing Request' in /usr/lib/python*/site- > packages/ipalib/plugins/cert.py to something like: > > except NSPEError, nsprerr: > raise errors.CertificateOperationError(error=_('Failure decoding > Certificate Signing Request" %s') % nsprerr) > > You'll need to restart the httpd process afterwards. This should give us the > real reason for the failure. Done. The error I get now is: Server failed request, will retry: 4301 (RPC failed at server. Certificate operation cannot be completed: Failure decoding Certificate Signing Request" [Errno -8018] error (-8018) unknown). and in /var/log/httpd/error_log: [Sat Oct 05 17:51:41 2013] [error] ipa: DEBUG: WSGI wsgi_dispatch.__call__: [Sat Oct 05 17:51:41 2013] [error] ipa: DEBUG: WSGI xmlserver.__call__: [Sat Oct 05 17:51:41 2013] [error] ipa: DEBUG: Created connection context.ldap2 [Sat Oct 05 17:51:41 2013] [error] ipa: DEBUG: WSGI WSGIExecutioner.__call__: [Sat Oct 05 17:51:41 2013] [error] ipa: DEBUG: raw: cert_request(u'MIIDcDCCAlgCAQAwNjEUMBIGA1UEChMLRk1SSS5VQkMuQ0ExHjAcBgNVBAMTFXNoYW1yb2NrLmJyYWluLnViYy5jYTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKCzypT3oNmPx90Tevn/vv8FUouT8UL2d8qmhxK0AUVPxJwoZPtkbQBWzUNxkTBkhWV/5s0hN19VBb5ruHTbeSv7KBX8P+CwopQbbjpaqpwvi3dso1NSnT3kU+cNYY1j4tvyKkwPVS7FrP4oELX+aEEOuGF8eyOPK78UlZtDrY0Npje5l8MsUrRMKqQAjhIFc4EzTb2tqcR8Ch+OzBHugcFXcmXGmFnHkK29z2f7Aq1ynk0SqWC0r7nZXw/17jI1OEeD9pagGH1OLEzMrJUQTrvQGH/W+XPt2+ZvJ3UtF4ltw2ViStiG958b32OQvGnbQVJjaIgjpOSiorfnhM0wCPcCAwEAAaCB9DAaBgkqhkiG9w0BCRQxDRMLU2VydmVyLUNlcnQwgdUGCSqGSIb3DQEJDjGBxzCBxDAOBgNVHQ8BAQAEBAMCBPAwgZkGA1UdEQEBAASBjjCBi6A8BgorBgEEAYI3FAIDoC4MLGRvZ3RhZ2xkYXAvc2hhbXJvY2suYnJhaW4udWJjLmNhQEZNUkkuVUJDLkNBoEsGBisGAQUCAqBBMD+gDRsLRk1SSS5VQkMuQ0GhLjAsoAMCAQGhJTAjGwpkb2d0YWdsZGFwGxVzaGFtcm9jay5icmFpbi51YmMuY2EwFgYDVR0lAQEABAwwCgYIKwYBBQUHAwEwDQYJKoZIhvcNAQELBQADggEBAIP+0+O/COqFwbqUCJ+LJiE8aAmP01SRvfJx/RSE9huquDd2XdHVIQ6lQj6qnQYTtCw2NKRq77R3VmUAiCMpQwI9/x/QaaI4MBvV9iYA8b1H/weyvZAMw1mGkdgY55KWPhBtCqLuxHcGRblrtsy2PGp9wm/834s5YamQky+InQFlDy4o5ox+5U5iZS+pvKm52d0TQTozvZ/gSTAqEc+gpwlGAU4U0VaC+7PYnwkYJ98jLDaALm2OCWnSvw/02NLlc+h02mTjumAQ/YnWYNXiAtUbiA8BAkjT0UGV79Vi/aUKxpBTZQXbldrHN/cAmUtSMxebNNQjyUdzAHEV+TUUP2o=', principal=u'dogtagldap/HOSTNAME.DOMAIN at FULLY.QUALIFIED.DOMAIN', add=True) [Sat Oct 05 17:51:41 2013] [error] ipa: DEBUG: cert_request(u'MIIDcDCCAlgCAQAwNjEUMBIGA1UEChMLRk1SSS5VQkMuQ0ExHjAcBgNVBAMTFXNoYW1yb2NrLmJyYWluLnViYy5jYTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKCzypT3oNmPx90Tevn/vv8FUouT8UL2d8qmhxK0AUVPxJwoZPtkbQBWzUNxkTBkhWV/5s0hN19VBb5ruHTbeSv7KBX8P+CwopQbbjpaqpwvi3dso1NSnT3kU+cNYY1j4tvyKkwPVS7FrP4oELX+aEEOuGF8eyOPK78UlZtDrY0Npje5l8MsUrRMKqQAjhIFc4EzTb2tqcR8Ch+OzBHugcFXcmXGmFnHkK29z2f7Aq1ynk0SqWC0r7nZXw/17jI1OEeD9pagGH1OLEzMrJUQTrvQGH/W+XPt2+ZvJ3UtF4ltw2ViStiG958b32OQvGnbQVJjaIgjpOSiorfnhM0wCPcCAwEAAaCB9DAaBgkqhkiG9w0BCRQxDRMLU2VydmVyLUNlcnQwgdUGCSqGSIb3DQEJDjGBxzCBxDAOBgNVHQ8BAQAEBAMCBPAwgZkGA1UdEQEBAASBjjCBi6A8BgorBgEEAYI3FAIDoC4MLGRvZ3RhZ2xkYXAvc2hhbXJvY2suYnJhaW4udWJjLmNhQEZNUkkuVUJDLkNBoEsGBisGAQUCAqBBMD+gDRsLRk1SSS5VQkMuQ0GhLjAsoAMCAQGhJTAjGwpkb2d0YWdsZGFwGxVzaGFtcm9jay5icmFpbi51YmMuY2EwFgYDVR0lAQEABAwwCgYIKwYBBQUHAwEwDQYJKoZIhvcNAQELBQADggEBAIP+0+O/COqFwbqUCJ+LJiE8aAmP01SRvfJx/RSE9huquDd2XdHVIQ6lQj6qnQYTtCw2NKRq77R3VmUAiCMpQwI9/x/QaaI4MBvV9iYA8b1H/weyvZAMw1mGkdgY55KWPhBtCqLuxHcGRblrtsy2PGp9wm/834s5YamQky+InQFlDy4o5ox+5U5iZS+pvKm52d0TQTozvZ/gSTAqEc+gpwlGAU4U0VaC+7PYnwkYJ98jLDaALm2OCWnSvw/02NLlc+h02mTjumAQ/YnWYNXiAtUbiA8BAkjT0UGV79Vi/aUKxpBTZQXbldrHN/cAmUtSMxebNNQjyUdzAHEV+TUUP2o=', principal=u'dogtagldap/HOSTNAME.DOMAIN at FULLY.QUALIFIED.DOMAIN', request_type=u'pkcs10', add=True) [Sat Oct 05 17:51:41 2013] [error] ipa: INFO: host/HOSTNAME.DOMAIN at FULLY.QUALIFIED.DOMAIN: cert_request(u'MIIDcDCCAlgCAQAwNjEUMBIGA1UEChMLRk1SSS5VQkMuQ0ExHjAcBgNVBAMTFXNoYW1yb2NrLmJyYWluLnViYy5jYTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKCzypT3oNmPx90Tevn/vv8FUouT8UL2d8qmhxK0AUVPxJwoZPtkbQBWzUNxkTBkhWV/5s0hN19VBb5ruHTbeSv7KBX8P+CwopQbbjpaqpwvi3dso1NSnT3kU+cNYY1j4tvyKkwPVS7FrP4oELX+aEEOuGF8eyOPK78UlZtDrY0Npje5l8MsUrRMKqQAjhIFc4EzTb2tqcR8Ch+OzBHugcFXcmXGmFnHkK29z2f7Aq1ynk0SqWC0r7nZXw/17jI1OEeD9pagGH1OLEzMrJUQTrvQGH/W+XPt2+ZvJ3UtF4ltw2ViStiG958b32OQvGnbQVJjaIgjpOSiorfnhM0wCPcCAwEAAaCB9DAaBgkqhkiG9w0BCRQxDRMLU2VydmVyLUNlcnQwgdUGCSqGSIb3DQEJDjGBxzCBxDAOBgNVHQ8BAQAEBAMCBPAwgZkGA1UdEQEBAASBjjCBi6A8BgorBgEEAYI3FAIDoC4MLGRvZ3RhZ2xkYXAvc2hhbXJvY2suYnJhaW4udWJjLmNhQEZNUkkuVUJDLkNBoEsGBisGAQUCAqBBMD+gDRsLRk1SSS5VQkMuQ0GhLjAsoAMCAQGhJTAjGwpkb2d0YWdsZGFwGxVzaGFtcm9jay5icmFpbi51YmMuY2EwFgYDVR0lAQEABAwwCgYIKwYBBQUHAwEwDQYJKoZIhvcNAQELBQADggEBAIP+0+O/COqFwbqUCJ+LJiE8aAmP01SRvfJx/RSE9huquDd2XdHVIQ6lQj6qnQYTtCw2NKRq77R3VmUAiCMpQwI9/x/QaaI4MBvV9iYA8b1H/weyvZAMw1mGkdgY55KWPhBtCqLuxHcGRblrtsy2PGp9wm/834s5YamQky+InQFlDy4o5ox+5U5iZS+pvKm52d0TQTozvZ/gSTAqEc+gpwlGAU4U0VaC+7PYnwkYJ98jLDaALm2OCWnSvw/02NLlc+h02mTjumAQ/YnWYNXiAtUbiA8BAkjT0UGV79Vi/aUKxpBTZQXbldrHN/cAmUtSMxebNNQjyUdzAHEV+TUUP2o=', principal=u'dogtagldap/HOSTNAME.DOMAIN at FULLY.QUALIFIED.DOMAIN', add=True): CertificateOperationError [Sat Oct 05 17:51:41 2013] [error] ipa: DEBUG: response: CertificateOperationError: Certificate operation cannot be completed: Failure decoding Certificate Signing Request" [Errno -8018] error (-8018) unknown [Sat Oct 05 17:51:41 2013] [error] ipa: DEBUG: no session id in request, generating empty session data with id=483b62ce1f77f2a678aad6285f1bdb65 [Sat Oct 05 17:51:41 2013] [error] ipa: DEBUG: store session: session_id=483b62ce1f77f2a678aad6285f1bdb65 start_timestamp=2013-10-05T17:51:41 access_timestamp=2013-10-05T17:51:41 expiration_timestamp=1969-12-31T16:00:00 [Sat Oct 05 17:51:41 2013] [error] ipa: DEBUG: finalize_kerberos_acquisition: xmlserver ccache_name="FILE:/tmp/krb5cc_apache_QRaqrv" session_id="483b62ce1f77f2a678aad6285f1bdb65" [Sat Oct 05 17:51:41 2013] [error] ipa: DEBUG: reading ccache data from file "/tmp/krb5cc_apache_QRaqrv" [Sat Oct 05 17:51:41 2013] [error] ipa: DEBUG: get_credential_times: principal=krbtgt/FULLY.QUALIFIED.DOMAIN at FULLY.QUALIFIED.DOMAIN, authtime=10/05/13 17:51:41, starttime=10/05/13 17:51:41, endtime=10/06/13 17:51:41, renew_till=12/31/69 16:00:00 [Sat Oct 05 17:51:41 2013] [error] ipa: DEBUG: KRB5_CCache FILE:/tmp/krb5cc_apache_QRaqrv endtime=1381107101 (10/06/13 17:51:41) [Sat Oct 05 17:51:41 2013] [error] ipa: DEBUG: set_session_expiration_time: duration_type=inactivity_timeout duration=1200 max_age=1381106801 expiration=1381021901.43 (2013-10-05T18:11:41) [Sat Oct 05 17:51:41 2013] [error] ipa: DEBUG: store session: session_id=483b62ce1f77f2a678aad6285f1bdb65 start_timestamp=2013-10-05T17:51:41 access_timestamp=2013-10-05T17:51:41 expiration_timestamp=2013-10-05T18:11:41 [Sat Oct 05 17:51:41 2013] [error] ipa: DEBUG: Destroyed connection context.ldap2 I know almost nothing about NSS but it seems that error -8018 is also known as "SEC_ERROR_UNKNOWN_PKCS11_ERROR". > This failure seems unrelated to the CSR itself, which looks fine. That's what I thought as well but it's nice to hear someone else confirm it! Thank you, --Ryan From simo at redhat.com Tue Oct 22 17:31:53 2013 From: simo at redhat.com (Simo Sorce) Date: Tue, 22 Oct 2013 13:31:53 -0400 Subject: [Freeipa-users] DNS views: request for comments In-Reply-To: <5266A47B.4000203@redhat.com> References: <524AE614.8090808@redhat.com> <52655AE2.7010207@redhat.com> <1382389075.9794.15.camel@willson.li.ssimo.org> <52668F3C.4010204@redhat.com> <5266A47B.4000203@redhat.com> Message-ID: <1382463113.9794.138.camel@willson.li.ssimo.org> On Tue, 2013-10-22 at 18:14 +0200, Petr Spacek wrote: > On 22.10.2013 16:44, Martin Kosek wrote: > > On 10/21/2013 10:57 PM, Simo Sorce wrote: > >> Comments inline. > >> > >> On Mon, 2013-10-21 at 18:48 +0200, Petr Spacek wrote: > >>> On 1.10.2013 17:11, Petr Spacek wrote: > >> > >> [trim] > > I should make one thing clear: > We already do two-way synchronization between LDAP and DNS server (run-time). > > Persistent search (and now syncrepl) dumps content of LDAP database to a > internal database in DNS server and the bind-dyndb-ldap plugin operates on > this internal database. I.e. changes done in LDAP are asynchronously applied > to internal database and vice versa, changes done via DNS protocol are written > back to LDAP. > > This is why we are able to apply any change in LDAP almost immediatelly to DNS > data. It is true that there are nasty corner cases, but up to now we didn't > receive many complains about data inconsistency. (This will change after the > major refactoring in bind-dyndb-ldap 4.0 :-)) Yes but this synchronization is tightly coupled and controlled and only the LDAP data is considered authoritative. It's quite different from using things like zone transfers to perform some sort of 'generic' synchronization. [..] > >> Doesn't this scheme means you always have to do 2 searches ? One to find > >> if the object is in the view and one to the base ? > >> > >> We could use multivalued RDNs to achieve something similar but that will > >> require you only one search (assuming it matters). > > Reading = 0 searches :-D Psearch/SyncRepl delivers the data from LDAP > asynchronously to the plugin, almost immediatelly after each change in LDAP. This is true only with the current specific implementation, I think we want to create a schema that can be used with an alternative implementation w/o forcing the use of syncrepl/psearch and synchronization. > >>> - values added on top of inherited set are represented as normal DNS > >>> attributes: e.g. aRecord: 192.0.2.1 > >>> - values deleted from inherited set - *are open question*: It would be great > >>> if we could store it under the same object as additions, it would make > >>> implementation a bit simpler. > >>> - Would it be acceptable to store override 'delete TXT record "hello"' as > >>> attribute 'tXTRecord;x-deleted: test'? > >> > >> I think this would be acceptable, however what happens if then someone > >> deletes the base object and later on again recreates it ? > >> > >> Will the view still 'mask' it ? > My original idea was: "Yes, it will." The main reason is that user can have > some tools which do LDAP delete/add instead of replace/modify, so some data > from the base could be accidentally exposed if we delete 'override' > automatically with base object. Ok. > >> Is this the actual desired outcome maybe ? > This is a good question :-) This is most generic/powerful mechanism but it > could create some nasty surprises. One drawback is that you have to go and add > 'mask'/'delete' record to affected views (if necessary) when you add a record > to the base. As long as it is possible it is not surprising, I would expect that when using inheritance. > Another variants: > aa) Do overrides on name-level instead of record level. I.e. records for > particular name will not be inherited if the override is present. > > Example: > Base definition: > - gateway.example.com. A 203.0.113.66 > - gateway.example.com. TXT "this record came from base" > - example.com MX 10 gateway.example.com. > > View definition: > - gateway.example.com. A 10.1.1.1 > > Result - view: > - gateway.example.com. A 10.1.1.1 > - example.com MX 10 gateway.example.com. I think this is preferable indeed. > => A and TXT records from base were not inherited because override for the > name 'gateway' was present in the view. > => MX record for name 'example.com' was inherited because there is no override > with this name in the view. > => Modification done in 'base' will not affect view in any way if the override > is present, so there can't be information leak. > => This approach doesn't require ;x-deleted or cn=deleted trick. It till requires an empty object to mask though, but that is fine I think, I like this better. > ab) No inheritance at all. > This is what BIND9 does if dynamic updates are enabled. After first update the > inheritance relationship is broken and views operate independently. I am not sure what this means exactly, our server uses Dynamic Updates by default, so I am not sure that 'breaking inheritance' on dynamic updates makes much sense, we'd have no inheritance at all. > Obviously, this is simplest and clearest solution. Maybe that it is enough for > most users, look at the support in open source software ... > > Maybe that some UI support for copying from one view to the other would be enough? It is certainly a first implementation option. Start w/o inheritance but do not preclude the option of adding it later. > >> Should we allow Dynamic Updates in Views at all ? > It would be too simple without dynamic updates :-) > > I think that we should allow updates, otherwise we can drop all the code for > DNS updates from SSSD, ipa-client-install etc. > > Of course, we can implement first version without support for updates and add > it later, if there is a demand. We just need to keep it in mind during design. The problem with updates in views is that generally views are returned based on the origin of the client. now if you have laptops and you get the laptop outside of the company then it could try to issue DNS updates, but given it is "outside" it would be associated to the "external" view ? I do not think you'd want to allow a laptop to update the external view in that case. Granted a company like that should probably have an internal zone for laptops that is not exposed at all ... but there will certainly be cases, esp in small setups. Perhaps it should be somehow optional. > >>> - The other option is to store deleted attributes in separate object: > >>> DN: cn=deleted, idnsName=record1, idnsName=zone1, idnsView=view1, cn=dns > >> > >> This sound cumbersome and require a 3rd search for every query, nack :) > Again, 0 searches because of syncrepl :-) Shouldn't depend on syncrepl for the general schema design imo, unless there is a very strong degradation of performance trying not to. > >> I like variant A, I think it is the most sensible and the only one > >> really needed. People have an internal view and want to 'filter' it some > >> for the external world or similar. > >> > >> > >>> Proposal - variant B (shared record groups) > >>> ==================== > >>> - not so simple to implement, especially update-performance could be an issue > >>> - multiple zones can share the same record group > >>> - each view can contain arbitrary zones anf those zones can inherit arbitrary > >>> record groups - inheritance is fully configurable > >>> - the data in views can be modified via DNS updates, a change done to > >>> inherited data creates an override (BIND9 does the same): e.g. name 'r1.z.' is > >>> shared between View1 and View2. Value change in View1 doesn't affect View2. > >>> - particular record from any shared record group can be overriden > >>> (deleted/replaced) in any zone in any view > >>> - changes done to the shared record group are propagated to all views (this is > >>> the hard part!) > >> > >> Sound very complex not only to build, but to explain to admins as well, > >> is anyone actually going to need this level of complexity, what scenario > >> would really benefit from this that can't be done with A ? > I can see one use case: > > Domains 'flower-eshop.com' and 'parfums-eshop.com' are hosted in 'data centre > 1', while domains 'car-eshop.com' and 'software-eshop.com' are hosted in 'data > centre 2'. > > Typically it means that sites in one DC/group share the same set of NS > records, MX records etc. > > So the admin will define record group "DC1": > NS ns1.dc1.examplewebhoster.com. > NS ns2.backup.examplewebhoster.com. > MX 10 mx1.dc1.examplewebhoster.com. > MX 20 mx1.dc2.examplewebhoster.com. > > Record group "DC2": > NS ns1.dc2.examplewebhoster.com. > NS ns1.backup.examplewebhoster.com. > MX 20 mx1.dc1.examplewebhoster.com. > MX 10 mx1.dc2.examplewebhoster.com. > > Now record group DC1 is assigned to servers hosted at DC1 and so on. > Result = new mail server for DC1 has to be added to single place (the record > group DC1) and all domains hosted at DC1 will automagically pick up the new > server. > > So you don't need to construct cycles over all servers in DC1, modify each > record by hand etc. > > This sounds nice 'on the paper', but I don't know how big the real demand is ... I do not see this as being very interesting in a FreeIPA scenario, but I'd like to hear from actual users here. [..] > > I read all the proposals, I would personally stick with variant A as this is > > something that is doable in near future. Variant 0 seems a bit utopic to me, > One year, may be. Views are pretty complex thing - don't forget to integration > with DNSSEC ... > > > especially when speaking about synchronization corner cases. Martin's thesis > > Please see the note at the beginning of my e-mail. We already do two-way > synchronization in bind-dyndb-ldap. As said, generic synchronization (especially 2 way) is quite different from tightly coupled sync, especially when you define a clear authoritative copy you can always revert to. > > may prove me wrong, we will see. > > Sure. Stand-alone daemon usually has some specific problems which are not so > problematic for plug-ins, we will see. Indeed, will see. Thanks for the work done so far, good thinking as usual. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Tue Oct 22 17:45:43 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 22 Oct 2013 13:45:43 -0400 Subject: [Freeipa-users] Failure decoding Certificate Signing Request In-Reply-To: <4236DE1EFED4374EA69B197EB5AC275735147A7B@S-ITSV-MBX02P.ead.ubc.ca> References: <3fc2cb83-f64c-450b-a9d9-d4612966bbc1@S-ITSV-HUB01P.ead.ubc.ca> <52666FE7.4060406@redhat.com> <4236DE1EFED4374EA69B197EB5AC275735147A7B@S-ITSV-MBX02P.ead.ubc.ca> Message-ID: <5266B9C7.5090507@redhat.com> Thomson, Ryan wrote: > Hi Rob, > >> There is some duplication in the error strings (ticket >> https://fedorahosted.org/freeipa/ticket/3988). Did you add a number prefix >> to yours, I see a 3 -in the error. If so, by my calculation, this works out to be >> an NSPRError. It would be helpful to know what exception is being raised, >> which we don't do. > > I did prefix numbers to the various error strings. > >> Either way, if you could enhance each occurrence of 'Failure decoding >> Certificate Signing Request' in /usr/lib/python*/site- >> packages/ipalib/plugins/cert.py to something like: >> >> except NSPEError, nsprerr: >> raise errors.CertificateOperationError(error=_('Failure decoding >> Certificate Signing Request" %s') % nsprerr) >> >> You'll need to restart the httpd process afterwards. This should give us the >> real reason for the failure. > > Done. The error I get now is: > > Server failed request, will retry: 4301 (RPC failed at server. Certificate operation cannot be completed: Failure decoding Certificate Signing Request" [Errno -8018] error (-8018) unknown). Hmm, very strange indeed. It should be using the NSS database initialized in mod_nss for Apache, which should remain open and available for wsgi. It almost seems like the database has been shut down. Can you add a logging event to log the value of nss.nss_is_initialized()? Have you done any configuration customization in Apache or mod_nss? thanks rob From bpk678 at gmail.com Tue Oct 22 20:24:16 2013 From: bpk678 at gmail.com (Brendan Kearney) Date: Tue, 22 Oct 2013 16:24:16 -0400 Subject: [Freeipa-users] No $ORIGIN directive in bind-dyndb-ldap In-Reply-To: <1382451974.19960.6.camel@desktop.bpk2.com> References: <1382451974.19960.6.camel@desktop.bpk2.com> Message-ID: <1382473456.19960.23.camel@desktop.bpk2.com> my config uses bind and bind-dyndb-ldap to host zone data in ldap. i am trying to achieve the equivalent directives and configuration of bind +bind-dyndb-ldap that i have in straight bind. attached is my forward zone (frozen before copying data, so that the jnl entries were written out). the desired outcome is to have zones configured so that unqualified queries are looked up locally and return properly, if appropriate, before being forwarded to any forwarders or via the hints to the roots or whatever is configured to be done with a record that does not have a locally authoritative entry. while zytrax does have good articles, the reference i provided is directly out of the bind admin guide, and likely a more authoritative voice on the subject. i have validated that when no $ORIGIN directive is set, a query using the short name will fail when looked up locally, and will either be forwarded or recursively searched for. the examples i provided go against bind+bind-dyndb-ldap, and the short name query fails. doing the same lookups against my straight bind instance, using the attached zone file, gives authoritative responses for both short and FQDN queries. -------------- next part -------------- $ORIGIN . $TTL 3600 ; 1 hour bpk2.com IN SOA server.bpk2.com. root.server.bpk2.com. ( 21684 ; serial 10800 ; refresh (3 hours) 3600 ; retry (1 hour) 604800 ; expire (1 week) 3600 ; minimum (1 hour) ) NS vpn.bpk2.com. NS server.bpk2.com. $ORIGIN bpk2.com. $TTL 600 ; 10 minutes _kerberos TXT "BPK2.COM" $TTL 5 ; 5 seconds cache A 192.168.25.1 A 192.168.50.1 ceton A 192.168.200.1 $TTL 3600 ; 1 hour desktop A 192.168.1.60 $TTL 1800 ; 30 minutes TXT "004f797684e9ec50c37966ab6377f6e5c6" $TTL 3600 ; 1 hour dhcp01 CNAME server dhcp02 CNAME vpn edge1037 A 192.168.3.1 TXT "31f8a6da151fb3fc048a6e3dbcd4099896" HP001560497B44 CNAME printer inspire A 192.168.2.145 $TTL 1800 ; 30 minutes TXT "3105220f898df9aa1cecba75583223a0e2" $TTL 3600 ; 1 hour iphone A 192.168.2.146 TXT "318d91a7366c7a0cbd8ac4a8cf5f11f2f8" ipsec A 192.168.52.1 $TTL 600 ; 10 minutes kerberos A 192.168.25.1 A 192.168.50.1 $TTL 3600 ; 1 hour laptop A 192.168.1.139 $TTL 1800 ; 30 minutes TXT "002a031452f258ef236a2463b272372ad6" $TTL 3600 ; 1 hour ldap A 192.168.37.3 ldap-master CNAME server ldap1 CNAME server ldap2 CNAME vpn modem A 192.168.100.1 music CNAME desktop ncsi CNAME server ns01 CNAME vpn ns02 CNAME server ntp CNAME vpn printer A 192.168.1.3 TXT "316f7731238b38ada102f07b426eb98a95" $TTL 600 ; 10 minutes proxy A 192.168.37.1 proxy1 CNAME server proxy2 CNAME vpn router CNAME router-vlan254 $TTL 3600 ; 1 hour router-ipmi A 192.168.253.3 $TTL 600 ; 10 minutes router-vlan1 A 192.168.1.254 router-vlan2 A 192.168.2.254 router-vlan25 A 192.168.25.254 router-vlan253 A 192.168.253.254 router-vlan254 A 192.168.254.254 router-vlan3 A 192.168.3.254 router-vlan37 A 192.168.37.254 router-vlan50 A 192.168.50.254 router-vlan52 A 192.168.52.254 server A 192.168.25.1 server-ipmi A 192.168.253.1 server-old A 192.168.1.1 switch A 192.168.254.253 wpad.tcp TXT "service: wpad:!http://www.bpk2.com:80/wpad.dat" SRV 0 0 80 server $TTL 3600 ; 1 hour test A 192.168.1.169 $TTL 1800 ; 30 minutes TXT "00b6f6a38a5caaab7be5bdc35d2d3e7acc" $TTL 600 ; 10 minutes tproxy CNAME server vpn A 192.168.50.1 vpn-ipmi A 192.168.253.2 wifi-g A 192.168.1.253 wifi-guest A 192.168.3.253 wifi-n A 192.168.2.253 wpad CNAME www www A 192.168.37.2 www1 CNAME server www2 CNAME vpn From ryan.thomson at ubc.ca Tue Oct 22 23:10:57 2013 From: ryan.thomson at ubc.ca (Thomson, Ryan) Date: Tue, 22 Oct 2013 23:10:57 +0000 Subject: [Freeipa-users] Failure decoding Certificate Signing Request In-Reply-To: <5266B9C7.5090507@redhat.com> References: <3fc2cb83-f64c-450b-a9d9-d4612966bbc1@S-ITSV-HUB01P.ead.ubc.ca> <52666FE7.4060406@redhat.com> <4236DE1EFED4374EA69B197EB5AC275735147A7B@S-ITSV-MBX02P.ead.ubc.ca> <5266B9C7.5090507@redhat.com> Message-ID: <4236DE1EFED4374EA69B197EB5AC275735148D59@S-ITSV-MBX02P.ead.ubc.ca> > -----Original Message----- > From: Rob Crittenden [mailto:rcritten at redhat.com] > Sent: Tuesday, October 22, 2013 10:46 AM > To: Thomson, Ryan; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Failure decoding Certificate Signing Request > > Thomson, Ryan wrote: > > Hi Rob, > > > >> There is some duplication in the error strings (ticket > >> https://fedorahosted.org/freeipa/ticket/3988). Did you add a number > >> prefix to yours, I see a 3 -in the error. If so, by my calculation, > >> this works out to be an NSPRError. It would be helpful to know what > >> exception is being raised, which we don't do. > > > > I did prefix numbers to the various error strings. > > > >> Either way, if you could enhance each occurrence of 'Failure decoding > >> Certificate Signing Request' in /usr/lib/python*/site- > >> packages/ipalib/plugins/cert.py to something like: > >> > >> except NSPEError, nsprerr: > >> raise errors.CertificateOperationError(error=_('Failure > >> decoding Certificate Signing Request" %s') % nsprerr) > >> > >> You'll need to restart the httpd process afterwards. This should give > >> us the real reason for the failure. > > > > Done. The error I get now is: > > > > Server failed request, will retry: 4301 (RPC failed at server. Certificate > operation cannot be completed: Failure decoding Certificate Signing > Request" [Errno -8018] error (-8018) unknown). > > Hmm, very strange indeed. > > It should be using the NSS database initialized in mod_nss for Apache, which > should remain open and available for wsgi. It almost seems like the database > has been shut down. > > Can you add a logging event to log the value of nss.nss_is_initialized()? > > Have you done any configuration customization in Apache or mod_nss? > > thanks > > rob The return value of nss.nss_is_initialized() is False when I resubmit the (expired) certs through certmonger. I did have a custom config for apache that configured a virtual host with SSL. I have disabled that config and restarted httpd, resubmitted the certs to certmonger but I still receive the same error. I will continue poking through my apache / mod_nss config to see if anything stands out. Cheers, --Ryan From rcritten at redhat.com Wed Oct 23 02:13:28 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 22 Oct 2013 22:13:28 -0400 Subject: [Freeipa-users] Failure decoding Certificate Signing Request In-Reply-To: <4236DE1EFED4374EA69B197EB5AC275735148D59@S-ITSV-MBX02P.ead.ubc.ca> References: <3fc2cb83-f64c-450b-a9d9-d4612966bbc1@S-ITSV-HUB01P.ead.ubc.ca> <52666FE7.4060406@redhat.com> <4236DE1EFED4374EA69B197EB5AC275735147A7B@S-ITSV-MBX02P.ead.ubc.ca> <5266B9C7.5090507@redhat.com> <4236DE1EFED4374EA69B197EB5AC275735148D59@S-ITSV-MBX02P.ead.ubc.ca> Message-ID: <526730C8.7030105@redhat.com> Thomson, Ryan wrote: >> -----Original Message----- >> From: Rob Crittenden [mailto:rcritten at redhat.com] >> Sent: Tuesday, October 22, 2013 10:46 AM >> To: Thomson, Ryan; freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] Failure decoding Certificate Signing Request >> >> Thomson, Ryan wrote: >>> Hi Rob, >>> >>>> There is some duplication in the error strings (ticket >>>> https://fedorahosted.org/freeipa/ticket/3988). Did you add a number >>>> prefix to yours, I see a 3 -in the error. If so, by my calculation, >>>> this works out to be an NSPRError. It would be helpful to know what >>>> exception is being raised, which we don't do. >>> >>> I did prefix numbers to the various error strings. >>> >>>> Either way, if you could enhance each occurrence of 'Failure decoding >>>> Certificate Signing Request' in /usr/lib/python*/site- >>>> packages/ipalib/plugins/cert.py to something like: >>>> >>>> except NSPEError, nsprerr: >>>> raise errors.CertificateOperationError(error=_('Failure >>>> decoding Certificate Signing Request" %s') % nsprerr) >>>> >>>> You'll need to restart the httpd process afterwards. This should give >>>> us the real reason for the failure. >>> >>> Done. The error I get now is: >>> >>> Server failed request, will retry: 4301 (RPC failed at server. Certificate >> operation cannot be completed: Failure decoding Certificate Signing >> Request" [Errno -8018] error (-8018) unknown). >> >> Hmm, very strange indeed. >> >> It should be using the NSS database initialized in mod_nss for Apache, which >> should remain open and available for wsgi. It almost seems like the database >> has been shut down. >> >> Can you add a logging event to log the value of nss.nss_is_initialized()? >> >> Have you done any configuration customization in Apache or mod_nss? >> >> thanks >> >> rob > > The return value of nss.nss_is_initialized() is False when I resubmit the (expired) certs through certmonger. Ok, that is the core of the issue then. pkcs10.load_certificate() will initialize NSS If it isn't already and I'm guessing that is failing and is the source of this exception. > I did have a custom config for apache that configured a virtual host with SSL. I have disabled that config and restarted httpd, resubmitted the certs to certmonger but I still receive the same error. I will continue poking through my apache / mod_nss config to see if anything stands out. You're still using mod_nss though, right? rob From pspacek at redhat.com Wed Oct 23 07:20:52 2013 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 23 Oct 2013 09:20:52 +0200 Subject: [Freeipa-users] No $ORIGIN directive in bind-dyndb-ldap In-Reply-To: <1382473456.19960.23.camel@desktop.bpk2.com> References: <1382451974.19960.6.camel@desktop.bpk2.com> <1382473456.19960.23.camel@desktop.bpk2.com> Message-ID: <526778D4.2020607@redhat.com> Hello, On 22.10.2013 22:24, Brendan Kearney wrote: > my config uses bind and bind-dyndb-ldap to host zone data in ldap. i am > trying to achieve the equivalent directives and configuration of bind > +bind-dyndb-ldap that i have in straight bind. Do you plan to use FreeIPA command line interface or not? With FreeIPA, you can create equivalent records with this set of commands: $ ipa dnszone-add bpk2.com $ ipa dnsrecord-add bpk2.com _kerberos --txt-rec=... etc. Those commands allow you to create almost equivalent data in LDAP. This doesn't work for you? Please note that dnsrecord-add command contains zone name (as the first argument), so the FQDN can be constructed from the first and second argument. DNS zone is represented by LDAP object which contains all other named in the zone: idnsname=bkp2.com,cn=dns,dc=ipa,dc=test Each name inside particular zone is represented by own LDAP object: idnsname=_kerberos, idnsname=bkp2.com,cn=dns,dc=ipa,dc=test As a result, FQDN can be constructed for each relative name in the zone simply by concatenating second and first idnsname components. Is it now clearer why bind-dyndb-ldap don't have equivalent of $ORIGIN? > attached is my forward zone (frozen before copying data, so that the jnl > entries were written out). > > the desired outcome is to have zones configured so that unqualified > queries are looked up locally and return properly, if appropriate, > before being forwarded to any forwarders or via the hints to the roots > or whatever is configured to be done with a record that does not have a > locally authoritative entry. AFAIK 'unqualified' names are purely client-side thing. I belive that all names have to be expanded to FQDN *before* the query is sent to any DNS server. (See search directive in /etc/resolv.conf.) > while zytrax does have good articles, the reference i provided is > directly out of the bind admin guide, and likely a more authoritative > voice on the subject. I agree. Please note that both sources say the same information, just in other words. > i have validated that when no $ORIGIN directive is set, a query using > the short name will fail when looked up locally, and will either be > forwarded or recursively searched for. the examples i provided go > against bind+bind-dyndb-ldap, and the short name query fails. doing the > same lookups against my straight bind instance, using the attached zone > file, gives authoritative responses for both short and FQDN queries. I belive that your zone file will be perfectly functional if you remove origin completely. You will have to replace name for SOA record. $ diff -u bpk2.com.db.orig bpk2.com.db.noorigin --- bpk2.com.db.orig 2013-10-23 09:09:47.568113243 +0200 +++ bpk2.com.db.noorigin 2013-10-23 09:10:09.347112464 +0200 @@ -1,6 +1,5 @@ -$ORIGIN . $TTL 3600 ; 1 hour -bpk2.com IN SOA server.bpk2.com. root.server.bpk2.com. ( +@ IN SOA server.bpk2.com. root.server.bpk2.com. ( 21684 ; serial 10800 ; refresh (3 hours) 3600 ; retry (1 hour) @@ -9,7 +8,6 @@ ) NS vpn.bpk2.com. NS server.bpk2.com. -$ORIGIN bpk2.com. $TTL 600 ; 10 minutes _kerberos TXT "BPK2.COM" $TTL 5 ; 5 seconds I assume that your zone definition in named.conf looks like: zone "bpk2.com." IN { type master; file "bpk2.com.db"; }; As a result, default origin "bpk2.com." is appended to all names in zone file - and that is it. Do not forget to bump serial and check server logs if the new zone file was loaded correctly ... Have a nice day! -- Petr^2 Spacek From pspacek at redhat.com Wed Oct 23 10:24:24 2013 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 23 Oct 2013 12:24:24 +0200 Subject: [Freeipa-users] DNS views: request for comments In-Reply-To: <1382463113.9794.138.camel@willson.li.ssimo.org> References: <524AE614.8090808@redhat.com> <52655AE2.7010207@redhat.com> <1382389075.9794.15.camel@willson.li.ssimo.org> <52668F3C.4010204@redhat.com> <5266A47B.4000203@redhat.com> <1382463113.9794.138.camel@willson.li.ssimo.org> Message-ID: <5267A3D8.4020003@redhat.com> On 22.10.2013 19:31, Simo Sorce wrote: > On Tue, 2013-10-22 at 18:14 +0200, Petr Spacek wrote: >> On 22.10.2013 16:44, Martin Kosek wrote: >>> On 10/21/2013 10:57 PM, Simo Sorce wrote: >>>> On Mon, 2013-10-21 at 18:48 +0200, Petr Spacek wrote: >>>>> On 1.10.2013 17:11, Petr Spacek wrote: [...] >>>> Doesn't this scheme means you always have to do 2 searches ? One to find >>>> if the object is in the view and one to the base ? >>>> >>>> We could use multivalued RDNs to achieve something similar but that will >>>> require you only one search (assuming it matters). >> >> Reading = 0 searches :-D Psearch/SyncRepl delivers the data from LDAP >> asynchronously to the plugin, almost immediatelly after each change in LDAP. > > This is true only with the current specific implementation, I think we > want to create a schema that can be used with an alternative > implementation w/o forcing the use of syncrepl/psearch and > synchronization. Good point! >>>>> - values added on top of inherited set are represented as normal DNS >>>>> attributes: e.g. aRecord: 192.0.2.1 >>>>> - values deleted from inherited set - *are open question*: It would be great >>>>> if we could store it under the same object as additions, it would make >>>>> implementation a bit simpler. >>>>> - Would it be acceptable to store override 'delete TXT record "hello"' as >>>>> attribute 'tXTRecord;x-deleted: test'? >>>> >>>> I think this would be acceptable, however what happens if then someone >>>> deletes the base object and later on again recreates it ? >>>> >>>> Will the view still 'mask' it ? >> My original idea was: "Yes, it will." The main reason is that user can have >> some tools which do LDAP delete/add instead of replace/modify, so some data >> from the base could be accidentally exposed if we delete 'override' >> automatically with base object. > > Ok. > >>>> Is this the actual desired outcome maybe ? >> This is a good question :-) This is most generic/powerful mechanism but it >> could create some nasty surprises. One drawback is that you have to go and add >> 'mask'/'delete' record to affected views (if necessary) when you add a record >> to the base. > > As long as it is possible it is not surprising, I would expect that when > using inheritance. > >> Another variants: >> aa) Do overrides on name-level instead of record level. I.e. records for >> particular name will not be inherited if the override is present. >> >> Example: >> Base definition: >> - gateway.example.com. A 203.0.113.66 >> - gateway.example.com. TXT "this record came from base" >> - example.com MX 10 gateway.example.com. >> >> View definition: >> - gateway.example.com. A 10.1.1.1 >> >> Result - view: >> - gateway.example.com. A 10.1.1.1 >> - example.com MX 10 gateway.example.com. > > I think this is preferable indeed. > >> => A and TXT records from base were not inherited because override for the >> name 'gateway' was present in the view. >> => MX record for name 'example.com' was inherited because there is no override >> with this name in the view. >> => Modification done in 'base' will not affect view in any way if the override >> is present, so there can't be information leak. >> => This approach doesn't require ;x-deleted or cn=deleted trick. > > It till requires an empty object to mask though, but that is fine I > think, I like this better. Me too. Reasonable use will be to fill 'the base' with all shared names/records and use views mainly for addition and minor edits, so empty objects will not appear so often. >> ab) No inheritance at all. >> This is what BIND9 does if dynamic updates are enabled. After first update the >> inheritance relationship is broken and views operate independently. > > I am not sure what this means exactly, our server uses Dynamic Updates > by default, so I am not sure that 'breaking inheritance' on dynamic > updates makes much sense, we'd have no inheritance at all. "we'd have no inheritance at all." Exactly. BIND9 simply copies inherited records to each view during start up and then views operate independently. (If you use dynamic updates.) >> Obviously, this is simplest and clearest solution. Maybe that it is enough for >> most users, look at the support in open source software ... >> >> Maybe that some UI support for copying from one view to the other would be enough? > > It is certainly a first implementation option. > Start w/o inheritance but do not preclude the option of adding it later. This is exactly why we have this discussion now. I want to prepare some future-proof plan. We have to find if 1:1 mapping between 'name+view' pair will be always here (even with views, inheritance and the other stuff). All bind-dyndb-ldap depend on this relationship (at the moment), so I want to know if we are going to break it or not. I don't want to finish DNSSEC and then start re-writing it again because of views ... >>>> Should we allow Dynamic Updates in Views at all ? >> It would be too simple without dynamic updates :-) >> >> I think that we should allow updates, otherwise we can drop all the code for >> DNS updates from SSSD, ipa-client-install etc. >> >> Of course, we can implement first version without support for updates and add >> it later, if there is a demand. We just need to keep it in mind during design. > > The problem with updates in views is that generally views are returned > based on the origin of the client. Exactly. > now if you have laptops and you get the laptop outside of the company > then it could try to issue DNS updates, but given it is "outside" it > would be associated to the "external" view ? Yes, it would be. > I do not think you'd want to allow a laptop to update the external view > in that case. We are lucky, because BIND 9 allows us to define different update policies per-'zone+view' pair. E.g. particular zone in an internal view can allow updates as usual but the some zone in an external view can deny any updates. We just need to store update policy somewhere. I guess that zone object stored in view container could be the right place, i.e. idnsName=zone1, idnsView=view1, cn=dns. > Granted a company like that should probably have an internal zone for > laptops that is not exposed at all ... but there will certainly be > cases, esp in small setups. > > Perhaps it should be somehow optional. > >>>>> - The other option is to store deleted attributes in separate object: >>>>> DN: cn=deleted, idnsName=record1, idnsName=zone1, idnsView=view1, cn=dns >>>> >>>> This sound cumbersome and require a 3rd search for every query, nack :) >> Again, 0 searches because of syncrepl :-) > > Shouldn't depend on syncrepl for the general schema design imo, unless > there is a very strong degradation of performance trying not to. > >>>> I like variant A, I think it is the most sensible and the only one >>>> really needed. People have an internal view and want to 'filter' it some >>>> for the external world or similar. >>>> >>>> >>>>> Proposal - variant B (shared record groups) >>>>> ==================== >>>>> - not so simple to implement, especially update-performance could be an issue >>>>> - multiple zones can share the same record group >>>>> - each view can contain arbitrary zones anf those zones can inherit arbitrary >>>>> record groups - inheritance is fully configurable >>>>> - the data in views can be modified via DNS updates, a change done to >>>>> inherited data creates an override (BIND9 does the same): e.g. name 'r1.z.' is >>>>> shared between View1 and View2. Value change in View1 doesn't affect View2. >>>>> - particular record from any shared record group can be overriden >>>>> (deleted/replaced) in any zone in any view >>>>> - changes done to the shared record group are propagated to all views (this is >>>>> the hard part!) >>>> >>>> Sound very complex not only to build, but to explain to admins as well, >>>> is anyone actually going to need this level of complexity, what scenario >>>> would really benefit from this that can't be done with A ? >> I can see one use case: >> >> Domains 'flower-eshop.com' and 'parfums-eshop.com' are hosted in 'data centre >> 1', while domains 'car-eshop.com' and 'software-eshop.com' are hosted in 'data >> centre 2'. >> >> Typically it means that sites in one DC/group share the same set of NS >> records, MX records etc. >> >> So the admin will define record group "DC1": >> NS ns1.dc1.examplewebhoster.com. >> NS ns2.backup.examplewebhoster.com. >> MX 10 mx1.dc1.examplewebhoster.com. >> MX 20 mx1.dc2.examplewebhoster.com. >> >> Record group "DC2": >> NS ns1.dc2.examplewebhoster.com. >> NS ns1.backup.examplewebhoster.com. >> MX 20 mx1.dc1.examplewebhoster.com. >> MX 10 mx1.dc2.examplewebhoster.com. >> >> Now record group DC1 is assigned to servers hosted at DC1 and so on. >> Result = new mail server for DC1 has to be added to single place (the record >> group DC1) and all domains hosted at DC1 will automagically pick up the new >> server. >> >> So you don't need to construct cycles over all servers in DC1, modify each >> record by hand etc. >> >> This sounds nice 'on the paper', but I don't know how big the real demand is ... > > I do not see this as being very interesting in a FreeIPA scenario, but > I'd like to hear from actual users here. I can see two minor use cases with every-day FreeIPA deployments: 1) Each zone managed by FreeIPA should list all DNS-enabled FreeIPA replicas in zone's NS records (for redundancy). => Replica add/delete means that user has to go through all zones and update NS records. (We don't do it automatically: https://fedorahosted.org/freeipa/ticket/3343) I'm not sure about this second use case, please correct me if I'm wrong. 2) Clients usually depend on SRV and _kerberos TXT records for auto-discovery. => Those records should be present in multiple domains if clients are scattered among those domains. (Is this assumption correct?) => Replica add/delete means that user has to go through all zones and update all relevant SRV records. I can see another solution for the second case - add only CNAMEs pointing to the records in 'master' FreeIPA domain. In that case record group will only simplify zone addition - you would have to assign one record group instead of creating multiple CNAMEs. Anyway, I don't think that those two cases are so important. This administrative burden can (and should!) be hidden in replica management scripts. The main question is - can we set this one-level-inheritance-only schema design (variant A) in stone? -- Petr^2 Spacek From ryan.thomson at ubc.ca Wed Oct 23 21:05:54 2013 From: ryan.thomson at ubc.ca (Thomson, Ryan) Date: Wed, 23 Oct 2013 21:05:54 +0000 Subject: [Freeipa-users] Failure decoding Certificate Signing Request In-Reply-To: <526730C8.7030105@redhat.com> References: <3fc2cb83-f64c-450b-a9d9-d4612966bbc1@S-ITSV-HUB01P.ead.ubc.ca> <52666FE7.4060406@redhat.com> <4236DE1EFED4374EA69B197EB5AC275735147A7B@S-ITSV-MBX02P.ead.ubc.ca> <5266B9C7.5090507@redhat.com> <4236DE1EFED4374EA69B197EB5AC275735148D59@S-ITSV-MBX02P.ead.ubc.ca> <526730C8.7030105@redhat.com> Message-ID: <4236DE1EFED4374EA69B197EB5AC27573514A59D@S-ITSV-MBX02P.ead.ubc.ca> > -----Original Message----- > From: Rob Crittenden [mailto:rcritten at redhat.com] > Sent: Tuesday, October 22, 2013 7:13 PM > To: Thomson, Ryan; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Failure decoding Certificate Signing Request > > Thomson, Ryan wrote: > >> -----Original Message----- > >> From: Rob Crittenden [mailto:rcritten at redhat.com] > >> Sent: Tuesday, October 22, 2013 10:46 AM > >> To: Thomson, Ryan; freeipa-users at redhat.com > >> Subject: Re: [Freeipa-users] Failure decoding Certificate Signing > >> Request > >> > >> Thomson, Ryan wrote: > >>> Hi Rob, > >>> > >>>> There is some duplication in the error strings (ticket > >>>> https://fedorahosted.org/freeipa/ticket/3988). Did you add a number > >>>> prefix to yours, I see a 3 -in the error. If so, by my calculation, > >>>> this works out to be an NSPRError. It would be helpful to know what > >>>> exception is being raised, which we don't do. > >>> > >>> I did prefix numbers to the various error strings. > >>> > >>>> Either way, if you could enhance each occurrence of 'Failure > >>>> decoding Certificate Signing Request' in /usr/lib/python*/site- > >>>> packages/ipalib/plugins/cert.py to something like: > >>>> > >>>> except NSPEError, nsprerr: > >>>> raise errors.CertificateOperationError(error=_('Failure > >>>> decoding Certificate Signing Request" %s') % nsprerr) > >>>> > >>>> You'll need to restart the httpd process afterwards. This should > >>>> give us the real reason for the failure. > >>> > >>> Done. The error I get now is: > >>> > >>> Server failed request, will retry: 4301 (RPC failed at server. > >>> Certificate > >> operation cannot be completed: Failure decoding Certificate Signing > >> Request" [Errno -8018] error (-8018) unknown). > >> > >> Hmm, very strange indeed. > >> > >> It should be using the NSS database initialized in mod_nss for > >> Apache, which should remain open and available for wsgi. It almost > >> seems like the database has been shut down. > >> > >> Can you add a logging event to log the value of nss.nss_is_initialized()? > >> > >> Have you done any configuration customization in Apache or mod_nss? > >> > >> thanks > >> > >> rob > > > > The return value of nss.nss_is_initialized() is False when I resubmit the > (expired) certs through certmonger. > > Ok, that is the core of the issue then. pkcs10.load_certificate() will initialize > NSS If it isn't already and I'm guessing that is failing and is the source of this > exception. > > > I did have a custom config for apache that configured a virtual host with > SSL. I have disabled that config and restarted httpd, resubmitted the certs to > certmonger but I still receive the same error. I will continue poking through > my apache / mod_nss config to see if anything stands out. > > You're still using mod_nss though, right? > > rob I'm still using mod_nss. I have discovered that I might be focusing on a symptom here rather than the core problem. If I restart httpd and then certmonger, the first error returned when certmonger tries to renew the certificates is not "Failure decoding Certificate Signing Request" but rather: "Server failed request, will retry: 4301 (RPC failed at server. Certificate operation cannot be completed: EXCEPTION (You did not provide a valid certificate for this operation))." for two certs, and: "Server failed request, will retry: 907 (RPC failed at server. cannot connect to 'https://HOSTNAME.DOMAIN:443/ca/agent/ca/displayBySerial': [Errno -8053] (SEC_ERROR_BUSY) NSS could not shutdown. Objects are still in use.)." for a third. After some time, I resubmit and the error returned changes to "Failure decoding..." for all three (expired) certs. In the httpd error_log during that time, I see the following errors and traceback: [Sun Oct 06 21:13:14 2013] [error] /usr/lib64/python2.6/getpass.py:83: GetPassWarning: Can not control echo on the terminal. [Sun Oct 06 21:13:14 2013] [error] passwd = fallback_getpass(prompt, stream) [Sun Oct 06 21:13:14 2013] [error] Warning: Password input may be echoed. [Sun Oct 06 21:13:14 2013] [error] Enter password for internal: [Sun Oct 06 21:13:14 2013] [error] exception in PK11 password callback [Sun Oct 06 21:13:14 2013] [error] Traceback (most recent call last): [Sun Oct 06 21:13:14 2013] [error] File "/usr/lib/python2.6/site-packages/ipapython/nsslib.py", line 229, in password_callback [Sun Oct 06 21:13:14 2013] [error] return getpass.getpass("Enter password for %s: " % slot.token_name); [Sun Oct 06 21:13:14 2013] [error] File "/usr/lib64/python2.6/getpass.py", line 83, in unix_getpass [Sun Oct 06 21:13:14 2013] [error] passwd = fallback_getpass(prompt, stream) [Sun Oct 06 21:13:14 2013] [error] File "/usr/lib64/python2.6/getpass.py", line 118, in fallback_getpass [Sun Oct 06 21:13:14 2013] [error] return _raw_input(prompt, stream) [Sun Oct 06 21:13:14 2013] [error] File "/usr/lib64/python2.6/getpass.py", line 135, in _raw_input [Sun Oct 06 21:13:14 2013] [error] raise EOFError [Sun Oct 06 21:13:14 2013] [error] EOFError It looks like perhaps there is a problem retrieving a password (for an NSS db?) with getpass. Thanks for your help so far, Rob. Much appreciated. Cheers, --Ryan From bpk678 at gmail.com Wed Oct 23 21:08:35 2013 From: bpk678 at gmail.com (Brendan Kearney) Date: Wed, 23 Oct 2013 17:08:35 -0400 Subject: [Freeipa-users] No $ORIGIN directive in bind-dyndb-ldap In-Reply-To: <526778D4.2020607@redhat.com> References: <1382451974.19960.6.camel@desktop.bpk2.com> <1382473456.19960.23.camel@desktop.bpk2.com> <526778D4.2020607@redhat.com> Message-ID: <1382562515.19960.37.camel@desktop.bpk2.com> > Do you plan to use FreeIPA command line interface or not? > > With FreeIPA, you can create equivalent records with this set of commands: > $ ipa dnszone-add bpk2.com > $ ipa dnsrecord-add bpk2.com _kerberos --txt-rec=... > etc. > > Those commands allow you to create almost equivalent data in LDAP. This > doesn't work for you? > > Please note that dnsrecord-add command contains zone name (as the first > argument), so the FQDN can be constructed from the first and second argument. i am using bind-dyndb-ldap without FreeIPA, or 389. It is on Fedora, with OpenLDAP and a bunch of steps to get it working. i am using phpLdapAdmin to administrate the ldap instance and have created the needed configs in ldap, using the existing sample ldif as a guide. > > DNS zone is represented by LDAP object which contains all other named in the zone: > idnsname=bkp2.com,cn=dns,dc=ipa,dc=test > > Each name inside particular zone is represented by own LDAP object: > idnsname=_kerberos, idnsname=bkp2.com,cn=dns,dc=ipa,dc=test > > As a result, FQDN can be constructed for each relative name in the zone simply > by concatenating second and first idnsname components. > > Is it now clearer why bind-dyndb-ldap don't have equivalent of $ORIGIN? no. you say that the FQDN can be constructed by stinging together 2 of the values in the DN, but neither bind, nor the bind-dyndb-ldap "plug-in" are doing that. > > attached is my forward zone (frozen before copying data, so that the jnl > > entries were written out). > > > > the desired outcome is to have zones configured so that unqualified > > queries are looked up locally and return properly, if appropriate, > > before being forwarded to any forwarders or via the hints to the roots > > or whatever is configured to be done with a record that does not have a > > locally authoritative entry. > > AFAIK 'unqualified' names are purely client-side thing. I belive that all > names have to be expanded to FQDN *before* the query is sent to any DNS > server. (See search directive in /etc/resolv.conf.) > and there are no conceivable scenarios where an unqualified query could ever get to the bind server? regardless of opinions on how frequent/infrequent it could happen, the fact is that this is an entirely legitimate scenario that improperly fails with an error. > > while zytrax does have good articles, the reference i provided is > > directly out of the bind admin guide, and likely a more authoritative > > voice on the subject. > > I agree. Please note that both sources say the same information, just in other > words. > > > i have validated that when no $ORIGIN directive is set, a query using > > the short name will fail when looked up locally, and will either be > > forwarded or recursively searched for. the examples i provided go > > against bind+bind-dyndb-ldap, and the short name query fails. doing the > > same lookups against my straight bind instance, using the attached zone > > file, gives authoritative responses for both short and FQDN queries. > > I belive that your zone file will be perfectly functional if you remove origin > completely. You will have to replace name for SOA record. it does not matter what will or will not work with my zones. what i am trying to account for is lookups failing against bind when using the bind-dyndb-ldap backend and a short name is specified. since the $ORIGIN directive is written into RFC, why is it electively being dropped, resulting in a broken implementation because of the lack of compliance? > $ diff -u bpk2.com.db.orig bpk2.com.db.noorigin > --- bpk2.com.db.orig 2013-10-23 09:09:47.568113243 +0200 > +++ bpk2.com.db.noorigin 2013-10-23 09:10:09.347112464 +0200 > @@ -1,6 +1,5 @@ > -$ORIGIN . > $TTL 3600 ; 1 hour > -bpk2.com IN SOA server.bpk2.com. root.server.bpk2.com. ( > +@ IN SOA server.bpk2.com. root.server.bpk2.com. ( > 21684 ; serial > 10800 ; refresh (3 hours) > 3600 ; retry (1 hour) > @@ -9,7 +8,6 @@ > ) > NS vpn.bpk2.com. > NS server.bpk2.com. > -$ORIGIN bpk2.com. > $TTL 600 ; 10 minutes > _kerberos TXT "BPK2.COM" > $TTL 5 ; 5 seconds > > > I assume that your zone definition in named.conf looks like: > zone "bpk2.com." IN { > type master; > file "bpk2.com.db"; > }; > > As a result, default origin "bpk2.com." is appended to all names in zone file > - and that is it. > > Do not forget to bump serial and check server logs if the new zone file was > loaded correctly ... > > Have a nice day! > From rcritten at redhat.com Thu Oct 24 01:58:13 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 23 Oct 2013 21:58:13 -0400 Subject: [Freeipa-users] Failure decoding Certificate Signing Request In-Reply-To: <4236DE1EFED4374EA69B197EB5AC27573514A59D@S-ITSV-MBX02P.ead.ubc.ca> References: <3fc2cb83-f64c-450b-a9d9-d4612966bbc1@S-ITSV-HUB01P.ead.ubc.ca> <52666FE7.4060406@redhat.com> <4236DE1EFED4374EA69B197EB5AC275735147A7B@S-ITSV-MBX02P.ead.ubc.ca> <5266B9C7.5090507@redhat.com> <4236DE1EFED4374EA69B197EB5AC275735148D59@S-ITSV-MBX02P.ead.ubc.ca> <526730C8.7030105@redhat.com> <4236DE1EFED4374EA69B197EB5AC27573514A59D@S-ITSV-MBX02P.ead.ubc.ca> Message-ID: <52687EB5.9030000@redhat.com> Thomson, Ryan wrote: >> -----Original Message----- >> From: Rob Crittenden [mailto:rcritten at redhat.com] >> Sent: Tuesday, October 22, 2013 7:13 PM >> To: Thomson, Ryan; freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] Failure decoding Certificate Signing Request >> >> Thomson, Ryan wrote: >>>> -----Original Message----- >>>> From: Rob Crittenden [mailto:rcritten at redhat.com] >>>> Sent: Tuesday, October 22, 2013 10:46 AM >>>> To: Thomson, Ryan; freeipa-users at redhat.com >>>> Subject: Re: [Freeipa-users] Failure decoding Certificate Signing >>>> Request >>>> >>>> Thomson, Ryan wrote: >>>>> Hi Rob, >>>>> >>>>>> There is some duplication in the error strings (ticket >>>>>> https://fedorahosted.org/freeipa/ticket/3988). Did you add a number >>>>>> prefix to yours, I see a 3 -in the error. If so, by my calculation, >>>>>> this works out to be an NSPRError. It would be helpful to know what >>>>>> exception is being raised, which we don't do. >>>>> >>>>> I did prefix numbers to the various error strings. >>>>> >>>>>> Either way, if you could enhance each occurrence of 'Failure >>>>>> decoding Certificate Signing Request' in /usr/lib/python*/site- >>>>>> packages/ipalib/plugins/cert.py to something like: >>>>>> >>>>>> except NSPEError, nsprerr: >>>>>> raise errors.CertificateOperationError(error=_('Failure >>>>>> decoding Certificate Signing Request" %s') % nsprerr) >>>>>> >>>>>> You'll need to restart the httpd process afterwards. This should >>>>>> give us the real reason for the failure. >>>>> >>>>> Done. The error I get now is: >>>>> >>>>> Server failed request, will retry: 4301 (RPC failed at server. >>>>> Certificate >>>> operation cannot be completed: Failure decoding Certificate Signing >>>> Request" [Errno -8018] error (-8018) unknown). >>>> >>>> Hmm, very strange indeed. >>>> >>>> It should be using the NSS database initialized in mod_nss for >>>> Apache, which should remain open and available for wsgi. It almost >>>> seems like the database has been shut down. >>>> >>>> Can you add a logging event to log the value of nss.nss_is_initialized()? >>>> >>>> Have you done any configuration customization in Apache or mod_nss? >>>> >>>> thanks >>>> >>>> rob >>> >>> The return value of nss.nss_is_initialized() is False when I resubmit the >> (expired) certs through certmonger. >> >> Ok, that is the core of the issue then. pkcs10.load_certificate() will initialize >> NSS If it isn't already and I'm guessing that is failing and is the source of this >> exception. >> >>> I did have a custom config for apache that configured a virtual host with >> SSL. I have disabled that config and restarted httpd, resubmitted the certs to >> certmonger but I still receive the same error. I will continue poking through >> my apache / mod_nss config to see if anything stands out. >> >> You're still using mod_nss though, right? >> >> rob > > I'm still using mod_nss. > > I have discovered that I might be focusing on a symptom here rather than the core problem. If I restart httpd and then certmonger, the first error returned when certmonger tries to renew the certificates is not "Failure decoding Certificate Signing Request" but rather: > > "Server failed request, will retry: 4301 (RPC failed at server. Certificate operation cannot be completed: EXCEPTION (You did not provide a valid certificate for this operation))." > > for two certs, and: > > "Server failed request, will retry: 907 (RPC failed at server. cannot connect to 'https://HOSTNAME.DOMAIN:443/ca/agent/ca/displayBySerial': [Errno -8053] (SEC_ERROR_BUSY) NSS could not shutdown. Objects are still in use.)." > > for a third. > > After some time, I resubmit and the error returned changes to "Failure decoding..." for all three (expired) certs. > > In the httpd error_log during that time, I see the following errors and traceback: > > [Sun Oct 06 21:13:14 2013] [error] /usr/lib64/python2.6/getpass.py:83: GetPassWarning: Can not control echo on the terminal. > [Sun Oct 06 21:13:14 2013] [error] passwd = fallback_getpass(prompt, stream) > [Sun Oct 06 21:13:14 2013] [error] Warning: Password input may be echoed. > [Sun Oct 06 21:13:14 2013] [error] Enter password for internal: > [Sun Oct 06 21:13:14 2013] [error] exception in PK11 password callback > [Sun Oct 06 21:13:14 2013] [error] Traceback (most recent call last): > [Sun Oct 06 21:13:14 2013] [error] File "/usr/lib/python2.6/site-packages/ipapython/nsslib.py", line 229, in password_callback > [Sun Oct 06 21:13:14 2013] [error] return getpass.getpass("Enter password for %s: " % slot.token_name); > [Sun Oct 06 21:13:14 2013] [error] File "/usr/lib64/python2.6/getpass.py", line 83, in unix_getpass > [Sun Oct 06 21:13:14 2013] [error] passwd = fallback_getpass(prompt, stream) > [Sun Oct 06 21:13:14 2013] [error] File "/usr/lib64/python2.6/getpass.py", line 118, in fallback_getpass > [Sun Oct 06 21:13:14 2013] [error] return _raw_input(prompt, stream) > [Sun Oct 06 21:13:14 2013] [error] File "/usr/lib64/python2.6/getpass.py", line 135, in _raw_input > [Sun Oct 06 21:13:14 2013] [error] raise EOFError > [Sun Oct 06 21:13:14 2013] [error] EOFError > > It looks like perhaps there is a problem retrieving a password (for an NSS db?) with getpass. > > Thanks for your help so far, Rob. Much appreciated. I think this still points to NSS not being initialized. The way we currently use NSS in the server is Apache fires things up using mod_nss, then because we are a child of Apache via mod_wsgi, we inherit the open NSS database in /etc/httpd/alias. This gives us the CA cert and the client cert we need in order to talk to dogtag. What I thought, and the excellent debugging above confirms, is that at some point the NSS database is being shut down. At some point we need to do some crypto and try to initialize it ourselves to no avail. We shouldn't ever need to do it in the server and thus don't have access to PINs and such because we don't need them. We do initialize things from time to time on the client side but we tend to do a database-less initialization (nss_init_nodb()). I'm not really sure what this tells us though. It would appear that SSL is working in Apache, because you are able to get far enough to make a request and have it fail. So the NSS database is still initialized in Apache, but for some reason the wsgi code doesn't seem to agree. Would it be possible for you to stop and restart Apache and run some simple IPA command like ipa user-show admin (and let me know if it succeeds)? Then send me the error_log? If you are in SELinux enforcing mode it would also be helpful to check for any AVCs. Maybe we simply can't access the database. thanks rob From pspacek at redhat.com Thu Oct 24 13:02:44 2013 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 24 Oct 2013 15:02:44 +0200 Subject: [Freeipa-users] No $ORIGIN directive in bind-dyndb-ldap In-Reply-To: <1382562515.19960.37.camel@desktop.bpk2.com> References: <1382451974.19960.6.camel@desktop.bpk2.com> <1382473456.19960.23.camel@desktop.bpk2.com> <526778D4.2020607@redhat.com> <1382562515.19960.37.camel@desktop.bpk2.com> Message-ID: <52691A74.4060502@redhat.com> On 23.10.2013 23:08, Brendan Kearney wrote: >> Do you plan to use FreeIPA command line interface or not? >> >> With FreeIPA, you can create equivalent records with this set of commands: >> $ ipa dnszone-add bpk2.com >> $ ipa dnsrecord-add bpk2.com _kerberos --txt-rec=... >> etc. >> >> Those commands allow you to create almost equivalent data in LDAP. This >> doesn't work for you? >> >> Please note that dnsrecord-add command contains zone name (as the first >> argument), so the FQDN can be constructed from the first and second argument. > > i am using bind-dyndb-ldap without FreeIPA, or 389. It is on Fedora, > with OpenLDAP and a bunch of steps to get it working. i am using > phpLdapAdmin to administrate the ldap instance and have created the > needed configs in ldap, using the existing sample ldif as a guide. > >> >> DNS zone is represented by LDAP object which contains all other named in the zone: >> idnsname=bkp2.com,cn=dns,dc=ipa,dc=test >> >> Each name inside particular zone is represented by own LDAP object: >> idnsname=_kerberos, idnsname=bkp2.com,cn=dns,dc=ipa,dc=test >> >> As a result, FQDN can be constructed for each relative name in the zone simply >> by concatenating second and first idnsname components. >> >> Is it now clearer why bind-dyndb-ldap don't have equivalent of $ORIGIN? > > no. you say that the FQDN can be constructed by stinging together 2 of > the values in the DN, but neither bind, nor the bind-dyndb-ldap > "plug-in" are doing that. In that case it is a bug. Please be so kind and provide us with all the information as described at https://fedorahosted.org/bind-dyndb-ldap/wiki/BugReporting#a3.Whatweneedtoknow >>> attached is my forward zone (frozen before copying data, so that the jnl >>> entries were written out). >>> >>> the desired outcome is to have zones configured so that unqualified >>> queries are looked up locally and return properly, if appropriate, >>> before being forwarded to any forwarders or via the hints to the roots >>> or whatever is configured to be done with a record that does not have a >>> locally authoritative entry. >> >> AFAIK 'unqualified' names are purely client-side thing. I belive that all >> names have to be expanded to FQDN *before* the query is sent to any DNS >> server. (See search directive in /etc/resolv.conf.) >> > > and there are no conceivable scenarios where an unqualified query could > ever get to the bind server? regardless of opinions on how > frequent/infrequent it could happen, the fact is that this is an > entirely legitimate scenario that improperly fails with an error. DNS server blindly follows algorithm described in http://tools.ietf.org/html/rfc6672#section-3.2 to construct the answer. If you want to resolve unqualified name (e.g. QNAME = 'server.') then the name in question has to be present in 'nearest ancestor to QNAME' (see 2nd point of the server's algorithm in RFC 6672). There is only one possible 'nearest ancestor' for unqualified names - the root. >>> while zytrax does have good articles, the reference i provided is >>> directly out of the bind admin guide, and likely a more authoritative >>> voice on the subject. >> >> I agree. Please note that both sources say the same information, just in other >> words. >> >>> i have validated that when no $ORIGIN directive is set, a query using >>> the short name will fail when looked up locally, and will either be >>> forwarded or recursively searched for. the examples i provided go >>> against bind+bind-dyndb-ldap, and the short name query fails. doing the >>> same lookups against my straight bind instance, using the attached zone >>> file, gives authoritative responses for both short and FQDN queries. >> >> I belive that your zone file will be perfectly functional if you remove origin >> completely. You will have to replace name for SOA record. > > it does not matter what will or will not work with my zones. what i am > trying to account for is lookups failing against bind when using the > bind-dyndb-ldap backend and a short name is specified. since the We will help you debug the problem, but we need to see exact configuration, parameters of the query, logs and possibly tcpdump. > $ORIGIN directive is written into RFC, why is it electively being > dropped, resulting in a broken implementation because of the lack of > compliance? I wasn't 100% accurate in previous post about this aspect. Technically, $ORIGIN is stored in LDAP - it is the second idnsname component of the DN (for names under zone apex). Examples: - $ORIGIN for zone itself is implicitly '.': idnsname=zone-name, cn=dns Resulting DNS name: zone-name. - $ORIGIN for any name under zone apex is the second idnsname component: idnsname=name, idnsname=origin, cn=dns Resulting DNS name: name.origin. I hope that this explains how the LDAP schema represents DNS data. >> $ diff -u bpk2.com.db.orig bpk2.com.db.noorigin >> --- bpk2.com.db.orig 2013-10-23 09:09:47.568113243 +0200 >> +++ bpk2.com.db.noorigin 2013-10-23 09:10:09.347112464 +0200 >> @@ -1,6 +1,5 @@ >> -$ORIGIN . >> $TTL 3600 ; 1 hour >> -bpk2.com IN SOA server.bpk2.com. root.server.bpk2.com. ( >> +@ IN SOA server.bpk2.com. root.server.bpk2.com. ( >> 21684 ; serial >> 10800 ; refresh (3 hours) >> 3600 ; retry (1 hour) >> @@ -9,7 +8,6 @@ >> ) >> NS vpn.bpk2.com. >> NS server.bpk2.com. >> -$ORIGIN bpk2.com. >> $TTL 600 ; 10 minutes >> _kerberos TXT "BPK2.COM" >> $TTL 5 ; 5 seconds >> >> >> I assume that your zone definition in named.conf looks like: >> zone "bpk2.com." IN { >> type master; >> file "bpk2.com.db"; >> }; >> >> As a result, default origin "bpk2.com." is appended to all names in zone file >> - and that is it. >> >> Do not forget to bump serial and check server logs if the new zone file was >> loaded correctly ... >> >> Have a nice day! -- Petr^2 Spacek From ryan.thomson at ubc.ca Thu Oct 24 16:58:12 2013 From: ryan.thomson at ubc.ca (Thomson, Ryan) Date: Thu, 24 Oct 2013 16:58:12 +0000 Subject: [Freeipa-users] Failure decoding Certificate Signing Request In-Reply-To: <52687EB5.9030000@redhat.com> References: <3fc2cb83-f64c-450b-a9d9-d4612966bbc1@S-ITSV-HUB01P.ead.ubc.ca> <52666FE7.4060406@redhat.com> <4236DE1EFED4374EA69B197EB5AC275735147A7B@S-ITSV-MBX02P.ead.ubc.ca> <5266B9C7.5090507@redhat.com> <4236DE1EFED4374EA69B197EB5AC275735148D59@S-ITSV-MBX02P.ead.ubc.ca> <526730C8.7030105@redhat.com> <4236DE1EFED4374EA69B197EB5AC27573514A59D@S-ITSV-MBX02P.ead.ubc.ca> <52687EB5.9030000@redhat.com> Message-ID: <4236DE1EFED4374EA69B197EB5AC27573514BC5F@S-ITSV-MBX02P.ead.ubc.ca> > -----Original Message----- > From: Rob Crittenden [mailto:rcritten at redhat.com] > Sent: Wednesday, October 23, 2013 6:58 PM > To: Thomson, Ryan; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Failure decoding Certificate Signing Request > > I think this still points to NSS not being initialized. The way we currently use > NSS in the server is Apache fires things up using mod_nss, then because we > are a child of Apache via mod_wsgi, we inherit the open NSS database in > /etc/httpd/alias. This gives us the CA cert and the client cert we need in > order to talk to dogtag. > > What I thought, and the excellent debugging above confirms, is that at some > point the NSS database is being shut down. At some point we need to do > some crypto and try to initialize it ourselves to no avail. We shouldn't ever > need to do it in the server and thus don't have access to PINs and such > because we don't need them. We do initialize things from time to time on > the client side but we tend to do a database-less initialization > (nss_init_nodb()). > > I'm not really sure what this tells us though. It would appear that SSL is > working in Apache, because you are able to get far enough to make a > request and have it fail. So the NSS database is still initialized in Apache, but > for some reason the wsgi code doesn't seem to agree. > > Would it be possible for you to stop and restart Apache and run some simple > IPA command like ipa user-show admin (and let me know if it succeeds)? > Then send me the error_log? > > If you are in SELinux enforcing mode it would also be helpful to check for any > AVCs. Maybe we simply can't access the database. > > thanks > > rob I am able to stop/wait/start apache and then execute "ipa user-show admin" successfully. Relevant error log from /var/log/httpd/error_log: [Mon Oct 07 18:36:51 2013] [error] ipa: DEBUG: WSGI wsgi_dispatch.__call__: [Mon Oct 07 18:36:51 2013] [error] ipa: DEBUG: WSGI xmlserver.__call__: [Mon Oct 07 18:36:51 2013] [error] ipa: DEBUG: Created connection context.ldap2 [Mon Oct 07 18:36:51 2013] [error] ipa: DEBUG: WSGI WSGIExecutioner.__call__: [Mon Oct 07 18:36:51 2013] [error] ipa: DEBUG: raw: user_show(u'admin', rights=False, all=False, raw=False, version=u'2.46') [Mon Oct 07 18:36:51 2013] [error] ipa: DEBUG: user_show(u'admin', rights=False, all=False, raw=False, version=u'2.46') [Mon Oct 07 18:36:51 2013] [error] ipa: DEBUG: retrieving schema for SchemaCache url=ldapi://%2fvar%2frun%2fslapd-FMRI-UBC-CA.socket conn= [Mon Oct 07 18:36:52 2013] [error] ipa: DEBUG: get_memberof: entry_dn=uid=admin,cn=users,cn=accounts,dc=fully,dc=qualified,dc=domain memberof=[ipapython.dn.DN('cn=admins,cn=groups,cn=accounts,dc=fully,dc=qualified,dc=domain'), ipapython.dn.DN('cn=replication administrators,cn=privileges,cn=pbac,dc=fully,dc=qualified,dc=domain'), ipapython.dn.DN('cn=add replication agreements,cn=permissions,cn=pbac,dc=fully,dc=qualified,dc=domain'), ipapython.dn.DN('cn=modify replication agreements,cn=permissions,cn=pbac,dc=fully,dc=qualified,dc=domain'), ipapython.dn.DN('cn=remove replication agreements,cn=permissions,cn=pbac,dc=fully,dc=qualified,dc=domain'), ipapython.dn.DN('cn=host enrollment,cn=privileges,cn=pbac,dc=fully,dc=qualified,dc=domain'), ipapython.dn.DN('cn=manage host keytab,cn=permissions,cn=pbac,dc=fully,dc=qualified,dc=domain'), ipapython.dn.DN('cn=enroll a host,cn=permissions,cn=pbac,dc=fully,dc=qualified,dc=domain'), ipapython.dn.DN('cn=add krbprincipalname to a host,cn=permissions,cn=pbac,dc=fully,dc=qualified,dc=domain'), ipapython.dn.DN('cn=unlock user accounts,cn=permissions,cn=pbac,dc=fully,dc=qualified,dc=domain'), ipapython.dn.DN('cn=manage service keytab,cn=permissions,cn=pbac,dc=fully,dc=qualified,dc=domain'), ipapython.dn.DN('cn=trust admins,cn=groups,cn=accounts,dc=fully,dc=qualified,dc=domain')] [Mon Oct 07 18:36:52 2013] [error] ipa: DEBUG: get_memberof: result direct=[ipapython.dn.DN('cn=admins,cn=groups,cn=accounts,dc=fully,dc=qualified,dc=domain'), ipapython.dn.DN('cn=trust admins,cn=groups,cn=accounts,dc=fully,dc=qualified,dc=domain')] indirect=[ipapython.dn.DN('cn=replication administrators,cn=privileges,cn=pbac,dc=fully,dc=qualified,dc=domain'), ipapython.dn.DN('cn=add replication agreements,cn=permissions,cn=pbac,dc=fully,dc=qualified,dc=domain'), ipapython.dn.DN('cn=modify replication agreements,cn=permissions,cn=pbac,dc=fully,dc=qualified,dc=domain'), ipapython.dn.DN('cn=remove replication agreements,cn=permissions,cn=pbac,dc=fully,dc=qualified,dc=domain'), ipapython.dn.DN('cn=host enrollment,cn=privileges,cn=pbac,dc=fully,dc=qualified,dc=domain'), ipapython.dn.DN('cn=manage host keytab,cn=permissions,cn=pbac,dc=fully,dc=qualified,dc=domain'), ipapython.dn.DN('cn=enroll a host,cn=permissions,cn=pbac,dc=fully,dc=qualified,dc=domain'), ipapython.dn.DN('cn=add krbprincipalname to a host,cn=permissions,cn=pbac,dc=fully,dc=qualified,dc=domain'), ipapython.dn.DN('cn=unlock user accounts,cn=permissions,cn=pbac,dc=fully,dc=qualified,dc=domain'), ipapython.dn.DN('cn=manage service keytab,cn=permissions,cn=pbac,dc=fully,dc=qualified,dc=domain')] [Mon Oct 07 18:36:52 2013] [error] ipa: INFO: admin at FULLY.QUALIFIED.DOMAIN: user_show(u'admin', rights=False, all=False, raw=False, version=u'2.46'): SUCCESS [Mon Oct 07 18:36:52 2013] [error] ipa: DEBUG: response: entries returned 1 [Mon Oct 07 18:36:52 2013] [error] ipa: DEBUG: no session id in request, generating empty session data with id=47992da2d1630a11bc106cc6390147e8 [Mon Oct 07 18:36:52 2013] [error] ipa: DEBUG: store session: session_id=47992da2d1630a11bc106cc6390147e8 start_timestamp=2013-10-07T18:36:52 access_timestamp=2013-10-07T18:36:52 expiration_timestamp=1969-12-31T16:00:00 [Mon Oct 07 18:36:52 2013] [error] ipa: DEBUG: finalize_kerberos_acquisition: xmlserver ccache_name="FILE:/tmp/krb5cc_apache_mFOaRq" session_id="47992da2d1630a11bc106cc6390147e8" [Mon Oct 07 18:36:52 2013] [error] ipa: DEBUG: reading ccache data from file "/tmp/krb5cc_apache_mFOaRq" [Mon Oct 07 18:36:52 2013] [error] ipa: DEBUG: get_credential_times: principal=HTTP/HOSTNAME.FULLY.QUALIFIED.DOMAIN at FULLY.QUALIFIED.DOMAIN, authtime=10/07/13 18:36:21, starttime=10/07/13 18:36:51, endtime=10/08/13 18:36:19, renew_till=12/31/69 16:00:00 [Mon Oct 07 18:36:52 2013] [error] ipa: DEBUG: KRB5_CCache FILE:/tmp/krb5cc_apache_mFOaRq endtime=1381282579 (10/08/13 18:36:19) [Mon Oct 07 18:36:52 2013] [error] ipa: DEBUG: set_session_expiration_time: duration_type=inactivity_timeout duration=1200 max_age=1381282279 expiration=1381197412.49 (2013-10-07T18:56:52) [Mon Oct 07 18:36:52 2013] [error] ipa: DEBUG: store session: session_id=47992da2d1630a11bc106cc6390147e8 start_timestamp=2013-10-07T18:36:52 access_timestamp=2013-10-07T18:36:52 expiration_timestamp=2013-10-07T18:56:52 [Mon Oct 07 18:36:52 2013] [error] ipa: DEBUG: Destroyed connection context.ldap2 And the command output with debugging on: root at HOSTNAME:~ # date Mon Oct 7 18:36:43 PDT 2013 root at HOSTNAME:~ # klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: admin at FULLY.QUALIFIED.DOMAIN Valid starting Expires Service principal 10/07/13 18:36:21 10/08/13 18:36:19 krbtgt/FULLY.QUALIFIED.DOMAIN at FULLY.QUALIFIED.DOMAIN root at HOSTNAME:~ # ipa user-show admin ipa: DEBUG: importing all plugin modules in '/usr/lib/python2.6/site-packages/ipalib/plugins'... ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/aci.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/automember.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/automount.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/baseldap.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/batch.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/cert.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/config.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/delegation.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/dns.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/group.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/hbacrule.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/hbacsvc.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/hbacsvcgroup.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/hbactest.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/host.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/hostgroup.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/idrange.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/internal.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/kerberos.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/krbtpolicy.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/migration.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/misc.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/netgroup.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/passwd.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/permission.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/ping.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/privilege.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/pwpolicy.py' ipa: DEBUG: args=klist -V ipa: DEBUG: stdout=Kerberos 5 version 1.10.3 ipa: DEBUG: stderr= ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/role.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/selfservice.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/selinuxusermap.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/service.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/sudocmd.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/sudocmdgroup.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/sudorule.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/trust.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/user.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/virtual.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/xmlclient.py' ipa: DEBUG: args=keyctl search @s user ipa_session_cookie:admin at FULLY.QUALIFIED.DOMAIN ipa: DEBUG: stdout=311493198 ipa: DEBUG: stderr= ipa: DEBUG: args=keyctl pipe 311493198 ipa: DEBUG: stdout=ipa_session=0b5649ff40d800567f75f34aef2cce11; Domain=HOSTNAME.FULLY.QUALIFIED.DOMAIN; Path=/ipa; Expires=Mon, 07 Oct 2013 04:29:31 GMT; Secure; HttpOnly ipa: DEBUG: stderr= ipa: DEBUG: found session_cookie in persistent storage for principal 'admin at FULLY.QUALIFIED.DOMAIN', cookie: 'ipa_session=0b5649ff40d800567f75f34aef2cce11; Domain=HOSTNAME.FULLY.QUALIFIED.DOMAIN; Path=/ipa; Expires=Mon, 07 Oct 2013 04:29:31 GMT; Secure; HttpOnly' ipa: DEBUG: deleting session data for principal 'admin at FULLY.QUALIFIED.DOMAIN': cookie named 'ipa_session'; expired at Mon, 07 Oct 2013 04:29:31 GMT' ipa: DEBUG: args=keyctl search @s user ipa_session_cookie:admin at FULLY.QUALIFIED.DOMAIN ipa: DEBUG: stdout=311493198 ipa: DEBUG: stderr= ipa: DEBUG: args=keyctl unlink 311493198 @s ipa: DEBUG: stdout= ipa: DEBUG: stderr= ipa: INFO: trying https://HOSTNAME.FULLY.QUALIFIED.DOMAIN/ipa/xml ipa: DEBUG: Created connection context.xmlclient ipa: DEBUG: raw: user_show(u'admin', rights=False, all=False, raw=False, version=u'2.46') ipa: DEBUG: user_show(u'admin', rights=False, all=False, raw=False, version=u'2.46') ipa: INFO: Forwarding 'user_show' to server u'https://HOSTNAME.FULLY.QUALIFIED.DOMAIN/ipa/xml' ipa: DEBUG: NSSConnection init HOSTNAME.FULLY.QUALIFIED.DOMAIN ipa: DEBUG: Connecting: 142.103.89.209:0 ipa: DEBUG: auth_certificate_callback: check_sig=True is_server=False Data: Version: 3 (0x2) Serial Number: 22 (0x16) Signature Algorithm: Algorithm: PKCS #1 SHA-256 With RSA Encryption Issuer: CN=Certificate Authority,O=FULLY.QUALIFIED.DOMAIN Validity: Not Before: Thu Apr 11 23:23:18 2013 UTC Not After: Tue Oct 08 23:23:18 2013 UTC Subject: CN=HOSTNAME.FULLY.QUALIFIED.DOMAIN,O=FULLY.QUALIFIED.DOMAIN Subject Public Key Info: Public Key Algorithm: Algorithm: PKCS #1 RSA Encryption RSA Public Key: Modulus: b0:b0:50:1f:e9:72:26:d5:dd:ff:70:ba:66:bb:a6:90: bf:02:e9:7f:9b:73:10:9b:d9:a5:84:f7:34:c6:ed:03: ca:48:11:5e:50:9d:19:9f:22:24:8a:17:35:69:d0:69: 0e:f7:a8:37:2d:46:11:98:5e:df:a8:2c:93:96:a7:66: e4:3d:20:c1:72:e2:94:46:36:0b:84:44:2e:94:a9:98: 7a:da:1d:3a:f0:13:53:47:0d:b1:30:21:9d:55:a8:32: 09:be:c6:d3:98:2e:6c:a1:a1:34:02:9a:7f:df:ba:4b: f1:c9:10:c4:0b:70:e7:08:de:98:24:c4:a6:d2:4a:e5: 0c:41:e7:f6:80:a5:7a:25:b7:8d:0e:b9:aa:b7:ff:4f: cd:85:b5:3e:1c:e0:6f:83:e5:c1:86:ec:e0:6f:dd:f2: 3a:6b:60:ce:3f:63:46:9a:75:5e:e3:20:76:d3:36:53: 07:1f:34:77:a7:42:3e:58:0d:30:15:f6:47:e3:a2:d3: 46:b0:cf:62:1b:00:2a:28:18:39:5c:35:3b:ff:c6:7a: c2:9d:08:75:17:92:d3:7f:58:6d:c8:bc:55:c3:6f:3e: 17:f7:55:bf:e6:3c:af:cc:8a:18:59:f1:46:50:07:36: 09:38:87:4b:38:67:44:f6:b6:bb:cf:f0:af:88:30:5f Exponent: 65537 (0x10001) Signed Extensions: (5) Name: Certificate Authority Key Identifier Critical: False Key ID: 3a:41:f5:c1:b7:ff:bb:79:13:d1:23:92:61:16:fc:7d: a7:d1:82:d2 Serial Number: None General Names: [0 total] Name: Authority Information Access Critical: False Name: Certificate Key Usage Critical: True Usages: Digital Signature Non-Repudiation Key Encipherment Data Encipherment Name: Extended Key Usage Critical: False Usages: TLS Web Server Authentication Certificate Name: Certificate Subject Key ID Critical: False Data: e0:56:1f:d5:73:7c:5f:7f:60:5e:d7:3c:88:43:8d:97: b7:f5:fb:24 Signature: Signature Algorithm: Algorithm: PKCS #1 SHA-256 With RSA Encryption Signature: 85:60:83:4c:d5:80:28:9c:ec:69:b0:26:7a:4f:fc:99: e1:4e:3d:78:54:59:d7:46:b3:cf:fb:81:8e:16:67:18: b4:c4:98:3f:16:54:05:ef:6e:79:5f:62:81:65:e3:a8: e7:7b:68:12:25:1f:af:dc:bf:3a:f7:74:72:9d:1d:51: ae:e8:12:73:4c:a8:19:ad:54:03:22:a6:c0:56:29:1a: cc:70:81:5e:fb:38:c0:f7:16:d5:9b:34:2c:16:43:84: b3:7f:bb:86:83:fd:9a:d7:f5:67:a8:f4:c3:33:58:5e: 89:7a:f6:9f:a8:d7:b6:f9:0b:47:d7:6e:46:53:32:63: e6:da:23:54:89:bc:4f:12:16:6d:eb:d4:f0:55:08:46: 64:69:46:55:20:90:ab:61:c4:f2:b6:d5:50:b5:48:07: c0:f9:da:8e:fb:dd:53:e6:9f:1f:4e:d9:ec:af:a6:ad: 75:76:75:e4:b7:b3:ad:56:52:66:f4:9b:71:0d:b1:92: a1:fc:16:c7:66:41:dd:b4:2f:df:34:ed:ad:29:26:40: 4f:85:a5:98:2c:9b:f0:18:42:3d:97:aa:73:16:3b:ac: 48:a9:8c:af:77:b3:24:d0:0d:07:ff:11:79:a9:24:a8: 2a:08:bd:e1:84:e3:6a:6f:2c:8e:62:78:8e:86:95:73 Fingerprint (MD5): 27:7d:ec:86:4f:07:65:9f:27:1e:eb:c4:af:9b:b0:b1 Fingerprint (SHA1): df:60:7a:1b:54:22:bd:f2:2c:ea:ee:51:17:23:ae:2d: f2:57:69:88 ipa: DEBUG: approved_usage = SSLServer intended_usage = SSLServer ipa: DEBUG: cert valid True for "CN=HOSTNAME.FULLY.QUALIFIED.DOMAIN,O=FULLY.QUALIFIED.DOMAIN" ipa: DEBUG: handshake complete, peer = 142.103.89.209:443 ipa: DEBUG: received Set-Cookie 'ipa_session=47992da2d1630a11bc106cc6390147e8; Domain=HOSTNAME.FULLY.QUALIFIED.DOMAIN; Path=/ipa; Expires=Tue, 08 Oct 2013 01:56:52 GMT; Secure; HttpOnly' ipa: DEBUG: storing cookie 'ipa_session=47992da2d1630a11bc106cc6390147e8; Domain=HOSTNAME.FULLY.QUALIFIED.DOMAIN; Path=/ipa; Expires=Tue, 08 Oct 2013 01:56:52 GMT; Secure; HttpOnly' for principal admin at FULLY.QUALIFIED.DOMAIN ipa: DEBUG: args=keyctl search @s user ipa_session_cookie:admin at FULLY.QUALIFIED.DOMAIN ipa: DEBUG: stdout= ipa: DEBUG: stderr=keyctl_search: Required key not available ipa: DEBUG: args=keyctl search @s user ipa_session_cookie:admin at FULLY.QUALIFIED.DOMAIN ipa: DEBUG: stdout= ipa: DEBUG: stderr=keyctl_search: Required key not available ipa: DEBUG: args=keyctl padd user ipa_session_cookie:admin at FULLY.QUALIFIED.DOMAIN @s ipa: DEBUG: stdout=655885819 ipa: DEBUG: stderr= ipa: DEBUG: Destroyed connection context.xmlclient User login: admin Last name: Administrator Home directory: /home/admin Login shell: /bin/bash UID: 1615800000 GID: 1615800000 Account disabled: False Password: True Member of groups: admins, trust admins Kerberos keys available: True SELinux is currently in permissive mode: root at HOSTNAME:~ # getenforce Permissive Thank you, --Ryan From rcritten at redhat.com Thu Oct 24 18:41:05 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 24 Oct 2013 14:41:05 -0400 Subject: [Freeipa-users] Failure decoding Certificate Signing Request In-Reply-To: <4236DE1EFED4374EA69B197EB5AC27573514BC5F@S-ITSV-MBX02P.ead.ubc.ca> References: <3fc2cb83-f64c-450b-a9d9-d4612966bbc1@S-ITSV-HUB01P.ead.ubc.ca> <52666FE7.4060406@redhat.com> <4236DE1EFED4374EA69B197EB5AC275735147A7B@S-ITSV-MBX02P.ead.ubc.ca> <5266B9C7.5090507@redhat.com> <4236DE1EFED4374EA69B197EB5AC275735148D59@S-ITSV-MBX02P.ead.ubc.ca> <526730C8.7030105@redhat.com> <4236DE1EFED4374EA69B197EB5AC27573514A59D@S-ITSV-MBX02P.ead.ubc.ca> <52687EB5.9030000@redhat.com> <4236DE1EFED4374EA69B197EB5AC27573514BC5F@S-ITSV-MBX02P.ead.ubc.ca> Message-ID: <526969C1.8010802@redhat.com> Thomson, Ryan wrote: >> -----Original Message----- >> From: Rob Crittenden [mailto:rcritten at redhat.com] >> Sent: Wednesday, October 23, 2013 6:58 PM >> To: Thomson, Ryan; freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] Failure decoding Certificate Signing Request >> >> I think this still points to NSS not being initialized. The way we currently use >> NSS in the server is Apache fires things up using mod_nss, then because we >> are a child of Apache via mod_wsgi, we inherit the open NSS database in >> /etc/httpd/alias. This gives us the CA cert and the client cert we need in >> order to talk to dogtag. >> >> What I thought, and the excellent debugging above confirms, is that at some >> point the NSS database is being shut down. At some point we need to do >> some crypto and try to initialize it ourselves to no avail. We shouldn't ever >> need to do it in the server and thus don't have access to PINs and such >> because we don't need them. We do initialize things from time to time on >> the client side but we tend to do a database-less initialization >> (nss_init_nodb()). >> >> I'm not really sure what this tells us though. It would appear that SSL is >> working in Apache, because you are able to get far enough to make a >> request and have it fail. So the NSS database is still initialized in Apache, but >> for some reason the wsgi code doesn't seem to agree. >> >> Would it be possible for you to stop and restart Apache and run some simple >> IPA command like ipa user-show admin (and let me know if it succeeds)? >> Then send me the error_log? >> >> If you are in SELinux enforcing mode it would also be helpful to check for any >> AVCs. Maybe we simply can't access the database. >> >> thanks >> >> rob > > I am able to stop/wait/start apache and then execute "ipa user-show admin" successfully. > Ok, let's try a couple more things. Can you set LogLevel debug in /etc/httpd/conf.d/nss.conf and restart Apache again? This may give us more information on what mod_nss is doing. Next, lets try a different cert command that should also invoke the NSS client within IPA: $ ipa cert-show 22 Can you describe your environment? Do you have multiple IPA masters? Was this a new install at 3.0 or is it an upgrade from 2.2? rob From root at nachtmaus.us Fri Oct 25 11:28:32 2013 From: root at nachtmaus.us (david t. klein) Date: Fri, 25 Oct 2013 06:28:32 -0500 Subject: [Freeipa-users] DNS views: request for comments In-Reply-To: <524AE614.8090808@redhat.com> References: <524AE614.8090808@redhat.com> Message-ID: <00ce01ced175$56e7e560$04b7b020$@us> In a previous life, I was DNS hostmaster for a large Fortune-rated firm for about a year. We used views in the typical way (internal vs external), but we also had a third view, in which we black-holed domains known to either propagate viruses or to be used for C&C. We would forward the traffic to the address hosting that view (an IP anycasted address, hosted on our DNS appliances), which would return the address of our malware analysis lab for known bad zones, and would forward everything else to our recursive/caching DNS proxies. -- 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 Petr Spacek Sent: Tuesday, October 01, 2013 10:11 AM To: freeipa-users at redhat.com Subject: [Freeipa-users] DNS views: request for comments Hello list, we would like to get more details about DNS views and how you use them in real life. Also, any idea how user a interface should work is more than welcome! (If you don't know views, read it as "differentiate answer to a DNS query on client's IP address basics".) Questions are: - For what purpose do you use views? E.g. handling clients inside/outside of company network (e.g. hiding internal names); Selecting nearest server in a big network; Some other weird 'Cloud' scenarios etc. etc. - How many views do you use? - Do you share some data between views? How did you solve that? Do you use some user interface for that? - Do you use DNS updates? (nsupdate/RFC 2136/RFC 3007) Previous discussions about DNS views: https://www.redhat.com/archives/freeipa-users/2012-April/msg00070.html https://www.redhat.com/archives/freeipa-devel/2012-May/msg00208.html Related tickets & bugs: https://fedorahosted.org/freeipa/ticket/2802 https://bugzilla.redhat.com/show_bug.cgi?id=815621 https://fedorahosted.org/freeipa/ticket/3725 https://fedorahosted.org/bind-dyndb-ldap/ticket/69 The next step will be to design LDAP schema for DNS data with views ... I can see three basic options: 1) Resign from any data sharing, which will make the thing pretty easy :-) In that case 'view1' will be represented by one sub-tree in LDAP, 'view2' will be another sub-tree etc. 2) Select one sub-tree which will be 'the base' containing all shared records. All other views will inherit and override data from the shared 'base'. 3) Make it as general as possible and allow multiple levels of inheritance. View3 inherits from View2 and it inherits from Base. (View3 <- View2 <- Base) It is basically generalized variant (2), but it could require different LDAP schema. Please post your opinions! -- Petr^2 Spacek _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3408 / Virus Database: 3222/6767 - Release Date: 10/20/13 From root at nachtmaus.us Fri Oct 25 11:45:20 2013 From: root at nachtmaus.us (david t. klein) Date: Fri, 25 Oct 2013 06:45:20 -0500 Subject: [Freeipa-users] Using IPA on Two Completely Different Domains In-Reply-To: References: Message-ID: <00f301ced177$af838ab0$0e8aa010$@us> The most straightforward and maintainable (from the point of view of sensible and obvious data) is to have two FreeIPA domains, each with Krb5 realm the same as its DNS domain, and then setup cross-realm Krb trusts. HTH -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 Trevor T Kates (Services - 6) Sent: Thursday, October 17, 2013 9:36 AM To: freeipa-users at redhat.com Subject: [Freeipa-users] Using IPA on Two Completely Different Domains Greetings, I?m looking for some advice with respect to implementing an IPA solution on two different domains. Both domains have names that are completely distinct from each other and are out of my control to change. I have IdM 3.0 under CentOS 6.4 supporting one domain and I?d like to put together another IdM instance for the other domain. There is some overlap of users between the two domains. As such, I was wondering if the best solution would be to just treat the domains as completely distinct and manage the IdM instances separately or if there is a way to link them together such that for the users that overlap, modifications only need to be made once and in one place. Thanks, Trevor T. Kates CONFIDENTIALITY NOTICE: This electronic message contains information which may be legally confidential and/or privileged and does not in any case represent a firm ENERGY COMMODITY bid or offer relating thereto which binds the sender without an additional express written confirmation to that effect. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you. _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3408 / Virus Database: 3222/6767 - Release Date: 10/20/13 From abokovoy at redhat.com Fri Oct 25 12:11:07 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 25 Oct 2013 15:11:07 +0300 Subject: [Freeipa-users] Using IPA on Two Completely Different Domains In-Reply-To: <00f301ced177$af838ab0$0e8aa010$@us> References: <00f301ced177$af838ab0$0e8aa010$@us> Message-ID: <20131025121107.GA25335@redhat.com> On Fri, 25 Oct 2013, david t. klein wrote: >The most straightforward and maintainable (from the point of view of >sensible and obvious data) is to have two FreeIPA domains, each with >Krb5 realm the same as its DNS domain, and then setup cross-realm Krb >trusts. Right now FreeIPA does not support trusts with another FreeIPA domain, only with an Active Directory forest. This means that while you would be able to set up cross-realm principals manually and authentication would work, identity for those trusted principals would not be established automatically upon logon to IPA clients in either domain. One would need to make sure SSSD configuration on all machines where users from both realms would need to log-in includes definitions for both IPA domains and krb5.conf would include proper auth_to_local rules for both realms. It is doable, just additional amount of work on top of manual cross-realm trust account creation. In FreeIPA we don't place restrictions on DNS domains in the same IPA realm other than the fact that one of DNS domains for the realm should be equivalent to the realm name (example.com for EXAMPLE.COM) or otherwise cross-forest trust with Active Directory would not work -- Active Directory enforces "domain equal realm" rule and automatically searches for service records in the DNS domain named as realm. IPA machines (clients and servers) can be in whatever DNS domains they want, just that service records for IPA masters should be resolvable in the DNS domain named as realm (again, for AD trusts case, normal GNU/Linux operations do not require that due to domain-realm mapping set up at client enrollment already). In FreeIPA 3.2+ we handle these additional DNS domains through 'ipa realmdomains' CLI commands (hooked up into DNS management, so that each time new DNS domain is encountered, realmdomains list is updated, even if we do not handle it directly) and expose them to the trusted Active Directory domain so that name suffix routing is correctly set up for these additional DNS domains belonging to IPA namespace. However, as we don't yet have formal IPA-IPA trusted relationship, much of work for this case is not automated. -- / Alexander Bokovoy From pspacek at redhat.com Fri Oct 25 13:07:40 2013 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 25 Oct 2013 15:07:40 +0200 Subject: [Freeipa-users] DNS views: request for comments In-Reply-To: <00ce01ced175$56e7e560$04b7b020$@us> References: <524AE614.8090808@redhat.com> <00ce01ced175$56e7e560$04b7b020$@us> Message-ID: <526A6D1C.4010907@redhat.com> Hello, On 25.10.2013 13:28, david t. klein wrote: > In a previous life, I was DNS hostmaster for a large Fortune-rated firm for > about a year. We used views in the typical way (internal vs external), but > we also had a third view, in which we black-holed domains known to either > propagate viruses or to be used for C&C. We would forward the traffic to the > address hosting that view (an IP anycasted address, hosted on our DNS > appliances), which would return the address of our malware analysis lab for > known bad zones, and would forward everything else to our recursive/caching > DNS proxies. This is very interesting. Could you elaborate how clients were directed to the third view? I.e. how is the a query associated with the view? External = IP addresses outside corporate network Internal = IP addresses inside corporate network Blackhole = ? I'm not following ... Did you mean that the 'internal' view contains some set of 'well known names' and those names were (only in the internal view) redirected to the lab? Or something else? Could you tell us if the following proposal for DNS views in FreeIPA seems okay to you, please? The proposal: - There is one default view: Any zones and records can be configured in this view. The default view can be even empty. - Other views 'inherit' data from the default view. Inheritance works in this way: Example: Default view definition: - gateway.example.com. A 203.0.113.66 - gateway.example.com. TXT "this record came from base" - example.com MX 10 gateway.example.com. Another-view definition (with implicit inheritance from default view): - gateway.example.com. A 10.1.1.1 Result for 'another-view': - gateway.example.com. A 10.1.1.1 - example.com MX 10 gateway.example.com. => A and TXT records for the name 'gateway.example.com.' from default view were not inherited because override was present in the 'another-view'. => MX record for name 'example.com' was inherited because there is no override with this name in the view. => Modification done in 'default view' will not affect 'another-view' in any way if a override is present, so there can't be information leak from 'default' view (I mean a leak caused by modification of existing record). Any feedback is more than welcome. Thank you very much for your time! Petr^2 Spacek > -- > 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 Petr Spacek > Sent: Tuesday, October 01, 2013 10:11 AM > To: freeipa-users at redhat.com > Subject: [Freeipa-users] DNS views: request for comments > > Hello list, > > we would like to get more details about DNS views and how you use them in > real > life. Also, any idea how user a interface should work is more than welcome! > > (If you don't know views, read it as "differentiate answer to a DNS query on > > client's IP address basics".) > > > Questions are: > - For what purpose do you use views? > E.g. handling clients inside/outside of company network (e.g. hiding > internal > names); Selecting nearest server in a big network; Some other weird 'Cloud' > scenarios etc. etc. > > - How many views do you use? > > - Do you share some data between views? How did you solve that? Do you use > some user interface for that? > > - Do you use DNS updates? (nsupdate/RFC 2136/RFC 3007) > > Previous discussions about DNS views: > https://www.redhat.com/archives/freeipa-users/2012-April/msg00070.html > https://www.redhat.com/archives/freeipa-devel/2012-May/msg00208.html > > Related tickets & bugs: > https://fedorahosted.org/freeipa/ticket/2802 > https://bugzilla.redhat.com/show_bug.cgi?id=815621 > https://fedorahosted.org/freeipa/ticket/3725 > https://fedorahosted.org/bind-dyndb-ldap/ticket/69 > > > The next step will be to design LDAP schema for DNS data with views ... > > I can see three basic options: > > 1) Resign from any data sharing, which will make the thing pretty easy :-) > In that case 'view1' will be represented by one sub-tree in LDAP, 'view2' > will > be another sub-tree etc. > > 2) Select one sub-tree which will be 'the base' containing all shared > records. > All other views will inherit and override data from the shared 'base'. > > 3) Make it as general as possible and allow multiple levels of inheritance. > View3 inherits from View2 and it inherits from Base. > (View3 <- View2 <- Base) > > It is basically generalized variant (2), but it could require different LDAP > > schema. > > > Please post your opinions! From ryan.thomson at ubc.ca Fri Oct 25 16:22:54 2013 From: ryan.thomson at ubc.ca (Thomson, Ryan) Date: Fri, 25 Oct 2013 16:22:54 +0000 Subject: [Freeipa-users] Failure decoding Certificate Signing Request In-Reply-To: <526969C1.8010802@redhat.com> References: <3fc2cb83-f64c-450b-a9d9-d4612966bbc1@S-ITSV-HUB01P.ead.ubc.ca> <52666FE7.4060406@redhat.com> <4236DE1EFED4374EA69B197EB5AC275735147A7B@S-ITSV-MBX02P.ead.ubc.ca> <5266B9C7.5090507@redhat.com> <4236DE1EFED4374EA69B197EB5AC275735148D59@S-ITSV-MBX02P.ead.ubc.ca> <526730C8.7030105@redhat.com> <4236DE1EFED4374EA69B197EB5AC27573514A59D@S-ITSV-MBX02P.ead.ubc.ca> <52687EB5.9030000@redhat.com> <4236DE1EFED4374EA69B197EB5AC27573514BC5F@S-ITSV-MBX02P.ead.ubc.ca> <526969C1.8010802@redhat.com> Message-ID: <4236DE1EFED4374EA69B197EB5AC27573514DF76@S-ITSV-MBX02P.ead.ubc.ca> > -----Original Message----- > From: Rob Crittenden [mailto:rcritten at redhat.com] > Sent: Thursday, October 24, 2013 11:41 AM > To: Thomson, Ryan; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Failure decoding Certificate Signing Request > > Thomson, Ryan wrote: > >> -----Original Message----- > >> From: Rob Crittenden [mailto:rcritten at redhat.com] > >> Sent: Wednesday, October 23, 2013 6:58 PM > >> To: Thomson, Ryan; freeipa-users at redhat.com > >> Subject: Re: [Freeipa-users] Failure decoding Certificate Signing > >> Request > >> > >> I think this still points to NSS not being initialized. The way we > >> currently use NSS in the server is Apache fires things up using > >> mod_nss, then because we are a child of Apache via mod_wsgi, we > >> inherit the open NSS database in /etc/httpd/alias. This gives us the > >> CA cert and the client cert we need in order to talk to dogtag. > >> > >> What I thought, and the excellent debugging above confirms, is that > >> at some point the NSS database is being shut down. At some point we > >> need to do some crypto and try to initialize it ourselves to no > >> avail. We shouldn't ever need to do it in the server and thus don't > >> have access to PINs and such because we don't need them. We do > >> initialize things from time to time on the client side but we tend to > >> do a database-less initialization (nss_init_nodb()). > >> > >> I'm not really sure what this tells us though. It would appear that > >> SSL is working in Apache, because you are able to get far enough to > >> make a request and have it fail. So the NSS database is still > >> initialized in Apache, but for some reason the wsgi code doesn't seem to > agree. > >> > >> Would it be possible for you to stop and restart Apache and run some > >> simple IPA command like ipa user-show admin (and let me know if it > succeeds)? > >> Then send me the error_log? > >> > >> If you are in SELinux enforcing mode it would also be helpful to > >> check for any AVCs. Maybe we simply can't access the database. > >> > >> thanks > >> > >> rob > > > > I am able to stop/wait/start apache and then execute "ipa user-show > admin" successfully. > > > > Ok, let's try a couple more things. > > Can you set LogLevel debug in /etc/httpd/conf.d/nss.conf and restart > Apache again? This may give us more information on what mod_nss is doing. > > Next, lets try a different cert command that should also invoke the NSS client > within IPA: > > $ ipa cert-show 22 > > Can you describe your environment? Do you have multiple IPA masters? Was > this a new install at 3.0 or is it an upgrade from 2.2? > > rob The environment is simple: Single master, upgraded from 2.2. Output in /var/log/httpd/error_log after setting LogLevel to debug in /etc/httpd/conf.d/nss.conf and restarting apache: [Sat Oct 05 00:04:25 2013] [notice] caught SIGTERM, shutting down [Sat Oct 05 00:04:26 2013] [notice] SELinux policy enabled; httpd running as context unconfined_u:system_r:httpd_t:s0 [Sat Oct 05 00:04:26 2013] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) [Sat Oct 05 00:04:26 2013] [info] Configuring server for SSL protocol [Sat Oct 05 00:04:26 2013] [debug] nss_engine_init.c(684): NSSProtocol: Enabling SSL3 [Sat Oct 05 00:04:26 2013] [debug] nss_engine_init.c(697): NSSProtocol: Enabling TLSv1.0 [Sat Oct 05 00:04:26 2013] [debug] nss_engine_init.c(751): NSSProtocol: [SSL 3.0] (minimum) [Sat Oct 05 00:04:26 2013] [debug] nss_engine_init.c(783): NSSProtocol: [TLS 1.0] (maximum) [Sat Oct 05 00:04:26 2013] [debug] nss_engine_init.c(983): NSSCipherSuite: Configuring permitted SSL ciphers [+rsa_rc4_128_md5,+rsa_rc4_128_sha,+rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,-rsa_rc2_40_md5,-rsa_null_md5,-rsa_null_sha,+fips_3des_sha,-fips_des_sha,-fortezza,-fortezza_rc4_128_sha,-fortezza_null,-rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,+rsa_aes_256_sha] [Sat Oct 05 00:04:26 2013] [info] Using nickname Server-Cert. [Sat Oct 05 00:04:26 2013] [notice] Digest: generating secret for digest authentication ... [Sat Oct 05 00:04:26 2013] [notice] Digest: done [Sat Oct 05 00:04:26 2013] [debug] proxy_util.c(1818): proxy: worker ajp://localhost:9447 already initialized [Sat Oct 05 00:04:26 2013] [debug] proxy_util.c(1818): proxy: worker ajp://localhost:9447 already initialized [Sat Oct 05 00:04:26 2013] [debug] proxy_util.c(1818): proxy: worker ajp://localhost:9447 already initialized [Sat Oct 05 00:04:26 2013] [debug] proxy_util.c(1818): proxy: worker ajp://localhost:9447 already initialized [Sat Oct 05 00:04:26 2013] [notice] Apache/2.2.15 (Unix) DAV/2 mod_auth_kerb/5.4 mod_nss/2.2.15 NSS/3.14.0.0 Basic ECC PHP/5.3.14 mod_wsgi/3.2 Python/2.6.6 configured -- resuming normal operations [Sat Oct 05 00:04:26 2013] [debug] proxy_util.c(1818): proxy: worker ajp://localhost:9447 already initialized [Sat Oct 05 00:04:26 2013] [debug] proxy_util.c(1818): proxy: worker ajp://localhost:9447 already initialized [Sat Oct 05 00:04:26 2013] [debug] proxy_util.c(1818): proxy: worker ajp://localhost:9447 already initialized [Sat Oct 05 00:04:26 2013] [debug] proxy_util.c(1818): proxy: worker ajp://localhost:9447 already initialized [Sat Oct 05 00:04:27 2013] [info] Configuring server for SSL protocol [Sat Oct 05 00:04:27 2013] [debug] nss_engine_init.c(684): NSSProtocol: Enabling SSL3 [Sat Oct 05 00:04:27 2013] [debug] nss_engine_init.c(697): NSSProtocol: Enabling TLSv1.0 [Sat Oct 05 00:04:27 2013] [debug] nss_engine_init.c(751): NSSProtocol: [SSL 3.0] (minimum) [Sat Oct 05 00:04:27 2013] [debug] nss_engine_init.c(783): NSSProtocol: [TLS 1.0] (maximum) [Sat Oct 05 00:04:27 2013] [debug] nss_engine_init.c(983): NSSCipherSuite: Configuring permitted SSL ciphers [+rsa_rc4_128_md5,+rsa_rc4_128_sha,+rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,-rsa_rc2_40_md5,-rsa_null_md5,-rsa_null_sha,+fips_3des_sha,-fips_des_sha,-fortezza,-fortezza_rc4_128_sha,-fortezza_null,-rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,+rsa_aes_256_sha] [Sat Oct 05 00:04:27 2013] [info] Using nickname Server-Cert. [Sat Oct 05 00:04:27 2013] [info] Configuring server for SSL protocol [Sat Oct 05 00:04:27 2013] [debug] nss_engine_init.c(684): NSSProtocol: Enabling SSL3 [Sat Oct 05 00:04:27 2013] [debug] nss_engine_init.c(697): NSSProtocol: Enabling TLSv1.0 [Sat Oct 05 00:04:27 2013] [debug] nss_engine_init.c(751): NSSProtocol: [SSL 3.0] (minimum) [Sat Oct 05 00:04:27 2013] [debug] nss_engine_init.c(783): NSSProtocol: [TLS 1.0] (maximum) [Sat Oct 05 00:04:27 2013] [debug] nss_engine_init.c(983): NSSCipherSuite: Configuring permitted SSL ciphers [+rsa_rc4_128_md5,+rsa_rc4_128_sha,+rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,-rsa_rc2_40_md5,-rsa_null_md5,-rsa_null_sha,+fips_3des_sha,-fips_des_sha,-fortezza,-fortezza_rc4_128_sha,-fortezza_null,-rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,+rsa_aes_256_sha] [Sat Oct 05 00:04:27 2013] [info] Using nickname Server-Cert. [Sat Oct 05 00:04:27 2013] [info] Configuring server for SSL protocol [Sat Oct 05 00:04:27 2013] [debug] nss_engine_init.c(684): NSSProtocol: Enabling SSL3 [Sat Oct 05 00:04:27 2013] [debug] nss_engine_init.c(697): NSSProtocol: Enabling TLSv1.0 [Sat Oct 05 00:04:27 2013] [debug] nss_engine_init.c(751): NSSProtocol: [SSL 3.0] (minimum) [Sat Oct 05 00:04:27 2013] [debug] nss_engine_init.c(783): NSSProtocol: [TLS 1.0] (maximum) [Sat Oct 05 00:04:27 2013] [debug] nss_engine_init.c(983): NSSCipherSuite: Configuring permitted SSL ciphers [+rsa_rc4_128_md5,+rsa_rc4_128_sha,+rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,-rsa_rc2_40_md5,-rsa_null_md5,-rsa_null_sha,+fips_3des_sha,-fips_des_sha,-fortezza,-fortezza_rc4_128_sha,-fortezza_null,-rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,+rsa_aes_256_sha] [Sat Oct 05 00:04:27 2013] [info] Using nickname Server-Cert. [Sat Oct 05 00:04:27 2013] [info] Configuring server for SSL protocol [Sat Oct 05 00:04:27 2013] [debug] nss_engine_init.c(684): NSSProtocol: Enabling SSL3 [Sat Oct 05 00:04:27 2013] [debug] nss_engine_init.c(697): NSSProtocol: Enabling TLSv1.0 [Sat Oct 05 00:04:27 2013] [debug] nss_engine_init.c(751): NSSProtocol: [SSL 3.0] (minimum) [Sat Oct 05 00:04:27 2013] [info] Configuring server for SSL protocol [Sat Oct 05 00:04:27 2013] [debug] nss_engine_init.c(684): NSSProtocol: Enabling SSL3 [Sat Oct 05 00:04:27 2013] [info] Configuring server for SSL protocol [Sat Oct 05 00:04:27 2013] [debug] nss_engine_init.c(783): NSSProtocol: [TLS 1.0] (maximum) [Sat Oct 05 00:04:27 2013] [debug] nss_engine_init.c(983): NSSCipherSuite: Configuring permitted SSL ciphers [+rsa_rc4_128_md5,+rsa_rc4_128_sha,+rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,-rsa_rc2_40_md5,-rsa_null_md5,-rsa_null_sha,+fips_3des_sha,-fips_des_sha,-fortezza,-fortezza_rc4_128_sha,-fortezza_null,-rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,+rsa_aes_256_sha] [Sat Oct 05 00:04:27 2013] [info] Using nickname Server-Cert. [Sat Oct 05 00:04:27 2013] [debug] nss_engine_init.c(697): NSSProtocol: Enabling TLSv1.0 [Sat Oct 05 00:04:27 2013] [debug] nss_engine_init.c(751): NSSProtocol: [SSL 3.0] (minimum) [Sat Oct 05 00:04:27 2013] [debug] nss_engine_init.c(783): NSSProtocol: [TLS 1.0] (maximum) [Sat Oct 05 00:04:27 2013] [debug] nss_engine_init.c(983): NSSCipherSuite: Configuring permitted SSL ciphers [+rsa_rc4_128_md5,+rsa_rc4_128_sha,+rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,-rsa_rc2_40_md5,-rsa_null_md5,-rsa_null_sha,+fips_3des_sha,-fips_des_sha,-fortezza,-fortezza_rc4_128_sha,-fortezza_null,-rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,+rsa_aes_256_sha] [Sat Oct 05 00:04:27 2013] [info] Using nickname Server-Cert. [Sat Oct 05 00:04:27 2013] [debug] nss_engine_init.c(684): NSSProtocol: Enabling SSL3 [Sat Oct 05 00:04:27 2013] [debug] nss_engine_init.c(697): NSSProtocol: Enabling TLSv1.0 [Sat Oct 05 00:04:27 2013] [debug] nss_engine_init.c(751): NSSProtocol: [SSL 3.0] (minimum) [Sat Oct 05 00:04:27 2013] [debug] nss_engine_init.c(783): NSSProtocol: [TLS 1.0] (maximum) [Sat Oct 05 00:04:27 2013] [debug] nss_engine_init.c(983): NSSCipherSuite: Configuring permitted SSL ciphers [+rsa_rc4_128_md5,+rsa_rc4_128_sha,+rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,-rsa_rc2_40_md5,-rsa_null_md5,-rsa_null_sha,+fips_3des_sha,-fips_des_sha,-fortezza,-fortezza_rc4_128_sha,-fortezza_null,-rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,+rsa_aes_256_sha] [Sat Oct 05 00:04:27 2013] [info] Using nickname Server-Cert. [Sat Oct 05 00:04:27 2013] [info] Configuring server for SSL protocol [Sat Oct 05 00:04:27 2013] [debug] nss_engine_init.c(684): NSSProtocol: Enabling SSL3 [Sat Oct 05 00:04:27 2013] [debug] nss_engine_init.c(697): NSSProtocol: Enabling TLSv1.0 [Sat Oct 05 00:04:27 2013] [debug] nss_engine_init.c(751): NSSProtocol: [SSL 3.0] (minimum) [Sat Oct 05 00:04:27 2013] [debug] nss_engine_init.c(783): NSSProtocol: [TLS 1.0] (maximum) [Sat Oct 05 00:04:27 2013] [debug] nss_engine_init.c(983): NSSCipherSuite: Configuring permitted SSL ciphers [+rsa_rc4_128_md5,+rsa_rc4_128_sha,+rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,-rsa_rc2_40_md5,-rsa_null_md5,-rsa_null_sha,+fips_3des_sha,-fips_des_sha,-fortezza,-fortezza_rc4_128_sha,-fortezza_null,-rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,+rsa_aes_256_sha] [Sat Oct 05 00:04:27 2013] [info] Using nickname Server-Cert. [Sat Oct 05 00:04:27 2013] [info] Configuring server for SSL protocol [Sat Oct 05 00:04:27 2013] [debug] nss_engine_init.c(684): NSSProtocol: Enabling SSL3 [Sat Oct 05 00:04:27 2013] [debug] nss_engine_init.c(697): NSSProtocol: Enabling TLSv1.0 [Sat Oct 05 00:04:27 2013] [debug] nss_engine_init.c(751): NSSProtocol: [SSL 3.0] (minimum) [Sat Oct 05 00:04:27 2013] [debug] nss_engine_init.c(783): NSSProtocol: [TLS 1.0] (maximum) [Sat Oct 05 00:04:27 2013] [debug] nss_engine_init.c(983): NSSCipherSuite: Configuring permitted SSL ciphers [+rsa_rc4_128_md5,+rsa_rc4_128_sha,+rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,-rsa_rc2_40_md5,-rsa_null_md5,-rsa_null_sha,+fips_3des_sha,-fips_des_sha,-fortezza,-fortezza_rc4_128_sha,-fortezza_null,-rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,+rsa_aes_256_sha] [Sat Oct 05 00:04:27 2013] [info] Using nickname Server-Cert. [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing all plugin modules in '/usr/lib/python2.6/site-packages/ipalib/plugins'... [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing all plugin modules in '/usr/lib/python2.6/site-packages/ipalib/plugins'... [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/aci.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/aci.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/automember.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/automember.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/automount.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/automount.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/baseldap.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/baseldap.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/batch.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/batch.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/cert.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/cert.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/config.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/config.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/delegation.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/delegation.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/dns.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/dns.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/group.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/group.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/hbacrule.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/hbacrule.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/hbacsvc.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/hbacsvc.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/hbacsvcgroup.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/hbacsvcgroup.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/hbactest.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/hbactest.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/host.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/host.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/hostgroup.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/hostgroup.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/idrange.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/idrange.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/internal.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/internal.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/kerberos.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/kerberos.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/krbtpolicy.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/krbtpolicy.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/migration.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/migration.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/misc.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/misc.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/netgroup.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/netgroup.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/passwd.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/permission.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/passwd.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/permission.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/ping.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/ping.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/privilege.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/privilege.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/pwpolicy.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/pwpolicy.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: args=klist -V [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: stdout=Kerberos 5 version 1.10.3 [Sat Oct 05 00:04:28 2013] [error] [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: stderr= [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: args=klist -V [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: stdout=Kerberos 5 version 1.10.3 [Sat Oct 05 00:04:28 2013] [error] [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: stderr= [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/role.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/role.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/selfservice.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/selfservice.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/selinuxusermap.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/service.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/sudocmd.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/selinuxusermap.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/service.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/sudocmd.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/sudocmdgroup.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/sudorule.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/sudocmdgroup.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/sudorule.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/trust.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/trust.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/user.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/virtual.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/xmlclient.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing all plugin modules in '/usr/lib/python2.6/site-packages/ipaserver/plugins'... [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipaserver/plugins/dogtag.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/user.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/virtual.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/xmlclient.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing all plugin modules in '/usr/lib/python2.6/site-packages/ipaserver/plugins'... [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipaserver/plugins/dogtag.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipaserver/plugins/join.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipaserver/plugins/join.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipaserver/plugins/ldap2.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipaserver/plugins/rabase.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipaserver/plugins/selfsign.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: skipping plugin module ipaserver.plugins.selfsign: selfsign is not selected as RA plugin, it is dogtag [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipaserver/plugins/ldap2.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipaserver/plugins/xmlserver.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipaserver/plugins/rabase.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipaserver/plugins/selfsign.py' [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: skipping plugin module ipaserver.plugins.selfsign: selfsign is not selected as RA plugin, it is dogtag [Sat Oct 05 00:04:28 2013] [error] ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipaserver/plugins/xmlserver.py' [Sat Oct 05 00:04:29 2013] [error] ipa: DEBUG: SessionAuthManager.register: name=jsonserver_session [Sat Oct 05 00:04:29 2013] [error] ipa: DEBUG: SessionAuthManager.register: name=jsonserver_session [Sat Oct 05 00:04:29 2013] [error] ipa: DEBUG: SessionAuthManager.register: name=xmlserver_session [Sat Oct 05 00:04:29 2013] [error] ipa: DEBUG: SessionAuthManager.register: name=xmlserver_session [Sat Oct 05 00:04:29 2013] [error] ipa: DEBUG: Mounting ipaserver.rpcserver.jsonserver_kerb() at '/json' [Sat Oct 05 00:04:29 2013] [error] ipa: DEBUG: Mounting ipaserver.rpcserver.jsonserver_kerb() at '/json' [Sat Oct 05 00:04:29 2013] [error] ipa: DEBUG: Mounting ipaserver.rpcserver.jsonserver_session() at '/session/json' [Sat Oct 05 00:04:29 2013] [error] ipa: DEBUG: Mounting ipaserver.rpcserver.jsonserver_session() at '/session/json' [Sat Oct 05 00:04:29 2013] [error] ipa: DEBUG: Mounting ipaserver.rpcserver.xmlserver_session() at '/session/xml' [Sat Oct 05 00:04:29 2013] [error] ipa: DEBUG: Mounting ipaserver.rpcserver.xmlserver_session() at '/session/xml' [Sat Oct 05 00:04:29 2013] [error] ipa: DEBUG: Mounting ipaserver.rpcserver.xmlserver() at '/xml' [Sat Oct 05 00:04:29 2013] [error] ipa: DEBUG: Mounting ipaserver.rpcserver.xmlserver() at '/xml' [Sat Oct 05 00:04:30 2013] [error] ipa: DEBUG: session_auth_duration: 0:20:00 [Sat Oct 05 00:04:30 2013] [error] ipa: DEBUG: session_auth_duration: 0:20:00 [Sat Oct 05 00:04:30 2013] [error] ipa: DEBUG: session_auth_duration: 0:20:00 [Sat Oct 05 00:04:30 2013] [error] ipa: DEBUG: session_auth_duration: 0:20:00 [Sat Oct 05 00:04:30 2013] [error] ipa: DEBUG: session_auth_duration: 0:20:00 [Sat Oct 05 00:04:30 2013] [error] ipa: DEBUG: session_auth_duration: 0:20:00 [Sat Oct 05 00:04:30 2013] [error] ipa: DEBUG: Mounting ipaserver.rpcserver.login_kerberos() at '/session/login_kerberos' [Sat Oct 05 00:04:30 2013] [error] ipa: DEBUG: Mounting ipaserver.rpcserver.login_kerberos() at '/session/login_kerberos' [Sat Oct 05 00:04:30 2013] [error] ipa: DEBUG: session_auth_duration: 0:20:00 [Sat Oct 05 00:04:30 2013] [error] ipa: DEBUG: session_auth_duration: 0:20:00 [Sat Oct 05 00:04:30 2013] [error] ipa: DEBUG: session_auth_duration: 0:20:00 [Sat Oct 05 00:04:30 2013] [error] ipa: DEBUG: session_auth_duration: 0:20:00 [Sat Oct 05 00:04:31 2013] [error] ipa: DEBUG: Mounting ipaserver.rpcserver.login_password() at '/session/login_password' [Sat Oct 05 00:04:31 2013] [error] ipa: DEBUG: Mounting ipaserver.rpcserver.login_password() at '/session/login_password' [Sat Oct 05 00:04:31 2013] [error] ipa: DEBUG: session_auth_duration: 0:20:00 [Sat Oct 05 00:04:31 2013] [error] ipa: DEBUG: session_auth_duration: 0:20:00 [Sat Oct 05 00:04:31 2013] [error] ipa: DEBUG: Mounting ipaserver.rpcserver.change_password() at '/session/change_password' [Sat Oct 05 00:04:31 2013] [error] ipa: DEBUG: Mounting ipaserver.rpcserver.change_password() at '/session/change_password' [Sat Oct 05 00:04:31 2013] [error] ipa: INFO: *** PROCESS START *** [Sat Oct 05 00:04:31 2013] [error] ipa: INFO: *** PROCESS START *** Command output from "ipa cert-show 22": root at HOSTNAME:~ # ipa cert-show 22 ipa: DEBUG: importing all plugin modules in '/usr/lib/python2.6/site-packages/ipalib/plugins'... ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/aci.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/automember.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/automount.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/baseldap.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/batch.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/cert.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/config.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/delegation.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/dns.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/group.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/hbacrule.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/hbacsvc.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/hbacsvcgroup.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/hbactest.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/host.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/hostgroup.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/idrange.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/internal.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/kerberos.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/krbtpolicy.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/migration.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/misc.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/netgroup.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/passwd.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/permission.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/ping.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/privilege.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/pwpolicy.py' ipa: DEBUG: args=klist -V ipa: DEBUG: stdout=Kerberos 5 version 1.10.3 ipa: DEBUG: stderr= ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/role.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/selfservice.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/selinuxusermap.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/service.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/sudocmd.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/sudocmdgroup.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/sudorule.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/trust.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/user.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/virtual.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/xmlclient.py' ipa: DEBUG: args=keyctl search @s user ipa_session_cookie:admin at FULLY.QUALIFIED.DOMAIN ipa: DEBUG: stdout= ipa: DEBUG: stderr=keyctl_search: Required key not available ipa: DEBUG: failed to find session_cookie in persistent storage for principal 'admin at FULLY.QUALIFIED.DOMAIN' ipa: INFO: trying https://HOSTNAME.DOMAIN/ipa/xml ipa: DEBUG: Created connection context.xmlclient ipa: DEBUG: raw: cert_show(u'22') ipa: DEBUG: cert_show(u'22') ipa: INFO: Forwarding 'cert_show' to server u'https://HOSTNAME.DOMAIN/ipa/xml' ipa: DEBUG: NSSConnection init HOSTNAME.DOMAIN ipa: DEBUG: Connecting: 142.103.89.209:0 ipa: DEBUG: auth_certificate_callback: check_sig=True is_server=False Data: Version: 3 (0x2) Serial Number: 22 (0x16) Signature Algorithm: Algorithm: PKCS #1 SHA-256 With RSA Encryption Issuer: CN=Certificate Authority,O=FULLY.QUALIFIED.DOMAIN Validity: Not Before: Thu Apr 11 23:23:18 2013 UTC Not After: Tue Oct 08 23:23:18 2013 UTC Subject: CN=HOSTNAME.DOMAIN,O=FULLY.QUALIFIED.DOMAIN Subject Public Key Info: Public Key Algorithm: Algorithm: PKCS #1 RSA Encryption RSA Public Key: Modulus: b0:b0:50:1f:e9:72:26:d5:dd:ff:70:ba:66:bb:a6:90: bf:02:e9:7f:9b:73:10:9b:d9:a5:84:f7:34:c6:ed:03: ca:48:11:5e:50:9d:19:9f:22:24:8a:17:35:69:d0:69: 0e:f7:a8:37:2d:46:11:98:5e:df:a8:2c:93:96:a7:66: e4:3d:20:c1:72:e2:94:46:36:0b:84:44:2e:94:a9:98: 7a:da:1d:3a:f0:13:53:47:0d:b1:30:21:9d:55:a8:32: 09:be:c6:d3:98:2e:6c:a1:a1:34:02:9a:7f:df:ba:4b: f1:c9:10:c4:0b:70:e7:08:de:98:24:c4:a6:d2:4a:e5: 0c:41:e7:f6:80:a5:7a:25:b7:8d:0e:b9:aa:b7:ff:4f: cd:85:b5:3e:1c:e0:6f:83:e5:c1:86:ec:e0:6f:dd:f2: 3a:6b:60:ce:3f:63:46:9a:75:5e:e3:20:76:d3:36:53: 07:1f:34:77:a7:42:3e:58:0d:30:15:f6:47:e3:a2:d3: 46:b0:cf:62:1b:00:2a:28:18:39:5c:35:3b:ff:c6:7a: c2:9d:08:75:17:92:d3:7f:58:6d:c8:bc:55:c3:6f:3e: 17:f7:55:bf:e6:3c:af:cc:8a:18:59:f1:46:50:07:36: 09:38:87:4b:38:67:44:f6:b6:bb:cf:f0:af:88:30:5f Exponent: 65537 (0x10001) Signed Extensions: (5) Name: Certificate Authority Key Identifier Critical: False Key ID: 3a:41:f5:c1:b7:ff:bb:79:13:d1:23:92:61:16:fc:7d: a7:d1:82:d2 Serial Number: None General Names: [0 total] Name: Authority Information Access Critical: False Name: Certificate Key Usage Critical: True Usages: Digital Signature Non-Repudiation Key Encipherment Data Encipherment Name: Extended Key Usage Critical: False Usages: TLS Web Server Authentication Certificate Name: Certificate Subject Key ID Critical: False Data: e0:56:1f:d5:73:7c:5f:7f:60:5e:d7:3c:88:43:8d:97: b7:f5:fb:24 Signature: Signature Algorithm: Algorithm: PKCS #1 SHA-256 With RSA Encryption Signature: 85:60:83:4c:d5:80:28:9c:ec:69:b0:26:7a:4f:fc:99: e1:4e:3d:78:54:59:d7:46:b3:cf:fb:81:8e:16:67:18: b4:c4:98:3f:16:54:05:ef:6e:79:5f:62:81:65:e3:a8: e7:7b:68:12:25:1f:af:dc:bf:3a:f7:74:72:9d:1d:51: ae:e8:12:73:4c:a8:19:ad:54:03:22:a6:c0:56:29:1a: cc:70:81:5e:fb:38:c0:f7:16:d5:9b:34:2c:16:43:84: b3:7f:bb:86:83:fd:9a:d7:f5:67:a8:f4:c3:33:58:5e: 89:7a:f6:9f:a8:d7:b6:f9:0b:47:d7:6e:46:53:32:63: e6:da:23:54:89:bc:4f:12:16:6d:eb:d4:f0:55:08:46: 64:69:46:55:20:90:ab:61:c4:f2:b6:d5:50:b5:48:07: c0:f9:da:8e:fb:dd:53:e6:9f:1f:4e:d9:ec:af:a6:ad: 75:76:75:e4:b7:b3:ad:56:52:66:f4:9b:71:0d:b1:92: a1:fc:16:c7:66:41:dd:b4:2f:df:34:ed:ad:29:26:40: 4f:85:a5:98:2c:9b:f0:18:42:3d:97:aa:73:16:3b:ac: 48:a9:8c:af:77:b3:24:d0:0d:07:ff:11:79:a9:24:a8: 2a:08:bd:e1:84:e3:6a:6f:2c:8e:62:78:8e:86:95:73 Fingerprint (MD5): 27:7d:ec:86:4f:07:65:9f:27:1e:eb:c4:af:9b:b0:b1 Fingerprint (SHA1): df:60:7a:1b:54:22:bd:f2:2c:ea:ee:51:17:23:ae:2d: f2:57:69:88 ipa: DEBUG: approved_usage = SSLServer intended_usage = SSLServer ipa: DEBUG: cert valid True for "CN=HOSTNAME.DOMAIN,O=FULLY.QUALIFIED.DOMAIN" ipa: DEBUG: handshake complete, peer = 142.103.89.209:443 ipa: DEBUG: received Set-Cookie 'ipa_session=770312911f588dc88e3d5847a28b3344; Domain=HOSTNAME.DOMAIN; Path=/ipa; Expires=Sat, 05 Oct 2013 07:45:45 GMT; Secure; HttpOnly' ipa: DEBUG: storing cookie 'ipa_session=770312911f588dc88e3d5847a28b3344; Domain=HOSTNAME.DOMAIN; Path=/ipa; Expires=Sat, 05 Oct 2013 07:45:45 GMT; Secure; HttpOnly' for principal admin at FULLY.QUALIFIED.DOMAIN ipa: DEBUG: args=keyctl search @s user ipa_session_cookie:admin at FULLY.QUALIFIED.DOMAIN ipa: DEBUG: stdout= ipa: DEBUG: stderr=keyctl_search: Required key not available ipa: DEBUG: args=keyctl search @s user ipa_session_cookie:admin at FULLY.QUALIFIED.DOMAIN ipa: DEBUG: stdout= ipa: DEBUG: stderr=keyctl_search: Required key not available ipa: DEBUG: args=keyctl padd user ipa_session_cookie:admin at FULLY.QUALIFIED.DOMAIN @s ipa: DEBUG: stdout=109211408 ipa: DEBUG: stderr= ipa: DEBUG: Caught fault 4301 from server https://HOSTNAME.DOMAIN/ipa/xml: Certificate operation cannot be completed: EXCEPTION (You did not provide a valid certificate for this operation) ipa: DEBUG: Destroyed connection context.xmlclient ipa: ERROR: Certificate operation cannot be completed: EXCEPTION (You did not provide a valid certificate for this operation) Debug output from /var/log/httpd/error_log for "ipa cert-show 22" command: [Sat Oct 05 00:25:44 2013] [info] Connection to child 3 established (server HOSTNAME.DOMAIN:443, client 142.103.89.209) [Sat Oct 05 00:25:44 2013] [info] Initial (No.1) HTTPS request received for child 3 (server HOSTNAME.DOMAIN:443) [Sat Oct 05 00:25:44 2013] [debug] src/mod_auth_kerb.c(1939): [client 142.103.89.209] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos, referer: https://HOSTNAME.DOMAIN/ipa/xml [Sat Oct 05 00:25:44 2013] [debug] src/mod_auth_kerb.c(1278): [client 142.103.89.209] Acquiring creds for HTTP at HOSTNAME.DOMAIN, referer: https://HOSTNAME.DOMAIN/ipa/xml [Sat Oct 05 00:25:44 2013] [debug] src/mod_auth_kerb.c(1472): [client 142.103.89.209] Credentials cache FILE:/tmp/krb5cc_48 not found, create one, referer: https://HOSTNAME.DOMAIN/ipa/xml [Sat Oct 05 00:25:44 2013] [debug] src/mod_auth_kerb.c(1538): [client 142.103.89.209] Obtaining new credentials for HTTP/HOSTNAME.DOMAIN, referer: https://HOSTNAME.DOMAIN/ipa/xml [Sat Oct 05 00:25:45 2013] [debug] src/mod_auth_kerb.c(1597): [client 142.103.89.209] Done obtaining credentials for s4u2proxy, referer: https://HOSTNAME.DOMAIN/ipa/xml [Sat Oct 05 00:25:45 2013] [debug] src/mod_auth_kerb.c(1691): [client 142.103.89.209] Verifying client data using KRB5 GSS-API , referer: https://HOSTNAME.DOMAIN/ipa/xml [Sat Oct 05 00:25:45 2013] [debug] src/mod_auth_kerb.c(1707): [client 142.103.89.209] Client delegated us their credential, referer: https://HOSTNAME.DOMAIN/ipa/xml [Sat Oct 05 00:25:45 2013] [debug] src/mod_auth_kerb.c(1726): [client 142.103.89.209] GSS-API token of length 156 bytes will be sent back, referer: https://HOSTNAME.DOMAIN/ipa/xml [Sat Oct 05 00:25:45 2013] [error] ipa: DEBUG: WSGI wsgi_dispatch.__call__: [Sat Oct 05 00:25:45 2013] [error] ipa: DEBUG: WSGI xmlserver.__call__: [Sat Oct 05 00:25:45 2013] [error] ipa: DEBUG: Created connection context.ldap2 [Sat Oct 05 00:25:45 2013] [error] ipa: DEBUG: WSGI WSGIExecutioner.__call__: [Sat Oct 05 00:25:45 2013] [error] ipa: DEBUG: raw: cert_show(u'22') [Sat Oct 05 00:25:45 2013] [error] ipa: DEBUG: cert_show(u'22') [Sat Oct 05 00:25:45 2013] [error] ipa: DEBUG: IPA: virtual verify retrieve certificate [Sat Oct 05 00:25:45 2013] [error] ipa: DEBUG: retrieving schema for SchemaCache url=ldapi://%2fvar%2frun%2fslapd-FULLY-QUALIFIED-DOMAIN.socket conn= [Sat Oct 05 00:25:45 2013] [error] ipa: DEBUG: ipaserver.plugins.dogtag.ra.get_certificate() [Sat Oct 05 00:25:45 2013] [error] ipa: DEBUG: https_request 'https://HOSTNAME.DOMAIN:443/ca/agent/ca/displayBySerial' [Sat Oct 05 00:25:45 2013] [error] ipa: DEBUG: https_request post 'xml=true&serialNumber=22' [Sat Oct 05 00:25:45 2013] [error] ipa: DEBUG: NSSConnection init HOSTNAME.DOMAIN [Sat Oct 05 00:25:45 2013] [error] ipa: DEBUG: Connecting: 142.103.89.209:0 [Sat Oct 05 00:25:45 2013] [info] Connection to child 4 established (server HOSTNAME.DOMAIN:443, client 142.103.89.209) [Sat Oct 05 00:25:45 2013] [error] ipa: DEBUG: auth_certificate_callback: check_sig=True is_server=False [Sat Oct 05 00:25:45 2013] [error] Data: [Sat Oct 05 00:25:45 2013] [error] Version: 3 (0x2) [Sat Oct 05 00:25:45 2013] [error] Serial Number: 22 (0x16) [Sat Oct 05 00:25:45 2013] [error] Signature Algorithm: [Sat Oct 05 00:25:45 2013] [error] Algorithm: PKCS #1 SHA-256 With RSA Encryption [Sat Oct 05 00:25:45 2013] [error] Issuer: CN=Certificate Authority,O=FULLY.QUALIFIED.DOMAIN [Sat Oct 05 00:25:45 2013] [error] Validity: [Sat Oct 05 00:25:45 2013] [error] Not Before: Thu Apr 11 23:23:18 2013 UTC [Sat Oct 05 00:25:45 2013] [error] Not After: Tue Oct 08 23:23:18 2013 UTC [Sat Oct 05 00:25:45 2013] [error] Subject: CN=HOSTNAME.DOMAIN,O=FULLY.QUALIFIED.DOMAIN [Sat Oct 05 00:25:45 2013] [error] Subject Public Key Info: [Sat Oct 05 00:25:45 2013] [error] Public Key Algorithm: [Sat Oct 05 00:25:45 2013] [error] Algorithm: PKCS #1 RSA Encryption [Sat Oct 05 00:25:45 2013] [error] RSA Public Key: [Sat Oct 05 00:25:45 2013] [error] Modulus: [Sat Oct 05 00:25:45 2013] [error] b0:b0:50:1f:e9:72:26:d5:dd:ff:70:ba:66:bb:a6:90: [Sat Oct 05 00:25:45 2013] [error] bf:02:e9:7f:9b:73:10:9b:d9:a5:84:f7:34:c6:ed:03: [Sat Oct 05 00:25:45 2013] [error] ca:48:11:5e:50:9d:19:9f:22:24:8a:17:35:69:d0:69: [Sat Oct 05 00:25:45 2013] [error] 0e:f7:a8:37:2d:46:11:98:5e:df:a8:2c:93:96:a7:66: [Sat Oct 05 00:25:45 2013] [error] e4:3d:20:c1:72:e2:94:46:36:0b:84:44:2e:94:a9:98: [Sat Oct 05 00:25:45 2013] [error] 7a:da:1d:3a:f0:13:53:47:0d:b1:30:21:9d:55:a8:32: [Sat Oct 05 00:25:45 2013] [error] 09:be:c6:d3:98:2e:6c:a1:a1:34:02:9a:7f:df:ba:4b: [Sat Oct 05 00:25:45 2013] [error] f1:c9:10:c4:0b:70:e7:08:de:98:24:c4:a6:d2:4a:e5: [Sat Oct 05 00:25:45 2013] [error] 0c:41:e7:f6:80:a5:7a:25:b7:8d:0e:b9:aa:b7:ff:4f: [Sat Oct 05 00:25:45 2013] [error] cd:85:b5:3e:1c:e0:6f:83:e5:c1:86:ec:e0:6f:dd:f2: [Sat Oct 05 00:25:45 2013] [error] 3a:6b:60:ce:3f:63:46:9a:75:5e:e3:20:76:d3:36:53: [Sat Oct 05 00:25:45 2013] [error] 07:1f:34:77:a7:42:3e:58:0d:30:15:f6:47:e3:a2:d3: [Sat Oct 05 00:25:45 2013] [error] 46:b0:cf:62:1b:00:2a:28:18:39:5c:35:3b:ff:c6:7a: [Sat Oct 05 00:25:45 2013] [error] c2:9d:08:75:17:92:d3:7f:58:6d:c8:bc:55:c3:6f:3e: [Sat Oct 05 00:25:45 2013] [error] 17:f7:55:bf:e6:3c:af:cc:8a:18:59:f1:46:50:07:36: [Sat Oct 05 00:25:45 2013] [error] 09:38:87:4b:38:67:44:f6:b6:bb:cf:f0:af:88:30:5f [Sat Oct 05 00:25:45 2013] [error] Exponent: [Sat Oct 05 00:25:45 2013] [error] 65537 (0x10001) [Sat Oct 05 00:25:45 2013] [error] Signed Extensions: (5) [Sat Oct 05 00:25:45 2013] [error] Name: Certificate Authority Key Identifier [Sat Oct 05 00:25:45 2013] [error] Critical: False [Sat Oct 05 00:25:45 2013] [error] Key ID: [Sat Oct 05 00:25:45 2013] [error] 3a:41:f5:c1:b7:ff:bb:79:13:d1:23:92:61:16:fc:7d: [Sat Oct 05 00:25:45 2013] [error] a7:d1:82:d2 [Sat Oct 05 00:25:45 2013] [error] Serial Number: None [Sat Oct 05 00:25:45 2013] [error] General Names: [0 total] [Sat Oct 05 00:25:45 2013] [error] [Sat Oct 05 00:25:45 2013] [error] Name: Authority Information Access [Sat Oct 05 00:25:45 2013] [error] Critical: False [Sat Oct 05 00:25:45 2013] [error] [Sat Oct 05 00:25:45 2013] [error] Name: Certificate Key Usage [Sat Oct 05 00:25:45 2013] [error] Critical: True [Sat Oct 05 00:25:45 2013] [error] Usages: [Sat Oct 05 00:25:45 2013] [error] Digital Signature [Sat Oct 05 00:25:45 2013] [error] Non-Repudiation [Sat Oct 05 00:25:45 2013] [error] Key Encipherment [Sat Oct 05 00:25:45 2013] [error] Data Encipherment [Sat Oct 05 00:25:45 2013] [error] [Sat Oct 05 00:25:45 2013] [error] Name: Extended Key Usage [Sat Oct 05 00:25:45 2013] [error] Critical: False [Sat Oct 05 00:25:45 2013] [error] Usages: [Sat Oct 05 00:25:45 2013] [error] TLS Web Server Authentication Certificate [Sat Oct 05 00:25:45 2013] [error] [Sat Oct 05 00:25:45 2013] [error] Name: Certificate Subject Key ID [Sat Oct 05 00:25:45 2013] [error] Critical: False [Sat Oct 05 00:25:45 2013] [error] Data: [Sat Oct 05 00:25:45 2013] [error] e0:56:1f:d5:73:7c:5f:7f:60:5e:d7:3c:88:43:8d:97: [Sat Oct 05 00:25:45 2013] [error] b7:f5:fb:24 [Sat Oct 05 00:25:45 2013] [error] [Sat Oct 05 00:25:45 2013] [error] Certificate Trust Flags: [Sat Oct 05 00:25:45 2013] [error] SSL Flags: [Sat Oct 05 00:25:45 2013] [error] User [Sat Oct 05 00:25:45 2013] [error] Email Flags: [Sat Oct 05 00:25:45 2013] [error] User [Sat Oct 05 00:25:45 2013] [error] Object Signing Flags: [Sat Oct 05 00:25:45 2013] [error] User [Sat Oct 05 00:25:45 2013] [error] Signature: [Sat Oct 05 00:25:45 2013] [error] Signature Algorithm: [Sat Oct 05 00:25:45 2013] [error] Algorithm: PKCS #1 SHA-256 With RSA Encryption [Sat Oct 05 00:25:45 2013] [error] Signature: [Sat Oct 05 00:25:45 2013] [error] 85:60:83:4c:d5:80:28:9c:ec:69:b0:26:7a:4f:fc:99: [Sat Oct 05 00:25:45 2013] [error] e1:4e:3d:78:54:59:d7:46:b3:cf:fb:81:8e:16:67:18: [Sat Oct 05 00:25:45 2013] [error] b4:c4:98:3f:16:54:05:ef:6e:79:5f:62:81:65:e3:a8: [Sat Oct 05 00:25:45 2013] [error] e7:7b:68:12:25:1f:af:dc:bf:3a:f7:74:72:9d:1d:51: [Sat Oct 05 00:25:45 2013] [error] ae:e8:12:73:4c:a8:19:ad:54:03:22:a6:c0:56:29:1a: [Sat Oct 05 00:25:45 2013] [error] cc:70:81:5e:fb:38:c0:f7:16:d5:9b:34:2c:16:43:84: [Sat Oct 05 00:25:45 2013] [error] b3:7f:bb:86:83:fd:9a:d7:f5:67:a8:f4:c3:33:58:5e: [Sat Oct 05 00:25:45 2013] [error] 89:7a:f6:9f:a8:d7:b6:f9:0b:47:d7:6e:46:53:32:63: [Sat Oct 05 00:25:45 2013] [error] e6:da:23:54:89:bc:4f:12:16:6d:eb:d4:f0:55:08:46: [Sat Oct 05 00:25:45 2013] [error] 64:69:46:55:20:90:ab:61:c4:f2:b6:d5:50:b5:48:07: [Sat Oct 05 00:25:45 2013] [error] c0:f9:da:8e:fb:dd:53:e6:9f:1f:4e:d9:ec:af:a6:ad: [Sat Oct 05 00:25:45 2013] [error] 75:76:75:e4:b7:b3:ad:56:52:66:f4:9b:71:0d:b1:92: [Sat Oct 05 00:25:45 2013] [error] a1:fc:16:c7:66:41:dd:b4:2f:df:34:ed:ad:29:26:40: [Sat Oct 05 00:25:45 2013] [error] 4f:85:a5:98:2c:9b:f0:18:42:3d:97:aa:73:16:3b:ac: [Sat Oct 05 00:25:45 2013] [error] 48:a9:8c:af:77:b3:24:d0:0d:07:ff:11:79:a9:24:a8: [Sat Oct 05 00:25:45 2013] [error] 2a:08:bd:e1:84:e3:6a:6f:2c:8e:62:78:8e:86:95:73 [Sat Oct 05 00:25:45 2013] [error] Fingerprint (MD5): [Sat Oct 05 00:25:45 2013] [error] 27:7d:ec:86:4f:07:65:9f:27:1e:eb:c4:af:9b:b0:b1 [Sat Oct 05 00:25:45 2013] [error] Fingerprint (SHA1): [Sat Oct 05 00:25:45 2013] [error] df:60:7a:1b:54:22:bd:f2:2c:ea:ee:51:17:23:ae:2d: [Sat Oct 05 00:25:45 2013] [error] f2:57:69:88 [Sat Oct 05 00:25:45 2013] [error] ipa: DEBUG: approved_usage = SSLServer intended_usage = SSLServer [Sat Oct 05 00:25:45 2013] [error] ipa: DEBUG: cert valid True for "CN=HOSTNAME.DOMAIN,O=FULLY.QUALIFIED.DOMAIN" [Sat Oct 05 00:25:45 2013] [error] ipa: DEBUG: handshake complete, peer = 142.103.89.209:443 [Sat Oct 05 00:25:45 2013] [info] Initial (No.1) HTTPS request received for child 4 (server HOSTNAME.DOMAIN:443) [Sat Oct 05 00:25:45 2013] [debug] nss_engine_kernel.c(314): Changed client verification type will force renegotiation [Sat Oct 05 00:25:45 2013] [debug] nss_engine_io.c(947): [client 142.103.89.209] filling buffer [Sat Oct 05 00:25:45 2013] [debug] nss_engine_io.c(998): [client 142.103.89.209] total of 24 bytes in buffer, eos=1 [Sat Oct 05 00:25:45 2013] [info] Requesting connection re-negotiation [Sat Oct 05 00:25:45 2013] [debug] nss_engine_kernel.c(409): Performing full renegotiation: complete handshake protocol [Sat Oct 05 00:25:45 2013] [debug] nss_engine_kernel.c(431): Awaiting re-negotiation handshake [Sat Oct 05 00:25:45 2013] [error] ipa: DEBUG: auth_certificate_callback: check_sig=True is_server=False [Sat Oct 05 00:25:45 2013] [error] Data: [Sat Oct 05 00:25:45 2013] [error] Version: 3 (0x2) [Sat Oct 05 00:25:45 2013] [error] Serial Number: 22 (0x16) [Sat Oct 05 00:25:45 2013] [error] Signature Algorithm: [Sat Oct 05 00:25:45 2013] [error] Algorithm: PKCS #1 SHA-256 With RSA Encryption [Sat Oct 05 00:25:45 2013] [error] Issuer: CN=Certificate Authority,O=FULLY.QUALIFIED.DOMAIN [Sat Oct 05 00:25:45 2013] [error] Validity: [Sat Oct 05 00:25:45 2013] [error] Not Before: Thu Apr 11 23:23:18 2013 UTC [Sat Oct 05 00:25:45 2013] [error] Not After: Tue Oct 08 23:23:18 2013 UTC [Sat Oct 05 00:25:45 2013] [error] Subject: CN=HOSTNAME.DOMAIN,O=FULLY.QUALIFIED.DOMAIN [Sat Oct 05 00:25:45 2013] [error] Subject Public Key Info: [Sat Oct 05 00:25:45 2013] [error] Public Key Algorithm: [Sat Oct 05 00:25:45 2013] [error] Algorithm: PKCS #1 RSA Encryption [Sat Oct 05 00:25:45 2013] [error] RSA Public Key: [Sat Oct 05 00:25:45 2013] [error] Modulus: [Sat Oct 05 00:25:45 2013] [error] b0:b0:50:1f:e9:72:26:d5:dd:ff:70:ba:66:bb:a6:90: [Sat Oct 05 00:25:45 2013] [error] bf:02:e9:7f:9b:73:10:9b:d9:a5:84:f7:34:c6:ed:03: [Sat Oct 05 00:25:45 2013] [error] ca:48:11:5e:50:9d:19:9f:22:24:8a:17:35:69:d0:69: [Sat Oct 05 00:25:45 2013] [error] 0e:f7:a8:37:2d:46:11:98:5e:df:a8:2c:93:96:a7:66: [Sat Oct 05 00:25:45 2013] [error] e4:3d:20:c1:72:e2:94:46:36:0b:84:44:2e:94:a9:98: [Sat Oct 05 00:25:45 2013] [error] 7a:da:1d:3a:f0:13:53:47:0d:b1:30:21:9d:55:a8:32: [Sat Oct 05 00:25:45 2013] [error] 09:be:c6:d3:98:2e:6c:a1:a1:34:02:9a:7f:df:ba:4b: [Sat Oct 05 00:25:45 2013] [error] f1:c9:10:c4:0b:70:e7:08:de:98:24:c4:a6:d2:4a:e5: [Sat Oct 05 00:25:45 2013] [error] 0c:41:e7:f6:80:a5:7a:25:b7:8d:0e:b9:aa:b7:ff:4f: [Sat Oct 05 00:25:45 2013] [error] cd:85:b5:3e:1c:e0:6f:83:e5:c1:86:ec:e0:6f:dd:f2: [Sat Oct 05 00:25:45 2013] [error] 3a:6b:60:ce:3f:63:46:9a:75:5e:e3:20:76:d3:36:53: [Sat Oct 05 00:25:45 2013] [error] 07:1f:34:77:a7:42:3e:58:0d:30:15:f6:47:e3:a2:d3: [Sat Oct 05 00:25:45 2013] [error] 46:b0:cf:62:1b:00:2a:28:18:39:5c:35:3b:ff:c6:7a: [Sat Oct 05 00:25:45 2013] [error] c2:9d:08:75:17:92:d3:7f:58:6d:c8:bc:55:c3:6f:3e: [Sat Oct 05 00:25:45 2013] [error] 17:f7:55:bf:e6:3c:af:cc:8a:18:59:f1:46:50:07:36: [Sat Oct 05 00:25:45 2013] [error] 09:38:87:4b:38:67:44:f6:b6:bb:cf:f0:af:88:30:5f [Sat Oct 05 00:25:45 2013] [error] Exponent: [Sat Oct 05 00:25:45 2013] [error] 65537 (0x10001) [Sat Oct 05 00:25:45 2013] [error] Signed Extensions: (5) [Sat Oct 05 00:25:45 2013] [error] Name: Certificate Authority Key Identifier [Sat Oct 05 00:25:45 2013] [error] Critical: False [Sat Oct 05 00:25:45 2013] [error] Key ID: [Sat Oct 05 00:25:45 2013] [error] 3a:41:f5:c1:b7:ff:bb:79:13:d1:23:92:61:16:fc:7d: [Sat Oct 05 00:25:45 2013] [error] a7:d1:82:d2 [Sat Oct 05 00:25:45 2013] [error] Serial Number: None [Sat Oct 05 00:25:45 2013] [error] General Names: [0 total] [Sat Oct 05 00:25:45 2013] [error] [Sat Oct 05 00:25:45 2013] [error] Name: Authority Information Access [Sat Oct 05 00:25:45 2013] [error] Critical: False [Sat Oct 05 00:25:45 2013] [error] [Sat Oct 05 00:25:45 2013] [error] Name: Certificate Key Usage [Sat Oct 05 00:25:45 2013] [error] Critical: True [Sat Oct 05 00:25:45 2013] [error] Usages: [Sat Oct 05 00:25:45 2013] [error] Digital Signature [Sat Oct 05 00:25:45 2013] [error] Non-Repudiation [Sat Oct 05 00:25:45 2013] [error] Key Encipherment [Sat Oct 05 00:25:45 2013] [error] Data Encipherment [Sat Oct 05 00:25:45 2013] [error] [Sat Oct 05 00:25:45 2013] [error] Name: Extended Key Usage [Sat Oct 05 00:25:45 2013] [error] Critical: False [Sat Oct 05 00:25:45 2013] [error] Usages: [Sat Oct 05 00:25:45 2013] [error] TLS Web Server Authentication Certificate [Sat Oct 05 00:25:45 2013] [error] [Sat Oct 05 00:25:45 2013] [error] Name: Certificate Subject Key ID [Sat Oct 05 00:25:45 2013] [error] Critical: False [Sat Oct 05 00:25:45 2013] [error] Data: [Sat Oct 05 00:25:45 2013] [error] e0:56:1f:d5:73:7c:5f:7f:60:5e:d7:3c:88:43:8d:97: [Sat Oct 05 00:25:45 2013] [error] b7:f5:fb:24 [Sat Oct 05 00:25:45 2013] [error] [Sat Oct 05 00:25:45 2013] [error] Certificate Trust Flags: [Sat Oct 05 00:25:45 2013] [error] SSL Flags: [Sat Oct 05 00:25:45 2013] [error] User [Sat Oct 05 00:25:45 2013] [error] Email Flags: [Sat Oct 05 00:25:45 2013] [error] User [Sat Oct 05 00:25:45 2013] [error] Object Signing Flags: [Sat Oct 05 00:25:45 2013] [error] User [Sat Oct 05 00:25:45 2013] [error] Signature: [Sat Oct 05 00:25:45 2013] [error] Signature Algorithm: [Sat Oct 05 00:25:45 2013] [error] Algorithm: PKCS #1 SHA-256 With RSA Encryption [Sat Oct 05 00:25:45 2013] [error] Signature: [Sat Oct 05 00:25:45 2013] [error] 85:60:83:4c:d5:80:28:9c:ec:69:b0:26:7a:4f:fc:99: [Sat Oct 05 00:25:45 2013] [error] e1:4e:3d:78:54:59:d7:46:b3:cf:fb:81:8e:16:67:18: [Sat Oct 05 00:25:45 2013] [error] b4:c4:98:3f:16:54:05:ef:6e:79:5f:62:81:65:e3:a8: [Sat Oct 05 00:25:45 2013] [error] e7:7b:68:12:25:1f:af:dc:bf:3a:f7:74:72:9d:1d:51: [Sat Oct 05 00:25:45 2013] [error] ae:e8:12:73:4c:a8:19:ad:54:03:22:a6:c0:56:29:1a: [Sat Oct 05 00:25:45 2013] [error] cc:70:81:5e:fb:38:c0:f7:16:d5:9b:34:2c:16:43:84: [Sat Oct 05 00:25:45 2013] [error] b3:7f:bb:86:83:fd:9a:d7:f5:67:a8:f4:c3:33:58:5e: [Sat Oct 05 00:25:45 2013] [error] 89:7a:f6:9f:a8:d7:b6:f9:0b:47:d7:6e:46:53:32:63: [Sat Oct 05 00:25:45 2013] [error] e6:da:23:54:89:bc:4f:12:16:6d:eb:d4:f0:55:08:46: [Sat Oct 05 00:25:45 2013] [error] 64:69:46:55:20:90:ab:61:c4:f2:b6:d5:50:b5:48:07: [Sat Oct 05 00:25:45 2013] [error] c0:f9:da:8e:fb:dd:53:e6:9f:1f:4e:d9:ec:af:a6:ad: [Sat Oct 05 00:25:45 2013] [error] 75:76:75:e4:b7:b3:ad:56:52:66:f4:9b:71:0d:b1:92: [Sat Oct 05 00:25:45 2013] [error] a1:fc:16:c7:66:41:dd:b4:2f:df:34:ed:ad:29:26:40: [Sat Oct 05 00:25:45 2013] [error] 4f:85:a5:98:2c:9b:f0:18:42:3d:97:aa:73:16:3b:ac: [Sat Oct 05 00:25:45 2013] [error] 48:a9:8c:af:77:b3:24:d0:0d:07:ff:11:79:a9:24:a8: [Sat Oct 05 00:25:45 2013] [error] 2a:08:bd:e1:84:e3:6a:6f:2c:8e:62:78:8e:86:95:73 [Sat Oct 05 00:25:45 2013] [error] Fingerprint (MD5): [Sat Oct 05 00:25:45 2013] [error] 27:7d:ec:86:4f:07:65:9f:27:1e:eb:c4:af:9b:b0:b1 [Sat Oct 05 00:25:45 2013] [error] Fingerprint (SHA1): [Sat Oct 05 00:25:45 2013] [error] df:60:7a:1b:54:22:bd:f2:2c:ea:ee:51:17:23:ae:2d: [Sat Oct 05 00:25:45 2013] [error] f2:57:69:88 [Sat Oct 05 00:25:45 2013] [error] ipa: DEBUG: approved_usage = SSLServer intended_usage = SSLServer [Sat Oct 05 00:25:45 2013] [error] ipa: DEBUG: cert valid True for "CN=HOSTNAME.DOMAIN,O=FULLY.QUALIFIED.DOMAIN" [Sat Oct 05 00:25:45 2013] [error] /usr/lib64/python2.6/getpass.py:83: GetPassWarning: Can not control echo on the terminal. [Sat Oct 05 00:25:45 2013] [error] passwd = fallback_getpass(prompt, stream) [Sat Oct 05 00:25:45 2013] [error] Warning: Password input may be echoed. [Sat Oct 05 00:25:45 2013] [error] Enter password for internal: [Sat Oct 05 00:25:45 2013] [error] exception in PK11 password callback [Sat Oct 05 00:25:45 2013] [error] Traceback (most recent call last): [Sat Oct 05 00:25:45 2013] [error] File "/usr/lib/python2.6/site-packages/ipapython/nsslib.py", line 229, in password_callback [Sat Oct 05 00:25:45 2013] [error] return getpass.getpass("Enter password for %s: " % slot.token_name); [Sat Oct 05 00:25:45 2013] [error] File "/usr/lib64/python2.6/getpass.py", line 83, in unix_getpass [Sat Oct 05 00:25:45 2013] [error] passwd = fallback_getpass(prompt, stream) [Sat Oct 05 00:25:45 2013] [error] File "/usr/lib64/python2.6/getpass.py", line 118, in fallback_getpass [Sat Oct 05 00:25:45 2013] [error] return _raw_input(prompt, stream) [Sat Oct 05 00:25:45 2013] [error] File "/usr/lib64/python2.6/getpass.py", line 135, in _raw_input [Sat Oct 05 00:25:45 2013] [error] raise EOFError [Sat Oct 05 00:25:45 2013] [error] EOFError [Sat Oct 05 00:25:45 2013] [error] ipa: DEBUG: handshake complete, peer = 142.103.89.209:443 [Sat Oct 05 00:25:45 2013] [debug] mod_proxy_ajp.c(45): proxy: AJP: canonicalising URL //localhost:9447/ca/agent/ca/displayBySerial [Sat Oct 05 00:25:45 2013] [debug] proxy_util.c(1521): [client 142.103.89.209] proxy: ajp: found worker ajp://localhost:9447 for ajp://localhost:9447/ca/agent/ca/displayBySerial [Sat Oct 05 00:25:45 2013] [debug] mod_proxy.c(1020): Running scheme ajp handler (attempt 0) [Sat Oct 05 00:25:45 2013] [debug] mod_proxy_http.c(1952): proxy: HTTP: declining URL ajp://localhost:9447/ca/agent/ca/displayBySerial [Sat Oct 05 00:25:45 2013] [debug] mod_proxy_ajp.c(709): proxy: AJP: serving URL ajp://localhost:9447/ca/agent/ca/displayBySerial [Sat Oct 05 00:25:45 2013] [debug] proxy_util.c(2026): proxy: AJP: has acquired connection for (localhost) [Sat Oct 05 00:25:45 2013] [debug] proxy_util.c(2082): proxy: connecting ajp://localhost:9447/ca/agent/ca/displayBySerial to localhost:9447 [Sat Oct 05 00:25:45 2013] [debug] proxy_util.c(2209): proxy: connected /ca/agent/ca/displayBySerial to localhost:9447 [Sat Oct 05 00:25:45 2013] [debug] proxy_util.c(2460): proxy: AJP: fam 2 socket created to connect to localhost [Sat Oct 05 00:25:45 2013] [debug] ajp_header.c(224): Into ajp_marshal_into_msgb [Sat Oct 05 00:25:45 2013] [debug] ajp_header.c(290): ajp_marshal_into_msgb: Header[0] [Host] = [HOSTNAME.DOMAIN] [Sat Oct 05 00:25:45 2013] [debug] ajp_header.c(290): ajp_marshal_into_msgb: Header[1] [Accept-Encoding] = [identity] [Sat Oct 05 00:25:45 2013] [debug] ajp_header.c(290): ajp_marshal_into_msgb: Header[2] [Content-Length] = [24] [Sat Oct 05 00:25:45 2013] [debug] ajp_header.c(290): ajp_marshal_into_msgb: Header[3] [Content-type] = [application/x-www-form-urlencoded] [Sat Oct 05 00:25:45 2013] [debug] ajp_header.c(290): ajp_marshal_into_msgb: Header[4] [Accept] = [text/plain] [Sat Oct 05 00:25:45 2013] [debug] ajp_header.c(450): ajp_marshal_into_msgb: Done [Sat Oct 05 00:25:45 2013] [debug] nss_engine_io.c(1030): [client 142.103.89.209] read from buffered SSL brigade, mode 0, 8186 bytes [Sat Oct 05 00:25:45 2013] [debug] nss_engine_io.c(1092): [client 142.103.89.209] buffered SSL brigade now exhausted; removing filter [Sat Oct 05 00:25:45 2013] [debug] mod_proxy_ajp.c(269): proxy: APR_BUCKET_IS_EOS [Sat Oct 05 00:25:45 2013] [debug] mod_proxy_ajp.c(274): proxy: data to read (max 8186 at 4) [Sat Oct 05 00:25:45 2013] [debug] mod_proxy_ajp.c(289): proxy: got 24 bytes of data [Sat Oct 05 00:25:45 2013] [debug] ajp_header.c(687): ajp_read_header: ajp_ilink_received 04 [Sat Oct 05 00:25:45 2013] [debug] ajp_header.c(697): ajp_parse_type: got 04 [Sat Oct 05 00:25:45 2013] [debug] ajp_header.c(516): ajp_unmarshal_response: status = 200 [Sat Oct 05 00:25:45 2013] [debug] ajp_header.c(537): ajp_unmarshal_response: Number of headers is = 2 [Sat Oct 05 00:25:45 2013] [debug] ajp_header.c(599): ajp_unmarshal_response: Header[0] [Content-Type] = [application/xml] [Sat Oct 05 00:25:45 2013] [debug] ajp_header.c(609): ajp_unmarshal_response: ap_set_content_type done [Sat Oct 05 00:25:45 2013] [debug] ajp_header.c(599): ajp_unmarshal_response: Header[1] [Content-Length] = [274] [Sat Oct 05 00:25:45 2013] [debug] ajp_header.c(687): ajp_read_header: ajp_ilink_received 03 [Sat Oct 05 00:25:45 2013] [debug] ajp_header.c(697): ajp_parse_type: got 03 [Sat Oct 05 00:25:45 2013] [error] ipa: DEBUG: parse_display_cert_xml() xml_text: [Sat Oct 05 00:25:45 2013] [error]
Certificate ManagerYou did not provide a valid certificate for this operation7 [Sat Oct 05 00:25:45 2013] [error] parse_result: [Sat Oct 05 00:25:45 2013] [error] {'request_status': 7, 'error_string': u'You did not provide a valid certificate for this operation', 'authority': u'Certificate Manager'} [Sat Oct 05 00:25:45 2013] [error] ipa: ERROR: ipaserver.plugins.dogtag.ra.get_certificate(): EXCEPTION (You did not provide a valid certificate for this operation) [Sat Oct 05 00:25:45 2013] [error] ipa: INFO: admin at FULLY.QUALIFIED.DOMAIN: cert_show(u'22'): CertificateOperationError [Sat Oct 05 00:25:45 2013] [error] ipa: DEBUG: response: CertificateOperationError: Certificate operation cannot be completed: EXCEPTION (You did not provide a valid certificate for this operation) [Sat Oct 05 00:25:45 2013] [debug] ajp_header.c(687): ajp_read_header: ajp_ilink_received 05 [Sat Oct 05 00:25:45 2013] [debug] ajp_header.c(697): ajp_parse_type: got 05 [Sat Oct 05 00:25:45 2013] [debug] mod_proxy_ajp.c(616): proxy: got response from (null) (localhost) [Sat Oct 05 00:25:45 2013] [debug] proxy_util.c(2044): proxy: AJP: has released connection for (localhost) [Sat Oct 05 00:25:45 2013] [info] Connection to child 4 closed (server HOSTNAME.DOMAIN:443, client 142.103.89.209) [Sat Oct 05 00:25:45 2013] [error] ipa: DEBUG: no session id in request, generating empty session data with id=770312911f588dc88e3d5847a28b3344 [Sat Oct 05 00:25:45 2013] [error] ipa: DEBUG: store session: session_id=770312911f588dc88e3d5847a28b3344 start_timestamp=2013-10-05T00:25:45 access_timestamp=2013-10-05T00:25:45 expiration_timestamp=1969-12-31T16:00:00 [Sat Oct 05 00:25:45 2013] [error] ipa: DEBUG: finalize_kerberos_acquisition: xmlserver ccache_name="FILE:/tmp/krb5cc_apache_iaPR3X" session_id="770312911f588dc88e3d5847a28b3344" [Sat Oct 05 00:25:45 2013] [error] ipa: DEBUG: reading ccache data from file "/tmp/krb5cc_apache_iaPR3X" [Sat Oct 05 00:25:45 2013] [error] ipa: DEBUG: get_credential_times: principal=HTTP/HOSTNAME.DOMAIN at FULLY.QUALIFIED.DOMAIN, authtime=10/05/13 00:24:59, starttime=10/05/13 00:25:14, endtime=10/06/13 00:24:42, renew_till=12/31/69 16:00:00 [Sat Oct 05 00:25:45 2013] [error] ipa: DEBUG: KRB5_CCache FILE:/tmp/krb5cc_apache_iaPR3X endtime=1381044282 (10/06/13 00:24:42) [Sat Oct 05 00:25:45 2013] [error] ipa: DEBUG: set_session_expiration_time: duration_type=inactivity_timeout duration=1200 max_age=1381043982 expiration=1380959145.43 (2013-10-05T00:45:45) [Sat Oct 05 00:25:45 2013] [error] ipa: DEBUG: store session: session_id=770312911f588dc88e3d5847a28b3344 start_timestamp=2013-10-05T00:25:45 access_timestamp=2013-10-05T00:25:45 expiration_timestamp=2013-10-05T00:45:45 [Sat Oct 05 00:25:45 2013] [error] ipa: DEBUG: Destroyed connection context.ldap2 [Sat Oct 05 00:25:45 2013] [info] Connection to child 3 closed (server HOSTNAME.DOMAIN:443, client 142.103.89.209) I'm not sure what to make of this. Thanks, --Ryan From rcritten at redhat.com Fri Oct 25 17:53:40 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 25 Oct 2013 13:53:40 -0400 Subject: [Freeipa-users] Failure decoding Certificate Signing Request In-Reply-To: <4236DE1EFED4374EA69B197EB5AC27573514DF76@S-ITSV-MBX02P.ead.ubc.ca> References: <3fc2cb83-f64c-450b-a9d9-d4612966bbc1@S-ITSV-HUB01P.ead.ubc.ca> <52666FE7.4060406@redhat.com> <4236DE1EFED4374EA69B197EB5AC275735147A7B@S-ITSV-MBX02P.ead.ubc.ca> <5266B9C7.5090507@redhat.com> <4236DE1EFED4374EA69B197EB5AC275735148D59@S-ITSV-MBX02P.ead.ubc.ca> <526730C8.7030105@redhat.com> <4236DE1EFED4374EA69B197EB5AC27573514A59D@S-ITSV-MBX02P.ead.ubc.ca> <52687EB5.9030000@redhat.com> <4236DE1EFED4374EA69B197EB5AC27573514BC5F@S-ITSV-MBX02P.ead.ubc.ca> <526969C1.8010802@redhat.com> <4236DE1EFED4374EA69B197EB5AC27573514DF76@S-ITSV-MBX02P.ead.ubc.ca> Message-ID: <526AB024.5060001@redhat.com> Thomson, Ryan wrote: >> -----Original Message----- >> From: Rob Crittenden [mailto:rcritten at redhat.com] >> Sent: Thursday, October 24, 2013 11:41 AM >> To: Thomson, Ryan; freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] Failure decoding Certificate Signing Request >> >> Thomson, Ryan wrote: >>>> -----Original Message----- >>>> From: Rob Crittenden [mailto:rcritten at redhat.com] >>>> Sent: Wednesday, October 23, 2013 6:58 PM >>>> To: Thomson, Ryan; freeipa-users at redhat.com >>>> Subject: Re: [Freeipa-users] Failure decoding Certificate Signing >>>> Request >>>> >>>> I think this still points to NSS not being initialized. The way we >>>> currently use NSS in the server is Apache fires things up using >>>> mod_nss, then because we are a child of Apache via mod_wsgi, we >>>> inherit the open NSS database in /etc/httpd/alias. This gives us the >>>> CA cert and the client cert we need in order to talk to dogtag. >>>> >>>> What I thought, and the excellent debugging above confirms, is that >>>> at some point the NSS database is being shut down. At some point we >>>> need to do some crypto and try to initialize it ourselves to no >>>> avail. We shouldn't ever need to do it in the server and thus don't >>>> have access to PINs and such because we don't need them. We do >>>> initialize things from time to time on the client side but we tend to >>>> do a database-less initialization (nss_init_nodb()). >>>> >>>> I'm not really sure what this tells us though. It would appear that >>>> SSL is working in Apache, because you are able to get far enough to >>>> make a request and have it fail. So the NSS database is still >>>> initialized in Apache, but for some reason the wsgi code doesn't seem to >> agree. >>>> >>>> Would it be possible for you to stop and restart Apache and run some >>>> simple IPA command like ipa user-show admin (and let me know if it >> succeeds)? >>>> Then send me the error_log? >>>> >>>> If you are in SELinux enforcing mode it would also be helpful to >>>> check for any AVCs. Maybe we simply can't access the database. >>>> >>>> thanks >>>> >>>> rob >>> >>> I am able to stop/wait/start apache and then execute "ipa user-show >> admin" successfully. >>> >> >> Ok, let's try a couple more things. >> >> Can you set LogLevel debug in /etc/httpd/conf.d/nss.conf and restart >> Apache again? This may give us more information on what mod_nss is doing. >> >> Next, lets try a different cert command that should also invoke the NSS client >> within IPA: >> >> $ ipa cert-show 22 >> >> Can you describe your environment? Do you have multiple IPA masters? Was >> this a new install at 3.0 or is it an upgrade from 2.2? >> >> rob > > The environment is simple: Single master, upgraded from 2.2. > > Output in /var/log/httpd/error_log after setting LogLevel to debug in /etc/httpd/conf.d/nss.conf and restarting apache: [ snip ] > > I'm not sure what to make of this. This is just more confirmation that the IPA framework is trying to initialize NSS for some reason. It should never do this which is why it is failing so spectacularly. Can you provide nss.conf and ipa.conf from /etc/httpd/conf.d? Who owns and what are the permissions of /etc/httpd/alias/*.db? thanks rob From ryan.thomson at ubc.ca Fri Oct 25 18:17:29 2013 From: ryan.thomson at ubc.ca (Thomson, Ryan) Date: Fri, 25 Oct 2013 18:17:29 +0000 Subject: [Freeipa-users] Failure decoding Certificate Signing Request In-Reply-To: <526AB024.5060001@redhat.com> References: <3fc2cb83-f64c-450b-a9d9-d4612966bbc1@S-ITSV-HUB01P.ead.ubc.ca> <52666FE7.4060406@redhat.com> <4236DE1EFED4374EA69B197EB5AC275735147A7B@S-ITSV-MBX02P.ead.ubc.ca> <5266B9C7.5090507@redhat.com> <4236DE1EFED4374EA69B197EB5AC275735148D59@S-ITSV-MBX02P.ead.ubc.ca> <526730C8.7030105@redhat.com> <4236DE1EFED4374EA69B197EB5AC27573514A59D@S-ITSV-MBX02P.ead.ubc.ca> <52687EB5.9030000@redhat.com> <4236DE1EFED4374EA69B197EB5AC27573514BC5F@S-ITSV-MBX02P.ead.ubc.ca> <526969C1.8010802@redhat.com> <4236DE1EFED4374EA69B197EB5AC27573514DF76@S-ITSV-MBX02P.ead.ubc.ca> <526AB024.5060001@redhat.com> Message-ID: <4236DE1EFED4374EA69B197EB5AC27573514E563@S-ITSV-MBX02P.ead.ubc.ca> > -----Original Message----- > From: Rob Crittenden [mailto:rcritten at redhat.com] > Sent: Friday, October 25, 2013 10:54 AM > To: Thomson, Ryan; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Failure decoding Certificate Signing Request > > Thomson, Ryan wrote: > >> -----Original Message----- > >> From: Rob Crittenden [mailto:rcritten at redhat.com] > >> Sent: Thursday, October 24, 2013 11:41 AM > >> To: Thomson, Ryan; freeipa-users at redhat.com > >> Subject: Re: [Freeipa-users] Failure decoding Certificate Signing > >> Request > >> > >> Thomson, Ryan wrote: > >>>> -----Original Message----- > >>>> From: Rob Crittenden [mailto:rcritten at redhat.com] > >>>> Sent: Wednesday, October 23, 2013 6:58 PM > >>>> To: Thomson, Ryan; freeipa-users at redhat.com > >>>> Subject: Re: [Freeipa-users] Failure decoding Certificate Signing > >>>> Request > >>>> > >>>> I think this still points to NSS not being initialized. The way we > >>>> currently use NSS in the server is Apache fires things up using > >>>> mod_nss, then because we are a child of Apache via mod_wsgi, we > >>>> inherit the open NSS database in /etc/httpd/alias. This gives us > >>>> the CA cert and the client cert we need in order to talk to dogtag. > >>>> > >>>> What I thought, and the excellent debugging above confirms, is that > >>>> at some point the NSS database is being shut down. At some point we > >>>> need to do some crypto and try to initialize it ourselves to no > >>>> avail. We shouldn't ever need to do it in the server and thus don't > >>>> have access to PINs and such because we don't need them. We do > >>>> initialize things from time to time on the client side but we tend > >>>> to do a database-less initialization (nss_init_nodb()). > >>>> > >>>> I'm not really sure what this tells us though. It would appear that > >>>> SSL is working in Apache, because you are able to get far enough to > >>>> make a request and have it fail. So the NSS database is still > >>>> initialized in Apache, but for some reason the wsgi code doesn't > >>>> seem to > >> agree. > >>>> > >>>> Would it be possible for you to stop and restart Apache and run > >>>> some simple IPA command like ipa user-show admin (and let me know > >>>> if it > >> succeeds)? > >>>> Then send me the error_log? > >>>> > >>>> If you are in SELinux enforcing mode it would also be helpful to > >>>> check for any AVCs. Maybe we simply can't access the database. > >>>> > >>>> thanks > >>>> > >>>> rob > >>> > >>> I am able to stop/wait/start apache and then execute "ipa user-show > >> admin" successfully. > >>> > >> > >> Ok, let's try a couple more things. > >> > >> Can you set LogLevel debug in /etc/httpd/conf.d/nss.conf and restart > >> Apache again? This may give us more information on what mod_nss is > doing. > >> > >> Next, lets try a different cert command that should also invoke the > >> NSS client within IPA: > >> > >> $ ipa cert-show 22 > >> > >> Can you describe your environment? Do you have multiple IPA masters? > >> Was this a new install at 3.0 or is it an upgrade from 2.2? > >> > >> rob > > > > The environment is simple: Single master, upgraded from 2.2. > > > > Output in /var/log/httpd/error_log after setting LogLevel to debug in > /etc/httpd/conf.d/nss.conf and restarting apache: > > [ snip ] > > > > > I'm not sure what to make of this. > > This is just more confirmation that the IPA framework is trying to initialize > NSS for some reason. It should never do this which is why it is failing so > spectacularly. > > Can you provide nss.conf and ipa.conf from /etc/httpd/conf.d? > > Who owns and what are the permissions of /etc/httpd/alias/*.db? > > thanks > > rob Thanks for sticking with me on this. Below is the contents of the requested files and ownership/permissions of the apache NSS db. /etc/httpd/conf.d/ipa.conf: # # VERSION 10 - DO NOT REMOVE THIS LINE # # This file may be overwritten on upgrades. # # LoadModule auth_kerb_module modules/mod_auth_kerb.so ProxyRequests Off #We use xhtml, a file format that the browser validates DirectoryIndex index.html # Substantially increase the request field size to support MS-PAC # requests, ticket #2767. This should easily support a 64KiB PAC. LimitRequestFieldSize 100000 # ipa-rewrite.conf is loaded separately # This is required so the auto-configuration works with Firefox 2+ AddType application/java-archive jar AddType application/x-xpinstall xpi # FIXME: WSGISocketPrefix is a server-scope directive. The mod_wsgi package # should really be fixed by adding this its /etc/httpd/conf.d/wsgi.conf: WSGISocketPrefix /var/run/httpd/wsgi # Configure mod_wsgi handler for /ipa WSGIDaemonProcess ipa processes=2 threads=1 maximum-requests=500 WSGIProcessGroup ipa WSGIApplicationGroup ipa WSGIImportScript /usr/share/ipa/wsgi.py process-group=ipa application-group=ipa WSGIScriptAlias /ipa /usr/share/ipa/wsgi.py WSGIScriptReloading Off # Turn off mod_msgi handler for errors, config, crl: SetHandler None SetHandler None SetHandler None KrbConstrainedDelegationLock ipa # Protect /ipa and everything below it in webspace with Apache Kerberos auth AuthType Kerberos AuthName "Kerberos Login" KrbMethodNegotiate on KrbMethodK5Passwd off KrbServiceName HTTP KrbAuthRealms FULLY.QUALIFIED.DOMAIN Krb5KeyTab /etc/httpd/conf/ipa.keytab KrbSaveCredentials on KrbConstrainedDelegation on Require valid-user ErrorDocument 401 /ipa/errors/unauthorized.html # Turn off Apache authentication for sessions Satisfy Any Order Deny,Allow Allow from all Satisfy Any Order Deny,Allow Allow from all Satisfy Any Order Deny,Allow Allow from all Satisfy Any Order Deny,Allow Allow from all # This is where we redirect on failed auth Alias /ipa/errors "/usr/share/ipa/html" # For the MIT Windows config files Alias /ipa/config "/usr/share/ipa/html" # Do no authentication on the directory that contains error messages SetHandler None AllowOverride None Satisfy Any Allow from all # For CRL publishing Alias /ipa/crl "/var/lib/ipa/pki-ca/publish" SetHandler None AllowOverride None Options Indexes FollowSymLinks Satisfy Any Allow from all # webUI is now completely static, and served out of that directory Alias /ipa/ui "/usr/share/ipa/ui" SetHandler None AllowOverride None Satisfy Any Allow from all # Protect our CGIs AuthType Kerberos AuthName "Kerberos Login" KrbMethodNegotiate on KrbMethodK5Passwd off KrbServiceName HTTP KrbAuthRealms FMRI.UBC.CA Krb5KeyTab /etc/httpd/conf/ipa.keytab KrbSaveCredentials on Require valid-user ErrorDocument 401 /ipa/errors/unauthorized.html # migration related pages Alias /ipa/migration "/usr/share/ipa/migration" AllowOverride None Satisfy Any Allow from all Options ExecCGI AddHandler wsgi-script .py /etc/httpd/conf.d/nss.conf: # # This is the Apache server configuration file providing SSL support using. # the mod_nss plugin. It contains the configuration directives to instruct # the server how to serve pages over an https connection. # # Do NOT simply read the instructions in here without understanding # what they do. They're here only as hints or reminders. If you are unsure # consult the online docs. You have been warned. # LoadModule nss_module modules/libmodnss.so # # When we also provide SSL we have to listen to the # standard HTTP port (see above) and to the HTTPS port # # Note: Configurations that use IPv6 but not IPv4-mapped addresses need two # Listen directives: "Listen [::]:443" and "Listen 0.0.0.0:443" # Listen 443 ## ## SSL Global Context ## ## All SSL configuration in this context applies both to ## the main server and all SSL-enabled virtual hosts. ## # # Some MIME-types for downloading Certificates and CRLs # AddType application/x-x509-ca-cert .crt AddType application/x-pkcs7-crl .crl # Pass Phrase Dialog: # Configure the pass phrase gathering process. # The filtering dialog program (`builtin' is a internal # terminal dialog) has to provide the pass phrase on stdout. NSSPassPhraseDialog "file:/etc/httpd/conf/password.conf" # Pass Phrase Helper: # This helper program stores the token password pins between # restarts of Apache. NSSPassPhraseHelper /usr/sbin/nss_pcache # Configure the SSL Session Cache. # NSSSessionCacheSize is the number of entries in the cache. # NSSSessionCacheTimeout is the SSL2 session timeout (in seconds). # NSSSession3CacheTimeout is the SSL3/TLS session timeout (in seconds). NSSSessionCacheSize 10000 NSSSessionCacheTimeout 100 NSSSession3CacheTimeout 86400 # # Pseudo Random Number Generator (PRNG): # Configure one or more sources to seed the PRNG of the SSL library. # The seed data should be of good random quality. # WARNING! On some platforms /dev/random blocks if not enough entropy # is available. Those platforms usually also provide a non-blocking # device, /dev/urandom, which may be used instead. # # This does not support seeding the RNG with each connection. NSSRandomSeed startup builtin #NSSRandomSeed startup file:/dev/random 512 #NSSRandomSeed startup file:/dev/urandom 512 # # TLS Negotiation configuration under RFC 5746 # # Only renegotiate if the peer's hello bears the TLS renegotiation_info # extension. Default off. NSSRenegotiation on # Peer must send Signaling Cipher Suite Value (SCSV) or # Renegotiation Info (RI) extension in ALL handshakes. Default: off NSSRequireSafeNegotiation on ## ## SSL Virtual Host Context ## # General setup for the virtual host #DocumentRoot "/etc/httpd/htdocs" #ServerName www.example.com:443 #ServerAdmin you at example.com # mod_nss can log to separate log files, you can choose to do that if you'd like # LogLevel is not inherited from httpd.conf. ErrorLog /etc/httpd/logs/error_log TransferLog /etc/httpd/logs/access_log LogLevel debug # SSL Engine Switch: # Enable/Disable SSL for this virtual host. NSSEngine on # SSL Cipher Suite: # List the ciphers that the client is permitted to negotiate. # See the mod_nss documentation for a complete list. # SSL 3 ciphers. SSL 2 is disabled by default. NSSCipherSuite +rsa_rc4_128_md5,+rsa_rc4_128_sha,+rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,-rsa_rc2_40_md5,-rsa_null_md5,-rsa_null_sha,+fips_3des_sha,-fips_des_sha,-fortezza,-fortezza_rc4_128_sha,-fortezza_null,-rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,+rsa_aes_256_sha # SSL 3 ciphers + ECC ciphers. SSL 2 is disabled by default. # # Comment out the NSSCipherSuite line above and use the one below if you have # ECC enabled NSS and mod_nss and want to use Elliptical Curve Cryptography #NSSCipherSuite +rsa_rc4_128_md5,+rsa_rc4_128_sha,+rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,-rsa_rc2_40_md5,-rsa_null_md5,-rsa_null_sha,+fips_3des_sha,-fips_des_sha,-fortezza,-fortezza_rc4_128_sha,-fortezza_null,-rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,+rsa_aes_256_sha,-ecdh_ecdsa_null_sha,+ecdh_ecdsa_rc4_128_sha,+ecdh_ecdsa_3des_sha,+ecdh_ecdsa_aes_128_sha,+ecdh_ecdsa_aes_256_sha,-ecdhe_ecdsa_null_sha,+ecdhe_ecdsa_rc4_128_sha,+ecdhe_ecdsa_3des_sha,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_sha,-ecdh_rsa_null_sha,+ecdh_rsa_128_sha,+ecdh_rsa_3des_sha,+ecdh_rsa_aes_128_sha,+ecdh_rsa_aes_256_sha,-echde_rsa_null,+ecdhe_rsa_rc4_128_sha,+ecdhe_rsa_3des_sha,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_sha NSSProtocol SSLv3,TLSv1.0 #NSSEnforceValidCerts off # SSL Certificate Nickname: # The nickname of the RSA server certificate you are going to use. NSSNickname Server-Cert # SSL Certificate Nickname: # The nickname of the ECC server certificate you are going to use, if you # have an ECC-enabled version of NSS and mod_nss #NSSECCNickname Server-Cert-ecc # Server Certificate Database: # The NSS security database directory that holds the certificates and # keys. The database consists of 3 files: cert8.db, key3.db and secmod.db. # Provide the directory that these files exist. NSSCertificateDatabase /etc/httpd/alias # Database Prefix: # In order to be able to store multiple NSS databases in one directory # they need unique names. This option sets the database prefix used for # cert8.db and key3.db. #NSSDBPrefix my-prefix- # Client Authentication (Type): # Client certificate verification type. Types are none, optional and # require. #NSSVerifyClient none # # Online Certificate Status Protocol (OCSP). # Verify that certificates have not been revoked before accepting them. #NSSOCSP off # # Use a default OCSP responder. If enabled this will be used regardless # of whether one is included in a client certificate. Note that the # server certificate is verified during startup. # # NSSOCSPDefaultURL defines the service URL of the OCSP responder # NSSOCSPDefaultName is the nickname of the certificate to trust to # sign the OCSP responses. #NSSOCSPDefaultResponder on #NSSOCSPDefaultURL http://example.com/ocsp/status #NSSOCSPDefaultName ocsp-nickname # Access Control: # With SSLRequire you can do per-directory access control based # on arbitrary complex boolean expressions containing server # variable checks and other lookup directives. The syntax is a # mixture between C and Perl. See the mod_nss documentation # for more details. # #NSSRequire ( %{SSL_CIPHER} !~ m/^(EXP|NULL)/ \ # and %{SSL_CLIENT_S_DN_O} eq "Snake Oil, Ltd." \ # and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"} \ # and %{TIME_WDAY} >= 1 and %{TIME_WDAY} <= 5 \ # and %{TIME_HOUR} >= 8 and %{TIME_HOUR} <= 20 ) \ # or %{REMOTE_ADDR} =~ m/^192\.76\.162\.[0-9]+$/ # # SSL Engine Options: # Set various options for the SSL engine. # o FakeBasicAuth: # Translate the client X.509 into a Basic Authorisation. This means that # the standard Auth/DBMAuth methods can be used for access control. The # user name is the `one line' version of the client's X.509 certificate. # Note that no password is obtained from the user. Every entry in the user # file needs this password: `xxj31ZMTZzkVA'. # o ExportCertData: # This exports two additional environment variables: SSL_CLIENT_CERT and # SSL_SERVER_CERT. These contain the PEM-encoded certificates of the # server (always existing) and the client (only existing when client # authentication is used). This can be used to import the certificates # into CGI scripts. # o StdEnvVars: # This exports the standard SSL/TLS related `SSL_*' environment variables. # Per default this exportation is switched off for performance reasons, # because the extraction step is an expensive operation and is usually # useless for serving static content. So one usually enables the # exportation for CGI and SSI requests only. # o StrictRequire: # This denies access when "NSSRequireSSL" or "NSSRequire" applied even # under a "Satisfy any" situation, i.e. when it applies access is denied # and no other module can change it. # o OptRenegotiate: # This enables optimized SSL connection renegotiation handling when SSL # directives are used in per-directory context. #NSSOptions +FakeBasicAuth +ExportCertData +CompatEnvVars +StrictRequire NSSOptions +StdEnvVars NSSOptions +StdEnvVars # Per-Server Logging: # The home of a custom SSL log file. Use this when you want a # compact non-error SSL logfile on a virtual host basis. #CustomLog /home/rcrit/redhat/apache/logs/ssl_request_log \ # "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b" Include conf.d/ipa-rewrite.conf And finally: root at HOSTNAME:/etc/httpd/alias # ls -alh *.db -rw-r-----. 1 root apache 64K Oct 5 00:17 cert8.db -rw-r-----. 1 root apache 36K Oct 5 00:17 key3.db -rw-r-----. 1 root apache 16K Oct 2 00:29 secmod.db Thank you, --Ryan From andrew.holway at gmail.com Mon Oct 28 15:15:56 2013 From: andrew.holway at gmail.com (Andrew Holway) Date: Mon, 28 Oct 2013 15:15:56 +0000 Subject: [Freeipa-users] DNS resource records problem. subdomains and /16's. Message-ID: Hello, I have created two DNS resource records. 51.10.in-addr.arpa. and test.domain.com. It seems that it does not like to use the 51.10.in-addr.arpa. for addresses. Must I specify each /24? In addition, if I am adding a host node.subdomain.test.nsslabs.com. It does not like this either. Must I specify a record for each subdomain? Am I missing a * somewhere? Thanks, Andrew From rcritten at redhat.com Mon Oct 28 15:20:45 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 28 Oct 2013 11:20:45 -0400 Subject: [Freeipa-users] DNS resource records problem. subdomains and /16's. In-Reply-To: References: Message-ID: <526E80CD.4010403@redhat.com> Andrew Holway wrote: > Hello, > > I have created two DNS resource records. 51.10.in-addr.arpa. and > test.domain.com. It seems that it does not like to use the > 51.10.in-addr.arpa. for addresses. Must I specify each /24? In > addition, if I am adding a host node.subdomain.test.nsslabs.com. It > does not like this either. Must I specify a record for each subdomain? > Am I missing a * somewhere? Can you be more specific about what you're seeing? rob From andrew.holway at gmail.com Mon Oct 28 15:33:04 2013 From: andrew.holway at gmail.com (Andrew Holway) Date: Mon, 28 Oct 2013 15:33:04 +0000 Subject: [Freeipa-users] DNS resource records problem. subdomains and /16's. In-Reply-To: <526E80CD.4010403@redhat.com> References: <526E80CD.4010403@redhat.com> Message-ID: Here is some info from FreeIPA . . . [root at freeipa ~]# ipa host-show Host name: node002.test.nsslabs.com Host name: node002.test.nsslabs.com Certificate: MIIDrzCCApegAwIBAgIBETANBgkqhkiG9w0BAQsFADA7MRkwFwYDVQQKExBURVNULk5TU0xBQlMuQ09NMR4wHAYDVQQDExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMTMxMDI4MDkwMDAxWhcNMTUxMDI5MDkwMDAxWjA+MRkwFwYDVQQKExBURVNULk5TU0xBQlMuQ09NMSEwHwYDVQQDExhub2RlMDAyLnRlc3QubnNzbGFicy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBNjwG219iSyJ7f8TVjoIUN8Wtk3WfaCTEW43d534UDCsC4e5pd/dsOqsCk+NqVf6u6SA80ZFnZp/z7ULoY9rm/+IRBY2M/ofu8PHVZ2wu33/4RhW9FXORh51rSaklefs3ZAgo+Ra2aiEdsm4vSk4+0f3dUnbtoqg6bkK0NHjUEkof/7EyM+WLhXUIfXnyFFu3gnHzqntX/SbybgtG8AuDSkm07LLnbY354u28OPE+DLaGgYPqZmuvdHVAEWu8i2uCywOyf3yHuFA59UjZclb7IQZ0qvm8GUUJjidFOfmgBSueyTUs+JvojYu2Z+roqwJpFY60oiSwMQw3fuHh/UqFAgMBAAGjgbowgbcwHwYDVR0jBBgwFoAUxjS+P9INb5f52vII8K8H9v8NqaUwRgYIKwYBBQUHAQEEOjA4MDYGCCsGAQUFBzABhipodHRwOi8vZnJlZWlwYS50ZXN0Lm5zc2xhYnMuY29tOjgwL2NhL29jc3AwDgYDVR0PAQH/BAQDAgTwMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAdBgNVHQ4EFgQUt6Eh8e4si95/Q/CbzbbAB5cESVUwDQYJKoZIhvcNAQELBQADggEBAK5OQe2jPdzTJZTizgLE8AMSlw9NWVCY0bLh4HbbIhazFo++FOlArRf8AfwukmFdv97JEy3wDWDccxQXBC+8/tmIP3TeILcLAwEmdmSynKXOvhQ97+EGNmQRO9uXLo1C5ognxUiDbjmXYWkMRjJFLzBvqbA4veRekgvS27faZa0lTTxygk2hrbcMyVN6MHGLdX07EMgSa6IkIUZ+TdLZwMep9IK6CtoJelTjDP0JIy3n5DBVzJ+C0GZ0XUyUE6vXFcpuvyGY4ckQHf1sEbWFcRmJsxsweAgGwol2GJAWa7vZJlTVJZOMgV8fO0aK0Y8kl/KHN+ycxWFQyxZ3njDPn6g= Principal name: host/node002.test.nsslabs.com at TEST.NSSLABS.COM Password: False Keytab: True Managed by: node002.test.nsslabs.com Subject: CN=node002.test.nsslabs.com,O=TEST.NSSLABS.COM Serial Number: 17 Serial Number (hex): 0x11 Issuer: CN=Certificate Authority,O=TEST.NSSLABS.COM Not Before: Mon Oct 28 09:00:01 2013 UTC Not After: Thu Oct 29 09:00:01 2015 UTC Fingerprint (MD5): d4:d7:fa:14:31:0a:71:70:c9:62:43:65:ab:c5:09:93 Fingerprint (SHA1): d2:72:8d:20:4b:c7:e5:a8:2d:bc:f9:e7:ca:c0:9b:f5:d9:53:c6:74 SSH public key fingerprint: 28:24:23:6C:6D:42:22:8A:38:10:C8:00:5B:11:43:F4 (ssh-dss), 43:3E:0A:E3:17:26:89:8B:6E:D3:66:FA:67:6D:CA:76 (ssh- rsa) [root at freeipa ~]# ipa host-show Host name: node001.swim1.test.nsslabs.com Host name: node001.swim1.test.nsslabs.com Certificate: MIIDtTCCAp2gAwIBAgIBEDANBgkqhkiG9w0BAQsFADA7MRkwFwYDVQQKExBURVNULk5TU0xBQlMuQ09NMR4wHAYDVQQDExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMTMxMDI4MDg1MjM0WhcNMTUxMDI5MDg1MjM0WjBEMRkwFwYDVQQKExBURVNULk5TU0xBQlMuQ09NMScwJQYDVQQDEx5ub2RlMDAxLnN3aW0xLnRlc3QubnNzbGFicy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCyLPK9JKLZLuDoecKehT9MZnBeaJqHzF6nC+JhXd6wf5Kcy7WyVCVgWxchnvMo0x0CPN5mRDfHUpsT3MRILmRl/0OGgPft4Tl5X27kwfORT3/YPQVohclR2xS3RRZUTsuPlY6L2If02DL6wauWKzfVxASHB43JKLoTOA5GnM9CBGirs6R3yiNW0ow41kKslM6mwAXCwh7bSMRmBd43T3bvtFGLAMqKzn4t+v0ezaFSRvXeVPUeK4Mt8ZhzQ/FwMVW2HT3og2TBgIbCnk/U6R1Syyic7OvNWiODXHoepcQgYXv/G3kt2bqqyO7JJZkznGskF8TRQga1rnpHs1bYkGEFAgMBAAGjgbowgbcwHwYDVR0jBBgwFoAUxjS+P9INb5f52vII8K8H9v8NqaUwRgYIKwYBBQUHAQEEOjA4MDYGCCsGAQUFBzABhipodHRwOi8vZnJlZWlwYS50ZXN0Lm5zc2xhYnMuY29tOjgwL2NhL29jc3AwDgYDVR0PAQH/BAQDAgTwMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAdBgNVHQ4EFgQUAKXs8vW7guBvh0XhWUXS26j2zJswDQYJKoZIhvcNAQELBQADggEBAJWW5ZFYGEtGLxhBeutryfMpU/R83/zxpgG6TpvJS/v4ODANLLz+cqN8J9Ogna/wnprrYleUuhxgAvYVIyYInpt+N765g2fKMDlS1CCrfxt4F8wgG7WpN4ZzcE7roa5pYa7CP9DRupXyZfUjbFxCbYixS3zV/CU9lddlt9OJWRnPksbr6jKVAfStWnL9e5DVbOeXSuQwIbDScRLkVL7Po/z1eZATZsAMtdOLhciTId157k9hxOPn1DCyh31Z70JiXFiVL+FazljxzMMyfPCdsvKKHhjTednMBgfwRqtBtA/Hf7LjjWqiaR12y0qOQyNmZ8ylu+1sxRqUv78t6ljVRvc= Principal name: host/node001.swim1.test.nsslabs.com at TEST.NSSLABS.COM Password: False Keytab: True Managed by: node001.swim1.test.nsslabs.com Subject: CN=node001.swim1.test.nsslabs.com,O=TEST.NSSLABS.COM Serial Number: 16 Serial Number (hex): 0x10 Issuer: CN=Certificate Authority,O=TEST.NSSLABS.COM Not Before: Mon Oct 28 08:52:34 2013 UTC Not After: Thu Oct 29 08:52:34 2015 UTC Fingerprint (MD5): ef:7f:11:54:a4:99:3c:58:f9:c8:5f:1c:2f:8e:a0:a3 Fingerprint (SHA1): 87:2b:37:e0:c8:7b:54:62:a1:6f:ae:fa:7b:2a:f6:a4:3a:c6:5c:c4 SSH public key fingerprint: B8:44:2F:2E:DC:4E:BF:BE:15:00:25:80:3B:A9:1D:5E (ssh-dss), 05:11:9B:EE:D0:7A:BA:9D:BA:48:18:82:84:8F:25:82 (ssh-rsa) On 28 October 2013 15:20, Rob Crittenden wrote: > Andrew Holway wrote: >> >> Hello, >> >> I have created two DNS resource records. 51.10.in-addr.arpa. and >> test.domain.com. It seems that it does not like to use the >> 51.10.in-addr.arpa. for addresses. Must I specify each /24? In >> addition, if I am adding a host node.subdomain.test.nsslabs.com. It >> does not like this either. Must I specify a record for each subdomain? >> Am I missing a * somewhere? > > > Can you be more specific about what you're seeing? > > rob > From andrew.holway at gmail.com Mon Oct 28 15:34:33 2013 From: andrew.holway at gmail.com (Andrew Holway) Date: Mon, 28 Oct 2013 15:34:33 +0000 Subject: [Freeipa-users] DNS resource records problem. subdomains and /16's. In-Reply-To: References: <526E80CD.4010403@redhat.com> Message-ID: Forward DNS for this host is working but reverse DNS is not: [root at freeipa ~]# dig node002.test.nsslabs.com @localhost ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.6 <<>> node002.test.nsslabs.com @localhost ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9260 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION: ;node002.test.nsslabs.com. IN A ;; ANSWER SECTION: node002.test.nsslabs.com. 1200 IN A 10.51.102.2 ;; AUTHORITY SECTION: test.nsslabs.com. 86400 IN NS freeipa.test.nsslabs.com. ;; ADDITIONAL SECTION: freeipa.test.nsslabs.com. 1200 IN A 10.51.101.23 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Mon Oct 28 04:30:28 2013 ;; MSG SIZE rcvd: 96 [root at freeipa ~]# dig 10.51.102.2 @localhost ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.6 <<>> 10.51.102.2 @localhost ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 57193 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;10.51.102.2. IN A ;; AUTHORITY SECTION: . 10800 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2013102800 1800 900 604800 86400 ;; Query time: 153 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Mon Oct 28 04:30:39 2013 ;; MSG SIZE rcvd: 104 On 28 October 2013 15:33, Andrew Holway wrote: > Here is some info from FreeIPA . . . > > [root at freeipa ~]# ipa host-show > > Host name: node002.test.nsslabs.com > > Host name: node002.test.nsslabs.com > > Certificate: MIIDrzCCApegAwIBAgIBETANBgkqhkiG9w0BAQsFADA7MRkwFwYDVQQKExBURVNULk5TU0xBQlMuQ09NMR4wHAYDVQQDExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMTMxMDI4MDkwMDAxWhcNMTUxMDI5MDkwMDAxWjA+MRkwFwYDVQQKExBURVNULk5TU0xBQlMuQ09NMSEwHwYDVQQDExhub2RlMDAyLnRlc3QubnNzbGFicy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBNjwG219iSyJ7f8TVjoIUN8Wtk3WfaCTEW43d534UDCsC4e5pd/dsOqsCk+NqVf6u6SA80ZFnZp/z7ULoY9rm/+IRBY2M/ofu8PHVZ2wu33/4RhW9FXORh51rSaklefs3ZAgo+Ra2aiEdsm4vSk4+0f3dUnbtoqg6bkK0NHjUEkof/7EyM+WLhXUIfXnyFFu3gnHzqntX/SbybgtG8AuDSkm07LLnbY354u28OPE+DLaGgYPqZmuvdHVAEWu8i2uCywOyf3yHuFA59UjZclb7IQZ0qvm8GUUJjidFOfmgBSueyTUs+JvojYu2Z+roqwJpFY60oiSwMQw3fuHh/UqFAgMBAAGjgbowgbcwHwYDVR0jBBgwFoAUxjS+P9INb5f52vII8K8H9v8NqaUwRgYIKwYBBQUHAQEEOjA4MDYGCCsGAQUFBzABhipodHRwOi8vZnJlZWlwYS50ZXN0Lm5zc2xhYnMuY29tOjgwL2NhL29jc3AwDgYDVR0PAQH/BAQDAgTwMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAdBgNVHQ4EFgQUt6Eh8e4si95/Q/CbzbbAB5cESVUwDQYJKoZIhvcNAQELBQADggEBAK5OQe2jPdzTJZTizgLE8AMSlw9NWVCY0bLh4HbbIhazFo++FOlArRf8AfwukmFdv97JEy3wDWDccxQXBC+8/tmIP3TeILcLAwEmdmSynKXOvhQ97+EGNmQRO9uXLo1C5ognxUiDbjmXYWkMRjJFLzBvqbA4veRekgvS27faZa0lTTxygk2hrbcMyVN6MHGLdX07EMgSa6IkIUZ+TdLZwMep9IK6CtoJelTjDP0JIy3n5DBVzJ+C0GZ0XUyUE6vXFcpuvyGY4ckQHf1sEbWFcRmJsxsweAgGwol2GJAWa7vZJlTVJZOMgV8fO0aK0Y8kl/KHN+ycxWFQyxZ3njDPn6g= > > Principal name: host/node002.test.nsslabs.com at TEST.NSSLABS.COM > > Password: False > > Keytab: True > > Managed by: node002.test.nsslabs.com > > Subject: CN=node002.test.nsslabs.com,O=TEST.NSSLABS.COM > > Serial Number: 17 > > Serial Number (hex): 0x11 > > Issuer: CN=Certificate Authority,O=TEST.NSSLABS.COM > > Not Before: Mon Oct 28 09:00:01 2013 UTC > > Not After: Thu Oct 29 09:00:01 2015 UTC > > Fingerprint (MD5): d4:d7:fa:14:31:0a:71:70:c9:62:43:65:ab:c5:09:93 > > Fingerprint (SHA1): > d2:72:8d:20:4b:c7:e5:a8:2d:bc:f9:e7:ca:c0:9b:f5:d9:53:c6:74 > > SSH public key fingerprint: > 28:24:23:6C:6D:42:22:8A:38:10:C8:00:5B:11:43:F4 (ssh-dss), > 43:3E:0A:E3:17:26:89:8B:6E:D3:66:FA:67:6D:CA:76 (ssh- > > rsa) > > [root at freeipa ~]# ipa host-show > > Host name: node001.swim1.test.nsslabs.com > > Host name: node001.swim1.test.nsslabs.com > > Certificate: MIIDtTCCAp2gAwIBAgIBEDANBgkqhkiG9w0BAQsFADA7MRkwFwYDVQQKExBURVNULk5TU0xBQlMuQ09NMR4wHAYDVQQDExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMTMxMDI4MDg1MjM0WhcNMTUxMDI5MDg1MjM0WjBEMRkwFwYDVQQKExBURVNULk5TU0xBQlMuQ09NMScwJQYDVQQDEx5ub2RlMDAxLnN3aW0xLnRlc3QubnNzbGFicy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCyLPK9JKLZLuDoecKehT9MZnBeaJqHzF6nC+JhXd6wf5Kcy7WyVCVgWxchnvMo0x0CPN5mRDfHUpsT3MRILmRl/0OGgPft4Tl5X27kwfORT3/YPQVohclR2xS3RRZUTsuPlY6L2If02DL6wauWKzfVxASHB43JKLoTOA5GnM9CBGirs6R3yiNW0ow41kKslM6mwAXCwh7bSMRmBd43T3bvtFGLAMqKzn4t+v0ezaFSRvXeVPUeK4Mt8ZhzQ/FwMVW2HT3og2TBgIbCnk/U6R1Syyic7OvNWiODXHoepcQgYXv/G3kt2bqqyO7JJZkznGskF8TRQga1rnpHs1bYkGEFAgMBAAGjgbowgbcwHwYDVR0jBBgwFoAUxjS+P9INb5f52vII8K8H9v8NqaUwRgYIKwYBBQUHAQEEOjA4MDYGCCsGAQUFBzABhipodHRwOi8vZnJlZWlwYS50ZXN0Lm5zc2xhYnMuY29tOjgwL2NhL29jc3AwDgYDVR0PAQH/BAQDAgTwMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAdBgNVHQ4EFgQUAKXs8vW7guBvh0XhWUXS26j2zJswDQYJKoZIhvcNAQELBQADggEBAJWW5ZFYGEtGLxhBeutryfMpU/R83/zxpgG6TpvJS/v4ODANLLz+cqN8J9Ogna/wnprrYleUuhxgAvYVIyYInpt+N765g2fKMDlS1CCrfxt4F8wgG7WpN4ZzcE7roa5pYa7CP9DRupXyZfUjbFxCbYixS3zV/CU9lddlt9OJWRnPksbr6jKVAfStWnL9e5DVbOeXSuQwIbDScRLkVL7Po/z1eZATZsAMtdOLhciTId157k9hxOPn1DCyh31Z70JiXFiVL+FazljxzMMyfPCdsvKKHhjTednMBgfwRqtBtA/Hf7LjjWqiaR12y0qOQyNmZ8ylu+1sxRqUv78t6ljVRvc= > > Principal name: host/node001.swim1.test.nsslabs.com at TEST.NSSLABS.COM > > Password: False > > Keytab: True > > Managed by: node001.swim1.test.nsslabs.com > > Subject: CN=node001.swim1.test.nsslabs.com,O=TEST.NSSLABS.COM > > Serial Number: 16 > > Serial Number (hex): 0x10 > > Issuer: CN=Certificate Authority,O=TEST.NSSLABS.COM > > Not Before: Mon Oct 28 08:52:34 2013 UTC > > Not After: Thu Oct 29 08:52:34 2015 UTC > > Fingerprint (MD5): ef:7f:11:54:a4:99:3c:58:f9:c8:5f:1c:2f:8e:a0:a3 > > Fingerprint (SHA1): > 87:2b:37:e0:c8:7b:54:62:a1:6f:ae:fa:7b:2a:f6:a4:3a:c6:5c:c4 > > SSH public key fingerprint: > B8:44:2F:2E:DC:4E:BF:BE:15:00:25:80:3B:A9:1D:5E (ssh-dss), > 05:11:9B:EE:D0:7A:BA:9D:BA:48:18:82:84:8F:25:82 (ssh-rsa) > > On 28 October 2013 15:20, Rob Crittenden wrote: >> Andrew Holway wrote: >>> >>> Hello, >>> >>> I have created two DNS resource records. 51.10.in-addr.arpa. and >>> test.domain.com. It seems that it does not like to use the >>> 51.10.in-addr.arpa. for addresses. Must I specify each /24? In >>> addition, if I am adding a host node.subdomain.test.nsslabs.com. It >>> does not like this either. Must I specify a record for each subdomain? >>> Am I missing a * somewhere? >> >> >> Can you be more specific about what you're seeing? >> >> rob >> From andrew.holway at gmail.com Mon Oct 28 15:43:09 2013 From: andrew.holway at gmail.com (Andrew Holway) Date: Mon, 28 Oct 2013 15:43:09 +0000 Subject: [Freeipa-users] DNS resource records problem. subdomains and /16's. In-Reply-To: References: <526E80CD.4010403@redhat.com> Message-ID: Sorry, I didn't mean to sent the last mail. However the FreeIPA has correctly set reverse and forward DNS. I have trimmed it up a bit for clarity. Forward DNS for this host is working but reverse DNS is not: [root at freeipa ~]# dig node002.test.nsslabs.com @localhost ;; QUESTION SECTION: ;node002.test.nsslabs.com. IN A ;; ANSWER SECTION: node002.test.nsslabs.com. 1200 IN A 10.51.102.2 ;; AUTHORITY SECTION: test.nsslabs.com. 86400 IN NS freeipa.test.nsslabs.com. ;; ADDITIONAL SECTION: freeipa.test.nsslabs.com. 1200 IN A 10.51.101.23 [root at freeipa ~]# dig 10.51.102.2 @localhost ;; QUESTION SECTION: ;10.51.102.2. IN A ;; AUTHORITY SECTION: . 10800 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2013102800 1800 900 604800 86400 The FreeIPA server has correctly set reverse and forward DNS. [root at freeipa ~]# dig freeipa.test.nsslabs.com @localhost ;; QUESTION SECTION: ;freeipa.test.nsslabs.com. IN A ;; ANSWER SECTION: freeipa.test.nsslabs.com. 1200 IN A 10.51.101.23 ;; AUTHORITY SECTION: test.nsslabs.com. 86400 IN NS freeipa.test.nsslabs.com. [root at freeipa ~]# dig -x 10.51.101.23 @localhost ;; QUESTION SECTION: ;23.101.51.10.in-addr.arpa. IN PTR ;; ANSWER SECTION: 23.101.51.10.in-addr.arpa. 86400 IN PTR freeipa.test.nsslabs.com. ;; AUTHORITY SECTION: 51.10.in-addr.arpa. 86400 IN NS freeipa.test.nsslabs.com. ;; ADDITIONAL SECTION: freeipa.test.nsslabs.com. 1200 IN A 10.51.101.23 This host has no reverse or forward DNS set up. But it IS enrolled in freeIPA. [root at freeipa ~]# dig node001.swim1.test.nsslabs.com @localhost ;; QUESTION SECTION: ;node001.swim1.test.nsslabs.com. IN A ;; AUTHORITY SECTION: test.nsslabs.com. 3600 IN SOA freeipa.test.nsslabs.com. hostmaster.test.nsslabs.com. 1382950803 3600 900 1209600 3600 [root at freeipa ~]# dig -x 10.51.102.2 @localhost ;; QUESTION SECTION: ;2.102.51.10.in-addr.arpa. IN PTR ;; AUTHORITY SECTION: 51.10.in-addr.arpa. 3600 IN SOA freeipa.test.nsslabs.com. hostmaster.test.nsslabs.com. 1382863622 3600 900 1209600 3600 From andrew.holway at gmail.com Mon Oct 28 15:53:26 2013 From: andrew.holway at gmail.com (Andrew Holway) Date: Mon, 28 Oct 2013 15:53:26 +0000 Subject: [Freeipa-users] DNS resource records problem. subdomains and /16's. In-Reply-To: References: <526E80CD.4010403@redhat.com> Message-ID: [root at freeipa ~]# ipa dnszone-find Zone name: 51.10.in-addr.arpa. Authoritative nameserver: freeipa.test.nsslabs.com. Administrator e-mail address: hostmaster.test.nsslabs.com. SOA serial: 1382863622 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3600 Active zone: TRUE Allow query: any; Allow transfer: none; Zone name: test.nsslabs.com Authoritative nameserver: freeipa.test.nsslabs.com. Administrator e-mail address: hostmaster.test.nsslabs.com. SOA serial: 1382950803 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3600 Active zone: TRUE Allow query: any; Allow transfer: none; ---------------------------- Number of entries returned 2 ---------------------------- On 28 October 2013 15:43, Andrew Holway wrote: > Sorry, I didn't mean to sent the last mail. However the FreeIPA has > correctly set reverse and forward DNS. I have trimmed it up a bit for > clarity. > > Forward DNS for this host is working but reverse DNS is not: > > [root at freeipa ~]# dig node002.test.nsslabs.com @localhost > > ;; QUESTION SECTION: > ;node002.test.nsslabs.com. IN A > ;; ANSWER SECTION: > node002.test.nsslabs.com. 1200 IN A 10.51.102.2 > ;; AUTHORITY SECTION: > test.nsslabs.com. 86400 IN NS freeipa.test.nsslabs.com. > ;; ADDITIONAL SECTION: > freeipa.test.nsslabs.com. 1200 IN A 10.51.101.23 > > [root at freeipa ~]# dig 10.51.102.2 @localhost > > ;; QUESTION SECTION: > ;10.51.102.2. IN A > ;; AUTHORITY SECTION: > . 10800 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2013102800 > 1800 900 604800 86400 > > The FreeIPA server has correctly set reverse and forward DNS. > > [root at freeipa ~]# dig freeipa.test.nsslabs.com @localhost > ;; QUESTION SECTION: > ;freeipa.test.nsslabs.com. IN A > ;; ANSWER SECTION: > freeipa.test.nsslabs.com. 1200 IN A 10.51.101.23 > ;; AUTHORITY SECTION: > test.nsslabs.com. 86400 IN NS freeipa.test.nsslabs.com. > > [root at freeipa ~]# dig -x 10.51.101.23 @localhost > ;; QUESTION SECTION: > ;23.101.51.10.in-addr.arpa. IN PTR > ;; ANSWER SECTION: > 23.101.51.10.in-addr.arpa. 86400 IN PTR freeipa.test.nsslabs.com. > ;; AUTHORITY SECTION: > 51.10.in-addr.arpa. 86400 IN NS freeipa.test.nsslabs.com. > ;; ADDITIONAL SECTION: > freeipa.test.nsslabs.com. 1200 IN A 10.51.101.23 > > > This host has no reverse or forward DNS set up. But it IS enrolled in freeIPA. > > [root at freeipa ~]# dig node001.swim1.test.nsslabs.com @localhost > > ;; QUESTION SECTION: > ;node001.swim1.test.nsslabs.com. IN A > ;; AUTHORITY SECTION: > test.nsslabs.com. 3600 IN SOA freeipa.test.nsslabs.com. > hostmaster.test.nsslabs.com. 1382950803 3600 900 1209600 3600 > > > [root at freeipa ~]# dig -x 10.51.102.2 @localhost > > ;; QUESTION SECTION: > ;2.102.51.10.in-addr.arpa. IN PTR > ;; AUTHORITY SECTION: > 51.10.in-addr.arpa. 3600 IN SOA freeipa.test.nsslabs.com. > hostmaster.test.nsslabs.com. 1382863622 3600 900 1209600 3600 From cbulist at gmail.com Mon Oct 28 16:23:05 2013 From: cbulist at gmail.com (cbulist at gmail.com) Date: Mon, 28 Oct 2013 11:23:05 -0500 Subject: [Freeipa-users] Using local sudoers file Message-ID: <526E8F69.4000808@gmail.com> I would like to continue using sudoers file for a while before to migrate it to freeipa. I changed nsswitch.conf to use sudo just from file but when I try some command that needs sudo privileges I get the error: sudo: pam_ldap: ldap_search_s No such object I followed the recommendations from: www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf but when I add sudo in services at sssd.conf and restart sssd service it fails for configuration error. -ipa-server 3.0.0-26 (Red Hat 6.4) -ipa-client 2.1.3-7 (Red Hat 5.8) Any recommendation about this problem? Thanks! From jhrozek at redhat.com Tue Oct 29 09:02:56 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 29 Oct 2013 10:02:56 +0100 Subject: [Freeipa-users] Using local sudoers file In-Reply-To: <526E8F69.4000808@gmail.com> References: <526E8F69.4000808@gmail.com> Message-ID: <20131029090256.GE3804@hendrix.brq.redhat.com> On Mon, Oct 28, 2013 at 11:23:05AM -0500, cbulist at gmail.com wrote: > I would like to continue using sudoers file for a while before to migrate it to freeipa. > I changed nsswitch.conf to use sudo just from file but when I try some command that needs sudo privileges I get the error: > > sudo: pam_ldap: ldap_search_s No such object Can you paste the full nsswitch.conf? > > I followed the recommendations from: > > www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf > > but when I add sudo in services at sssd.conf and restart sssd service it fails for configuration error. So why do you add sudo to sssd.conf if the plan is to use local sudoers? Sudo integration was only introduced recently, it's not present on RHEL5. > > -ipa-server 3.0.0-26 (Red Hat 6.4) > -ipa-client 2.1.3-7 (Red Hat 5.8) > > Any recommendation about this problem? From bret.wortman at damascusgrp.com Tue Oct 29 13:59:33 2013 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Tue, 29 Oct 2013 09:59:33 -0400 Subject: [Freeipa-users] sudo client on CentOS 6.4? Message-ID: <526FBF45.9080307@damascusgrp.com> I'm trying to bring some CentOS 6.4 systems into our IPA network, and everything seems to be working find except sudo (which works against all our Fedora-based systems). I've set it up as documented on freeipa.org, and that same config as I said works for Fedora (I have adjusted to use /etc/nslcd.conf on CentOS instead of /etc/ldap.conf). If I remove "files" from /etc/nsswitch.conf, I get the following: $ sudo -iu root sudo: no valid sudoers sources found, quitting sudo: unable to initialize policy plugin I have sudoers_debug set to "1", but this is producing no output that I've been able to find. Not surprising, since it looks like the sudo command itself isn't ever querying ldap at all.... What should I try next? -- *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 51f7de33e4b08d2bdb8b4860 Type: image/png Size: 28526 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3766 bytes Desc: S/MIME Cryptographic Signature URL: From jhrozek at redhat.com Tue Oct 29 14:07:22 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 29 Oct 2013 15:07:22 +0100 Subject: [Freeipa-users] sudo client on CentOS 6.4? In-Reply-To: <526FBF45.9080307@damascusgrp.com> References: <526FBF45.9080307@damascusgrp.com> Message-ID: <20131029140722.GT3804@hendrix.brq.redhat.com> On Tue, Oct 29, 2013 at 09:59:33AM -0400, Bret Wortman wrote: > I'm trying to bring some CentOS 6.4 systems into our IPA network, > and everything seems to be working find except sudo (which works > against all our Fedora-based systems). > > I've set it up as documented on freeipa.org, and that same config as > I said works for Fedora (I have adjusted to use /etc/nslcd.conf on > CentOS instead of /etc/ldap.conf). If I remove "files" from > /etc/nsswitch.conf, I get the following: > > $ sudo -iu root > sudo: no valid sudoers sources found, quitting > sudo: unable to initialize policy plugin > > I have sudoers_debug set to "1", but this is producing no output > that I've been able to find. Not surprising, since it looks like the > sudo command itself isn't ever querying ldap at all.... > > What should I try next? Do you have libsss_sudo installed? From rcritten at redhat.com Tue Oct 29 14:09:17 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 29 Oct 2013 10:09:17 -0400 Subject: [Freeipa-users] sudo client on CentOS 6.4? In-Reply-To: <526FBF45.9080307@damascusgrp.com> References: <526FBF45.9080307@damascusgrp.com> Message-ID: <526FC18D.6040101@redhat.com> Bret Wortman wrote: > I'm trying to bring some CentOS 6.4 systems into our IPA network, and > everything seems to be working find except sudo (which works against all > our Fedora-based systems). > > I've set it up as documented on freeipa.org, and that same config as I > said works for Fedora (I have adjusted to use /etc/nslcd.conf on CentOS > instead of /etc/ldap.conf). If I remove "files" from /etc/nsswitch.conf, > I get the following: > > $ sudo -iu root > sudo: no valid sudoers sources found, quitting > sudo: unable to initialize policy plugin > > I have sudoers_debug set to "1", but this is producing no output that > I've been able to find. Not surprising, since it looks like the sudo > command itself isn't ever querying ldap at all.... > > What should I try next? > The configuration file you want is /etc/sudo-ldap.conf. See sudoers.ldap(5). Not sure how great an example this is, but this is the one on my 6.4 dev box: binddn uid=sudo,cn=sysaccounts,cn=etc,dc=example,dc=com bindpw SecretPassword ssl start_tls tls_cacertfile /etc/ipa/ca.crt tls_checkpeer yes bind_timelimit 5 timelimit 15 uri ldap://ipa.example.com sudoers_base ou=SUDOers,dc=example,dc=com sudoers_debug 2 rob From andrew.holway at gmail.com Tue Oct 29 14:33:18 2013 From: andrew.holway at gmail.com (Andrew Holway) Date: Tue, 29 Oct 2013 14:33:18 +0000 Subject: [Freeipa-users] sudo client on CentOS 6.4? In-Reply-To: <526FBF45.9080307@damascusgrp.com> References: <526FBF45.9080307@damascusgrp.com> Message-ID: For 6.4 use these instructions. https://www.redhat.com/archives/freeipa-users/2013-June/msg00064.html Thanks, Andrew On 29 October 2013 13:59, Bret Wortman wrote: > I'm trying to bring some CentOS 6.4 systems into our IPA network, and > everything seems to be working find except sudo (which works against all > our Fedora-based systems). > > I've set it up as documented on freeipa.org, and that same config as I > said works for Fedora (I have adjusted to use /etc/nslcd.conf on CentOS > instead of /etc/ldap.conf). If I remove "files" from /etc/nsswitch.conf, I > get the following: > > $ sudo -iu root > sudo: no valid sudoers sources found, quitting > sudo: unable to initialize policy plugin > > I have sudoers_debug set to "1", but this is producing no output that I've > been able to find. Not surprising, since it looks like the sudo command > itself isn't ever querying ldap at all.... > > What should I try next? > > > -- > *Bret Wortman* > > http://damascusgrp.com/ > http://about.me/wortmanbret > > > _______________________________________________ > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: 51f7de33e4b08d2bdb8b4860 Type: image/png Size: 28526 bytes Desc: not available URL: From bret.wortman at damascusgrp.com Tue Oct 29 14:46:25 2013 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Tue, 29 Oct 2013 10:46:25 -0400 Subject: [Freeipa-users] sudo client on CentOS 6.4? In-Reply-To: <526FC18D.6040101@redhat.com> References: <526FBF45.9080307@damascusgrp.com> <526FC18D.6040101@redhat.com> Message-ID: <526FCA41.6000509@damascusgrp.com> That did the trick. I'll update Puppet accordingly. Thanks, Rob. Bret On 10/29/2013 10:09 AM, Rob Crittenden wrote: > Bret Wortman wrote: >> I'm trying to bring some CentOS 6.4 systems into our IPA network, and >> everything seems to be working find except sudo (which works against all >> our Fedora-based systems). >> >> I've set it up as documented on freeipa.org, and that same config as I >> said works for Fedora (I have adjusted to use /etc/nslcd.conf on CentOS >> instead of /etc/ldap.conf). If I remove "files" from /etc/nsswitch.conf, >> I get the following: >> >> $ sudo -iu root >> sudo: no valid sudoers sources found, quitting >> sudo: unable to initialize policy plugin >> >> I have sudoers_debug set to "1", but this is producing no output that >> I've been able to find. Not surprising, since it looks like the sudo >> command itself isn't ever querying ldap at all.... >> >> What should I try next? >> > > The configuration file you want is /etc/sudo-ldap.conf. See > sudoers.ldap(5). > > Not sure how great an example this is, but this is the one on my 6.4 > dev box: > > binddn uid=sudo,cn=sysaccounts,cn=etc,dc=example,dc=com > bindpw SecretPassword > > ssl start_tls > tls_cacertfile /etc/ipa/ca.crt > tls_checkpeer yes > > bind_timelimit 5 > timelimit 15 > > uri ldap://ipa.example.com > sudoers_base ou=SUDOers,dc=example,dc=com > > sudoers_debug 2 > > > rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3766 bytes Desc: S/MIME Cryptographic Signature URL: From ryan.thomson at ubc.ca Tue Oct 29 21:54:54 2013 From: ryan.thomson at ubc.ca (Thomson, Ryan) Date: Tue, 29 Oct 2013 21:54:54 +0000 Subject: [Freeipa-users] Failure decoding Certificate Signing Request In-Reply-To: <4236DE1EFED4374EA69B197EB5AC27573514E563@S-ITSV-MBX02P.ead.ubc.ca> References: <3fc2cb83-f64c-450b-a9d9-d4612966bbc1@S-ITSV-HUB01P.ead.ubc.ca> <52666FE7.4060406@redhat.com> <4236DE1EFED4374EA69B197EB5AC275735147A7B@S-ITSV-MBX02P.ead.ubc.ca> <5266B9C7.5090507@redhat.com> <4236DE1EFED4374EA69B197EB5AC275735148D59@S-ITSV-MBX02P.ead.ubc.ca> <526730C8.7030105@redhat.com> <4236DE1EFED4374EA69B197EB5AC27573514A59D@S-ITSV-MBX02P.ead.ubc.ca> <52687EB5.9030000@redhat.com> <4236DE1EFED4374EA69B197EB5AC27573514BC5F@S-ITSV-MBX02P.ead.ubc.ca> <526969C1.8010802@redhat.com> <4236DE1EFED4374EA69B197EB5AC27573514DF76@S-ITSV-MBX02P.ead.ubc.ca> <526AB024.5060001@redhat.com> <4236DE1EFED4374EA69B197EB5AC27573514E563@S-ITSV-MBX02P.ead.ubc.ca> Message-ID: <5e3dd211-cb42-4e4e-b4d4-480d9516c72c@S-ITSV-HUB03P.ead.ubc.ca> > -----Original Message----- > From: freeipa-users-bounces at redhat.com [mailto:freeipa-users- > bounces at redhat.com] On Behalf Of Thomson, Ryan > Sent: Friday, October 25, 2013 11:17 AM > To: Rob Crittenden; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Failure decoding Certificate Signing Request [snip] > > > I'm not sure what to make of this. > > > > This is just more confirmation that the IPA framework is trying to > > initialize NSS for some reason. It should never do this which is why > > it is failing so spectacularly. > > > > Can you provide nss.conf and ipa.conf from /etc/httpd/conf.d? > > > > Who owns and what are the permissions of /etc/httpd/alias/*.db? > > > > thanks > > > > rob [snip] After further troubleshooting and trying too many crazy things, I was finally able to "hack" FreeIPA into renewing the certificates. Behold the terrible hack, it is quite awful and certainly not an actual fix. During my troubleshooting, I kept coming back to the getpass EOFError: [Sat Sep 28 03:48:17 2013] [error] /usr/lib64/python2.6/getpass.py:83: GetPassWarning: Can not control echo on the terminal. [Sat Sep 28 03:48:17 2013] [error] passwd = fallback_getpass(prompt, stream) [Sat Sep 28 03:48:17 2013] [error] Warning: Password input may be echoed. [Sat Sep 28 03:48:17 2013] [error] Enter password for internal: [Sat Sep 28 03:48:17 2013] [error] exception in PK11 password callback [Sat Sep 28 03:48:17 2013] [error] Traceback (most recent call last): [Sat Sep 28 03:48:18 2013] [error] File "/usr/lib/python2.6/site-packages/ipapython/nsslib.py", line 230, in password_callback [Sat Sep 28 03:48:18 2013] [error] return getpass.getpass("Enter password for %s: " % slot.token_name); [Sat Sep 28 03:48:18 2013] [error] File "/usr/lib64/python2.6/getpass.py", line 83, in unix_getpass [Sat Sep 28 03:48:18 2013] [error] passwd = fallback_getpass(prompt, stream) [Sat Sep 28 03:48:18 2013] [error] File "/usr/lib64/python2.6/getpass.py", line 118, in fallback_getpass [Sat Sep 28 03:48:18 2013] [error] return _raw_input(prompt, stream) [Sat Sep 28 03:48:18 2013] [error] File "/usr/lib64/python2.6/getpass.py", line 135, in _raw_input [Sat Sep 28 03:48:18 2013] [error] raise EOFError [Sat Sep 28 03:48:18 2013] [error] EOFError So eventually I found my way into /usr/lib/python2.6/site-packages/ipapython/nsslib.py and the getpass password_callback function. Instead of allowing the password_callback() to return "getpass.getpass("Enter password for %s: " % slot.token_name);", which was rasing the EOFError exception, I simply returned the text string from /etc/httpd/alias/password.conf! >From what little I know about python and coding in general, it seems that getpass was trying to read the NSS DB password from somewhere but was reading nothing instead and thus raising EOFError. I'm not sure what to do about a permanent fix as maintaining the NSS DB password in a source file does seems rather insecure. Given the above, what does a permanent fix actually look like? Is the getpass callback function broken or is my environment broken? --Ryan From rcritten at redhat.com Wed Oct 30 18:26:50 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 30 Oct 2013 14:26:50 -0400 Subject: [Freeipa-users] Failure decoding Certificate Signing Request In-Reply-To: <5e3dd211-cb42-4e4e-b4d4-480d9516c72c@S-ITSV-HUB03P.ead.ubc.ca> References: <3fc2cb83-f64c-450b-a9d9-d4612966bbc1@S-ITSV-HUB01P.ead.ubc.ca> <52666FE7.4060406@redhat.com> <4236DE1EFED4374EA69B197EB5AC275735147A7B@S-ITSV-MBX02P.ead.ubc.ca> <5266B9C7.5090507@redhat.com> <4236DE1EFED4374EA69B197EB5AC275735148D59@S-ITSV-MBX02P.ead.ubc.ca> <526730C8.7030105@redhat.com> <4236DE1EFED4374EA69B197EB5AC27573514A59D@S-ITSV-MBX02P.ead.ubc.ca> <52687EB5.9030000@redhat.com> <4236DE1EFED4374EA69B197EB5AC27573514BC5F@S-ITSV-MBX02P.ead.ubc.ca> <526969C1.8010802@redhat.com> <4236DE1EFED4374EA69B197EB5AC27573514DF76@S-ITSV-MBX02P.ead.ubc.ca> <526AB024.5060001@redhat.com> <4236DE1EFED4374EA69B197EB5AC27573514E563@S-ITSV-MBX02P.ead.ubc.ca> <5e3dd211-cb42-4e4e-b4d4-480d9516c72c@S-ITSV-HUB03P.ead.ubc.ca> Message-ID: <52714F6A.5000601@redhat.com> Thomson, Ryan wrote: >> -----Original Message----- >> From: freeipa-users-bounces at redhat.com [mailto:freeipa-users- >> bounces at redhat.com] On Behalf Of Thomson, Ryan >> Sent: Friday, October 25, 2013 11:17 AM >> To: Rob Crittenden; freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] Failure decoding Certificate Signing Request > > [snip] > >>>> I'm not sure what to make of this. >>> >>> This is just more confirmation that the IPA framework is trying to >>> initialize NSS for some reason. It should never do this which is why >>> it is failing so spectacularly. >>> >>> Can you provide nss.conf and ipa.conf from /etc/httpd/conf.d? >>> >>> Who owns and what are the permissions of /etc/httpd/alias/*.db? >>> >>> thanks >>> >>> rob > > [snip] > > After further troubleshooting and trying too many crazy things, I was finally able to "hack" FreeIPA into renewing the certificates. Behold the terrible hack, it is quite awful and certainly not an actual fix. > > During my troubleshooting, I kept coming back to the getpass EOFError: > > [Sat Sep 28 03:48:17 2013] [error] /usr/lib64/python2.6/getpass.py:83: GetPassWarning: Can not control echo on the terminal. > [Sat Sep 28 03:48:17 2013] [error] passwd = fallback_getpass(prompt, stream) > [Sat Sep 28 03:48:17 2013] [error] Warning: Password input may be echoed. > [Sat Sep 28 03:48:17 2013] [error] Enter password for internal: > [Sat Sep 28 03:48:17 2013] [error] exception in PK11 password callback > [Sat Sep 28 03:48:17 2013] [error] Traceback (most recent call last): > [Sat Sep 28 03:48:18 2013] [error] File "/usr/lib/python2.6/site-packages/ipapython/nsslib.py", line 230, in password_callback > [Sat Sep 28 03:48:18 2013] [error] return getpass.getpass("Enter password for %s: " % slot.token_name); > [Sat Sep 28 03:48:18 2013] [error] File "/usr/lib64/python2.6/getpass.py", line 83, in unix_getpass > [Sat Sep 28 03:48:18 2013] [error] passwd = fallback_getpass(prompt, stream) > [Sat Sep 28 03:48:18 2013] [error] File "/usr/lib64/python2.6/getpass.py", line 118, in fallback_getpass > [Sat Sep 28 03:48:18 2013] [error] return _raw_input(prompt, stream) > [Sat Sep 28 03:48:18 2013] [error] File "/usr/lib64/python2.6/getpass.py", line 135, in _raw_input > [Sat Sep 28 03:48:18 2013] [error] raise EOFError > [Sat Sep 28 03:48:18 2013] [error] EOFError > > So eventually I found my way into /usr/lib/python2.6/site-packages/ipapython/nsslib.py and the getpass password_callback function. Instead of allowing the password_callback() to return "getpass.getpass("Enter password for %s: " % slot.token_name);", which was rasing the EOFError exception, I simply returned the text string from /etc/httpd/alias/password.conf! > > From what little I know about python and coding in general, it seems that getpass was trying to read the NSS DB password from somewhere but was reading nothing instead and thus raising EOFError. > > I'm not sure what to do about a permanent fix as maintaining the NSS DB password in a source file does seems rather insecure. Given the above, what does a permanent fix actually look like? Is the getpass callback function broken or is my environment broken? Right, and removing it will cause other cert requests to fail in the same way. It will also get lost upon the next update of the ipa-python package. The root of the problem is that for some unknown reason the NSS database isn't already initialized. I've been unable to reproduce that here so don't really have any idea what the problem could be. A slightly more secure workaround might be to set an empty password on the NSS database in /etc/httpd/alias. SELinux and FS permissions will protect the key material but a password won't be required any more. This would mean some other configuration changes, and I don't know that we've tested this specifically, but it would probably work. Certainly the sort of thing where you back up a lot of things first. rob