From jhrozek at redhat.com Mon Feb 1 08:23:07 2016 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 1 Feb 2016 09:23:07 +0100 Subject: [Freeipa-users] [SSSD-users] Re: heads-up: new code to fetch sudo rules from an IPA server coming to Fedora and RHEL-6 In-Reply-To: <56AE7580.6060501@stroeder.com> References: <20160127152103.GD3448@hendrix.redhat.com> <56AE7580.6060501@stroeder.com> Message-ID: <20160201082307.GO27885@hendrix.redhat.com> On Sun, Jan 31, 2016 at 09:58:40PM +0100, Michael Str?der wrote: > Jakub Hrozek wrote: > > the sssd's code that fetches sudo rules from the IPA server got an > > overhaul recently. The search would no longer be performed against the > > compat tree, but against IPA's native LDAP tree. This would have the > > advantage that environments that don't use the slapi-nis' compat tree > > for another reason (like old or non-Linux clients) would no longer > > require slapi-nis to be running at all. > > Frankly I don't understand this text. Especially I don't know what the terms > "compat tree" and "IPA's native LDAP tree" really mean. I'm sorry, I will try to rephrase. If you add sudo rules to an IPA server using the "ipa sudorule" commands, the LDAP objects are added to cn=sudorules,cn=sudo,$DC tree in using a schema that is specific to IPA. The rule might look like this one on my test server: dn: ipaUniqueID=c4bba598-9f5b-11e5-8750-525400676811,cn=sudorules,cn=sudo,dc=ipa,dc=test cn: readfiles ipaenabledflag: TRUE externaluser: jsmith ipaUniqueID: c4bba598-9f5b-11e5-8750-525400676811 memberallowcmd: ipaUniqueID=cb15fdc6-9f5b-11e5-b9f5-525400676811,cn=sudocmds,cn=sudo,dc=ipa,dc=test objectClass: ipasudorule objectClass: ipaassociation However, the client side (both the LDAP connector that is built-in to sudo itself and the SSSD) only understood the schema as defined by http://linux.die.net/man/5/sudoers.ldap Therefore, there is a another subtree on the IPA server, rooted at ou=sudoers,$DC. This subtree is often called the 'compat' tree, because in was built with non-SSSD clients in mind. The objects are put into the compat tree by the slapi-nis Directory Server plugin. The rule above would be converted to: dn: cn=readfiles,ou=sudoers,dc=ipa,dc=test sudoUser: jsmith objectClass: sudoRole objectClass: top sudoCommand: /usr/bin/less cn: readfiles However, this auto-generation does not come for free and in some environments, the slapi-nis plugin was causing substantial load on the server side. So we added code to the sssd's ipa_provider to handle the objects stored at cn=sudorules,cn=sudo,$DC so that the slapi-nis plugin can be disabled. The functionality of the ipa's sudo_provider should stay the same, it's just that it's now able to process a different schema and this change allows the admin to disable the slapi-nis plugin (unless they need another piece of its functionality, which is translating the user and group objects into rfc2307 schema for legacy clients..) > > Does this only affect the IPA provider? Yes. From lslebodn at redhat.com Mon Feb 1 08:28:36 2016 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Mon, 1 Feb 2016 09:28:36 +0100 Subject: [Freeipa-users] SSSD Crash Causing Inaccessibility In-Reply-To: References: <20160128232255.GA18347@mail.corp.redhat.com> <20160129124915.GK24839@mail.corp.redhat.com> Message-ID: <20160201082835.GA25310@mail.corp.redhat.com> On (29/01/16 14:08), Jeff Hallyburton wrote: >Lukas, > >Installed versions of sssd: > ># rpm -qa | grep -i sssd > >sssd-common-1.13.0-40.el7_2.1.x86_64 > >sssd-ipa-1.13.0-40.el7_2.1.x86_64 > >sssd-1.13.0-40.el7_2.1.x86_64 > >sssd-krb5-common-1.13.0-40.el7_2.1.x86_64 > >sssd-ad-1.13.0-40.el7_2.1.x86_64 > >sssd-ldap-1.13.0-40.el7_2.1.x86_64 > >sssd-proxy-1.13.0-40.el7_2.1.x86_64 > >python-sssdconfig-1.13.0-40.el7_2.1.noarch > >sssd-client-1.13.0-40.el7_2.1.x86_64 > >sssd-common-pac-1.13.0-40.el7_2.1.x86_64 > >sssd-krb5-1.13.0-40.el7_2.1.x86_64 > >No core dumps unfortunately. > That's stable version. But on the other hand we do not test OOM. Is there something interesting in /varlog/sssd/sssd.log? LS From mkosek at redhat.com Mon Feb 1 11:41:02 2016 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 1 Feb 2016 12:41:02 +0100 Subject: [Freeipa-users] IPA Web Portal using outdated ciphers, breaking with some clients In-Reply-To: References: <56ABBF50.5050107@redhat.com> Message-ID: <56AF444E.6090101@redhat.com> On 01/29/2016 08:52 PM, Jeff Hallyburton wrote: > Rob, > > Chrome is flagging this, and given the error (I've attached a copy) its > probably due to the cipher suite (possibly specifically that it uses > SHA1). This article has more details and is consistent with what we're > seeing: > > http://security.stackexchange.com/questions/83831/google-chrome-your-connection-to-website-is-encrypted-with-obsolete-cryptograph > > We've also seen similar issues come up with other applications during > penetration scans (e.g., Qualys) which is why I've noted it here. Hello Jeff, This is not because of TLS 1.2 would have a problem, but rather because of the FreeIPA default selection of Apache ciphers. This is something being discussed and fixed in this thread: http://www.redhat.com/archives/freeipa-devel/2016-January/msg00369.html and this ticket: https://fedorahosted.org/freeipa/ticket/5589 After our initial tests (you can see results in the ticket), FreeIPA should no longer receive this warning and should score "A" in the SSLabs test. This change is expected to be released in 4.3.1 version, which is now in development. Martin From nix125432512689712 at gmail.com Mon Feb 1 19:04:02 2016 From: nix125432512689712 at gmail.com (sysadmin ofdoom) Date: Mon, 1 Feb 2016 12:04:02 -0700 Subject: [Freeipa-users] Sudo privilege inheritance in FreeIPA (3.0.x branch) In-Reply-To: References: Message-ID: Sorry for not defining the question. The question for this is: Are sudo rules supposed to be inherited in the same manner as HBAC rules? >From the case above, all my HBAC rules are working fine with indirect membership, but sudo only works with direct membership. I also saw the Tech preview SSSD packages for RHEL 6.8. I tried those too and verified that the issue is still present. On Wed, Jan 27, 2016 at 9:36 AM, sysadmin ofdoom < nix125432512689712 at gmail.com> wrote: > I am trying to implement FreeIPA in a larger environment. Due to the > complexity of the environment I've been constructing a user group structure > such that i have groups at the following levels: > > project --> project_at_site --> project_site_vendor > > HBAC rules are defined at the lowest level (vendor at site) and associated > with a host group at the same level. > > Each of the above user group levels will have a corresponding sudo group. > (Used to provide a vendor access to servers the vendor supports at a > specific site at a moments notice) > > HBAC rules are propagating up the chain correctly. > > When a user is added to a top level group (e.g. project or project-sudo) > the indirect membership shows up for both Sudo and HBAC rules. > > The problem is that I can't get the sudo privileges to work when the user > shows indirect membership for the sudo rule. If i make the user a direct > member of the sudo rule, i can use sudo. > > As I've looked at debug logs, i was able to see that the query used when i > was identical when i was successful at using sudo and when i i got denied. > The difference is the failure would have a message like > [sudosrv_get_sudorules_from_cache] (0x0400): Returning 1 rules for [ > user at example.com] The successes returned 2 rules. > > The only change made between the success and failure was making the user a > direct member of the sudo rule where the failure was an indirect member. > > Thanks for any help! > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From three18ti at gmail.com Mon Feb 1 22:11:32 2016 From: three18ti at gmail.com (Jon) Date: Mon, 1 Feb 2016 16:11:32 -0600 Subject: [Freeipa-users] [freeipa-users] Problem managing Autofs with FreeIPA Message-ID: Hello, I am attempting to configure autofs to automount home directories from an NFS server. I'm following these instructions as this was the only contiguous "here's what you need to do" instructions as the FreeIPA and Fedora documentation seems to contradict itself, and there's no clear cut a. then b. then c. (Admittedly, this is my first foray into managing home dirs this way, so I'm learning all around :) but I need a bit of direction...) First things first, can anyone confirm these directions are correct please? http://blog.delouw.ch/2015/03/14/using-ipa-to-provide-automount-maps-for-nfsv4-home-directories/ I'm going to assume they are for the purposes of the rest of the post. I'm currently working with three servers: freeipa01 - The FreeIPA server home-dir01 - The Home directory NFS server ipa-test01 - My test server where I'm making changes/trying to mount the home directory. ipa-test01 is the only CentOS 6.5 machine (no choice, it's the "production blessed" image), freeipa01 and home-dir01 are both CentOS7. Following those above linked instructions, I have created the following autmount configurations: Automount Configuration: >> [root at ipa-test01 ~]# ipa automountlocation-find >> ---------------------------- >> 1 automount location matched >> ---------------------------- >> Location: default >> ---------------------------- >> Number of entries returned 1 >> ---------------------------- >> >> [root at ipa-test01 ~]# ipa automountmap-find >> Location: default >> ------------------------ >> 3 automount maps matched >> ------------------------ >> Map: auto.direct >> >> Map: auto.home >> >> Map: auto.master >> ---------------------------- >> Number of entries returned 3 >> ---------------------------- >> >> [root at ipa-test01 ~]# ipa automountkey-find default auto.home >> ----------------------- >> 1 automount key matched >> ----------------------- >> Key: * >> Mount information: -fstype=nfs4,rw,sec=krb5,soft,rsize=8192,wsize=8192 home-dir01.sub.domain.mydomain.com:/exports/home/& >> ---------------------------- >> Number of entries returned 1 >> ---------------------------- Exports configuration: >> [root at home-dir01 home]# cat /etc/exports >> /exports/home *(rw,no_root_squash,sec=sys:krb5:krb5i:krb5p) At some point I generated this error. I have been unable to reproduce it... Included for completeness of my reporting but I don't think it's currently an issue. >> Feb 1 15:43:19 ipa-test01 rpc.gssd[1371]: ERROR: No credentials found for connection to server home-dir01.sub.domain.mydomain.com Without an entry in /etc/hosts I receive the following error when attempting to login as my domain user: >> Feb 1 16:22:13 ipa-test01 kernel: type=1105 audit(1454361733.209:125): user pid=1777 uid=0 auid=0 ses=1 msg='op=PAM:session_open acct=" jona at mydomain.com" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success' >> Feb 1 16:22:22 ipa-test01 rpc.gssd[1371]: ERROR: unable to resolve 2605:1c00:50f2:300a:aaaa:56ff:ffff:442a to hostname: Temporary failure in name resolution >> Feb 1 16:22:22 ipa-test01 rpc.gssd[1371]: ERROR: failed to read service info >> Feb 1 16:22:22 ipa-test01 rpc.gssd[1371]: ERROR: unable to resolve 192.168.10.250 to hostname: Name or service not known >> Feb 1 16:22:22 ipa-test01 rpc.gssd[1371]: ERROR: failed to read service info So I added the entry in /etc/hosts for my nfs server (will fix in DNS, but we use 3rd party DNS service that is not integrated with AD...), I get the following error (repeated attempts to sudo), note the "res=success" >> ipa-test01:/var/log/messages >> Feb 1 16:16:38 ipa-test01 kernel: __ratelimit: 90 callbacks suppressed >> Feb 1 16:16:38 ipa-test01 kernel: type=1123 audit(1454361398.936:92): user pid=1632 uid=0 auid=0 ses=1 msg='cwd="/root" cmd="-sh" terminal=pts/0 res=success' >> Feb 1 16:16:38 ipa-test01 kernel: type=1103 audit(1454361398.936:93): user pid=1632 uid=0 auid=0 ses=1 msg='op=PAM:setcred acct="jona at mydomain.com" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success' >> Feb 1 16:16:38 ipa-test01 kernel: type=1105 audit(1454361398.943:94): user pid=1632 uid=0 auid=0 ses=1 msg='op=PAM:session_open acct=" jona at mydomain.com" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success' >> Feb 1 16:16:38 ipa-test01 kernel: type=1106 audit(1454361398.944:95): user pid=1632 uid=0 auid=0 ses=1 msg='op=PAM:session_close acct=" jona at mydomain.com" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success' >> Feb 1 16:16:38 ipa-test01 kernel: type=1104 audit(1454361398.944:96): user pid=1632 uid=0 auid=0 ses=1 msg='op=PAM:setcred acct="jona at mydomain.com" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success' >> Feb 1 16:16:39 ipa-test01 kernel: type=1123 audit(1454361399.976:97): user pid=1635 uid=0 auid=0 ses=1 msg='cwd="/root" cmd="-sh" terminal=pts/0 res=success' >> Feb 1 16:16:39 ipa-test01 kernel: type=1103 audit(1454361399.976:98): user pid=1635 uid=0 auid=0 ses=1 msg='op=PAM:setcred acct="jona at mydomain.com" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success' >> Feb 1 16:16:39 ipa-test01 kernel: type=1105 audit(1454361399.982:99): user pid=1635 uid=0 auid=0 ses=1 msg='op=PAM:session_open acct=" jona at mydomain.com" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success' >> Feb 1 16:16:39 ipa-test01 kernel: type=1106 audit(1454361399.983:100): user pid=1635 uid=0 auid=0 ses=1 msg='op=PAM:session_close acct=" jona at mydomain.com" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success' >> Feb 1 16:16:39 ipa-test01 kernel: type=1104 audit(1454361399.983:101): user pid=1635 uid=0 auid=0 ses=1 msg='op=PAM:setcred acct="jona at mydomain.com" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success' These are the corresponding attempts to change user: >> [root at ipa-test01 ~]# sudo -iu jona at mydomain.com >> sudo: unable to change directory to /home/mydomain.com/jona: No such file or directory >> sudo: unable to execute /bin/sh: No such file or directory >> [root at ipa-test01 ~]# sudo -iu jona at mydomain.com >> sudo: unable to change directory to /home/mydomain.com/jona: No such file or directory >> sudo: unable to execute /bin/sh: No such file or directory >> [root at ipa-test01 ~]# sudo -iu jona at mydomain.com >> sudo: unable to change directory to /home/mydomain.com/jona: No such file or directory >> sudo: unable to execute /bin/sh: No such file or directory So clearly, it's not mounting the homedir, but I'm not producing any kind of error message... Note that I have no problem mounting this directory manually (with or without an entry in my /etc/hosts): >> [root at ipa-test01 ~]# mount home-dir01.sub.domain.mydomain.com:/exports/home/ /home/ >> home-dir01.sub.domain.mydomain.com:/exports/home/ on /home type nfs (rw,vers=4,addr=2605:1c00:50f2:300a:aaaa:56ff:ffff:442a,clientaddr=2605:1c00:50f2:300a:aaaa:56ff:ffff:dbf6) Interestingly enough, when I create an /etc/auto.home, I'm able to mount my home dir without issues: >> [root at ipa-test01 ~]# cat /root/auto.home >> * -fstype=nfs,soft,intr,rsize=8192,wsize=8192,nosuid,tcp 192.168.10.250: /exports/home/& >> [root at ipa-test01 ~]# cp /root/auto.home /etc/ >> [root at ipa-test01 ~]# service autofs restart >> Stopping automount: [ OK ] >> Starting automount: [ OK ] >> [root at ipa-test01 ~]# sudo -iu jona at mydomain.com >> -sh-4.1$ pwd >> /home/mydomain.com/jona >> -sh-4.1$ mount | grep home >> /dev/mapper/rootvg-home on /home type ext4 (rw,nodev) >> 192.168.10.250:/exports/home/mydomain.com on /home/mydomain.com type nfs (rw,nosuid,soft,intr,rsize=8192,wsize=8192,tcp,sloppy,vers=4,addr=192.168.10.250,clientaddr=192.168.10.84) >> [root at ipa-test01 ~]# rm /etc/auto.home >> rm: remove regular file `/etc/auto.home'? y >> [root at ipa-test01 ~]# service autofs restart >> Stopping automount: [ OK ] >> Starting automount: [ OK ] >> [root at ipa-test01 ~]# sudo -iu jona at mydomain.com >> sudo: unable to change directory to /home/mydomain.com/jona: No such file or directory >> sudo: unable to execute /bin/sh: No such file or directory But I think this counts as part of the "files" in the line in my nsswitch.conf: >> [root at ipa-test01 ~]# cat /etc/nsswitch.conf | grep automount >> automount: sss files If I'm understanding correctly, the server should pull all of this information from LDAP on where to mount from/to and should not have a local configuration file for dealing with "LDAP Managed" mount points. At this point I'm stumped. None of the guides or previous mailing lists seem to discuss this specific issue... Can anyone provide some further ideas for troubleshooting my setup please? Also, because I'm working with an AD domain, my login credentials are jona at mydomain.com which means my home directory is /home/mydomain.com/jona, so when any user from the AD domain logs into this server, all home dirs will be mounted since we're mounting home-dir01:/exports/home/mydomain.com to ipa-test01:/home/mydomain.com, right? Is there anyway to force more granular mounting of home directories? Thanks for the assistance! Best Regards, Jon A -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.vanveelen at gmail.com Tue Feb 2 01:18:34 2016 From: robert.vanveelen at gmail.com (Robert van Veelen) Date: Tue, 02 Feb 2016 01:18:34 +0000 Subject: [Freeipa-users] ca install fails upgrading to 4.2.0 Message-ID: Hi, I'm trying to create an ipa replica from ipa-server-3.0.0-47/pki-ca-9.0.3-45 to ipa-server-4.2.0-15/pki-ca-10.2.5-6 and cannot get the install to complete. The CS is configured as a sub to an external CA. I keep getting the same error when running the replica-install. Digging into pki-ca's debug log, I find the following errors: java.lang.Exception: SystemCertsVerification: system certs verification failure & CertUtils: verifySystemCertByNickname() failed: caSigningCert cert-pki-ca I've tried regenerating the source cacert.p12, upgrading pki-ca to latest, etc. It just seems like the new replica is unable to verify the certs while running selftests. any good tips for a next step to work out whats going on? Thanks, -rob -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Tue Feb 2 07:45:44 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 2 Feb 2016 08:45:44 +0100 Subject: [Freeipa-users] [Centos7.2 Freeipa 4.2] browser : your session has expired In-Reply-To: References: <2135244242.20514616.1454172899622.JavaMail.zimbra@redhat.com> Message-ID: <56B05EA8.3030502@redhat.com> On 01/31/2016 09:49 AM, wodel youchi wrote: > Hi, > > I miss explained myself apparently, here it is: > > I open a session with login/password, I do some work, I left it for a > while, the session disconnects which is normal. > I come back, I try to authenticate with login/password it keeps telling me > : your session has expired. > > Regards. Is there a time difference between a machine with browser and an IPA server? > > 2016-01-30 17:54 GMT+01:00 Alexander Bokovoy : > >> >> >> ----- Original Message ----- >>> Hi, >>> >>> When accessing the webui of Freeipa from the browser using login >> password, I >>> get your session has expired. >>> >>> >>> As a workaround I have to either : >>> - Delete the https certificate of the ipa server from the browser and >> delete >>> history then relogin again. >>> - Restart ipa services : ipactl restart >> - delete cookies in the browser corresponding to IPA server. >> >>> PS: The machine I am using to connect to the webui of freeipa is not >> enrolled >>> in it, I am using login/pass to connect not kerberos. >> Web UI session is set to 30 minutes or so. >> >> -- >> / Alexander Bokovoy >> > > > -- Petr Vobornik From christopher.lamb at ch.ibm.com Tue Feb 2 08:14:44 2016 From: christopher.lamb at ch.ibm.com (Christopher Lamb) Date: Tue, 2 Feb 2016 09:14:44 +0100 Subject: [Freeipa-users] [Centos7.2 Freeipa 4.2] browser : your session has expired In-Reply-To: <56B05EA8.3030502@redhat.com> References: <2135244242.20514616.1454172899622.JavaMail.zimbra@redhat.com> <56B05EA8.3030502@redhat.com> Message-ID: <201602020814.u128EqYb012506@d06av01.portsmouth.uk.ibm.com> Hi Petr I get exactly the same behaviour ever so often. We are running IPA server 4.2.0 15.0.1.el7_2.3, (though we got the same problem with earlier releases too). In my case the laptop running Firefox / FreeIPA WebUI, and the OEL Server running the IPA server have time within seconds / milliseconds of one another. The server uses NTPD (and has full missile lock on the NTP pool servers), and the laptop uses whatever OSX uses to keep time accurate. As I only need to use the FreeIPA WebUI rarely (every few months or so) the exact behaviour is difficult to pin down. It seems to work like this: a) I will sometimes have access without the "your session has expired" error. Typically this is when I have not used FreeIPA for a long time (months). b) then some days later, when I revisit the WebUI, the "your session has expired" error will crop up. c) as I have access to several workstations, each with several browsers installed (IE, FF, Chrome, Safari etc.), I may get luck and find one that does not give the error (while the others do). Just like the OP, the workstations are not FreeIPA hosts (or servers), and we use login /pw for the WebUI. Chris From: Petr Vobornik To: wodel youchi , Alexander Bokovoy Cc: freeipa-users at redhat.com Date: 02.02.2016 08:48 Subject: Re: [Freeipa-users] [Centos7.2 Freeipa 4.2] browser : your session has expired Sent by: freeipa-users-bounces at redhat.com On 01/31/2016 09:49 AM, wodel youchi wrote: > Hi, > > I miss explained myself apparently, here it is: > > I open a session with login/password, I do some work, I left it for a > while, the session disconnects which is normal. > I come back, I try to authenticate with login/password it keeps telling me > : your session has expired. > > Regards. Is there a time difference between a machine with browser and an IPA server? > > 2016-01-30 17:54 GMT+01:00 Alexander Bokovoy : > >> >> >> ----- Original Message ----- >>> Hi, >>> >>> When accessing the webui of Freeipa from the browser using login >> password, I >>> get your session has expired. >>> >>> >>> As a workaround I have to either : >>> - Delete the https certificate of the ipa server from the browser and >> delete >>> history then relogin again. >>> - Restart ipa services : ipactl restart >> - delete cookies in the browser corresponding to IPA server. >> >>> PS: The machine I am using to connect to the webui of freeipa is not >> enrolled >>> in it, I am using login/pass to connect not kerberos. >> Web UI session is set to 30 minutes or so. >> >> -- >> / Alexander Bokovoy >> > > > -- Petr Vobornik -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: From abokovoy at redhat.com Tue Feb 2 08:31:46 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 2 Feb 2016 10:31:46 +0200 Subject: [Freeipa-users] [Centos7.2 Freeipa 4.2] browser : your session has expired In-Reply-To: <201602020814.u128Epr2004536@d06av07.portsmouth.uk.ibm.com> References: <2135244242.20514616.1454172899622.JavaMail.zimbra@redhat.com> <56B05EA8.3030502@redhat.com> <201602020814.u128Epr2004536@d06av07.portsmouth.uk.ibm.com> Message-ID: <20160202083146.GM23415@redhat.com> On Tue, 02 Feb 2016, Christopher Lamb wrote: > >Hi Petr > >I get exactly the same behaviour ever so often. We are running IPA server >4.2.0 15.0.1.el7_2.3, (though we got the same problem with earlier releases >too). > >In my case the laptop running Firefox / FreeIPA WebUI, and the OEL Server >running the IPA server have time within seconds / milliseconds of one >another. The server uses NTPD (and has full missile lock on the NTP pool >servers), and the laptop uses whatever OSX uses to keep time accurate. > >As I only need to use the FreeIPA WebUI rarely (every few months or so) the >exact behaviour is difficult to pin down. It seems to work like this: > >a) I will sometimes have access without the "your session has expired" >error. Typically this is when I have not used FreeIPA for a long time >(months). > >b) then some days later, when I revisit the WebUI, the "your session has >expired" error will crop up. > >c) as I have access to several workstations, each with several browsers >installed (IE, FF, Chrome, Safari etc.), I may get luck and find one that >does not give the error (while the others do). > >Just like the OP, the workstations are not FreeIPA hosts (or servers), and >we use login /pw for the WebUI. Can you hit ctrl+shift+I in Firefox (open development console), select 'Network' tab there, hit reload, and explore the requests/responses there when the error is manifested. Unfortunately, there is no way to copy out the whole traffic but you can at least make screenshots. This approach allows you to see what's happening inside the communication without need to decode SSL traffic in Wireshark. -- / Alexander Bokovoy From pvoborni at redhat.com Tue Feb 2 08:35:27 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 2 Feb 2016 09:35:27 +0100 Subject: [Freeipa-users] [Centos7.2 Freeipa 4.2] browser : your session has expired In-Reply-To: <201602020814.u128Eqmw025660@d06av05.portsmouth.uk.ibm.com> References: <2135244242.20514616.1454172899622.JavaMail.zimbra@redhat.com> <56B05EA8.3030502@redhat.com> <201602020814.u128Eqmw025660@d06av05.portsmouth.uk.ibm.com> Message-ID: <56B06A4F.8010508@redhat.com> On 02/02/2016 09:14 AM, Christopher Lamb wrote: > > Hi Petr > > I get exactly the same behaviour ever so often. We are running IPA server > 4.2.0 15.0.1.el7_2.3, (though we got the same problem with earlier releases > too). > > In my case the laptop running Firefox / FreeIPA WebUI, and the OEL Server > running the IPA server have time within seconds / milliseconds of one > another. The server uses NTPD (and has full missile lock on the NTP pool > servers), and the laptop uses whatever OSX uses to keep time accurate. > > As I only need to use the FreeIPA WebUI rarely (every few months or so) the > exact behaviour is difficult to pin down. It seems to work like this: > > a) I will sometimes have access without the "your session has expired" > error. Typically this is when I have not used FreeIPA for a long time > (months). > > b) then some days later, when I revisit the WebUI, the "your session has > expired" error will crop up. > > c) as I have access to several workstations, each with several browsers > installed (IE, FF, Chrome, Safari etc.), I may get luck and find one that > does not give the error (while the others do). > > Just like the OP, the workstations are not FreeIPA hosts (or servers), and > we use login /pw for the WebUI. It does not matter if the workastation is FreeIPA host when login /pw is used. When it happens, could you examine Set-Cookie response header of login_password request and its response in browser developer tools. It would be good to find out if the response is successful(200) and what is the cookie expiration date. If it's not successful, then what is in response and in X-IPA-Rejection-Reason response header. https://pvoborni.fedorapeople.org/images/ff-dev-tools-xhr.png > > Chris > > > > From: Petr Vobornik > To: wodel youchi , Alexander Bokovoy > > Cc: freeipa-users at redhat.com > Date: 02.02.2016 08:48 > Subject: Re: [Freeipa-users] [Centos7.2 Freeipa 4.2] browser : your > session has expired > Sent by: freeipa-users-bounces at redhat.com > > > > On 01/31/2016 09:49 AM, wodel youchi wrote: >> Hi, >> >> I miss explained myself apparently, here it is: >> >> I open a session with login/password, I do some work, I left it for a >> while, the session disconnects which is normal. >> I come back, I try to authenticate with login/password it keeps telling > me >> : your session has expired. >> >> Regards. > > Is there a time difference between a machine with browser and an IPA > server? > >> >> 2016-01-30 17:54 GMT+01:00 Alexander Bokovoy : >> >>> >>> >>> ----- Original Message ----- >>>> Hi, >>>> >>>> When accessing the webui of Freeipa from the browser using login >>> password, I >>>> get your session has expired. >>>> >>>> >>>> As a workaround I have to either : >>>> - Delete the https certificate of the ipa server from the browser and >>> delete >>>> history then relogin again. >>>> - Restart ipa services : ipactl restart >>> - delete cookies in the browser corresponding to IPA server. >>> >>>> PS: The machine I am using to connect to the webui of freeipa is not >>> enrolled >>>> in it, I am using login/pass to connect not kerberos. >>> Web UI session is set to 30 minutes or so. >>> >>> -- >>> / Alexander Bokovoy >>> >> >> >> > > > -- > Petr Vobornik > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project > -- Petr Vobornik From jhrozek at redhat.com Tue Feb 2 08:37:46 2016 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 2 Feb 2016 09:37:46 +0100 Subject: [Freeipa-users] Sudo privilege inheritance in FreeIPA (3.0.x branch) In-Reply-To: References: Message-ID: <20160202083746.GB5518@hendrix> On Wed, Jan 27, 2016 at 09:36:13AM -0700, sysadmin ofdoom wrote: > I am trying to implement FreeIPA in a larger environment. Due to the > complexity of the environment I've been constructing a user group structure > such that i have groups at the following levels: > > project --> project_at_site --> project_site_vendor I'm not sure the order of the hierarchy is correct, can you show an example with ipa group-show? > > HBAC rules are defined at the lowest level (vendor at site) and associated > with a host group at the same level. > > Each of the above user group levels will have a corresponding sudo group. > (Used to provide a vendor access to servers the vendor supports at a > specific site at a moments notice) > > HBAC rules are propagating up the chain correctly. > > When a user is added to a top level group (e.g. project or project-sudo) > the indirect membership shows up for both Sudo and HBAC rules. > > The problem is that I can't get the sudo privileges to work when the user > shows indirect membership for the sudo rule. If i make the user a direct > member of the sudo rule, i can use sudo. > > As I've looked at debug logs, i was able to see that the query used when i > was identical when i was successful at using sudo and when i i got denied. > The difference is the failure would have a message like > [sudosrv_get_sudorules_from_cache] (0x0400): Returning 1 rules for [ > user at example.com] The successes returned 2 rules. > > The only change made between the success and failure was making the user a > direct member of the sudo rule where the failure was an indirect member. > > Thanks for any help! sudo uses the list of groups as returned by initgroups()/getgrouplist(), so if the user is a member of that group (as reported by id $user), then the sudo rule should match. From christopher.lamb at ch.ibm.com Tue Feb 2 08:40:54 2016 From: christopher.lamb at ch.ibm.com (Christopher Lamb) Date: Tue, 2 Feb 2016 09:40:54 +0100 Subject: [Freeipa-users] [Centos7.2 Freeipa 4.2] browser : your session has expired In-Reply-To: <20160202083146.GM23415@redhat.com> References: <2135244242.20514616.1454172899622.JavaMail.zimbra@redhat.com> <56B05EA8.3030502@redhat.com> <201602020814.u128Epr2004536@d06av07.portsmouth.uk.ibm.com> <20160202083146.GM23415@redhat.com> Message-ID: <201602020841.u128fIZM000747@d06av02.portsmouth.uk.ibm.com> From: Alexander Bokovoy To: Christopher Lamb/Switzerland/IBM at IBMCH Cc: Petr Vobornik , freeipa-users at redhat.com, wodel youchi Date: 02.02.2016 09:32 Subject: Re: [Freeipa-users] [Centos7.2 Freeipa 4.2] browser : your session has expired On Tue, 02 Feb 2016, Christopher Lamb wrote: > >Hi Petr > >I get exactly the same behaviour ever so often. We are running IPA server >4.2.0 15.0.1.el7_2.3, (though we got the same problem with earlier releases >too). > >In my case the laptop running Firefox / FreeIPA WebUI, and the OEL Server >running the IPA server have time within seconds / milliseconds of one >another. The server uses NTPD (and has full missile lock on the NTP pool >servers), and the laptop uses whatever OSX uses to keep time accurate. > >As I only need to use the FreeIPA WebUI rarely (every few months or so) the >exact behaviour is difficult to pin down. It seems to work like this: > >a) I will sometimes have access without the "your session has expired" >error. Typically this is when I have not used FreeIPA for a long time >(months). > >b) then some days later, when I revisit the WebUI, the "your session has >expired" error will crop up. > >c) as I have access to several workstations, each with several browsers >installed (IE, FF, Chrome, Safari etc.), I may get luck and find one that >does not give the error (while the others do). > >Just like the OP, the workstations are not FreeIPA hosts (or servers), and >we use login /pw for the WebUI. Can you hit ctrl+shift+I in Firefox (open development console), select 'Network' tab there, hit reload, and explore the requests/responses there when the error is manifested. Unfortunately, there is no way to copy out the whole traffic but you can at least make screenshots. This approach allows you to see what's happening inside the communication without need to decode SSL traffic in Wireshark. -- / Alexander Bokovoy -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 07581046.jpg Type: image/jpeg Size: 50158 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: From jhrozek at redhat.com Tue Feb 2 08:41:59 2016 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 2 Feb 2016 09:41:59 +0100 Subject: [Freeipa-users] [freeipa-users] Problem managing Autofs with FreeIPA In-Reply-To: References: Message-ID: <20160202084159.GC5518@hendrix> On Mon, Feb 01, 2016 at 04:11:32PM -0600, Jon wrote: > Hello, > > I am attempting to configure autofs to automount home directories from an > NFS server. > > I'm following these instructions as this was the only contiguous "here's > what you need to do" instructions as the FreeIPA and Fedora documentation > seems to contradict itself, and there's no clear cut a. then b. then c. > (Admittedly, this is my first foray into managing home dirs this way, so > I'm learning all around :) but I need a bit of direction...) > > First things first, can anyone confirm these directions are correct please? > > > http://blog.delouw.ch/2015/03/14/using-ipa-to-provide-automount-maps-for-nfsv4-home-directories/ > > I'm going to assume they are for the purposes of the rest of the post. > > I'm currently working with three servers: > freeipa01 - The FreeIPA server > home-dir01 - The Home directory NFS server > ipa-test01 - My test server where I'm making changes/trying to mount the > home directory. > > ipa-test01 is the only CentOS 6.5 machine (no choice, it's the "production > blessed" image), freeipa01 and home-dir01 are both CentOS7. > > Following those above linked instructions, I have created the following > autmount configurations: > > Automount Configuration: > >> [root at ipa-test01 ~]# ipa automountlocation-find > >> ---------------------------- > >> 1 automount location matched > >> ---------------------------- > >> Location: default > >> ---------------------------- > >> Number of entries returned 1 > >> ---------------------------- > >> > >> [root at ipa-test01 ~]# ipa automountmap-find > >> Location: default > >> ------------------------ > >> 3 automount maps matched > >> ------------------------ > >> Map: auto.direct > >> > >> Map: auto.home > >> > >> Map: auto.master > >> ---------------------------- > >> Number of entries returned 3 > >> ---------------------------- > >> > >> [root at ipa-test01 ~]# ipa automountkey-find default auto.home > >> ----------------------- > >> 1 automount key matched > >> ----------------------- > >> Key: * > >> Mount information: -fstype=nfs4,rw,sec=krb5,soft,rsize=8192,wsize=8192 > home-dir01.sub.domain.mydomain.com:/exports/home/& > >> ---------------------------- > >> Number of entries returned 1 > >> ---------------------------- > > Exports configuration: > > >> [root at home-dir01 home]# cat /etc/exports > >> /exports/home *(rw,no_root_squash,sec=sys:krb5:krb5i:krb5p) > > > > At some point I generated this error. I have been unable to reproduce > it... Included for completeness of my reporting but I don't think it's > currently an issue. > > >> Feb 1 15:43:19 ipa-test01 rpc.gssd[1371]: ERROR: No credentials found > for connection to server home-dir01.sub.domain.mydomain.com > > > Without an entry in /etc/hosts I receive the following error when > attempting to login as my domain user: > > >> Feb 1 16:22:13 ipa-test01 kernel: type=1105 audit(1454361733.209:125): > user pid=1777 uid=0 auid=0 ses=1 msg='op=PAM:session_open acct=" > jona at mydomain.com" exe="/usr/bin/sudo" hostname=? addr=? > terminal=/dev/pts/0 res=success' > >> Feb 1 16:22:22 ipa-test01 rpc.gssd[1371]: ERROR: unable to resolve > 2605:1c00:50f2:300a:aaaa:56ff:ffff:442a to hostname: Temporary failure in > name resolution > >> Feb 1 16:22:22 ipa-test01 rpc.gssd[1371]: ERROR: failed to read service > info > >> Feb 1 16:22:22 ipa-test01 rpc.gssd[1371]: ERROR: unable to resolve > 192.168.10.250 to hostname: Name or service not known > >> Feb 1 16:22:22 ipa-test01 rpc.gssd[1371]: ERROR: failed to read service > info > > > So I added the entry in /etc/hosts for my nfs server (will fix in DNS, but > we use 3rd party DNS service that is not integrated with AD...), I get the > following error (repeated attempts to sudo), note the "res=success" > > >> ipa-test01:/var/log/messages > >> Feb 1 16:16:38 ipa-test01 kernel: __ratelimit: 90 callbacks suppressed > >> Feb 1 16:16:38 ipa-test01 kernel: type=1123 audit(1454361398.936:92): > user pid=1632 uid=0 auid=0 ses=1 msg='cwd="/root" cmd="-sh" terminal=pts/0 > res=success' > >> Feb 1 16:16:38 ipa-test01 kernel: type=1103 audit(1454361398.936:93): > user pid=1632 uid=0 auid=0 ses=1 msg='op=PAM:setcred acct="jona at mydomain.com" > exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success' > >> Feb 1 16:16:38 ipa-test01 kernel: type=1105 audit(1454361398.943:94): > user pid=1632 uid=0 auid=0 ses=1 msg='op=PAM:session_open acct=" > jona at mydomain.com" exe="/usr/bin/sudo" hostname=? addr=? > terminal=/dev/pts/0 res=success' > >> Feb 1 16:16:38 ipa-test01 kernel: type=1106 audit(1454361398.944:95): > user pid=1632 uid=0 auid=0 ses=1 msg='op=PAM:session_close acct=" > jona at mydomain.com" exe="/usr/bin/sudo" hostname=? addr=? > terminal=/dev/pts/0 res=success' > >> Feb 1 16:16:38 ipa-test01 kernel: type=1104 audit(1454361398.944:96): > user pid=1632 uid=0 auid=0 ses=1 msg='op=PAM:setcred acct="jona at mydomain.com" > exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success' > >> Feb 1 16:16:39 ipa-test01 kernel: type=1123 audit(1454361399.976:97): > user pid=1635 uid=0 auid=0 ses=1 msg='cwd="/root" cmd="-sh" terminal=pts/0 > res=success' > >> Feb 1 16:16:39 ipa-test01 kernel: type=1103 audit(1454361399.976:98): > user pid=1635 uid=0 auid=0 ses=1 msg='op=PAM:setcred acct="jona at mydomain.com" > exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success' > >> Feb 1 16:16:39 ipa-test01 kernel: type=1105 audit(1454361399.982:99): > user pid=1635 uid=0 auid=0 ses=1 msg='op=PAM:session_open acct=" > jona at mydomain.com" exe="/usr/bin/sudo" hostname=? addr=? > terminal=/dev/pts/0 res=success' > >> Feb 1 16:16:39 ipa-test01 kernel: type=1106 audit(1454361399.983:100): > user pid=1635 uid=0 auid=0 ses=1 msg='op=PAM:session_close acct=" > jona at mydomain.com" exe="/usr/bin/sudo" hostname=? addr=? > terminal=/dev/pts/0 res=success' > >> Feb 1 16:16:39 ipa-test01 kernel: type=1104 audit(1454361399.983:101): > user pid=1635 uid=0 auid=0 ses=1 msg='op=PAM:setcred acct="jona at mydomain.com" > exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success' > > These are the corresponding attempts to change user: > > >> [root at ipa-test01 ~]# sudo -iu jona at mydomain.com > >> sudo: unable to change directory to /home/mydomain.com/jona: No such > file or directory > >> sudo: unable to execute /bin/sh: No such file or directory > >> [root at ipa-test01 ~]# sudo -iu jona at mydomain.com > >> sudo: unable to change directory to /home/mydomain.com/jona: No such > file or directory > >> sudo: unable to execute /bin/sh: No such file or directory > >> [root at ipa-test01 ~]# sudo -iu jona at mydomain.com > >> sudo: unable to change directory to /home/mydomain.com/jona: No such > file or directory > >> sudo: unable to execute /bin/sh: No such file or directory > > So clearly, it's not mounting the homedir, but I'm not producing any kind > of error message... Note that I have no problem mounting this directory > manually (with or without an entry in my /etc/hosts): > > >> [root at ipa-test01 ~]# mount home-dir01.sub.domain.mydomain.com:/exports/home/ > /home/ > >> home-dir01.sub.domain.mydomain.com:/exports/home/ on /home type nfs > (rw,vers=4,addr=2605:1c00:50f2:300a:aaaa:56ff:ffff:442a,clientaddr=2605:1c00:50f2:300a:aaaa:56ff:ffff:dbf6) > > > > Interestingly enough, when I create an /etc/auto.home, I'm able to mount my > home dir without issues: > > >> [root at ipa-test01 ~]# cat /root/auto.home > >> * -fstype=nfs,soft,intr,rsize=8192,wsize=8192,nosuid,tcp 192.168.10.250: > /exports/home/& > >> [root at ipa-test01 ~]# cp /root/auto.home /etc/ > >> [root at ipa-test01 ~]# service autofs restart > >> Stopping automount: [ OK ] > >> Starting automount: [ OK ] > >> [root at ipa-test01 ~]# sudo -iu jona at mydomain.com > >> -sh-4.1$ pwd > >> /home/mydomain.com/jona > >> -sh-4.1$ mount | grep home > >> /dev/mapper/rootvg-home on /home type ext4 (rw,nodev) > >> 192.168.10.250:/exports/home/mydomain.com on /home/mydomain.com type nfs > (rw,nosuid,soft,intr,rsize=8192,wsize=8192,tcp,sloppy,vers=4,addr=192.168.10.250,clientaddr=192.168.10.84) > >> [root at ipa-test01 ~]# rm /etc/auto.home > >> rm: remove regular file `/etc/auto.home'? y > >> [root at ipa-test01 ~]# service autofs restart > >> Stopping automount: [ OK ] > >> Starting automount: [ OK ] > >> [root at ipa-test01 ~]# sudo -iu jona at mydomain.com > >> sudo: unable to change directory to /home/mydomain.com/jona: No such > file or directory > >> sudo: unable to execute /bin/sh: No such file or directory > > > But I think this counts as part of the "files" in the line in my > nsswitch.conf: > > >> [root at ipa-test01 ~]# cat /etc/nsswitch.conf | grep automount > >> automount: sss files > > > If I'm understanding correctly, the server should pull all of this > information from LDAP on where to mount from/to and should not have a local > configuration file for dealing with "LDAP Managed" mount points. > > At this point I'm stumped. None of the guides or previous mailing lists > seem to discuss this specific issue... Can anyone provide some further > ideas for troubleshooting my setup please? > > > Also, because I'm working with an AD domain, my login credentials are > jona at mydomain.com which means my home directory is /home/mydomain.com/jona, > so when any user from the AD domain logs into this server, all home dirs > will be mounted since we're mounting home-dir01:/exports/home/mydomain.com > to ipa-test01:/home/mydomain.com, right? Is there anyway to force more > granular mounting of home directories? > > Thanks for the assistance! You'll want to make sure the mount entry and key is returned by automounter from the sss module. Normally I test it like this: - make sure the autofs service is enabled in sssd.conf - enable debug_level=7 in the [autofs] and [domain] services - restart sssd - run "automounter -m" in the foreground - look at the automounter output and the sssd logs for clues.. btw is auto.home linked to auto.master ? From mkosek at redhat.com Tue Feb 2 08:46:32 2016 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 2 Feb 2016 09:46:32 +0100 Subject: [Freeipa-users] ca install fails upgrading to 4.2.0 In-Reply-To: References: Message-ID: <56B06CE8.2080000@redhat.com> On 02/02/2016 02:18 AM, Robert van Veelen wrote: > Hi, > I'm trying to create an ipa replica from > ipa-server-3.0.0-47/pki-ca-9.0.3-45 to ipa-server-4.2.0-15/pki-ca-10.2.5-6 > and cannot get the install to complete. The CS is configured as a sub to an > external CA. I keep getting the same error when running the > replica-install. Digging into pki-ca's debug log, I find the following > errors: > > java.lang.Exception: SystemCertsVerification: system certs verification > failure > & > CertUtils: verifySystemCertByNickname() failed: caSigningCert cert-pki-ca > > I've tried regenerating the source cacert.p12, upgrading pki-ca to latest, > etc. It just seems like the new replica is unable to verify the certs while > running selftests. any good tips for a next step to work out whats going on? > > Thanks, > > -rob Can this be the same problem as answered by Endi here: https://www.redhat.com/archives/freeipa-users/2016-January/msg00564.html ? From pvoborni at redhat.com Tue Feb 2 08:48:21 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 2 Feb 2016 09:48:21 +0100 Subject: [Freeipa-users] [Centos7.2 Freeipa 4.2] browser : your session has expired In-Reply-To: <201602020841.u128fH7E012700@d06av06.portsmouth.uk.ibm.com> References: <2135244242.20514616.1454172899622.JavaMail.zimbra@redhat.com> <56B05EA8.3030502@redhat.com> <201602020814.u128Epr2004536@d06av07.portsmouth.uk.ibm.com> <20160202083146.GM23415@redhat.com> <201602020841.u128fH7E012700@d06av06.portsmouth.uk.ibm.com> Message-ID: <56B06D55.8030206@redhat.com> The 401 after successful 200 is an issue with session which to browser looks as expired session. Please examine cookie headers of both the 'login_password' and the subsequent 'json' request (as written in the other mail). On 02/02/2016 09:40 AM, Christopher Lamb wrote: > > From: Alexander Bokovoy > To: Christopher Lamb/Switzerland/IBM at IBMCH > Cc: Petr Vobornik , freeipa-users at redhat.com, > wodel youchi > Date: 02.02.2016 09:32 > Subject: Re: [Freeipa-users] [Centos7.2 Freeipa 4.2] browser : your > session has expired > > > > On Tue, 02 Feb 2016, Christopher Lamb wrote: >> >> Hi Petr >> >> I get exactly the same behaviour ever so often. We are running IPA server >> 4.2.0 15.0.1.el7_2.3, (though we got the same problem with earlier > releases >> too). >> >> In my case the laptop running Firefox / FreeIPA WebUI, and the OEL Server >> running the IPA server have time within seconds / milliseconds of one >> another. The server uses NTPD (and has full missile lock on the NTP pool >> servers), and the laptop uses whatever OSX uses to keep time accurate. >> >> As I only need to use the FreeIPA WebUI rarely (every few months or so) > the >> exact behaviour is difficult to pin down. It seems to work like this: >> >> a) I will sometimes have access without the "your session has expired" >> error. Typically this is when I have not used FreeIPA for a long time >> (months). >> >> b) then some days later, when I revisit the WebUI, the "your session has >> expired" error will crop up. >> >> c) as I have access to several workstations, each with several browsers >> installed (IE, FF, Chrome, Safari etc.), I may get luck and find one that >> does not give the error (while the others do). >> >> Just like the OP, the workstations are not FreeIPA hosts (or servers), and >> we use login /pw for the WebUI. > Can you hit ctrl+shift+I in Firefox (open development console), select > 'Network' tab there, hit reload, and explore the requests/responses > there when the error is manifested. Unfortunately, there is no way to > copy out the whole traffic but you can at least make screenshots. > > This approach allows you to see what's happening inside the > communication without need to decode SSL traffic in Wireshark. > -- > / Alexander Bokovoy > -- Petr Vobornik From christopher.lamb at ch.ibm.com Tue Feb 2 08:49:25 2016 From: christopher.lamb at ch.ibm.com (Christopher Lamb) Date: Tue, 2 Feb 2016 09:49:25 +0100 Subject: [Freeipa-users] Fw: [Centos7.2 Freeipa 4.2] browser : your session has expired Message-ID: <201602020849.u128nYiA025338@d06av02.portsmouth.uk.ibm.com> Sorry, Notes is playing up, and sent the last before I could type any text! The POST /ipa/session/login_password is successful. but the POST /ipa/session/json and GET /ipa/session/login_kerberos both give 401 unathorized Chris ----- Forwarded by Christopher Lamb/Switzerland/IBM on 02.02.2016 09:46 ----- From: Christopher Lamb/Switzerland/IBM at IBMCH To: Alexander Bokovoy Cc: freeipa-users at redhat.com Date: 02.02.2016 09:42 Subject: Re: [Freeipa-users] [Centos7.2 Freeipa 4.2] browser : your session has expired Sent by: freeipa-users-bounces at redhat.com Inactive hide details for Alexander Bokovoy ---02.02.2016 09:32:00---On Tue, 02 Feb 2016, Christopher Lamb wrote: >Alexander Bokovoy ---02.02.2016 09:32:00---On Tue, 02 Feb 2016, Christopher Lamb wrote: > From: Alexander Bokovoy To: Christopher Lamb/Switzerland/IBM at IBMCH Cc: Petr Vobornik , freeipa-users at redhat.com, wodel youchi Date: 02.02.2016 09:32 Subject: Re: [Freeipa-users] [Centos7.2 Freeipa 4.2] browser : your session has expired On Tue, 02 Feb 2016, Christopher Lamb wrote: > >Hi Petr > >I get exactly the same behaviour ever so often. We are running IPA server >4.2.0 15.0.1.el7_2.3, (though we got the same problem with earlier releases >too). > >In my case the laptop running Firefox / FreeIPA WebUI, and the OEL Server >running the IPA server have time within seconds / milliseconds of one >another. The server uses NTPD (and has full missile lock on the NTP pool >servers), and the laptop uses whatever OSX uses to keep time accurate. > >As I only need to use the FreeIPA WebUI rarely (every few months or so) the >exact behaviour is difficult to pin down. It seems to work like this: > >a) I will sometimes have access without the "your session has expired" >error. Typically this is when I have not used FreeIPA for a long time >(months). > >b) then some days later, when I revisit the WebUI, the "your session has >expired" error will crop up. > >c) as I have access to several workstations, each with several browsers >installed (IE, FF, Chrome, Safari etc.), I may get luck and find one that >does not give the error (while the others do). > >Just like the OP, the workstations are not FreeIPA hosts (or servers), and >we use login /pw for the WebUI. Can you hit ctrl+shift+I in Firefox (open development console), select 'Network' tab there, hit reload, and explore the requests/responses there when the error is manifested. Unfortunately, there is no way to copy out the whole traffic but you can at least make screenshots. This approach allows you to see what's happening inside the communication without need to decode SSL traffic in Wireshark. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0D180498.jpg Type: image/jpeg Size: 50158 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0D904784.gif Type: image/gif Size: 105 bytes Desc: not available URL: From mkosek at redhat.com Tue Feb 2 08:53:00 2016 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 2 Feb 2016 09:53:00 +0100 Subject: [Freeipa-users] Fw: [Centos7.2 Freeipa 4.2] browser : your session has expired In-Reply-To: <201602020849.u128nYiA025338@d06av02.portsmouth.uk.ibm.com> References: <201602020849.u128nYiA025338@d06av02.portsmouth.uk.ibm.com> Message-ID: <56B06E6C.1030009@redhat.com> On 02/02/2016 09:49 AM, Christopher Lamb wrote: > > > Sorry, Notes is playing up, and sent the last before I could type any text! > > The POST /ipa/session/login_password is successful. > > but the POST /ipa/session/json and GET /ipa/session/login_kerberos both > give 401 unathorized > > Chris Just to make sure we have covered all possible pit holes we have already gathered on our Troubleshooting page, did check all the advise in this list http://www.freeipa.org/page/Troubleshooting#Cannot_authenticate_to_Web_UI ? From christopher.lamb at ch.ibm.com Tue Feb 2 09:33:55 2016 From: christopher.lamb at ch.ibm.com (Christopher Lamb) Date: Tue, 2 Feb 2016 10:33:55 +0100 Subject: [Freeipa-users] Fw: [Centos7.2 Freeipa 4.2] browser : your session has expired In-Reply-To: <56B06E6C.1030009@redhat.com> References: <201602020849.u128nYiA025338@d06av02.portsmouth.uk.ibm.com> <56B06E6C.1030009@redhat.com> Message-ID: <201602020934.u129Y0Ni017005@d06av11.portsmouth.uk.ibm.com> Hi Martin, Good points Web UI Cannot authenticate to Web UI Make sure that the user can authenticate in CLI, e.g. with?kinit $USER --> yes the user can ssh to FreeIPA hosts, and can call kinit without error. Make sure that?httpd,?dirsrv?and?ipa_memcached?services on the affected FreeIPA server are running. --> httpd, slapd and memcached all running (proved by pgrep -l) Make sure there are no related?SELinux AVCs -- SELinux is disabled Make sure that cookies are enabled on the client browser --> enabled Make sure that the time on the FreeIPA server is up to date and there is no (significant) clock skew (freeipa-users thread) --> no clock skew Search for any related errors in?/var/log/httpd/error_log --> no errors today Chris From: Martin Kosek To: Christopher Lamb/Switzerland/IBM at IBMCH, freeipa-users at redhat.com Cc: Alexander Bokovoy Date: 02.02.2016 09:53 Subject: Re: [Freeipa-users] Fw: [Centos7.2 Freeipa 4.2] browser : your session has expired On 02/02/2016 09:49 AM, Christopher Lamb wrote: > > > Sorry, Notes is playing up, and sent the last before I could type any text! > > The POST /ipa/session/login_password is successful. > > but the POST /ipa/session/json and GET /ipa/session/login_kerberos both > give 401 unathorized > > Chris Just to make sure we have covered all possible pit holes we have already gathered on our Troubleshooting page, did check all the advise in this list http://www.freeipa.org/page/Troubleshooting#Cannot_authenticate_to_Web_UI ? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: From wdh at dds.nl Tue Feb 2 10:43:57 2016 From: wdh at dds.nl (Winfried de Heiden) Date: Tue, 2 Feb 2016 11:43:57 +0100 Subject: [Freeipa-users] OTP Message-ID: <56B0886D.2060608@dds.nl> An HTML attachment was scrubbed... URL: From robert.vanveelen at gmail.com Tue Feb 2 10:51:58 2016 From: robert.vanveelen at gmail.com (Robert van Veelen) Date: Tue, 02 Feb 2016 10:51:58 +0000 Subject: [Freeipa-users] ca install fails upgrading to 4.2.0 In-Reply-To: <56B06CE8.2080000@redhat.com> References: <56B06CE8.2080000@redhat.com> Message-ID: Unfortunately not. I saw that thread and grabbed the patch and updated spec to give it a try. Same issue. cheers, -rob On Tue, 2 Feb 2016 at 08:46 Martin Kosek wrote: > On 02/02/2016 02:18 AM, Robert van Veelen wrote: > > Hi, > > I'm trying to create an ipa replica from > > ipa-server-3.0.0-47/pki-ca-9.0.3-45 to > ipa-server-4.2.0-15/pki-ca-10.2.5-6 > > and cannot get the install to complete. The CS is configured as a sub to > an > > external CA. I keep getting the same error when running the > > replica-install. Digging into pki-ca's debug log, I find the following > > errors: > > > > java.lang.Exception: SystemCertsVerification: system certs verification > > failure > > & > > CertUtils: verifySystemCertByNickname() failed: caSigningCert > cert-pki-ca > > > > I've tried regenerating the source cacert.p12, upgrading pki-ca to > latest, > > etc. It just seems like the new replica is unable to verify the certs > while > > running selftests. any good tips for a next step to work out whats going > on? > > > > Thanks, > > > > -rob > > Can this be the same problem as answered by Endi here: > https://www.redhat.com/archives/freeipa-users/2016-January/msg00564.html > ? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Tue Feb 2 11:10:14 2016 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 2 Feb 2016 12:10:14 +0100 Subject: [Freeipa-users] Fw: [Centos7.2 Freeipa 4.2] browser : your session has expired In-Reply-To: <201602020934.u129Y1Rt015307@d06av06.portsmouth.uk.ibm.com> References: <201602020849.u128nYiA025338@d06av02.portsmouth.uk.ibm.com> <56B06E6C.1030009@redhat.com> <201602020934.u129Y1Rt015307@d06av06.portsmouth.uk.ibm.com> Message-ID: <56B08E96.5080605@redhat.com> On 02/02/2016 10:33 AM, Christopher Lamb wrote: > > Hi Martin, > > Good points > > Web UI > Cannot authenticate to Web UI > Make sure that the user can authenticate in CLI, e.g. with kinit $USER > --> yes the user can ssh to FreeIPA hosts, and can call kinit without > error. > Make sure that httpd, dirsrv and ipa_memcached services on the affected > FreeIPA server are running. --> httpd, slapd and memcached all running > (proved by pgrep -l) > Make sure there are no related SELinux AVCs -- SELinux is disabled That made me sad a little, I can only say: http://stopdisablingselinux.com/ :-) > Make sure that cookies are enabled on the client browser --> enabled > Make sure that the time on the FreeIPA server is up to date and there is > no (significant) clock skew (freeipa-users thread) --> no clock skew > Search for any related errors in /var/log/httpd/error_log --> no errors > today Ok, thanks for ruling out the basic issues, I will let Petr and Alexander dive in the others. When we discover the culprit, it would be nice to add it to this list too. > From: Martin Kosek > To: Christopher Lamb/Switzerland/IBM at IBMCH, > freeipa-users at redhat.com > Cc: Alexander Bokovoy > Date: 02.02.2016 09:53 > Subject: Re: [Freeipa-users] Fw: [Centos7.2 Freeipa 4.2] browser : your > session has expired > > > > On 02/02/2016 09:49 AM, Christopher Lamb wrote: >> >> >> Sorry, Notes is playing up, and sent the last before I could type any > text! >> >> The POST /ipa/session/login_password is successful. >> >> but the POST /ipa/session/json and GET /ipa/session/login_kerberos both >> give 401 unathorized >> >> Chris > > Just to make sure we have covered all possible pit holes we have already > gathered on our Troubleshooting page, did check all the advise in this list > > http://www.freeipa.org/page/Troubleshooting#Cannot_authenticate_to_Web_UI > > ? > > > > From mkosek at redhat.com Tue Feb 2 11:20:24 2016 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 2 Feb 2016 12:20:24 +0100 Subject: [Freeipa-users] ca install fails upgrading to 4.2.0 In-Reply-To: References: <56B06CE8.2080000@redhat.com> Message-ID: <56B090F8.9000403@redhat.com> On 02/02/2016 11:51 AM, Robert van Veelen wrote: > Unfortunately not. I saw that thread and grabbed the patch and updated spec > to give it a try. Same issue. > cheers, Ah, pity. Let me CC Endi in this thread then. I suspect he will be interested in the same log files as in the referred thread. > On Tue, 2 Feb 2016 at 08:46 Martin Kosek wrote: > >> On 02/02/2016 02:18 AM, Robert van Veelen wrote: >>> Hi, >>> I'm trying to create an ipa replica from >>> ipa-server-3.0.0-47/pki-ca-9.0.3-45 to >> ipa-server-4.2.0-15/pki-ca-10.2.5-6 >>> and cannot get the install to complete. The CS is configured as a sub to >> an >>> external CA. I keep getting the same error when running the >>> replica-install. Digging into pki-ca's debug log, I find the following >>> errors: >>> >>> java.lang.Exception: SystemCertsVerification: system certs verification >>> failure >>> & >>> CertUtils: verifySystemCertByNickname() failed: caSigningCert >> cert-pki-ca >>> >>> I've tried regenerating the source cacert.p12, upgrading pki-ca to >> latest, >>> etc. It just seems like the new replica is unable to verify the certs >> while >>> running selftests. any good tips for a next step to work out whats going >> on? >>> >>> Thanks, >>> >>> -rob >> >> Can this be the same problem as answered by Endi here: >> https://www.redhat.com/archives/freeipa-users/2016-January/msg00564.html >> ? >> >> > From harald.dunkel at aixigo.de Tue Feb 2 11:39:00 2016 From: harald.dunkel at aixigo.de (Harald Dunkel) Date: Tue, 2 Feb 2016 12:39:00 +0100 Subject: [Freeipa-users] Joining realm failed with "SSL certificate problem: self signed certificate in certificate chain" In-Reply-To: <56AB88B2.3050400@aixigo.de> References: <56AB5928.9090103@aixigo.de> <56AB8146.1080002@redhat.com> <56AB88B2.3050400@aixigo.de> Message-ID: <56B09554.5010609@aixigo.de> Found it. The error message on the ipa server (in /var/log/httpd/error_log) was less misleading: SSL Library Error: -12195 Peer does not recognize and trust the CA that issued your certificate After installing the ca-certificates package and adding the root certificate to it the problem was gone. Thanx to everybody Harri From Andy.Thompson at e-tcc.com Tue Feb 2 14:04:05 2016 From: Andy.Thompson at e-tcc.com (Andy Thompson) Date: Tue, 2 Feb 2016 14:04:05 +0000 Subject: [Freeipa-users] freeipa client in DMZ Message-ID: <538ed64fd6c24abe851c28910e8752d1@TCCCORPEXCH02.TCC.local> Are ports required to be open for a freeipa client in a DMZ to the AD DCs for trusted users to login? I've got everything open to the IPA servers required and can lookup users and sudo rules and such but trusted users are not able to login. Thanks -andy *** This communication may contain privileged and/or confidential information. It is intended solely for the use of the addressee. If you are not the intended recipient, you are strictly prohibited from disclosing, copying, distributing or using any of this information. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. *** From jbaird at follett.com Tue Feb 2 14:12:58 2016 From: jbaird at follett.com (Baird, Josh) Date: Tue, 2 Feb 2016 14:12:58 +0000 Subject: [Freeipa-users] freeipa client in DMZ In-Reply-To: <538ed64fd6c24abe851c28910e8752d1@TCCCORPEXCH02.TCC.local> References: <538ed64fd6c24abe851c28910e8752d1@TCCCORPEXCH02.TCC.local> Message-ID: I believe the sssd clients will need to communicate directly with your AD domain controllers, unfortunately. I wish there was a clean way around this, since we have a ton of DC's in our HUB site, and I don't really want to poke holes in the firewall(s) for all of them. Would someone from sssd/IPA mind chiming in here? What exactly needs to be open? What DNS record can we query to get the exact list of DC's that need to be available? Is there a way to restrict the list of domain controllers that certain sssd clients need to communicate with (for scenarios like this)? Thanks, Josh > -----Original Message----- > From: freeipa-users-bounces at redhat.com [mailto:freeipa-users- > bounces at redhat.com] On Behalf Of Andy Thompson > Sent: Tuesday, February 02, 2016 9:04 AM > To: freeipa-users at redhat.com > Subject: [Freeipa-users] freeipa client in DMZ > > Are ports required to be open for a freeipa client in a DMZ to the AD DCs for > trusted users to login? I've got everything open to the IPA servers required > and can lookup users and sudo rules and such but trusted users are not able > to login. > > Thanks > > -andy > > > > *** This communication may contain privileged and/or confidential > information. It is intended solely for the use of the addressee. If you are not > the intended recipient, you are strictly prohibited from disclosing, copying, > distributing or using any of this information. If you received this > communication in error, please contact the sender immediately and destroy > the material in its entirety, whether electronic or hard copy. *** > > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project From abokovoy at redhat.com Tue Feb 2 14:50:14 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 2 Feb 2016 16:50:14 +0200 Subject: [Freeipa-users] freeipa client in DMZ In-Reply-To: References: <538ed64fd6c24abe851c28910e8752d1@TCCCORPEXCH02.TCC.local> Message-ID: <20160202145014.GA22179@redhat.com> On Tue, 02 Feb 2016, Baird, Josh wrote: >I believe the sssd clients will need to communicate directly with your >AD domain controllers, unfortunately. I wish there was a clean way >around this, since we have a ton of DC's in our HUB site, and I don't >really want to poke holes in the firewall(s) for all of them. There is a way with FreeIPA 4.2+, but you need to have MIT Kerberos 1.13 on the client side. This way all clients will talk to IPA masters and IPA master would serve as Kerberos proxy using MS-KKDCP protocol. >Would someone from sssd/IPA mind chiming in here? What exactly needs >to be open? What DNS record can we query to get the exact list of DC's >that need to be available? Is there a way to restrict the list of >domain controllers that certain sssd clients need to communicate with >(for scenarios like this)? For normal IPA-AD trust following is needed from IPA clients: - access from IPA client to AD DCs for Kerberos (port 88 TCP/UDP, 464 TCP/UDP) - access from IPA client to IPA master for LDAP (389 TCP), Kerberos (port 88 TCP/UDP, port 464 TCP/UDP) - access from IPA client to your DNS server (53 UDP), whatever that could be There might be other ports too, I don't remember off-hand. If you want to block certain domain controllers from being accessible by IPA clients, make sure you are doing it with rejection so that SSSD and Kerberos library would properly jump to the next discovered AD DC. DNS SRV records often contain all AD DCs and there is no support for sites in Kerberos library to pick up only the local ones, it takes what is given from DNS SRV records (if use of DNS-based discovery is enabled) and tries them one by one. -- / Alexander Bokovoy From sbose at redhat.com Tue Feb 2 14:55:00 2016 From: sbose at redhat.com (Sumit Bose) Date: Tue, 2 Feb 2016 15:55:00 +0100 Subject: [Freeipa-users] freeipa client in DMZ In-Reply-To: References: <538ed64fd6c24abe851c28910e8752d1@TCCCORPEXCH02.TCC.local> Message-ID: <20160202145500.GA15522@p.redhat.com> On Tue, Feb 02, 2016 at 02:12:58PM +0000, Baird, Josh wrote: > I believe the sssd clients will need to communicate directly with your AD domain controllers, unfortunately. I wish there was a clean way around this, since we have a ton of DC's in our HUB site, and I don't really want to poke holes in the firewall(s) for all of them. > > Would someone from sssd/IPA mind chiming in here? What exactly needs to be open? What DNS record can we query to get the exact list of DC's that need to be available? Is there a way to restrict the list of domain controllers that certain sssd clients need to communicate with (for scenarios like this)? The clients only need to communicate with AD during authentication and only for password authentication. Since the authentication is Kerberos based port 88 should be open and although typically it is sufficient for Kerberos to use UDP in the AD case we need TCP as well because AD Kerberos tickets are too large for UDP due to the PAC data in the ticket. If you want to allow password changes you have to open port 749 as well. For the trusted domain SSSD delegates everything including finding a suitable KDC to libkrb5. If 'dns_lookup_kdc = true' and no realm definition is available for the AD domain in /etc/krb5.conf libkrb5 will do a SRV query for _kerberos._tcp.ad.domain (no sites or other AD specific options). If you want to restrict the AD servers the clients want to talk and keep the holes in the firewall small I would suggest to add the AD realms to /etc/krb5.conf which only contains the KDC the clients should talk to. HTH bye, Sumit > > Thanks, > > Josh > > > -----Original Message----- > > From: freeipa-users-bounces at redhat.com [mailto:freeipa-users- > > bounces at redhat.com] On Behalf Of Andy Thompson > > Sent: Tuesday, February 02, 2016 9:04 AM > > To: freeipa-users at redhat.com > > Subject: [Freeipa-users] freeipa client in DMZ > > > > Are ports required to be open for a freeipa client in a DMZ to the AD DCs for > > trusted users to login? I've got everything open to the IPA servers required > > and can lookup users and sudo rules and such but trusted users are not able > > to login. > > > > Thanks > > > > -andy > > > > > > > > *** This communication may contain privileged and/or confidential > > information. It is intended solely for the use of the addressee. If you are not > > the intended recipient, you are strictly prohibited from disclosing, copying, > > distributing or using any of this information. If you received this > > communication in error, please contact the sender immediately and destroy > > the material in its entirety, whether electronic or hard copy. *** > > > > > > -- > > Manage your subscription for the Freeipa-users mailing list: > > https://www.redhat.com/mailman/listinfo/freeipa-users > > Go to http://freeipa.org for more info on the project > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project From Andy.Thompson at e-tcc.com Tue Feb 2 14:51:55 2016 From: Andy.Thompson at e-tcc.com (Andy Thompson) Date: Tue, 2 Feb 2016 14:51:55 +0000 Subject: [Freeipa-users] freeipa client in DMZ In-Reply-To: References: <538ed64fd6c24abe851c28910e8752d1@TCCCORPEXCH02.TCC.local> Message-ID: <121c74da103b4a15b1f67a07b9b5e8ee@TCCCORPEXCH02.TCC.local> > -----Original Message----- > From: Baird, Josh [mailto:jbaird at follett.com] > Sent: Tuesday, February 2, 2016 9:13 AM > To: Andy Thompson ; freeipa- > users at redhat.com > Subject: RE: freeipa client in DMZ > > I believe the sssd clients will need to communicate directly with your AD > domain controllers, unfortunately. I wish there was a clean way around this, > since we have a ton of DC's in our HUB site, and I don't really want to poke > holes in the firewall(s) for all of them. > > Would someone from sssd/IPA mind chiming in here? What exactly needs to > be open? What DNS record can we query to get the exact list of DC's that > need to be available? Is there a way to restrict the list of domain controllers > that certain sssd clients need to communicate with (for scenarios like this)? > > Thanks, > > Josh > > > -----Original Message----- > > From: freeipa-users-bounces at redhat.com [mailto:freeipa-users- > > bounces at redhat.com] On Behalf Of Andy Thompson > > Sent: Tuesday, February 02, 2016 9:04 AM > > To: freeipa-users at redhat.com > > Subject: [Freeipa-users] freeipa client in DMZ > > > > Are ports required to be open for a freeipa client in a DMZ to the AD > > DCs for trusted users to login? I've got everything open to the IPA > > servers required and can lookup users and sudo rules and such but > > trusted users are not able to login. > > > > Thanks > > > > -andy > > > > Going through my firewall logs it appears kerberos needs opened to the DCs at a minimum although I dropped 464 in there as well. Once I opened that up I was able to authenticate I'm not much of an AD guy so I don't know if there is a way to limit the servers accessed within AD. In my environment I had to setup separate DNS servers for the AD domain due to the environment setup so I could control it that way by removing DC records from that DNS environment. My thought is that it relies on the _kerberos._tcp srv records -andy From michael.rainey.ctr at nrlssc.navy.mil Tue Feb 2 15:49:52 2016 From: michael.rainey.ctr at nrlssc.navy.mil (Michael Rainey (Contractor)) Date: Tue, 2 Feb 2016 09:49:52 -0600 Subject: [Freeipa-users] FreeIPA smart card how to Message-ID: Greetings FreeIPA Community, I have been testing and working with the smart card login feature of the IPA server, and have had some successes with this project. However, my latest server/client setup isn't working as expected. I can where the problem is occurring, which is the Common Name on the Card is not being mapped to the proper attribute on the IPA server. So here's my question: Is there a howto which explains how an where this mapping occurs? Is this something I can configure myself, or is hard coded. Sincerely, -- *Michael Rainey* -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Tue Feb 2 15:56:22 2016 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 2 Feb 2016 16:56:22 +0100 Subject: [Freeipa-users] FreeIPA smart card how to In-Reply-To: References: Message-ID: <56B0D1A6.4070400@redhat.com> On 02/02/2016 04:49 PM, Michael Rainey (Contractor) wrote: > Greetings FreeIPA Community, > > I have been testing and working with the smart card login feature of the IPA > server, and have had some successes with this project. However, my latest > server/client setup isn't working as expected. I can where the problem is > occurring, which is the Common Name on the Card is not being mapped to the > proper attribute on the IPA server. So here's my question: Is there a howto > which explains how an where this mapping occurs? Is this something I can > configure myself, or is hard coded. At the moment, the Smart Card support present in SSSD looks up the user by searching with a blob containing the whole SC certificate. This BTW means that the certificate needs to be present at user entry in FreeIPA to make sure it matches, no other mapping mechanism is available yet. We have some plans though: http://www.freeipa.org/page/V4/User_Certificates#Certificate_Identity_Mapping If you are interested in HOWTOs, Nathan Kinder put together pretty neat blog posts how to make Smart Card authentication working: http://www.freeipa.org/page/V4/User_Certificates#References HTH, Martin From michael.rainey.ctr at nrlssc.navy.mil Tue Feb 2 19:42:35 2016 From: michael.rainey.ctr at nrlssc.navy.mil (Michael Rainey (Contractor)) Date: Tue, 2 Feb 2016 13:42:35 -0600 Subject: [Freeipa-users] FreeIPA smart card how to In-Reply-To: <56B0D1A6.4070400@redhat.com> References: <56B0D1A6.4070400@redhat.com> Message-ID: Okay. I haven't been able to get around this issue. I can log using my username, my card is recognized by GDM and reads the card as expected, but I am unable to login using my smartcard. From what I can see in the logs the common name on my card doesn't match the username on my test account. Feb 2 13:00:05 cabildo gdm-smartcard]: pam_krb5[5152]: error resolving user name '' to uid/gid pair Feb 2 13:00:05 cabildo gdm-smartcard]: pam_krb5[5152]: error getting information about ' Feb 2 13:00:06 cabildo gdm-smartcard]: pam_unix(gdm-smartcard:account): could not identify user (from getpwnam()) Feb 2 13:00:06 cabildo gdm-smartcard]: pam_sss(gdm-smartcard:account): Access denied for user : 10 (User not known to the underlying authentication module) Feb 2 13:00:06 cabildo gdm-smartcard]: pam_krb5[5152]: error resolving user name '' to uid/gid pair Feb 2 13:00:13 cabildo gdm-smartcard]: pam_pkcs11(gdm-smartcard:auth): pam_get_pwd() failed: Conversation error Where do I go from here? *Michael Rainey* NRL 7320 Computer Support Group Building 1009, Room C156 Stennis Space Center, MS 39529 On 02/02/2016 09:56 AM, Martin Kosek wrote: > On 02/02/2016 04:49 PM, Michael Rainey (Contractor) wrote: >> Greetings FreeIPA Community, >> >> I have been testing and working with the smart card login feature of the IPA >> server, and have had some successes with this project. However, my latest >> server/client setup isn't working as expected. I can where the problem is >> occurring, which is the Common Name on the Card is not being mapped to the >> proper attribute on the IPA server. So here's my question: Is there a howto >> which explains how an where this mapping occurs? Is this something I can >> configure myself, or is hard coded. > At the moment, the Smart Card support present in SSSD looks up the user by > searching with a blob containing the whole SC certificate. This BTW means that > the certificate needs to be present at user entry in FreeIPA to make sure it > matches, no other mapping mechanism is available yet. We have some plans though: > > http://www.freeipa.org/page/V4/User_Certificates#Certificate_Identity_Mapping > > If you are interested in HOWTOs, Nathan Kinder put together pretty neat blog > posts how to make Smart Card authentication working: > > http://www.freeipa.org/page/V4/User_Certificates#References > > HTH, > Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From bantony at gmail.com Tue Feb 2 20:46:58 2016 From: bantony at gmail.com (Benoy Antony) Date: Tue, 2 Feb 2016 12:46:58 -0800 Subject: [Freeipa-users] FreeIPA for securing Hadoop clusters Message-ID: Greetings FreeIPA Community, For the past few months, we have been working on securing our Hadoop clusters at eBay using FreeIpa. We have been using Microsoft AD and we are replacing it with FreeIpa. Hadoop uses Kerberos, Ldap, certificates and secret keys for security. FreeIPA is a good fit. We are developing automation scripts and some services for integrating Hadoop with FreeIpa, which we plan to opensource once it is ready. We like to share our experience and lessons learned in the upcoming Hadoop Summit. Please support us by voting for our topic at https://hadoopsummit.uservoice.com/forums/344958-governance-and-security/suggestions/11664876-freeipa-for-securing-hadoop-fish cheers, Benoy Antony -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Tue Feb 2 21:20:53 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 2 Feb 2016 23:20:53 +0200 Subject: [Freeipa-users] FreeIPA for securing Hadoop clusters In-Reply-To: References: Message-ID: <20160202212053.GI22179@redhat.com> On Tue, 02 Feb 2016, Benoy Antony wrote: >Greetings FreeIPA Community, > >For the past few months, we have been working on securing our Hadoop >clusters at eBay using FreeIpa. We have been using Microsoft AD and we are >replacing it with FreeIpa. > >Hadoop uses Kerberos, Ldap, certificates and secret keys for security. >FreeIPA is a good fit. We are developing automation scripts and some >services for integrating Hadoop with FreeIpa, which we plan to opensource >once it is ready. Great. If you need some review (I had to deal with Hadoop and complex IPA environments, including trust to AD, myself), feel free to contact. > >We like to share our experience and lessons learned in the upcoming Hadoop >Summit. Please support us by voting for our topic at >https://hadoopsummit.uservoice.com/forums/344958-governance-and-security/suggestions/11664876-freeipa-for-securing-hadoop-fish Voted. -- / Alexander Bokovoy From sbose at redhat.com Tue Feb 2 21:38:07 2016 From: sbose at redhat.com (Sumit Bose) Date: Tue, 2 Feb 2016 22:38:07 +0100 Subject: [Freeipa-users] FreeIPA smart card how to In-Reply-To: References: <56B0D1A6.4070400@redhat.com> Message-ID: <20160202213807.GC20953@p.redhat.com> On Tue, Feb 02, 2016 at 01:42:35PM -0600, Michael Rainey (Contractor) wrote: > Okay. I haven't been able to get around this issue. I can log using my > username, my card is recognized by GDM and reads the card as expected, but I > am unable to login using my smartcard. From what I can see in the logs the > common name on my card doesn't match the username on my test account. > > Feb 2 13:00:05 cabildo gdm-smartcard]: pam_krb5[5152]: error resolving user > name '' to uid/gid pair > Feb 2 13:00:05 cabildo gdm-smartcard]: pam_krb5[5152]: error getting > information about ' > Feb 2 13:00:06 cabildo gdm-smartcard]: pam_unix(gdm-smartcard:account): > could not identify user (from getpwnam()) > Feb 2 13:00:06 cabildo gdm-smartcard]: pam_sss(gdm-smartcard:account): > Access denied for user : 10 (User not known to the underlying > authentication module) > Feb 2 13:00:06 cabildo gdm-smartcard]: pam_krb5[5152]: error resolving user > name '' to uid/gid pair > Feb 2 13:00:13 cabildo gdm-smartcard]: pam_pkcs11(gdm-smartcard:auth): > pam_get_pwd() failed: Conversation error Your pam configuration is wrong. I assume you used authconfig with the --enablesmartcard option. This will enable the "classical" Smartcard authentication scheme with pam_pkcs11 and pam_krb which out of the box won't work with FreeIPA. Please try to roll-back to a default PAM configuration with the --disablesmartcard option. After that gdm will hopefully use gdm-password instead of gdm-smartcard and let SSSD do the rest. HTH bye, Sumit > > Where do I go from here? > > *Michael Rainey* > NRL 7320 > Computer Support Group > Building 1009, Room C156 > Stennis Space Center, MS 39529 > On 02/02/2016 09:56 AM, Martin Kosek wrote: > >On 02/02/2016 04:49 PM, Michael Rainey (Contractor) wrote: > >>Greetings FreeIPA Community, > >> > >>I have been testing and working with the smart card login feature of the IPA > >>server, and have had some successes with this project. However, my latest > >>server/client setup isn't working as expected. I can where the problem is > >>occurring, which is the Common Name on the Card is not being mapped to the > >>proper attribute on the IPA server. So here's my question: Is there a howto > >>which explains how an where this mapping occurs? Is this something I can > >>configure myself, or is hard coded. > >At the moment, the Smart Card support present in SSSD looks up the user by > >searching with a blob containing the whole SC certificate. This BTW means that > >the certificate needs to be present at user entry in FreeIPA to make sure it > >matches, no other mapping mechanism is available yet. We have some plans though: > > > >http://www.freeipa.org/page/V4/User_Certificates#Certificate_Identity_Mapping > > > >If you are interested in HOWTOs, Nathan Kinder put together pretty neat blog > >posts how to make Smart Card authentication working: > > > >http://www.freeipa.org/page/V4/User_Certificates#References > > > >HTH, > >Martin > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project From Lachlan.Simpson at petermac.org Tue Feb 2 22:23:40 2016 From: Lachlan.Simpson at petermac.org (Simpson Lachlan) Date: Tue, 2 Feb 2016 22:23:40 +0000 Subject: [Freeipa-users] "Installing the client" Message-ID: <0137003026EBE54FBEC540C5600C03C4332E92@PMC-EXMBX02.petermac.org.au> In the docs, there is a section called "Installing the client". https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html#setting-up-clients The very first step contains language that is not explained. "For a regular user system" has one install method, and "An administrator machine" has another. There is no indication what an administrator machine might be used for - is this a replica? Is it a system that can run ipa commands on behalf of the ipa-server? What is the difference between a regular user system and an administrator machine? Cheers L. This email (including any attachments or links) may contain confidential and/or legally privileged information and is intended only to be read or used by the addressee. If you are not the intended addressee, any use, distribution, disclosure or copying of this email is strictly prohibited. Confidentiality and legal privilege attached to this email (including any attachments) are not waived or lost by reason of its mistaken delivery to you. If you have received this email in error, please delete it and notify us immediately by telephone or email. Peter MacCallum Cancer Centre provides no guarantee that this transmission is free of virus or that it has not been intercepted or altered and will not be liable for any delay in its receipt. From Lachlan.Simpson at petermac.org Tue Feb 2 22:35:08 2016 From: Lachlan.Simpson at petermac.org (Simpson Lachlan) Date: Tue, 2 Feb 2016 22:35:08 +0000 Subject: [Freeipa-users] Joining a host Message-ID: <0137003026EBE54FBEC540C5600C03C4332EB5@PMC-EXMBX02.petermac.org.au> Hola, Presuming a regular machine, I've started the join as per instructions: yum install ipa-client [root at vmts-linux1 ~]# ipa-client-install Error checking LDAP: Operations error: 000004DC: LdapErr: DSID-0C0906E8, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v1db1 Discovery was successful! Client hostname: vmts-linux1.unix.example.org Realm: UNIX.EXAMPLE.ORG DNS Domain: unix.example.org IPA Server: dc1.example.org BaseDN: dc=unix,dc=example,dc=org There are two things here that I'd like to understand. 1. There was an error, but the process seems to have been successful? Should I be investigating that error or is it to be expected? 2. The IPA server is wrong - the machine it has found the PDC server (with a one way trust IPA->AD), but not the IPA server. I can only presume this is in error and that I should run the command again explicitly stating the IPA server? Cheers L. This email (including any attachments or links) may contain confidential and/or legally privileged information and is intended only to be read or used by the addressee. If you are not the intended addressee, any use, distribution, disclosure or copying of this email is strictly prohibited. Confidentiality and legal privilege attached to this email (including any attachments) are not waived or lost by reason of its mistaken delivery to you. If you have received this email in error, please delete it and notify us immediately by telephone or email. Peter MacCallum Cancer Centre provides no guarantee that this transmission is free of virus or that it has not been intercepted or altered and will not be liable for any delay in its receipt. From abokovoy at redhat.com Tue Feb 2 22:35:30 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 3 Feb 2016 00:35:30 +0200 Subject: [Freeipa-users] "Installing the client" In-Reply-To: <0137003026EBE54FBEC540C5600C03C4332E92@PMC-EXMBX02.petermac.org.au> References: <0137003026EBE54FBEC540C5600C03C4332E92@PMC-EXMBX02.petermac.org.au> Message-ID: <20160202223530.GK22179@redhat.com> On Tue, 02 Feb 2016, Simpson Lachlan wrote: >In the docs, there is a section called "Installing the client". > >https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html#setting-up-clients > >The very first step contains language that is not explained. > >"For a regular user system" has one install method, and "An >administrator machine" has another. > >There is no indication what an administrator machine might be used for >- is this a replica? Is it a system that can run ipa commands on behalf >of the ipa-server? > >What is the difference between a regular user system and an >administrator machine? If you want to administer IPA from the command line, you need to install IPA command line tools. This is what it calls as 'administrator machine'. For a regular client system you wouldn't be running 'ipa' command, thus installing ipa-admintools is not needed. I agree it is a bit terse there so it might be a good idea to file a documentation bug against 'ipa' component of RHEL 7. -- / Alexander Bokovoy From nik.eb.inc at gmail.com Tue Feb 2 23:29:49 2016 From: nik.eb.inc at gmail.com (Nik Lam) Date: Wed, 3 Feb 2016 10:29:49 +1100 Subject: [Freeipa-users] PKINIT support in FreeIPA 4.2.0 Message-ID: Hello, I installed ipa-server on Centos 7.1 and later did and upgrade of the whole system to Centos 7.2. I think the FreeIPA version changed from 4.1.0 to 4.2.0 between these Centos/RHEL minor releases. We'd now like to try integrating with a 2FA provider via a radius proxy and want to use anonymous PKINIT to secure the initial communications between the client and the KDC. We've tried following the MIT Kerberos PKINIT configuration documentation http://web.mit.edu/kerberos/krb5-1.14/doc/admin/pkinit.html generating our own certs manually with openssl but haven't had any luck. We're seeing this in the kdc log: preauth pkinit failed to initialize: No realms configured correctly for pkinit support I've noticed there are many new pkinit-related options that have been added to the ipa-server-install script in 4.2.0, so it looks like PKINIT is available in this version of FreeIPA. Is that the case? And if it is, what is the recommended way to enable it given that it seems to have been disabled in the original install that I did? Or would it just be easier to start from scratch with a 4.2.0 ipa-server-install? (It's a test instance that doesn't have too much in it - it will take a several hours to rebuild from scratch.) Regards, Nik -------------- next part -------------- An HTML attachment was scrubbed... URL: From mexigabacho at gmail.com Tue Feb 2 23:42:44 2016 From: mexigabacho at gmail.com (Christopher Young) Date: Tue, 2 Feb 2016 18:42:44 -0500 Subject: [Freeipa-users] Obtaining certificate private keys for Apache/etc. Message-ID: I've been doing some reading and perhaps I'm confusing myself, but I couldn't find any definitive guide on how to go about doing what I think it a pretty simple thing. My ipa-client installs appear to generate a new TLS/SSL/PKI cert for each host when they are registered. I'd like to utilize that certificate with Apache/tomcat/etc.. I'm aware of how to obtain the certificate itself, however I'm not clear on how to obtain the private key (in a format that I can use as well) that was used to generate the certificate. Would someone kindly point me in the right direction or ideally just educate me on the command/options needed to do this. In particular, I'm looking to create pem files for both the key and cert for use with Apache, but it would be useful to understand how to do it for other stores as well. (Hint: this would be great to just have in a document that makes it clear). :) Thanks again to the freeipa team. I love this product. -- Chris From peter at pakos.pl Tue Feb 2 23:44:19 2016 From: peter at pakos.pl (Peter Pakos) Date: Tue, 2 Feb 2016 23:44:19 +0000 Subject: [Freeipa-users] FreeIPA Consistency Checker Message-ID: <56B13F53.6020908@pakos.pl> Hi, I just wanted to share a little script that I've created to check consistency across FreeIPA servers. https://github.com/peterpakos/ipa_check_consistency I hope you will like it. Please note, it's been tested only with FreeIPA 4.2 (Centos 7.2) so I'm not sure if it works with other versions. Please feel free to try it and if you have any improvement ideas then log them via GitHub. Thanks. -- Kind regards, Peter Pakos From luca.filipozzi at ubc.ca Tue Feb 2 23:50:54 2016 From: luca.filipozzi at ubc.ca (Filipozzi, Luca) Date: Tue, 2 Feb 2016 23:50:54 +0000 Subject: [Freeipa-users] Obtaining certificate private keys for Apache/etc. In-Reply-To: References: Message-ID: I wrote the following guide for sysadmins at my university in an attempt to coalesce in one place what I consider to be the good practices for X.509 certificate management using OpenSSL. I've included examples on how to load private keys, end-entity certificates and intermediate certificates into alternate trust stores (PKCS for IIS and JKS for Java). https://confluence.id.ubc.ca:8443/display/ITSecurity/how+to+obtain%2C+deploy+and+verify+an+X.509+certificate Let me know if you have suggestions for improvement. -- Luca Filipozzi, UBC IT Enterprise Architecture On Feb 2, 2016, at 15:43, Christopher Young > wrote: I've been doing some reading and perhaps I'm confusing myself, but I couldn't find any definitive guide on how to go about doing what I think it a pretty simple thing. My ipa-client installs appear to generate a new TLS/SSL/PKI cert for each host when they are registered. I'd like to utilize that certificate with Apache/tomcat/etc.. I'm aware of how to obtain the certificate itself, however I'm not clear on how to obtain the private key (in a format that I can use as well) that was used to generate the certificate. Would someone kindly point me in the right direction or ideally just educate me on the command/options needed to do this. In particular, I'm looking to create pem files for both the key and cert for use with Apache, but it would be useful to understand how to do it for other stores as well. (Hint: this would be great to just have in a document that makes it clear). :) Thanks again to the freeipa team. I love this product. -- Chris -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project -------------- next part -------------- An HTML attachment was scrubbed... URL: From Lachlan.Simpson at petermac.org Wed Feb 3 00:31:25 2016 From: Lachlan.Simpson at petermac.org (Simpson Lachlan) Date: Wed, 3 Feb 2016 00:31:25 +0000 Subject: [Freeipa-users] FW: Joining a host In-Reply-To: <0137003026EBE54FBEC540C5600C03C4332ED9@PMC-EXMBX02.petermac.org.au> References: <0137003026EBE54FBEC540C5600C03C4332EB0@PMC-EXMBX02.petermac.org.au> <0137003026EBE54FBEC540C5600C03C4332ED9@PMC-EXMBX02.petermac.org.au> Message-ID: <0137003026EBE54FBEC540C5600C03C433308E@PMC-EXMBX02.petermac.org.au> > -----Original Message----- > From: Simpson Lachlan > Sent: Wednesday, 3 February 2016 9:50 AM > To: Simpson Lachlan > Subject: RE: Joining a host > > > -----Original Message----- > > From: Simpson Lachlan > > > > [root at vmts-linux1 ~]# ipa-client-install Error checking LDAP: Operations error: > > 000004DC: LdapErr: DSID-0C0906E8, comment: In order to perform this > > operation a successful bind must be completed on the connection., data > > 0, v1db1 Discovery was successful! > > Client hostname: vmts-linux1.unix.example.org > > Realm: UNIX.EXAMPLE.ORG > > DNS Domain: unix.example.org > > IPA Server: dc1.example.org > > BaseDN: dc=unix,dc=example,dc=org > > > > Interestingly, if I choose to explicitly put the IPA server name, I get dire warnings > of no DNS autodiscover. > > The man page states: > > "Client machine can also be configured without a DNS autodiscovery at all. When > both --server and --domain options are used, client installer will use the specified > server and domain directly." > > > [root at vmts-linux1 ~]# ipa-client-install --server=vmts-linuxidm.unix.example.org > Usage: ipa-client-install [options] > > ipa-client-install: error: --server cannot be used without providing --domain > > [root at vmts-linux1 ~]# ipa-client-install --server=vmts-linuxidm.unix.example.org - > -domain=unix.example.org 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]: > > > I think we now have two solid conclusions: > > - there are DNS issues in my domain that I need to fix up (why isn't > _ldap._tcp.unix.example.org resolving to the IPA server?) > - the man page should clearly state that --server can't be run without the --domain > option, unless it can, and the error message is wrong. > > Cheers > L. This email (including any attachments or links) may contain confidential and/or legally privileged information and is intended only to be read or used by the addressee. If you are not the intended addressee, any use, distribution, disclosure or copying of this email is strictly prohibited. Confidentiality and legal privilege attached to this email (including any attachments) are not waived or lost by reason of its mistaken delivery to you. If you have received this email in error, please delete it and notify us immediately by telephone or email. Peter MacCallum Cancer Centre provides no guarantee that this transmission is free of virus or that it has not been intercepted or altered and will not be liable for any delay in its receipt. From Lachlan.Simpson at petermac.org Wed Feb 3 00:33:06 2016 From: Lachlan.Simpson at petermac.org (Simpson Lachlan) Date: Wed, 3 Feb 2016 00:33:06 +0000 Subject: [Freeipa-users] Joining a host In-Reply-To: <0137003026EBE54FBEC540C5600C03C4333089@PMC-EXMBX02.petermac.org.au> References: <0137003026EBE54FBEC540C5600C03C4332EB0@PMC-EXMBX02.petermac.org.au> <0137003026EBE54FBEC540C5600C03C4332ED9@PMC-EXMBX02.petermac.org.au> <0137003026EBE54FBEC540C5600C03C4333089@PMC-EXMBX02.petermac.org.au> Message-ID: <0137003026EBE54FBEC540C5600C03C433309C@PMC-EXMBX02.petermac.org.au> > > -----Original Message----- > > From: Simpson Lachlan > > Sent: Wednesday, 3 February 2016 9:50 AM > > > > [root at vmts-linux1 ~]# ipa-client-install > > --server=vmts-linuxidm.unix.example.org - -domain=unix.example.org > > 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]: > > > > > > I think we now have two solid conclusions: > > > > - there are DNS issues in my domain that I need to fix up (why isn't > > _ldap._tcp.unix.example.org resolving to the IPA server?) > > - the man page should clearly state that --server can't be run > > without the --domain option, unless it can, and the error message is wrong. Sure enough, #1 was true, and when the DNS entries for _ldap._tcp and _kerberos._tcp within that domain were fixed, running ipa-client-install worked exactly as expected. Cheers L. This email (including any attachments or links) may contain confidential and/or legally privileged information and is intended only to be read or used by the addressee. If you are not the intended addressee, any use, distribution, disclosure or copying of this email is strictly prohibited. Confidentiality and legal privilege attached to this email (including any attachments) are not waived or lost by reason of its mistaken delivery to you. If you have received this email in error, please delete it and notify us immediately by telephone or email. Peter MacCallum Cancer Centre provides no guarantee that this transmission is free of virus or that it has not been intercepted or altered and will not be liable for any delay in its receipt. From jb.ruybal at gmail.com Wed Feb 3 00:47:02 2016 From: jb.ruybal at gmail.com (Joshua Ruybal) Date: Wed, 03 Feb 2016 00:47:02 +0000 Subject: [Freeipa-users] DNS Dynamic Update Failing Message-ID: Hi All, I've run into a frustrating issue regarding DNS Dynamic Updating. In a nutshell: If I enroll a new client when the forward policy on a dns zone is set to "disabled" I don't have a problem enrolling the client and updating the dns record. However if the policy of the zone is set to "only" or "first", nsupdate fails during the client install. Install logs says nsupdate: Specified Zone 'example.com' does not exist (NXDOMAIN). I'm seeing this in multiple zones, and all I need to change to fix it is to change the forwarding policy. However it's problematic as we start the rollout, since we will need to rely on external dns until we have all servers enrolled. Client Install Log Snippet: 2016-02-02T22:53:17Z DEBUG args=/usr/bin/nsupdate -g /etc/ipa/.dns_update.txt 2016-02-02T22:53:17Z DEBUG stdout= 2016-02-02T22:53:17Z DEBUG stderr=specified zone 'dev.example.net' does not exist (NXDOMAIN) specified zone 'dev.example.net' does not exist (NXDOMAIN) Zone Configuration: [admin at ipa01 ~]$ ipa dnszone-show --all Zone name: dev.example.net dn: idnsname=dev.example.net,cn=dns,dc=example,dc=com Zone name: dev.example.net Authoritative nameserver: ipa01 Administrator e-mail address: hostmaster.dev.example.net. SOA serial: 1454447236 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3600 BIND update policy: grant EXAMPLE.COM krb5-self * A; grant EXAMPLE.COM krb5-self * AAAA; grant EXAMPLE.COM krb5-self * SSHFP; Active zone: TRUE Dynamic update: TRUE Allow query: any; Allow transfer: none; Zone forwarders: 8.8.8.8 Forward policy: only nsrecord: ipa01, ipa02 objectclass: top, idnsrecord, idnszone Any ideas on how to remedy this? I'd like to avoid updating records by hand if it can be avoided. Thanks! Josh -------------- next part -------------- An HTML attachment was scrubbed... URL: From tkent at xetus.com Wed Feb 3 00:59:37 2016 From: tkent at xetus.com (Terence Kent) Date: Tue, 2 Feb 2016 16:59:37 -0800 Subject: [Freeipa-users] "Failed to initialize credentials using keytab [default]" errors on functioning clients Message-ID: <10DFEC43-C0C6-4871-81C4-D6710EE3466E@xetus.com> Hello, We?ve been using SSSD with FreeIPA very successfully for a while now - we love it. Recently, we?ve noticed that all our linux hosts (All Ubuntu 14.04) log the following message pretty regularly (several dozen times per day): "Failed to initialize credentials using keytab [default]: Generic error (see e-text). Unable to create GSSAPI-encrypted LDAP connection.? Now, outside of this message, we have no symptoms that things aren?t functioning properly. SSSD is properly recognizing changes whenever we update our FreeIPA server. Can anyone point us in the right direction on how to fix this issue? So far, we?ve done the following: 1. Verified the /etc/krb5.keytab seems to be fine (and it does). 2. Verified that changes to our FreeIPA servers properly get replicated to the clients. Thanks! Terence -------------- next part -------------- An HTML attachment was scrubbed... URL: From mexigabacho at gmail.com Wed Feb 3 02:23:44 2016 From: mexigabacho at gmail.com (Christopher Young) Date: Tue, 2 Feb 2016 21:23:44 -0500 Subject: [Freeipa-users] Obtaining certificate private keys for Apache/etc. In-Reply-To: References: Message-ID: That looks more like a regular SSL/TLS guide. I was asking about interacting with FreeIPA (likely via certmonger, I think) specifically. If anyone has details on obtaining the default system cert (and especially the private key) and exporting/converting to PEMs, I'd greatly appreciate. I will try and look over your guide regardless soon and provide some feedback. At the moment, I'm confused about where the private keys used to generate the default host PKI certs are stored and how to extract them. On Tue, Feb 2, 2016 at 6:50 PM, Filipozzi, Luca wrote: > I wrote the following guide for sysadmins at my university in an attempt to > coalesce in one place what I consider to be the good practices for X.509 > certificate management using OpenSSL. I've included examples on how to load > private keys, end-entity certificates and intermediate certificates into > alternate trust stores (PKCS for IIS and JKS for Java). > > https://confluence.id.ubc.ca:8443/display/ITSecurity/how+to+obtain%2C+deploy+and+verify+an+X.509+certificate > > Let me know if you have suggestions for improvement. > > -- > Luca Filipozzi, UBC IT Enterprise Architecture > > On Feb 2, 2016, at 15:43, Christopher Young wrote: > > I've been doing some reading and perhaps I'm confusing myself, but I > couldn't find any definitive guide on how to go about doing what I > think it a pretty simple thing. > > My ipa-client installs appear to generate a new TLS/SSL/PKI cert for > each host when they are registered. I'd like to utilize that > certificate with Apache/tomcat/etc.. I'm aware of how to obtain the > certificate itself, however I'm not clear on how to obtain the private > key (in a format that I can use as well) that was used to generate the > certificate. > > Would someone kindly point me in the right direction or ideally just > educate me on the command/options needed to do this. In particular, > I'm looking to create pem files for both the key and cert for use with > Apache, but it would be useful to understand how to do it for other > stores as well. (Hint: this would be great to just have in a document > that makes it clear). :) > > Thanks again to the freeipa team. I love this product. > > -- Chris > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project From Lachlan.Simpson at petermac.org Wed Feb 3 04:08:57 2016 From: Lachlan.Simpson at petermac.org (Simpson Lachlan) Date: Wed, 3 Feb 2016 04:08:57 +0000 Subject: [Freeipa-users] User mapping between domains In-Reply-To: <0137003026EBE54FBEC540C5600C03C4333226@PMC-EXMBX02.petermac.org.au> References: <0137003026EBE54FBEC540C5600C03C4333226@PMC-EXMBX02.petermac.org.au> Message-ID: <0137003026EBE54FBEC540C5600C03C433325E@PMC-EXMBX02.petermac.org.au> > -----Original Message----- > From: Simpson Lachlan > > and that via the ID Views Default Trust View the IPA server would: > - see that jsmith is "Smith Jane" in AD > - authenticate against "Smith Jane"'s AD password > - see that jsmith's uid now needs to be 1500 instead of 17890983 > - see that jsmith's home should be /home/jsmith, creating this dir if it > doesn't exist > - see that jsmith's shell is /bin/bash I should add: - how do I clear the SSSD cache on client hosts when details change upstream? - the documentation mentioned - http://www.freeipa.org/page/V4/Migrating_existing_environments_to_Trust#How_to_Test - indicates that after applying an override via command line like: ipa idoverrideuser-add 'Default Trust View' testuser at tbad.idm.lab.eng.brq.redhat.com --uid 5555 we need to follow this up with a restart of SSSD. I've not known this to be sufficient. I cannot give a "sufficient" way to make this override stick - "magic hand waving" that has worked for me includes: restarting SSSD twice, rebooting the IPA server, and sometimes it seems that after a . Am I missing something? Cheers L. Details: Centos 7.2 sssd-common-1.13.0-40.el7_2.1.x86_64 sssd-ad-1.13.0-40.el7_2.1.x86_64 sssd-1.13.0-40.el7_2.1.x86_64 python-sssdconfig-1.13.0-40.el7_2.1.noarch sssd-krb5-common-1.13.0-40.el7_2.1.x86_64 sssd-ipa-1.13.0-40.el7_2.1.x86_64 sssd-ldap-1.13.0-40.el7_2.1.x86_64 sssd-proxy-1.13.0-40.el7_2.1.x86_64 sssd-client-1.13.0-40.el7_2.1.x86_64 sssd-common-pac-1.13.0-40.el7_2.1.x86_64 sssd-krb5-1.13.0-40.el7_2.1.x86_64 cheers L. This email (including any attachments or links) may contain confidential and/or legally privileged information and is intended only to be read or used by the addressee. If you are not the intended addressee, any use, distribution, disclosure or copying of this email is strictly prohibited. Confidentiality and legal privilege attached to this email (including any attachments) are not waived or lost by reason of its mistaken delivery to you. If you have received this email in error, please delete it and notify us immediately by telephone or email. Peter MacCallum Cancer Centre provides no guarantee that this transmission is free of virus or that it has not been intercepted or altered and will not be liable for any delay in its receipt. From Lachlan.Simpson at petermac.org Wed Feb 3 03:59:55 2016 From: Lachlan.Simpson at petermac.org (Simpson Lachlan) Date: Wed, 3 Feb 2016 03:59:55 +0000 Subject: [Freeipa-users] User mapping between domains Message-ID: <0137003026EBE54FBEC540C5600C03C433322B@PMC-EXMBX02.petermac.org.au> IPA is successfully installed, a one way trust created, and we have been able to login using AD credentials. For future googler's, there is some bare bones documentation on how to allow AD users to login to your system, under the heading "Allow access for users from AD domain to protected resources" http://www.freeipa.org/page/Active_Directory_trust_setup#Configure_IPA_server_for_cross-realm_trusts I can confirm this works for a one directional trust (IPA trusts AD), since that is what we have. Question/Issue: Currently I have two logins, one in the AD domain and one on each server in the IPA domain. The desire is to close that gap. We were under the impression that, utilising idoverrideuser, that we could map AD's "Smith Jane"@example.org (or EXAMPLE\Jane Smith; yes I know our AD logins have spaces in them, it's a technical debt that has no solution roadmap within the org) to jsmith at unix.example.org (which we would set up in IPA), and be able to override certain aspects, like: - instead of using the clumsy ssh "Smith Jane"@example.org at host1.unix.example.org to login to a system, we could use: ssh jsmith at host1.unix.example.org and that via the ID Views Default Trust View the IPA server would: - see that jsmith is "Smith Jane" in AD - authenticate against "Smith Jane"'s AD password - see that jsmith's uid now needs to be 1500 instead of 17890983 - see that jsmith's home should be /home/jsmith, creating this dir if it doesn't exist - see that jsmith's shell is /bin/bash Am I merely imagining that this is possible? My information came from various blog posts on the RH blog that suggested such a thing was possible, and this post on the FreeIPA site: http://www.freeipa.org/page/V4/Migrating_existing_environments_to_Trust#ID_Views Given the above use case, can I please get advice on: - is there a preferred order in which IPA user (jsmith at unix.example.org) is created and AD user (EXAMPLE\Smith Jane) has their ID Views Default Trust View entry created? - for the creation of homedir on login, does this need to be done per host, via ipa-client-install's --mkhomedir option rather than per user? Have I missed something? Cheers L. This email (including any attachments or links) may contain confidential and/or legally privileged information and is intended only to be read or used by the addressee. If you are not the intended addressee, any use, distribution, disclosure or copying of this email is strictly prohibited. Confidentiality and legal privilege attached to this email (including any attachments) are not waived or lost by reason of its mistaken delivery to you. If you have received this email in error, please delete it and notify us immediately by telephone or email. Peter MacCallum Cancer Centre provides no guarantee that this transmission is free of virus or that it has not been intercepted or altered and will not be liable for any delay in its receipt. From jhrozek at redhat.com Wed Feb 3 07:30:45 2016 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 3 Feb 2016 08:30:45 +0100 Subject: [Freeipa-users] "Failed to initialize credentials using keytab [default]" errors on functioning clients In-Reply-To: <10DFEC43-C0C6-4871-81C4-D6710EE3466E@xetus.com> References: <10DFEC43-C0C6-4871-81C4-D6710EE3466E@xetus.com> Message-ID: <20160203073045.GP5518@hendrix> On Tue, Feb 02, 2016 at 04:59:37PM -0800, Terence Kent wrote: > Hello, > > We?ve been using SSSD with FreeIPA very successfully for a while now - we love it. Recently, we?ve noticed that all our linux hosts (All Ubuntu 14.04) log the following message pretty regularly (several dozen times per day): > > "Failed to initialize credentials using keytab [default]: Generic error (see e-text). Unable to create GSSAPI-encrypted LDAP connection.? > > Now, outside of this message, we have no symptoms that things aren?t functioning properly. SSSD is properly recognizing changes whenever we update our FreeIPA server. > > Can anyone point us in the right direction on how to fix this issue? So far, we?ve done the following: > > 1. Verified the /etc/krb5.keytab seems to be fine (and it does). with kinit -k, right? > 2. Verified that changes to our FreeIPA servers properly get replicated to the clients. strange, I would have thought that this would cause the client to go offline. Can you send the complete logs? Ideally ldap_child.log and sssd_$domain.log From jhrozek at redhat.com Wed Feb 3 07:37:02 2016 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 3 Feb 2016 08:37:02 +0100 Subject: [Freeipa-users] User mapping between domains In-Reply-To: <0137003026EBE54FBEC540C5600C03C433322B@PMC-EXMBX02.petermac.org.au> References: <0137003026EBE54FBEC540C5600C03C433322B@PMC-EXMBX02.petermac.org.au> Message-ID: <20160203073702.GQ5518@hendrix> On Wed, Feb 03, 2016 at 03:59:55AM +0000, Simpson Lachlan wrote: > IPA is successfully installed, a one way trust created, and we have been able to > login using AD credentials. > > For future googler's, there is some bare bones documentation on how to allow AD > users to login to your system, under the heading "Allow access for users from AD > domain to protected resources" > > http://www.freeipa.org/page/Active_Directory_trust_setup#Configure_IPA_server_for_cross-realm_trusts > > I can confirm this works for a one directional trust (IPA trusts AD), since that > is what we have. > > Question/Issue: > > Currently I have two logins, one in the AD domain and one on each server in > the IPA domain. The desire is to close that gap. > > We were under the impression that, utilising idoverrideuser, that we could map > AD's > > "Smith Jane"@example.org (or EXAMPLE\Jane Smith; yes I know our AD logins > have spaces in them, it's a technical debt that has no solution roadmap within > the org) to > > jsmith at unix.example.org (which we would set up in IPA), > > and be able to override certain aspects, like: > > - instead of using the clumsy > > ssh "Smith Jane"@example.org at host1.unix.example.org btw normally you can login with samAccountName or UPN. I find it a bit odd that samAccountName would contain "Smith Jane", I would expect that to be in the gecos attribute.. Maybe in this case using UPN would be at least a bit easier , because you wouldn't have to quote it? > > to login to a system, we could use: > > ssh jsmith at host1.unix.example.org No, this cannot be done, at least not this way. While you can "remap" the AD usernames to a different one with id overrides functionality (so that "Smith Jane" might have a different name, you would still need to use the fully qualified name, not a shortname. This is because the trusted AD domain is a subdomain in SSSD lingo and all subdomains are implicitly fully qualified. If you want to use shortnames for your AD logins, you can use the default_domain_suffix option. But then only the domain that you put into this option's value can use short names and all other domains (including the IPA domain) must be fully qualified. > > and that via the ID Views Default Trust View the IPA server would: > - see that jsmith is "Smith Jane" in AD > - authenticate against "Smith Jane"'s AD password > - see that jsmith's uid now needs to be 1500 instead of 17890983 > - see that jsmith's home should be /home/jsmith, creating this dir if it > doesn't exist > - see that jsmith's shell is /bin/bash > > Am I merely imagining that this is possible? > > My information came from various blog posts on the RH blog that suggested such a > thing was possible, and this post on the FreeIPA site: > > http://www.freeipa.org/page/V4/Migrating_existing_environments_to_Trust#ID_Views > > Given the above use case, can I please get advice on: > > - is there a preferred order in which IPA user (jsmith at unix.example.org) is > created and AD user (EXAMPLE\Smith Jane) has their ID Views Default Trust > View entry created? > - for the creation of homedir on login, does this need to be done per host, via > ipa-client-install's --mkhomedir option rather than per user? > > > Have I missed something? > > Cheers > L. > > > This email (including any attachments or links) may contain > confidential and/or legally privileged information and is > intended only to be read or used by the addressee. If you > are not the intended addressee, any use, distribution, > disclosure or copying of this email is strictly > prohibited. > Confidentiality and legal privilege attached to this email > (including any attachments) are not waived or lost by > reason of its mistaken delivery to you. > If you have received this email in error, please delete it > and notify us immediately by telephone or email. Peter > MacCallum Cancer Centre provides no guarantee that this > transmission is free of virus or that it has not been > intercepted or altered and will not be liable for any delay > in its receipt. > > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project From mkosek at redhat.com Wed Feb 3 07:57:03 2016 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 3 Feb 2016 08:57:03 +0100 Subject: [Freeipa-users] Joining a host In-Reply-To: <0137003026EBE54FBEC540C5600C03C4332EB5@PMC-EXMBX02.petermac.org.au> References: <0137003026EBE54FBEC540C5600C03C4332EB5@PMC-EXMBX02.petermac.org.au> Message-ID: <56B1B2CF.80305@redhat.com> On 02/02/2016 11:35 PM, Simpson Lachlan wrote: > Hola, > > Presuming a regular machine, I've started the join as per instructions: > > yum install ipa-client > > [root at vmts-linux1 ~]# ipa-client-install > Error checking LDAP: Operations error: 000004DC: LdapErr: DSID-0C0906E8, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v1db1 > Discovery was successful! > Client hostname: vmts-linux1.unix.example.org > Realm: UNIX.EXAMPLE.ORG > DNS Domain: unix.example.org > IPA Server: dc1.example.org > BaseDN: dc=unix,dc=example,dc=org > > > There are two things here that I'd like to understand. > > 1. There was an error, but the process seems to have been successful? Should I be investigating that error or is it to be expected? Hi Simpson, I suspect that ipa-client-install had problems verifying a server during the discovery, so it may have assumed some values itself, it probably did it wrong. Details are in the ipaclient-install.log. > 2. The IPA server is wrong - the machine it has found the PDC server (with a one way trust IPA->AD), but not the IPA server. I can only presume this is in error and that I should run the command again explicitly stating the IPA server? So are you saying that FreeIPA actually discovered on an AD server? Do you DNS domain with SRV records for FreeIPA set up? If yes, you can pass it via "--domain" option of ipa-client-install, without using hard coded server list via "--server" options. From mkosek at redhat.com Wed Feb 3 08:01:22 2016 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 3 Feb 2016 09:01:22 +0100 Subject: [Freeipa-users] "Installing the client" In-Reply-To: <20160202223530.GK22179@redhat.com> References: <0137003026EBE54FBEC540C5600C03C4332E92@PMC-EXMBX02.petermac.org.au> <20160202223530.GK22179@redhat.com> Message-ID: <56B1B3D2.9000509@redhat.com> On 02/02/2016 11:35 PM, Alexander Bokovoy wrote: > On Tue, 02 Feb 2016, Simpson Lachlan wrote: >> In the docs, there is a section called "Installing the client". >> >> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html#setting-up-clients >> >> >> The very first step contains language that is not explained. >> >> "For a regular user system" has one install method, and "An >> administrator machine" has another. >> >> There is no indication what an administrator machine might be used for >> - is this a replica? Is it a system that can run ipa commands on behalf >> of the ipa-server? >> >> What is the difference between a regular user system and an >> administrator machine? > If you want to administer IPA from the command line, you need to install IPA > command line tools. This is what it calls as 'administrator machine'. > > For a regular client system you wouldn't be running 'ipa' command, thus > installing ipa-admintools is not needed. > > I agree it is a bit terse there so it might be a good idea to file a > documentation bug against 'ipa' component of RHEL 7. I would suggest using the documentation component directly. Here is the direct link for filing the bug: https://bugzilla.redhat.com/enter_bug.cgi?product=Red%20Hat%20Enterprise%20Linux%207&component=doc-Linux_Domain_Identity_Management_Guide From mkosek at redhat.com Wed Feb 3 08:12:23 2016 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 3 Feb 2016 09:12:23 +0100 Subject: [Freeipa-users] Obtaining certificate private keys for Apache/etc. In-Reply-To: References: Message-ID: <56B1B667.4060508@redhat.com> On 02/03/2016 12:42 AM, Christopher Young wrote: > I've been doing some reading and perhaps I'm confusing myself, but I > couldn't find any definitive guide on how to go about doing what I > think it a pretty simple thing. > > My ipa-client installs appear to generate a new TLS/SSL/PKI cert for > each host when they are registered. I'd like to utilize that > certificate with Apache/tomcat/etc.. I'm aware of how to obtain the > certificate itself, however I'm not clear on how to obtain the private > key (in a format that I can use as well) that was used to generate the > certificate. > > Would someone kindly point me in the right direction or ideally just > educate me on the command/options needed to do this. In particular, > I'm looking to create pem files for both the key and cert for use with > Apache, but it would be useful to understand how to do it for other > stores as well. (Hint: this would be great to just have in a document > that makes it clear). :) Hi Chris, I do not think it is a good idea to do what you are doing :-) The host certificate does not need to be the same as Web certificate. From FreeIPA 4.1 (IIRC), it is not even requested by default on all clients. I would rather recommend generating a separate certificate for the Web UI, we have some walkthrough here: http://www.freeipa.org/page/PKI#Requesting_a_new_certificate > Thanks again to the freeipa team. I love this product. And I love to hear notes from the community like this, very rewarding! From mbasti at redhat.com Wed Feb 3 08:45:02 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 3 Feb 2016 09:45:02 +0100 Subject: [Freeipa-users] DNS Dynamic Update Failing In-Reply-To: References: Message-ID: <56B1BE0E.7080603@redhat.com> On 03.02.2016 01:47, Joshua Ruybal wrote: > Hi All, > > I've run into a frustrating issue regarding DNS Dynamic Updating. > > In a nutshell: > > If I enroll a new client when the forward policy on a dns zone is set > to "disabled" I don't have a problem enrolling the client and updating > the dns record. > > However if the policy of the zone is set to "only" or "first", > nsupdate fails during the client install. Install logs says nsupdate: > Specified Zone 'example.com ' does not exist > (NXDOMAIN). > > I'm seeing this in multiple zones, and all I need to change to fix it > is to change the forwarding policy. However it's problematic as we > start the rollout, since we will need to rely on external dns until we > have all servers enrolled. > > > Client Install Log Snippet: > > 2016-02-02T22:53:17Z DEBUG args=/usr/bin/nsupdate -g > /etc/ipa/.dns_update.txt > 2016-02-02T22:53:17Z DEBUG stdout= > 2016-02-02T22:53:17Z DEBUG stderr=specified zone 'dev.example.net > ' does not exist (NXDOMAIN) > specified zone 'dev.example.net ' does not > exist (NXDOMAIN) > > Zone Configuration: > > [admin at ipa01 ~]$ ipa dnszone-show --all > Zone name: dev.example.net > dn: idnsname=dev.example.net > ,cn=dns,dc=example,dc=com > Zone name: dev.example.net > Authoritative nameserver: ipa01 > Administrator e-mail address: hostmaster.dev.example.net > . > SOA serial: 1454447236 > SOA refresh: 3600 > SOA retry: 900 > SOA expire: 1209600 > SOA minimum: 3600 > BIND update policy: grant EXAMPLE.COM > krb5-self * A; grant EXAMPLE.COM krb5-self * > AAAA; grant EXAMPLE.COM krb5-self * SSHFP; > Active zone: TRUE > Dynamic update: TRUE > Allow query: any; > Allow transfer: none; > Zone forwarders: 8.8.8.8 > Forward policy: only > nsrecord: ipa01, ipa02 > objectclass: top, idnsrecord, idnszone > > Any ideas on how to remedy this? I'd like to avoid updating records by > hand if it can be avoided. > > Thanks! > Josh > > Hello, which version of freeIPA do you use? If version is older than 4.1, then specifying forward policy and forwarders cause that zone work as forwardzone thus, you cannot add host there, because all queries ale forwarded to specified forwarders (8.8.8.8) which does not know zone dev.example.com If version is 4.1+ then nsupdate should work and it can be bug. However I'm curious why do you need forwarding in master zone, what is the use case? More details about forwardzones in IPA: http://www.freeipa.org/page/V4/Forward_zones IMO you need specify global forwarder to your external DNS server, instead of adding per zone forwarders. Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbose at redhat.com Wed Feb 3 09:08:21 2016 From: sbose at redhat.com (Sumit Bose) Date: Wed, 3 Feb 2016 10:08:21 +0100 Subject: [Freeipa-users] PKINIT support in FreeIPA 4.2.0 In-Reply-To: References: Message-ID: <20160203090821.GD20953@p.redhat.com> On Wed, Feb 03, 2016 at 10:29:49AM +1100, Nik Lam wrote: > Hello, > > I installed ipa-server on Centos 7.1 and later did and upgrade of the whole > system to Centos 7.2. > > I think the FreeIPA version changed from 4.1.0 to 4.2.0 between these > Centos/RHEL minor releases. > > We'd now like to try integrating with a 2FA provider via a radius proxy and > want to use anonymous PKINIT to secure the initial communications between > the client and the KDC. > > We've tried following the MIT Kerberos PKINIT configuration documentation > > http://web.mit.edu/kerberos/krb5-1.14/doc/admin/pkinit.html > > generating our own certs manually with openssl but haven't had any luck. > We're seeing this in the kdc log: > > preauth pkinit failed to initialize: No realms configured correctly for > pkinit support Which changes did you apply to krb5.conf? Did you use the IPA CA to sign the certificate or some other CA? > > I've noticed there are many new pkinit-related options that have been added > to the ipa-server-install script in 4.2.0, so it looks like PKINIT is > available in this version of FreeIPA. Is that the case? Which options are you referring to? bye, Sumit > > And if it is, what is the recommended way to enable it given that it seems > to have been disabled in the original install that I did? Or would it just > be easier to start from scratch with a 4.2.0 ipa-server-install? (It's a > test instance that doesn't have too much in it - it will take a several > hours to rebuild from scratch.) > > Regards, > > Nik > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project From rmj at ast.cam.ac.uk Wed Feb 3 16:35:29 2016 From: rmj at ast.cam.ac.uk (Roderick Johnstone) Date: Wed, 3 Feb 2016 16:35:29 +0000 Subject: [Freeipa-users] netapp unable to do ldap lookups over ssl to RHEL 7.2 ipa server In-Reply-To: <56AB5ACA.3080909@redhat.com> References: <56AA0ED9.9020505@ast.cam.ac.uk> <56AA1A1D.2080501@redhat.com> <56AA644E.3080000@ast.cam.ac.uk> <56AB3F9A.6050309@redhat.com> <56AB5509.2040403@ast.cam.ac.uk> <56AB5ACA.3080909@redhat.com> Message-ID: <56B22C51.8010803@ast.cam.ac.uk> On 29/01/16 12:27, Christian Heimes wrote: > On 2016-01-29 13:03, Roderick Johnstone wrote: >> On 29/01/16 10:31, Christian Heimes wrote: >>> On 2016-01-28 19:56, Roderick Johnstone wrote: >>>> On 28/01/16 13:39, Christian Heimes wrote: >>>>> On 2016-01-28 13:51, Roderick Johnstone wrote: >>>>>> Hi >>>>>> >>>>>> My netapp filer is happily doing ldap over ssl lookups for account >>>>>> information to my RHEL 6.7 testing ipa server >>>>>> (ipa-server-3.0.0-47.el6_7.1.x86_64). >>>>>> >>>>>> However, when I switch the filer to use my RHEL 7.2 ipa server >>>>>> (ipa-server-4.2.0-15.el7_2.3.x86_64) the lookup doesn't work. >>>>>> >>>>>> In the dirsrv log file I see entries like this: >>>>>> >>>>>> [28/Jan/2016:09:17:45 +0000] conn=1338 fd=112 slot=112 SSL connection >>>>>> from xxx.xxx.xxx.xxx to yyy.yyy.yy.yyy >>>>>> [28/Jan/2016:09:17:45 +0000] conn=1338 op=-1 fd=112 closed - Cannot >>>>>> communicate securely with peer: no common encryption algorithm(s). >>>>>> >>>>>> (xxx.xxx.xxx.xxx is the filer ip address and yyy.yyy.yyy.yyy is the >>>>>> ipa >>>>>> server ip address). >>>>>> >>>>>> Looking in the ldap directory for fields with cipher in the name >>>>>> shows a >>>>>> very different set of nssslenabledciphers between the two ipa-server >>>>>> versions. >>>>>> >>>>>> I wonder if this might be the issue? >>>>>> >>>>>> Can the ldap server tell me what ciphers its being requested to use by >>>>>> the filer? >>>>> >>>>> Yes, it looks like it is the issue. The supported cipher suites were >>>>> hardened a while ago. The ticket >>>>> https://fedorahosted.org/freeipa/ticket/4395 contains more information. >>>>> >>>>> During the TLS handshake the client sends a list of supported cipher >>>>> suites to the server. The server also has a list of supported cipher >>>>> suites. But the server never sends this list to the client. Instead it >>>>> picks one common cipher suite (usually the most secure) from the common >>>>> set of cipher suites. >>>>> >>>>> I don't know if you can get 389 DS to print the cipher suites. But you >>>>> can snoop the ciper suites from the TLS handshake with wireshark or >>>>> tshark. The handshake isnt't encrypted and can be captures on either >>>>> the >>>>> host or the server. >>>>> >>>>> # tshark -Vx -Y "ssl.handshake.ciphersuites" -i YOUR_INTERFACE tcp port >>>>> ldaps >>>>> >>>>> Christian >>>>> >>>> >>>> Thanks Christian. Thats really helpful. >>>> >>>> Now I have a list of ciphers being asked for and I found that the ldap >>>> server logs which ciphers its using when it starts up file >>>> /var/log/dirsrv/slapd-/error. There isn't any overlap. >>>> >>>> I noticed that there is a setting in the >>>> dn: cn=encryption,cn=config >>>> allowWeakCipher: off >>>> >>>> and >>>> nsSSL3Ciphers: +all >>>> >>>> and found some documentation on this here: >>>> http://directory.fedoraproject.org/docs/389ds/design/nss-cipher-design.html >>>> >>>> >>>> So, maybe I could add one (or several) of the required ciphers to >>>> nsSSL3Ciphers or possibly as a last resort set allowWeakCipher: on? >>> >>> Hi Roderick, >>> >>> I highly recommend against lowering the settings. Weak ciphers are >>> broken and insecure ciphers, some even with NULL encryption or no >>> authentication. At best weak ciphers may (!) protect your against a >>> passive sniffer and incompetent attacker. They won't protect you against >>> a serious attack. >>> >>> Are you able to reconfigure or update the client? Does the client even >>> speak TLS 1.0 to the server or is it restricted to SSLv2 and SSLv3? >>> >>> If you show me the complete handshake, I can give you further advice. >>> The handshake output of tshark starts like this: >>> >>> Secure Sockets Layer >>> SSL Record Layer: Handshake Protocol: Client Hello >>> Content Type: Handshake (22) >>> Version: TLS 1.0 (0x0301) >>> >>> Christian >>> >>> >> >> Christian >> >> I don't think we have much control over the available client ciphers. We >> are running the latest Data OnTap version for our natapps so we have >> what we have. The netapp can do TLSv1 though. >> >> We do have firewalling on the ipa servers so that will help until one of >> our trusted networks is compromised! >> >> I'll send you the handshake output from tshark off list. > > Hi Roderick, > > thanks for the handshake. It looks like the application initiates a > SSLv2 handshake and then does a protocol upgrade to TLS 1.0. This alone > makes the connection vulnerable to a man-in-the-middle attacks. You > should disable SSLv2 and SSLv3 on the client app ASAP. The broken > versions must be disabled on both sides. > > The cipher suite list is horrible, too. You don't want anything with > SSL2, RC2, RC4, DES, DSS, DHE, MD5 or EXPORT in its name. > TLS_RSA_WITH_3DES_EDE_CBC_SHA is the only cipher suite that is remotely > good. 3DES is slow but not entirely broken as RC4. TLS/SSL in CBC mode > has issues with padding, because TLS does MAC-then-encrypt. > > Christian > Christian If I wanted to enable TLS_RSA_WITH_3DES_EDE_CBC_SHA in the LDAP server can you advise the best way to do that please? I'm not quite sure how adding TLS_RSA_WITH_3DES_EDE_CBC_SHA to nsSSL3Ciphers: +all interacts with the allowWeakCipher: off ie does adding TLS_RSA_WITH_3DES_EDE_CBC_SHA to nsSSL3Ciphers: override its rejection in allowWeakCipher: off or do I need to set allowWeakCipher: on and then explicitly exclude all the other weak ciphers in the nsSSL3Ciphers: line? Thanks Roderick From michael.rainey.ctr at nrlssc.navy.mil Wed Feb 3 18:52:01 2016 From: michael.rainey.ctr at nrlssc.navy.mil (Michael Rainey (Contractor)) Date: Wed, 3 Feb 2016 12:52:01 -0600 Subject: [Freeipa-users] Enabling smart card on GDM manually. Message-ID: <6wIHnJBQKryXx8DEMzkcMG3_WFTBMDFp7vAu2Wcll9OsGCTrLiRr5A@cipher.nrlssc.navy.mil> Hello, How does one manually enable smart card login on GDM without using the authconfig command? I've tried using gsettings and dconf-editor. The "enable-smartcard-authentication" seems to locked at false. Sumit suggested to not use authconfig to enable smartcard login, because it tweaks the pam configuration to the point that an IPA client is unable to authenticate using the smartcard. Any suggestions? -- *Michael Rainey* NRL 7320 Computer Support Group Building 1009, Room C156 Stennis Space Center, MS 39529 -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.rainey.ctr at nrlssc.navy.mil Wed Feb 3 19:14:20 2016 From: michael.rainey.ctr at nrlssc.navy.mil (Michael Rainey (Contractor)) Date: Wed, 3 Feb 2016 13:14:20 -0600 Subject: [Freeipa-users] Enabling smart card on GDM manually. In-Reply-To: <6wIHnJBQKryXx8DEMzkcMG3_WFTBMDFp7vAu2Wcll9OsGCTrLiRr5A@cipher.nrlssc.navy.mil> References: <6wIHnJBQKryXx8DEMzkcMG3_WFTBMDFp7vAu2Wcll9OsGCTrLiRr5A@cipher.nrlssc.navy.mil> Message-ID: Please disregard this message. I discovered the answer after the message was sent. There is a locks file in /etc/dconf/db/distro.d/locks. I edited the /etc/dconf/db/distro.d/10-authconfig and rebooted. It is recognizing the smartcard now. *Michael Rainey* NRL 7320 Computer Support Group Building 1009, Room C156 Stennis Space Center, MS 39529 On 02/03/2016 12:52 PM, Michael Rainey (Contractor) wrote: > Hello, > > How does one manually enable smart card login on GDM without using the > authconfig command? I've tried using gsettings and dconf-editor. The > "enable-smartcard-authentication" seems to locked at false. > > Sumit suggested to not use authconfig to enable smartcard login, > because it tweaks the pam configuration to the point that an IPA > client is unable to authenticate using the smartcard. > > Any suggestions? > -- > *Michael Rainey* > NRL 7320 > Computer Support Group > Building 1009, Room C156 > Stennis Space Center, MS 39529 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mexigabacho at gmail.com Wed Feb 3 20:58:34 2016 From: mexigabacho at gmail.com (Christopher Young) Date: Wed, 3 Feb 2016 15:58:34 -0500 Subject: [Freeipa-users] Obtaining certificate private keys for Apache/etc. In-Reply-To: <56B1B667.4060508@redhat.com> References: <56B1B667.4060508@redhat.com> Message-ID: Thanks. That's good advice and good to know. I'm going to be trying to work this into an Ansible role, so having a command listing helps alot. That leads to a curious question if anyone has thought about building an Ansible module(s) for manipulating FreeIPA objects. I'm going to do some searching for that. On Wed, Feb 3, 2016 at 3:12 AM, Martin Kosek wrote: > On 02/03/2016 12:42 AM, Christopher Young wrote: >> I've been doing some reading and perhaps I'm confusing myself, but I >> couldn't find any definitive guide on how to go about doing what I >> think it a pretty simple thing. >> >> My ipa-client installs appear to generate a new TLS/SSL/PKI cert for >> each host when they are registered. I'd like to utilize that >> certificate with Apache/tomcat/etc.. I'm aware of how to obtain the >> certificate itself, however I'm not clear on how to obtain the private >> key (in a format that I can use as well) that was used to generate the >> certificate. >> >> Would someone kindly point me in the right direction or ideally just >> educate me on the command/options needed to do this. In particular, >> I'm looking to create pem files for both the key and cert for use with >> Apache, but it would be useful to understand how to do it for other >> stores as well. (Hint: this would be great to just have in a document >> that makes it clear). :) > > Hi Chris, > > I do not think it is a good idea to do what you are doing :-) The host > certificate does not need to be the same as Web certificate. From FreeIPA 4.1 > (IIRC), it is not even requested by default on all clients. > > I would rather recommend generating a separate certificate for the Web UI, we > have some walkthrough here: > > http://www.freeipa.org/page/PKI#Requesting_a_new_certificate > >> Thanks again to the freeipa team. I love this product. > > And I love to hear notes from the community like this, very rewarding! From razvan.vilt at me.com Wed Feb 3 21:09:37 2016 From: razvan.vilt at me.com (=?utf-8?Q?=22R=C4=83zvan_Corneliu_C=2ER=2E_VILT=22?=) Date: Wed, 03 Feb 2016 23:09:37 +0200 Subject: [Freeipa-users] Apple OpenDirectory Integration Message-ID: <673C3518-D3FA-47C2-9FEC-E1A6F986F8FF@me.com> Hi Guys, I've done a small scale demo of using FreeIPA instead of an Open Directory Server to serve Apple OS X clients. This is based on my experiences from one year ago (Ticket #4813). I've also attached some screenshots. Here's what works: Host sees the IPA Server Host is able to register to the IPA server Host creates a computer account (needs a bit of help here) Host sets it's own random password (including kerberosPrincipalKey and kerberosExtraData) Host can see the users and other computers in the LDAP Host can use TLS registration with FreeIPA's own root certificate as found in cn=CACert,cn=ipa,cn=etc Host can use just Kerberos for authentication and doesn't need an Apple Password Server Here's what needs to be done to get there: Create a cn=config,$baseDN entry (attached example ldif). This can be created automatically based on a template. Create and ACI that gives anonymous read access to cn=config,$baseDN (SNIP #3) Modify an existing ACI to give altSecurityIdentities and description to anonymous/public consumption (SNIP #4) Extend the schema to include apple-configuration (SNIP #1) Extend the schema to include apple-user (should be renamed to apple-account since it applies also to hosts) (SNIP #2) Add PLAIN to the supported SASL mechanisms (I don't know why it's missing anyway because it's restricted to TLS by default). For me, without further investigation of the reasons, I had to also disable CRAM-MD5 and DIGEST-MD5 on the 389 DS. Make sure (if you upgraded from a v3) that you have OCSP and/or CRL working Add an _ldap._tcp entry in avahi and/or server the LDAP server via DHCP and/or serve the search domain via DHCP and make the DNS-SD service entries for it. Here's what's missing from FreeIPA: A 389 Directory Server plugin that generates altSecurityIdentities and AuthAuthority values automatically for an objectClass=apple-account. This would automatically present the following entries (user admin used as an example): -- altSecurityIdentitites: Kerberos:admin at EXAMPLE.ORG AuthAuthority: ;Kerberosv5;;admin at EXAMPLE.ORG;EXAMPLE.ORG; -- AuthAuthority is interesting because it supports not only basic LDAP authentication, but also Kerberos, Netlogon and Apple Password Server and you can specify multiple authentication authorities (including an Active Directory). A better way to specify homes for users. Not everyone uses automount and automount maps (although OS X can use them). We need to be able to specify not the assumably mounted home directory, but the protocol (afp, nfs, cifs, etc.), server and share/directory. Furthermore, most Mac Admins will have a heart-attack if they see an auto-mounted /home/$username instead of the usual /Users/$username. Here's what's missing from OS X: A way to request OS X to do GSS-TSIG registration to the DNS. We may have an MCX method to do that, but I haven't investigated. NSUpdate is available and has support for gss-tsig. I think that for Active Directory it does this automatically, and if so, we should be able to reproduce it. A way to specify that the fqdn argument should actually be an FQDN. We might have to write a 389 DS plugin to take the CN without the final "$" and add the domain name after it. SUDO Map support. Currently, the only way to specify if an account has sudo rights is to make it an admin. This makes it clear that without Password Server support (partly implemented in the LPWS project), the usage scenarios are limited to normal users and SSO to servers. OTOH, OS X only knows admin and non-admin accounts, so it's not that bad. Steps to produce my demo install before the patches below: ipa-server-install -r EXAMPLE.ORG -n example.org -p deadbeef -a deadbeef -P deadbeef --hostname=ipa.example.org --ip-address=172.16.23.138 --ssh-trust-dns -U --setup-dns --no-forwarders Is anyone from Red Hat willing to pick this up? It would be a nice addition. If so, I am offering to do the testing and fine-tuning for all post-Tiger releases. I can also share virtual machines for server and client configuration. The Apple schemas are included in Apple's GPL code-drops for OpenLDAP if anyone is wondering about licensing. We don't need the full schemas because we can map most stuff to our own schema and it works brilliantly. Regards, R?zvan -------- SNIP #1---------- dn: cn=schema changetype: modify add: attributeTypes attributeTypes: (1.3.6.1.4.1.63.1000.1.1.1.12.3 NAME 'apple-config-realname' DESC 'config real name' EQUALITY caseExactIA5Match SUBSTR caseExactIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) attributeTypes: (1.3.6.1.4.1.63.1000.1.1.1.12.7 NAME 'apple-kdc-authkey' DESC 'KDC master key RSA encrypted with realm public key' EQUALITY caseExactMatch SUBSTR caseExactSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) attributeTypes: (1.3.6.1.4.1.63.1000.1.1.1.12.8 NAME 'apple-kdc-configdata' DESC 'Contents of the kdc.conf file' EQUALITY caseExactMatch SUBSTR caseExactSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) attributeTypes: (1.3.6.1.4.1.63.1000.1.1.1.1.19 NAME 'apple-keyword' DESC 'keywords' EQUALITY caseExactMatch SUBSTR caseExactSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) attributeTypes: (1.3.6.1.4.1.63.1000.1.1.1.12.5 NAME 'apple-ldap-replica' DESC 'LDAP replication list' EQUALITY caseExactMatch SUBSTR caseExactSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) attributeTypes: (1.3.6.1.4.1.63.1000.1.1.1.12.6 NAME 'apple-ldap-writable-replica' DESC 'LDAP writable replication list' EQUALITY caseExactMatch SUBSTR caseExactSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) attributeTypes: (1.3.6.1.4.1.63.1000.1.1.1.12.4 NAME 'apple-password-server-list' DESC 'password server replication plist' EQUALITY caseExactMatch SUBSTR caseExactSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) attributeTypes: (1.3.6.1.4.1.63.1000.1.1.1.12.1 NAME 'apple-password-server-location' DESC 'password server location' EQUALITY caseExactIA5Match SUBSTR caseExactIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) attributeTypes: (1.3.6.1.4.1.250.1.60 NAME 'ttl' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) attributeTypes: (1.3.6.1.4.1.63.1000.1.1.1.17.1 NAME 'apple-xmlplist' DESC 'XML plist data' EQUALITY caseExactMatch SUBSTR caseExactSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) - add: objectclasses objectClasses: (1.3.6.1.4.1.63.1000.1.1.2.12 NAME 'apple-configuration' DESC 'configuration' SUP top STRUCTURAL MAY ( cn $ apple-config-realname $ modifyTimestamp $ apple-password-server-location $ apple-password-server-list $ apple-ldap-replica $ apple-ldap-writable-replica $ apple-keyword $ apple-kdc-authkey $ apple-kdc-configdata $ apple-xmlplist $ ttl ) ) -------- END of SNIP #1------- -------- SNIP #2---------- cn=schema: changetype: modify add: attributeTypes attributesTypes: ( 1.2.840.113556.1.4.867 NAME 'altSecurityIdentities' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) attributesTypes: ( 1.3.6.1.4.1.63.1000.1.1.2.16.2 NAME ( 'authAuthority' 'authAuthority2' ) DESC 'password server authentication authority' EQUALITY caseExactMatch SUBSTR caseExactSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) - add: objectclasses objectclasses: ( 1.3.6.1.4.1.63.1000.1.1.2.1 NAME 'apple-user' SUP top AUXILIARY DESC 'apple user account' MAY ( authAuthority $ sambaAcctFlags $ sambaPwdLastSet $ sambaLogonTime $ sambaLogoffTime $ sambaKickoffTime $ sambaHomeDrive $ sambaLogonScript $ sambaProfilePath $ sambaUserWorkstations $ sambaHomePath $ sambaSID $ sambaPrimaryGroupSID $ userCertificate $ userPKCS12 $ jpegPhoto $ altSecurityIdentities ) ) -------- END of SNIP #2------- -------- SNIP #3 ---------- targetattr = "description || cn || objectclass || ou || apple-xmlplist")(targetfilter ="(objectclass=apple-configuration)")(version 3.0;acl "permission:System: Read Mac Profile";allow (compare,read,search) userdn = "ldap:///anyone";) -------- END of SNIP #3------- -------- SNIP #4 ---------- (targetattr = "altSecurityIdentities || cn || createtimestamp || description || displayname || entryusn || gecos || gidnumber || givenname || homedirectory || initials || ipantsecurityidentifier || loginshell || manager || modifytimestamp || objectclass || sn || title || uid || uidnumber")(targetfilter = "(objectclass=posixaccount)")(version 3.0;acl "permission:System: Read User Standard Attributes";allow (compare,read,search) userdn = "ldap:///anyone";) --------- END of SNIP #4------ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cn_config.ldif Type: application/octet-stream Size: 57279 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2016-02-03 at 22.11.57.png Type: image/png Size: 189973 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2016-02-03 at 22.12.53.png Type: image/png Size: 91870 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2016-02-03 at 22.11.41.png Type: image/png Size: 75008 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2016-02-03 at 22.11.49.png Type: image/png Size: 245733 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbose at redhat.com Wed Feb 3 21:47:12 2016 From: sbose at redhat.com (Sumit Bose) Date: Wed, 3 Feb 2016 22:47:12 +0100 Subject: [Freeipa-users] Enabling smart card on GDM manually. In-Reply-To: References: <6wIHnJBQKryXx8DEMzkcMG3_WFTBMDFp7vAu2Wcll9OsGCTrLiRr5A@cipher.nrlssc.navy.mil> Message-ID: <20160203214712.GI20953@p.redhat.com> On Wed, Feb 03, 2016 at 01:14:20PM -0600, Michael Rainey (Contractor) wrote: > Please disregard this message. I discovered the answer after the message > was sent. > > There is a locks file in /etc/dconf/db/distro.d/locks. I edited the > /etc/dconf/db/distro.d/10-authconfig and rebooted. It is recognizing the > smartcard now. Don't switch on the Smartcard support in gdm, if will force gdm to use pam_krb5 and pam_pkcs11. Just use the default configuration after running ipa-client-install and add 'pam_cert_auth = True' to the [pam] section of sssd.conf. If now a user tries to login via gdm or the console and has a Smartcard inserted which has a certificate which matches the one in the user entry on the IPA server SSSD will not ask for a password but for the Smartcard PIN. HTH bye, Sumit > > *Michael Rainey* > NRL 7320 > Computer Support Group > Building 1009, Room C156 > Stennis Space Center, MS 39529 > On 02/03/2016 12:52 PM, Michael Rainey (Contractor) wrote: > >Hello, > > > >How does one manually enable smart card login on GDM without using the > >authconfig command? I've tried using gsettings and dconf-editor. The > >"enable-smartcard-authentication" seems to locked at false. > > > >Sumit suggested to not use authconfig to enable smartcard login, because > >it tweaks the pam configuration to the point that an IPA client is unable > >to authenticate using the smartcard. > > > >Any suggestions? > >-- > >*Michael Rainey* > >NRL 7320 > >Computer Support Group > >Building 1009, Room C156 > >Stennis Space Center, MS 39529 > > > > > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project From jb.ruybal at gmail.com Wed Feb 3 22:18:34 2016 From: jb.ruybal at gmail.com (Joshua Ruybal) Date: Wed, 03 Feb 2016 22:18:34 +0000 Subject: [Freeipa-users] DNS Dynamic Update Failing In-Reply-To: <56B1BE0E.7080603@redhat.com> References: <56B1BE0E.7080603@redhat.com> Message-ID: Thanks for the reply. It makes a bit more sense now. I'm running FreeIPA 3.0.0 on CentOS 6.7 I followed your advice and was able to use dynamic update once I removed the zone forwarder. However I've set the global config to "forward only", but I'm still getting local resolution when I use dig from a client server. I'd expect to see the external records instead. I'm not seeing much in documentation how to troubleshoot this. Also I realize we're falling into the realm of a different subject and can start a fresh email chain if needed. Thanks again, Josh On Wed, Feb 3, 2016 at 12:45 AM Martin Basti wrote: > > > On 03.02.2016 01:47, Joshua Ruybal wrote: > > Hi All, > > I've run into a frustrating issue regarding DNS Dynamic Updating. > > In a nutshell: > > If I enroll a new client when the forward policy on a dns zone is set to > "disabled" I don't have a problem enrolling the client and updating the dns > record. > > However if the policy of the zone is set to "only" or "first", nsupdate > fails during the client install. Install logs says nsupdate: Specified Zone > 'example.com' does not exist (NXDOMAIN). > > I'm seeing this in multiple zones, and all I need to change to fix it is > to change the forwarding policy. However it's problematic as we start the > rollout, since we will need to rely on external dns until we have all > servers enrolled. > > > Client Install Log Snippet: > > 2016-02-02T22:53:17Z DEBUG args=/usr/bin/nsupdate -g > /etc/ipa/.dns_update.txt > 2016-02-02T22:53:17Z DEBUG stdout= > 2016-02-02T22:53:17Z DEBUG stderr=specified zone 'dev.example.net' does > not exist (NXDOMAIN) > specified zone 'dev.example.net' does not exist (NXDOMAIN) > > Zone Configuration: > > [admin at ipa01 ~]$ ipa dnszone-show --all > Zone name: dev.example.net > dn: idnsname=dev.example.net,cn=dns,dc=example,dc=com > Zone name: dev.example.net > Authoritative nameserver: ipa01 > Administrator e-mail address: hostmaster.dev.example.net. > SOA serial: 1454447236 > SOA refresh: 3600 > SOA retry: 900 > SOA expire: 1209600 > SOA minimum: 3600 > BIND update policy: grant EXAMPLE.COM krb5-self * A; grant EXAMPLE.COM > krb5-self * AAAA; grant EXAMPLE.COM krb5-self * SSHFP; > Active zone: TRUE > Dynamic update: TRUE > Allow query: any; > Allow transfer: none; > Zone forwarders: 8.8.8.8 > Forward policy: only > nsrecord: ipa01, ipa02 > objectclass: top, idnsrecord, idnszone > > Any ideas on how to remedy this? I'd like to avoid updating records by > hand if it can be avoided. > > Thanks! > Josh > > > Hello, > > which version of freeIPA do you use? > > If version is older than 4.1, then specifying forward policy and > forwarders cause that zone work as forwardzone thus, you cannot add host > there, because all queries ale forwarded to specified forwarders (8.8.8.8) > which does not know zone dev.example.com > > If version is 4.1+ then nsupdate should work and it can be bug. However > I'm curious why do you need forwarding in master zone, what is the use case? > > More details about forwardzones in IPA: > http://www.freeipa.org/page/V4/Forward_zones > > IMO you need specify global forwarder to your external DNS server, instead > of adding per zone forwarders. > > > Martin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Lachlan.Simpson at petermac.org Wed Feb 3 23:10:50 2016 From: Lachlan.Simpson at petermac.org (Simpson Lachlan) Date: Wed, 3 Feb 2016 23:10:50 +0000 Subject: [Freeipa-users] Client Host isn't picking up the idduseroverrides Message-ID: <0137003026EBE54FBEC540C5600C03C433346B@PMC-EXMBX02.petermac.org.au> When my users log into the IPA server, the id user over rides work. But they don't when we log into a client host? What are we doing wrong? The overrides are in the "Default Trust View" so should be applied to all hosts. We are trying to find *why* and *where* this is failing, but without much success. >From what I've read, this should be controlled by the sssd service on the host, but if we run sssd -I to watch what happens during a failed login or a login that doesn't successfully get the id user over ride applied, we don't see any errors or log entries that would indicate why. We see this: [root at vmts-linux1 ~]# /usr/sbin/sssd -i [sssd[be[unix.example.org]]] [krb5_auth_store_creds] (0x0010): unsupported PAM command [249]. [sssd[be[unix.example.org]]] [krb5_auth_store_creds] (0x0010): password not available, offline auth may not work. But there isn't anything in any logs that would indicate there's a communication happening between the host and the server that we can see. We have tried sss_cache -E on the host to clear cache, but we still aren't getting the over rides. Cheers L. This email (including any attachments or links) may contain confidential and/or legally privileged information and is intended only to be read or used by the addressee. If you are not the intended addressee, any use, distribution, disclosure or copying of this email is strictly prohibited. Confidentiality and legal privilege attached to this email (including any attachments) are not waived or lost by reason of its mistaken delivery to you. If you have received this email in error, please delete it and notify us immediately by telephone or email. Peter MacCallum Cancer Centre provides no guarantee that this transmission is free of virus or that it has not been intercepted or altered and will not be liable for any delay in its receipt. From Nathan.Peters at globalrelay.net Wed Feb 3 23:20:01 2016 From: Nathan.Peters at globalrelay.net (Nathan Peters) Date: Wed, 3 Feb 2016 23:20:01 +0000 Subject: [Freeipa-users] Freeipa 4.1.4 Very slow sudo access waiting for eventpoll Message-ID: We have a FreeIPA 4.1.4 domain running on CentOS 7.1. We have noticed that from certain machines, sudo is instant, and from others, it takes about 5 seconds. All machines involved can resolve each other through DNS (both forward and reverse lookups). Running an strace reveals that sssd_pam is hanging for 4.3 seconds waiting for /proc/freeipaproccessid/fd3 which maps to [eventpoll] 0.000044 epoll_wait(3, {{EPOLLIN, {u32=6976896, u64=6976896}}}, 1, 4896) = 1 4.373816 read(9, "l\2\1\1\206\0\0\0\10\0\0\0\25\0\0\0\5\1u\0\10\0\0\0\10\1g\0\7ua("..., 2048) = 174 lrwx------ 1 root root 64 Feb 3 19:04 3 -> [eventpoll] There are no nfs mounts on this system, so I can't see why this system call would take so long. This is happening on 3 of our machines right now, but others can login just fine. The pam/authconfig setup is identical on all of them. Any ideas why sssd would be timing out trying to get [eventpoll] out of the /proc directory? -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Thu Feb 4 07:09:20 2016 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 4 Feb 2016 08:09:20 +0100 Subject: [Freeipa-users] DNS Dynamic Update Failing In-Reply-To: References: <56B1BE0E.7080603@redhat.com> Message-ID: <56B2F920.3070006@redhat.com> On 3.2.2016 23:18, Joshua Ruybal wrote: > Thanks for the reply. It makes a bit more sense now. > > I'm running FreeIPA 3.0.0 on CentOS 6.7 > > I followed your advice and was able to use dynamic update once I removed > the zone forwarder. However I've set the global config to "forward only", > but I'm still getting local resolution when I use dig from a client server. > I'd expect to see the external records instead. > > I'm not seeing much in documentation how to troubleshoot this. > > Also I realize we're falling into the realm of a different subject and can > start a fresh email chain if needed. No problem. Please read https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/managing-dns-forwarding.html it might explain what can and cannot be done with zone forwarders. Petr^2 Spacek > > Thanks again, > > Josh > > On Wed, Feb 3, 2016 at 12:45 AM Martin Basti wrote: > >> >> >> On 03.02.2016 01:47, Joshua Ruybal wrote: >> >> Hi All, >> >> I've run into a frustrating issue regarding DNS Dynamic Updating. >> >> In a nutshell: >> >> If I enroll a new client when the forward policy on a dns zone is set to >> "disabled" I don't have a problem enrolling the client and updating the dns >> record. >> >> However if the policy of the zone is set to "only" or "first", nsupdate >> fails during the client install. Install logs says nsupdate: Specified Zone >> 'example.com' does not exist (NXDOMAIN). >> >> I'm seeing this in multiple zones, and all I need to change to fix it is >> to change the forwarding policy. However it's problematic as we start the >> rollout, since we will need to rely on external dns until we have all >> servers enrolled. >> >> >> Client Install Log Snippet: >> >> 2016-02-02T22:53:17Z DEBUG args=/usr/bin/nsupdate -g >> /etc/ipa/.dns_update.txt >> 2016-02-02T22:53:17Z DEBUG stdout= >> 2016-02-02T22:53:17Z DEBUG stderr=specified zone 'dev.example.net' does >> not exist (NXDOMAIN) >> specified zone 'dev.example.net' does not exist (NXDOMAIN) >> >> Zone Configuration: >> >> [admin at ipa01 ~]$ ipa dnszone-show --all >> Zone name: dev.example.net >> dn: idnsname=dev.example.net,cn=dns,dc=example,dc=com >> Zone name: dev.example.net >> Authoritative nameserver: ipa01 >> Administrator e-mail address: hostmaster.dev.example.net. >> SOA serial: 1454447236 >> SOA refresh: 3600 >> SOA retry: 900 >> SOA expire: 1209600 >> SOA minimum: 3600 >> BIND update policy: grant EXAMPLE.COM krb5-self * A; grant EXAMPLE.COM >> krb5-self * AAAA; grant EXAMPLE.COM krb5-self * SSHFP; >> Active zone: TRUE >> Dynamic update: TRUE >> Allow query: any; >> Allow transfer: none; >> Zone forwarders: 8.8.8.8 >> Forward policy: only >> nsrecord: ipa01, ipa02 >> objectclass: top, idnsrecord, idnszone >> >> Any ideas on how to remedy this? I'd like to avoid updating records by >> hand if it can be avoided. >> >> Thanks! >> Josh >> >> >> Hello, >> >> which version of freeIPA do you use? >> >> If version is older than 4.1, then specifying forward policy and >> forwarders cause that zone work as forwardzone thus, you cannot add host >> there, because all queries ale forwarded to specified forwarders (8.8.8.8) >> which does not know zone dev.example.com >> >> If version is 4.1+ then nsupdate should work and it can be bug. However >> I'm curious why do you need forwarding in master zone, what is the use case? >> >> More details about forwardzones in IPA: >> http://www.freeipa.org/page/V4/Forward_zones >> >> IMO you need specify global forwarder to your external DNS server, instead >> of adding per zone forwarders. >> >> >> Martin >> > > > -- Petr^2 Spacek From nik.eb.inc at gmail.com Thu Feb 4 08:25:29 2016 From: nik.eb.inc at gmail.com (Nik Lam) Date: Thu, 4 Feb 2016 19:25:29 +1100 Subject: [Freeipa-users] PKINIT support in FreeIPA 4.2.0 In-Reply-To: <20160203090821.GD20953@p.redhat.com> References: <20160203090821.GD20953@p.redhat.com> Message-ID: On Wed, Feb 3, 2016 at 8:08 PM, Sumit Bose wrote: > On Wed, Feb 03, 2016 at 10:29:49AM +1100, Nik Lam wrote: > > Hello, > > > > I installed ipa-server on Centos 7.1 and later did and upgrade of the > whole > > system to Centos 7.2. > > > > I think the FreeIPA version changed from 4.1.0 to 4.2.0 between these > > Centos/RHEL minor releases. > > > > We'd now like to try integrating with a 2FA provider via a radius proxy > and > > want to use anonymous PKINIT to secure the initial communications between > > the client and the KDC. > > > > We've tried following the MIT Kerberos PKINIT configuration documentation > > > > http://web.mit.edu/kerberos/krb5-1.14/doc/admin/pkinit.html > > > > generating our own certs manually with openssl but haven't had any luck. > > We're seeing this in the kdc log: > > > > preauth pkinit failed to initialize: No realms configured correctly > for > > pkinit support > > Which changes did you apply to krb5.conf? Did you use the IPA CA to sign > the certificate or some other CA? > > > > > I've noticed there are many new pkinit-related options that have been > added > > to the ipa-server-install script in 4.2.0, so it looks like PKINIT is > > available in this version of FreeIPA. Is that the case? > > Which options are you referring to? > > bye, > Sumit > > > > > And if it is, what is the recommended way to enable it given that it > seems > > to have been disabled in the original install that I did? Or would it > just > > be easier to start from scratch with a 4.2.0 ipa-server-install? (It's a > > test instance that doesn't have too much in it - it will take a several > > hours to rebuild from scratch.) > > > > Regards, > > > > Nik > > > Thanks Sumit. It sounds like PKINIT is available but clearly I'm doing it wrong. > Which changes did you apply to krb5.conf? Did you use the IPA CA to sign the certificate or some other CA? Actually, I modified the kdc.conf file - placed the kdc.pem, kdckey.pem and cacert.pem files in /var/kerberos/krb5kdc/ that I generated via openssl commands in the MIT Kerberos documentation. The only change to kdc.conf file was to append the location of the kdckey.pem file to pkinit_identity. pkinit_identity = FILE:/var/kerberos/krb5kdc/kdc.pem pkinit_anchors = FILE:/var/kerberos/krb5kdc/cacert.pem became pkinit_identity = FILE:/var/kerberos/krb5kdc/kdc.pem,/var/kerberos/krb5kdc/kdckey.pem pkinit_anchors = FILE:/var/kerberos/krb5kdc/cacert.pem Should I have been modifying krb5.conf instead? It aslo sounds like I need to use a certificate signed by the IPAs CA - is this something that should be generated using ipa-getcert? Or do I just find the IPA CA's private key and use openssl following the MIT Kerberos documentation? > Which options are you referring to? When I looked at the --help text for 4.1.0 and 4.2.0 versions of ipa-server-install, I noticed that 4.2.0 has these in the "certificate system options": --no-pkinit disables pkinit setup steps --pkinit-cert-file=FILE File containing the Kerberos KDC SSL certificate and private key --pkinit-pin=PIN The password to unlock the Kerberos KDC private key --pkinit-cert-name=NAME Name of the Kerberos KDC SSL certificate to install Seeing that first one, I was a little hopeful that pkinit is enabled by default in 4.2.0 but on a fresh install I just tried, I'm still seeing the following in krb5kdc.log when IPA is started up, so clearly it isn't. (Error): preauth pkinit failed to initialize: No realms configured correctly for pkinit support Regards, Nik -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Thu Feb 4 08:47:05 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 4 Feb 2016 09:47:05 +0100 Subject: [Freeipa-users] Obtaining certificate private keys for Apache/etc. In-Reply-To: References: <56B1B667.4060508@redhat.com> Message-ID: <56B31009.6010509@redhat.com> Christopher Young wrote: > Thanks. That's good advice and good to know. I'm going to be trying > to work this into an Ansible role, so having a command listing helps > alot. > > That leads to a curious question if anyone has thought about building > an Ansible module(s) for manipulating FreeIPA objects. I'm going to > do some searching for that. To close the loop, the dfault cert in IPA clients is stored in an NSS database and NSS doesn't give up its private keys willingly. The only way to get them is to export to a PKCS#12 file using pk12util then extract them using openssl pkcs12. rob > > On Wed, Feb 3, 2016 at 3:12 AM, Martin Kosek wrote: >> On 02/03/2016 12:42 AM, Christopher Young wrote: >>> I've been doing some reading and perhaps I'm confusing myself, but I >>> couldn't find any definitive guide on how to go about doing what I >>> think it a pretty simple thing. >>> >>> My ipa-client installs appear to generate a new TLS/SSL/PKI cert for >>> each host when they are registered. I'd like to utilize that >>> certificate with Apache/tomcat/etc.. I'm aware of how to obtain the >>> certificate itself, however I'm not clear on how to obtain the private >>> key (in a format that I can use as well) that was used to generate the >>> certificate. >>> >>> Would someone kindly point me in the right direction or ideally just >>> educate me on the command/options needed to do this. In particular, >>> I'm looking to create pem files for both the key and cert for use with >>> Apache, but it would be useful to understand how to do it for other >>> stores as well. (Hint: this would be great to just have in a document >>> that makes it clear). :) >> >> Hi Chris, >> >> I do not think it is a good idea to do what you are doing :-) The host >> certificate does not need to be the same as Web certificate. From FreeIPA 4.1 >> (IIRC), it is not even requested by default on all clients. >> >> I would rather recommend generating a separate certificate for the Web UI, we >> have some walkthrough here: >> >> http://www.freeipa.org/page/PKI#Requesting_a_new_certificate >> >>> Thanks again to the freeipa team. I love this product. >> >> And I love to hear notes from the community like this, very rewarding! > From rcritten at redhat.com Thu Feb 4 10:16:14 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 4 Feb 2016 11:16:14 +0100 Subject: [Freeipa-users] Apple OpenDirectory Integration In-Reply-To: <673C3518-D3FA-47C2-9FEC-E1A6F986F8FF@me.com> References: <673C3518-D3FA-47C2-9FEC-E1A6F986F8FF@me.com> Message-ID: <56B324EE.4020403@redhat.com> "R?zvan Corneliu C.R. VILT" wrote: > Hi Guys, > > I've done a small scale demo of using FreeIPA instead of an Open > Directory Server to serve Apple OS X clients. This is based on my > experiences from one year ago (Ticket #4813). I've also attached some > screenshots. This is very cool and excellent work! Currently the FreeIPA wiki points to http://linsec.ca/Using_FreeIPA_for_User_Authentication#Mac_OS_X_10.7.2F10.8 for instructions on configuring MacOS. Are these sufficient to match what you've accomplished? > *Here's what works:* > > * Host sees the IPA Server > * Host is able to register to the IPA server > * Host creates a computer account (needs a bit of help here) > * Host sets it's own random password (including kerberosPrincipalKey > and kerberosExtraData) > * Host can see the users and other computers in the LDAP > * Host can use TLS registration with FreeIPA's own root certificate as > found in cn=CACert,cn=ipa,cn=etc > * Host can use just Kerberos for authentication and doesn't need an > Apple Password Server > > > *Here's what needs to be done to get there:* > > * Create a cn=config,$baseDN entry (attached example ldif). This can > be created automatically based on a template. > * Create and ACI that gives anonymous read access to cn=config,$baseDN > (SNIP #3) > * Modify an existing ACI to give altSecurityIdentities and description > to anonymous/public consumption (SNIP #4) > * Extend the schema to include apple-configuration (SNIP #1) > * Extend the schema to include apple-user (should be renamed to > apple-account since it applies also to hosts) (SNIP #2) > * Add PLAIN to the supported SASL mechanisms (I don't know why it's > missing anyway because it's restricted to TLS by default). For me, > without further investigation of the reasons, I had to also disable > CRAM-MD5 and DIGEST-MD5 on the 389 DS. > * Make sure (if you upgraded from a v3) that you have OCSP and/or CRL > working > * Add an _ldap._tcp entry in avahi and/or server the LDAP server via > DHCP and/or serve the search domain via DHCP and make the DNS-SD > service entries for it. > > > *Here's what's missing from FreeIPA:* > > A 389 Directory Server plugin that generates altSecurityIdentities and > AuthAuthority values automatically for an objectClass=apple-account. > This would automatically present the following entries (user admin used > as an example): > -- > altSecurityIdentitites: Kerberos:admin at EXAMPLE.ORG > AuthAuthority: ;Kerberosv5;;admin at EXAMPLE.ORG > ;EXAMPLE.ORG ; > -- > AuthAuthority is interesting because it supports not only basic LDAP > authentication, but also Kerberos, Netlogon and Apple Password Server > and you can specify multiple authentication authorities (including an > Active Directory). Is this generally static data set once during user-creation? If so them the framework can manage it w/o requiring a 389-ds plugin which means it would be far easier to do. > A better way to specify homes for users. Not everyone uses automount and > automount maps (although OS X can use them). We need to be able to > specify not the assumably mounted home directory, but the protocol (afp, > nfs, cifs, etc.), server and share/directory. Furthermore, most Mac > Admins will have a heart-attack if they see an auto-mounted > /home/$username instead of the usual /Users/$username. Not sure what you mean. Do you mean having a way to map it by client type? You may be able to do it by having client-type-based automount maps. > *Here's what's missing from OS X:* > A way to request OS X to do GSS-TSIG registration to the DNS. We may > have an MCX method to do that, but I haven't investigated. NSUpdate is > available and has support for gss-tsig. I think that for Active > Directory it does this automatically, and if so, we should be able to > reproduce it. > > A way to specify that the fqdn argument should actually be an FQDN. We > might have to write a 389 DS plugin to take the CN without the final "$" > and add the domain name after it. > > SUDO Map support. Currently, the only way to specify if an account has > sudo rights is to make it an admin. This makes it clear that without > Password Server support (partly implemented in the LPWS project), the > usage scenarios are limited to normal users and SSO to servers. OTOH, OS > X only knows admin and non-admin accounts, so it's not that bad. > > *Steps to produce my demo install before the patches below:* > ipa-server-install -r EXAMPLE.ORG -n example.org > -p deadbeef -a deadbeef -P > deadbeef --hostname=ipa.example.org > --ip-address=172.16.23.138 --ssh-trust-dns -U --setup-dns --no-forwarders > > Is anyone from Red Hat willing to pick this up? It would be a nice > addition. If so, I am offering to do the testing and fine-tuning for all > post-Tiger releases. I can also share virtual machines for server and > client configuration. I'd open one or more RFE tickets on https://fedorahosted.org/freeipa/newticket > The Apple schemas are included in Apple's GPL code-drops for OpenLDAP if > anyone is wondering about licensing. We don't need the full schemas > because we can map most stuff to our own schema and it works brilliantly. It is probably best to stick with the Apple schema otherwise there could be pain later if something changes, requiring additional mapping. rob From razvan.vilt at me.com Thu Feb 4 12:03:13 2016 From: razvan.vilt at me.com (=?utf-8?Q?=22R=C4=83zvan_Corneliu_C=2ER=2E_VILT=22?=) Date: Thu, 04 Feb 2016 14:03:13 +0200 Subject: [Freeipa-users] Apple OpenDirectory Integration In-Reply-To: <56B324EE.4020403@redhat.com> References: <673C3518-D3FA-47C2-9FEC-E1A6F986F8FF@me.com> <56B324EE.4020403@redhat.com> Message-ID: <8492664F-8AC0-40EA-B749-F01E4FA2DC5A@me.com> > On 4 feb. 2016, at 12:16, Rob Crittenden wrote: > This is very cool and excellent work! Thanks. I've done most of the R&D 1 year ago for a client that has a medium Mac-only network. Since a year passed, I wanted to share my results in order make sure that the information won't be lost or obsoleted. Furthermore, FreeIPA is a wonderful piece of software that is making the life of admins around the world easier and due to BYOD policies Macs should get more love. > Currently the FreeIPA wiki points to http://linsec.ca/Using_FreeIPA_for_User_Authentication#Mac_OS_X_10.7.2F10.8 for instructions on configuring MacOS. Are these sufficient to match what you've accomplished? Nope, what I've accomplished is different. I've managed to get OS X clients to register to the IPA server like it's an Open Directory Server. No command line interaction on the clients at all. No need for manual keytabs or manual file editing or PAM modules or Apple scripts. Just click join in the System Preferences -> Users Preferences Pane. >> A 389 Directory Server plugin that generates altSecurityIdentities and >> AuthAuthority values automatically for an objectClass=apple-account. >> This would automatically present the following entries (user admin used >> as an example): >> -- >> altSecurityIdentitites: Kerberos:admin at EXAMPLE.ORG >> AuthAuthority: ;Kerberosv5;;admin at EXAMPLE.ORG >> ;EXAMPLE.ORG ; >> -- >> > > Is this generally static data set once during user-creation? If so them the framework can manage it w/o requiring a 389-ds plugin which means it would be far easier to do. It's static data. It's a concatenation of multiple strings: a hard-coded one, the uid and the realm. It only changes if you rename the user account. It is used to route the authn phase to the Kerberos account (no PAM configuration!!!). > >> A better way to specify homes for users. Not everyone uses automount and >> automount maps (although OS X can use them). We need to be able to >> specify not the assumably mounted home directory, but the protocol (afp, >> nfs, cifs, etc.), server and share/directory. Furthermore, most Mac >> Admins will have a heart-attack if they see an auto-mounted >> /home/$username instead of the usual /Users/$username. > > Not sure what you mean. Do you mean having a way to map it by client type? You may be able to do it by having client-type-based automount maps. OK. So on Linux you do an automount map for the file server with the homes and state that the user home directory is in /home/$userName On Windows, you give the home folder as \\server\share\folder, but assume that the protocol is SMB/CIFS. On Mac OS X, you give the protocol, the server and the share\folder. You could use automount, but I've never seen any OS X admin do that. Mainly because you loose the roaming ability (they call it file synchronization). Mac OS X can use roaming profiles just like Windows. They don't have to be mounted except at logon time which is important for road-warriors. Since most Macs are laptops, the road-warrior scenario is assumed. Otherwise, you just get local homes. >> Is anyone from Red Hat willing to pick this up? It would be a nice >> addition. If so, I am offering to do the testing and fine-tuning for all >> post-Tiger releases. I can also share virtual machines for server and >> client configuration. > > I'd open one or more RFE tickets on https://fedorahosted.org/freeipa/newticket One was already opened (https://fedorahosted.org/freeipa/ticket/4813) and I'm in CC. Since nothing happened for 1 year after my offer to document it, I've decided to start this thread. >> The Apple schemas are included in Apple's GPL code-drops for OpenLDAP if >> anyone is wondering about licensing. We don't need the full schemas >> because we can map most stuff to our own schema and it works brilliantly. > > It is probably best to stick with the Apple schema otherwise there could be pain later if something changes, requiring additional mapping. I wouldn't encourage it for two reasons: 1) The Apple schema is designed to be remapped to any other schema. That's the point of cn=config. That's what I did. It describes the attribute mappings to internal data structures. I've identified a minimal number of apple-schema items that have no direct mapping to freeIPA datastructures and documented them in the two schema expansions in the email. 2) Using the Apple schema without remapping would duplicate a most of the data and would make account maintenance and LDAP Browsing more difficult in the future. Since Apple is flexible about the schema, why shouldn't we use that? From abokovoy at redhat.com Thu Feb 4 12:20:26 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 4 Feb 2016 14:20:26 +0200 Subject: [Freeipa-users] Apple OpenDirectory Integration In-Reply-To: <8492664F-8AC0-40EA-B749-F01E4FA2DC5A@me.com> References: <673C3518-D3FA-47C2-9FEC-E1A6F986F8FF@me.com> <56B324EE.4020403@redhat.com> <8492664F-8AC0-40EA-B749-F01E4FA2DC5A@me.com> Message-ID: <20160204122026.GY22179@redhat.com> On Thu, 04 Feb 2016, "R?zvan Corneliu C.R. VILT" wrote: > >> On 4 feb. 2016, at 12:16, Rob Crittenden wrote: >> This is very cool and excellent work! > >Thanks. I've done most of the R&D 1 year ago for a client that has a >medium Mac-only network. Since a year passed, I wanted to share my >results in order make sure that the information won't be lost or >obsoleted. Furthermore, FreeIPA is a wonderful piece of software that >is making the life of admins around the world easier and due to BYOD >policies Macs should get more love. > >> Currently the FreeIPA wiki points to >> http://linsec.ca/Using_FreeIPA_for_User_Authentication#Mac_OS_X_10.7.2F10.8 >> for instructions on configuring MacOS. Are these sufficient to match >> what you've accomplished? > >Nope, what I've accomplished is different. I've managed to get OS X >clients to register to the IPA server like it's an Open Directory >Server. No command line interaction on the clients at all. No need for >manual keytabs or manual file editing or PAM modules or Apple scripts. >Just click join in the System Preferences -> Users Preferences Pane. > >>> A 389 Directory Server plugin that generates altSecurityIdentities and >>> AuthAuthority values automatically for an objectClass=apple-account. >>> This would automatically present the following entries (user admin used >>> as an example): >>> -- >>> altSecurityIdentitites: Kerberos:admin at EXAMPLE.ORG >>> AuthAuthority: ;Kerberosv5;;admin at EXAMPLE.ORG >>> ;EXAMPLE.ORG ; >>> -- >>> >> >> Is this generally static data set once during user-creation? If so >> them the framework can manage it w/o requiring a 389-ds plugin which >> means it would be far easier to do. > >It's static data. It's a concatenation of multiple strings: a >hard-coded one, the uid and the realm. It only changes if you rename >the user account. It is used to route the authn phase to the Kerberos >account (no PAM configuration!!!). I wonder if we should use CoS plugin to get this data added to user entries instead of storing it in every single user's LDAP entry -- the only thing that is different is uid but the rest is the same, right? >> >>> A better way to specify homes for users. Not everyone uses automount and >>> automount maps (although OS X can use them). We need to be able to >>> specify not the assumably mounted home directory, but the protocol (afp, >>> nfs, cifs, etc.), server and share/directory. Furthermore, most Mac >>> Admins will have a heart-attack if they see an auto-mounted >>> /home/$username instead of the usual /Users/$username. >> >> Not sure what you mean. Do you mean having a way to map it by client >> type? You may be able to do it by having client-type-based automount >> maps. > >OK. So on Linux you do an automount map for the file server with the >homes and state that the user home directory is in /home/$userName > >On Windows, you give the home folder as \\server\share\folder, but >assume that the protocol is SMB/CIFS. > >On Mac OS X, you give the protocol, the server and the share\folder. >You could use automount, but I've never seen any OS X admin do that. >Mainly because you loose the roaming ability (they call it file >synchronization). Mac OS X can use roaming profiles just like Windows. >They don't have to be mounted except at logon time which is important >for road-warriors. Since most Macs are laptops, the road-warrior >scenario is assumed. Otherwise, you just get local homes. If you don't provide any share details, what happens? Will Mac OS X would fill-in the defaults based on the user name? >> I'd open one or more RFE tickets on https://fedorahosted.org/freeipa/newticket > >One was already opened (https://fedorahosted.org/freeipa/ticket/4813) >and I'm in CC. Since nothing happened for 1 year after my offer to >document it, I've decided to start this thread. It mostly boils down to IPA developers not really having access to Mac OS X devices. And load of other tickets to solve, of course. >>> The Apple schemas are included in Apple's GPL code-drops for OpenLDAP if >>> anyone is wondering about licensing. We don't need the full schemas >>> because we can map most stuff to our own schema and it works brilliantly. >> >> It is probably best to stick with the Apple schema otherwise there >> could be pain later if something changes, requiring additional >> mapping. > >I wouldn't encourage it for two reasons: >1) The Apple schema is designed to be remapped to any other schema. >That's the point of cn=config. That's what I did. It describes the >attribute mappings to internal data structures. I've identified a >minimal number of apple-schema items that have no direct mapping to >freeIPA datastructures and documented them in the two schema expansions >in the email. >2) Using the Apple schema without remapping would duplicate a most of >the data and would make account maintenance and LDAP Browsing more >difficult in the future. Since Apple is flexible about the schema, why >shouldn't we use that? Good points. Remapping is better from our perspective too. -- / Alexander Bokovoy From razvan.vilt at me.com Thu Feb 4 12:22:55 2016 From: razvan.vilt at me.com (=?utf-8?Q?=22R=C4=83zvan_Corneliu_C=2ER=2E_VILT=22?=) Date: Thu, 04 Feb 2016 14:22:55 +0200 Subject: [Freeipa-users] Apple OpenDirectory Integration In-Reply-To: <8492664F-8AC0-40EA-B749-F01E4FA2DC5A@me.com> References: <673C3518-D3FA-47C2-9FEC-E1A6F986F8FF@me.com> <56B324EE.4020403@redhat.com> <8492664F-8AC0-40EA-B749-F01E4FA2DC5A@me.com> Message-ID: <0548B96A-D6E0-4C36-9A3D-9F4E09278D00@me.com> >> It is probably best to stick with the Apple schema otherwise there could be pain later if something changes, requiring additional mapping. > > I wouldn't encourage it for two reasons: > 1) The Apple schema is designed to be remapped to any other schema. That's the point of cn=config. That's what I did. It describes the attribute mappings to internal data structures. I've identified a minimal number of apple-schema items that have no direct mapping to freeIPA datastructures and documented them in the two schema expansions in the email. > 2) Using the Apple schema without remapping would duplicate a most of the data and would make account maintenance and LDAP Browsing more difficult in the future. Since Apple is flexible about the schema, why shouldn't we use that? If you open up the ldif file from the first email and base64 decode the entries you will see clear configuration directives such as below. These mean that you don't need to stick with Apple's schema and neither does Apple (for forward and backward compatibility): OD Policy: ========== Denied SASL Methods DIGEST-MD5 CRAM-MD5 Configured Security Level Advisory Client Caching Binding Required Man In The Middle No ClearText Authentications Packet Encryption Packet Signing Directory Binding LDAP Servers: ============= Here you list the replicas, read-only or read-write. For registration a r/w replica will be used, preferably the primary master. IPaddresses 172.16.23.138 PrimaryMaster ipa.example.org ReplicaName Master Replicas Kerberos KRB5.conf: =================== Since you can register to multiple realms at one on a Mac, you need to modify (and not replace) the krb5.conf file so they are including the information as opposed to the file. edu.mit.kerberos domain_realm .example.org EXAMPLE.ORG example.org EXAMPLE.ORG libdefaults default_realm EXAMPLE.ORG realms EXAMPLE.ORG KADM_List ipa.example.org 172.16.23.138 KDC_List ipa.example.org 172.16.23.138 OD Config snipplets: ==================== Server information used for LDAP binding. Delay Rebind Try in seconds 0 Enable Use Map Search Base cn=config,dc=example,dc=org OpenClose Timeout in seconds 15 Port Number 389 SSL Search Timeout in seconds 120 Server 172.16.23.138 Server Mappings Template Name FreeIPA Server Template Search Base Suffix dc=example,dc=org Template Version 1.0 UI Name Example.ORG OD Config Attribute Type Maps snipplet: ======================================= Open Directory also includes them, but they map to different attributes. Attribute Type Map Native Map fqdn Standard Name dsAttrTypeStandard:RecordName Native Map ipaUniqueId Standard Name dsAttrTypeStandard:GeneratedUID Native Map sambaSID Standard Name dsAttrTypeStandard:SMBSID Native Map Group Object Classes OR Object Classes ipaHost krbPrincipal krbPrincipalAux apple-user ieee802Device Search Base cn=computers,cn=accounts,dc=example,dc=org Standard Name dsRecTypeStandard:Computers From jhrozek at redhat.com Thu Feb 4 13:17:05 2016 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 4 Feb 2016 14:17:05 +0100 Subject: [Freeipa-users] Client Host isn't picking up the idduseroverrides In-Reply-To: <0137003026EBE54FBEC540C5600C03C433346B@PMC-EXMBX02.petermac.org.au> References: <0137003026EBE54FBEC540C5600C03C433346B@PMC-EXMBX02.petermac.org.au> Message-ID: <20160204131705.GL3654@hendrix.brq.redhat.com> On Wed, Feb 03, 2016 at 11:10:50PM +0000, Simpson Lachlan wrote: > When my users log into the IPA server, the id user over rides work. > > But they don't when we log into a client host? > > What are we doing wrong? > > The overrides are in the "Default Trust View" so should be applied to all hosts. > > We are trying to find *why* and *where* this is failing, but without much success. > > >From what I've read, this should be controlled by the sssd service on the host, but if we run sssd -I to watch what happens during a failed login or a login that doesn't successfully get the id user over ride applied, we don't see any errors or log entries that would indicate why. > > We see this: > > [root at vmts-linux1 ~]# /usr/sbin/sssd -i > [sssd[be[unix.example.org]]] [krb5_auth_store_creds] (0x0010): unsupported PAM command [249]. > [sssd[be[unix.example.org]]] [krb5_auth_store_creds] (0x0010): password not available, offline auth may not work. This is unrelated. > > But there isn't anything in any logs that would indicate there's a communication happening between the host and the server that we can see. > > We have tried sss_cache -E on the host to clear cache, but we still aren't getting the over rides. If you changed the client override to a non-default one, then you would have to restart the client. Can you enable sssd debugging as per: https://fedorahosted.org/sssd/wiki/Troubleshooting and either send it to the list or if there are confidential information, send it to me directly? (Just note we're attending a conference now, so answers might lag..) From jhrozek at redhat.com Thu Feb 4 13:19:03 2016 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 4 Feb 2016 14:19:03 +0100 Subject: [Freeipa-users] Freeipa 4.1.4 Very slow sudo access waiting for eventpoll In-Reply-To: References: Message-ID: <20160204131903.GM3654@hendrix.brq.redhat.com> On Wed, Feb 03, 2016 at 11:20:01PM +0000, Nathan Peters wrote: > We have a FreeIPA 4.1.4 domain running on CentOS 7.1. > > We have noticed that from certain machines, sudo is instant, and from others, it takes about 5 seconds. > > All machines involved can resolve each other through DNS (both forward and reverse lookups). > > Running an strace reveals that sssd_pam is hanging for 4.3 seconds waiting for /proc/freeipaproccessid/fd3 which maps to [eventpoll] > > > 0.000044 epoll_wait(3, {{EPOLLIN, {u32=6976896, u64=6976896}}}, 1, 4896) = 1 > > 4.373816 read(9, "l\2\1\1\206\0\0\0\10\0\0\0\25\0\0\0\5\1u\0\10\0\0\0\10\1g\0\7ua("..., 2048) = 174 > > lrwx------ 1 root root 64 Feb 3 19:04 3 -> [eventpoll] > > There are no nfs mounts on this system, so I can't see why this system call would take so long. > > This is happening on 3 of our machines right now, but others can login just fine. The pam/authconfig setup is identical on all of them. > > Any ideas why sssd would be timing out trying to get [eventpoll] out of the /proc directory? I guess what you're seeing is the tevent loop sssd uses waiting for input. I would recommend to enable sssd logs and take a look there. Feel free to post the logs on the list so we can help you with debugging. I would guess that it takes a long time to resolve some large group, but without logs it's hard to tell. This is the sssd upstream troubleshooting guide: https://fedorahosted.org/sssd/wiki/Troubleshooting From robert.vanveelen at gmail.com Thu Feb 4 13:27:30 2016 From: robert.vanveelen at gmail.com (Robert van Veelen) Date: Thu, 04 Feb 2016 13:27:30 +0000 Subject: [Freeipa-users] ca install fails upgrading to 4.2.0 In-Reply-To: <56B090F8.9000403@redhat.com> References: <56B06CE8.2080000@redhat.com> <56B090F8.9000403@redhat.com> Message-ID: I reran the replica-install and interrupted the script to set debug=1. The debug log didn't change very much at startup since the failure seems to occur already in the pre-start selftest. So it is still the same "java.lang.Exception: SystemCertsVerification: system certs verification failure" [04/Feb/2016:13:19:45][localhost-startStop-1]: SignedAuditEventFactory: create() message=[AuditEvent=CIMC_CERT_VERIFICATION][SubjectID=$System$][Outcome=Success][CertNickName=auditSigningCert cert-pki-ca] CIMC certificate verification java.lang.Exception: SystemCertsVerification: system certs verification failure at com.netscape.cms.selftests.common.SystemCertsVerification.runSelfTest(SystemCertsVerification.java:198) at com.netscape.cmscore.selftests.SelfTestSubsystem.runSelfTestsAtStartup(SelfTestSubsystem.java:861) at com.netscape.cmscore.selftests.SelfTestSubsystem.startup(SelfTestSubsystem.java:1797) at com.netscape.cmscore.apps.CMSEngine.startupSubsystems(CMSEngine.java:1701) at com.netscape.cmscore.apps.CMSEngine.startup(CMSEngine.java:1148) at com.netscape.certsrv.apps.CMS.startup(CMS.java:200) at com.netscape.certsrv.apps.CMS.start(CMS.java:1602) at com.netscape.cms.servlet.base.CMSStartServlet.init(CMSStartServlet.java:114) at javax.servlet.GenericServlet.init(GenericServlet.java:158) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:277) at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:274) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAsPrivileged(Subject.java:549) at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:309) at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:169) at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:123) at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1272) at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1197) at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1087) at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5210) at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5493) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901) at org.apache.catalina.core.ContainerBase.access$000(ContainerBase.java:133) at org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:156) at org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:145) at java.security.AccessController.doPrivileged(Native Method) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:875) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:632) at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:672) at org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1862) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) [04/Feb/2016:13:19:45][localhost-startStop-1]: SignedAuditEventFactory: create() message=[AuditEvent=SELFTESTS_EXECUTION][SubjectID=$System$][Outcome=Failure] self tests execution (see selftests.log for details) Where can I manually check the certificates that were imported from the existing master? -rob On Tue, 2 Feb 2016 at 11:20 Martin Kosek wrote: > On 02/02/2016 11:51 AM, Robert van Veelen wrote: > > Unfortunately not. I saw that thread and grabbed the patch and updated > spec > > to give it a try. Same issue. > > cheers, > > Ah, pity. Let me CC Endi in this thread then. I suspect he will be > interested > in the same log files as in the referred thread. > > > On Tue, 2 Feb 2016 at 08:46 Martin Kosek wrote: > > > >> On 02/02/2016 02:18 AM, Robert van Veelen wrote: > >>> Hi, > >>> I'm trying to create an ipa replica from > >>> ipa-server-3.0.0-47/pki-ca-9.0.3-45 to > >> ipa-server-4.2.0-15/pki-ca-10.2.5-6 > >>> and cannot get the install to complete. The CS is configured as a sub > to > >> an > >>> external CA. I keep getting the same error when running the > >>> replica-install. Digging into pki-ca's debug log, I find the following > >>> errors: > >>> > >>> java.lang.Exception: SystemCertsVerification: system certs > verification > >>> failure > >>> & > >>> CertUtils: verifySystemCertByNickname() failed: caSigningCert > >> cert-pki-ca > >>> > >>> I've tried regenerating the source cacert.p12, upgrading pki-ca to > >> latest, > >>> etc. It just seems like the new replica is unable to verify the certs > >> while > >>> running selftests. any good tips for a next step to work out whats > going > >> on? > >>> > >>> Thanks, > >>> > >>> -rob > >> > >> Can this be the same problem as answered by Endi here: > >> > https://www.redhat.com/archives/freeipa-users/2016-January/msg00564.html > >> ? > >> > >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan.vilt at me.com Thu Feb 4 13:46:34 2016 From: razvan.vilt at me.com (=?utf-8?Q?=22R=C4=83zvan_Corneliu_C=2ER=2E_VILT=22?=) Date: Thu, 04 Feb 2016 15:46:34 +0200 Subject: [Freeipa-users] Apple OpenDirectory Integration In-Reply-To: <20160204122026.GY22179@redhat.com> References: <673C3518-D3FA-47C2-9FEC-E1A6F986F8FF@me.com> <56B324EE.4020403@redhat.com> <8492664F-8AC0-40EA-B749-F01E4FA2DC5A@me.com> <20160204122026.GY22179@redhat.com> Message-ID: <59272774-C250-4EFD-B9E0-DF941840C659@me.com> >> It's static data. It's a concatenation of multiple strings: a >> hard-coded one, the uid and the realm. It only changes if you rename >> the user account. It is used to route the authn phase to the Kerberos >> account (no PAM configuration!!!). > I wonder if we should use CoS plugin to get this data added to user > entries instead of storing it in every single user's LDAP entry -- the > only thing that is different is uid but the rest is the same, right? Right. At least for single realms with no trust domains. If you have an identity from another realm, you need to use the KRB5 principal from that realm. So instead of mapping to the UID, we should map to the krbPrincipal. The format for altSecurityIdentities is: ======================================= "Kerberos:" + $krbPrincipal Or for certificate logon: "X509:" + "CN=" + $issuerRDN + "CN=" + $subject. Such as: "X509:CN=Apple Root CA,OU=Apple Certification Authority,O=Apple Inc.,C=USCN=com.apple.idms.appleid.prd.deadbeefdeadbeefdeadbeefdeadbeef" It's identical to the altSecurityIdentities from MSDN and was adopted by Apple from Microsoft. See https://msdn.microsoft.com/en-us/library/cc220106.aspx In theory it can also be used for SC Certificate logons (see above example). It is also used by iCloud for certificate logons. The format for authAuthority is: ============================================= Kerberos -------- Minimal Kerberos: ";Kerberosv5;;" + $krbPrincipal + ";" + $realm + ";" Fully compliant Kerberos: ";Kerberosv5;" + "0x"$GUID_HEX + ";" + $krbPrincipal + ";" + $realm + ";" + "Realm Public Key" Documented on: https://developer.apple.com/library/mac/documentation/Networking/Conceptual/Open_Directory/openDirectoryConcepts/openDirectoryConcepts.html#//apple_ref/doc/uid/TP40000917-CH3-68599 Basic Authentication -------------------- Of no interest, just crypt(). Documented on: https://developer.apple.com/library/mac/documentation/Networking/Conceptual/Open_Directory/openDirectoryConcepts/openDirectoryConcepts.html#//apple_ref/doc/uid/TP40000917-CH3-68270 Apple Password Server Authentication: ------------------------------------- ;ApplePasswordServer;0xfc00000000001e291a400254ba69508,1024 65537 100000735360000022652669667510124737971525265977003458292838259662475941942339637701783031842665637489899899968013535474647377427038990743911664412758698759306606987798849786426049586039725915353359580583450027978985802381494661566820916379229460639580871881869418576860074704243214464804408968770344748232621 root at ipa.example.com:172.23.36.138 Documented on: https://developer.apple.com/library/mac/documentation/Networking/Conceptual/Open_Directory/openDirectoryConcepts/openDirectoryConcepts.html#//apple_ref/doc/uid/TP40000917-CH3-68312 Partly implemented in https://code.google.com/archive/p/lpws but without an IPA Bridge. Shadow Hash Authentication (used by local accounts): ---------------------------------------------------- ;ShadowHash;HASHLIST: Documented on: https://developer.apple.com/library/mac/documentation/Networking/Conceptual/Open_Directory/openDirectoryConcepts/openDirectoryConcepts.html#//apple_ref/doc/uid/TP40000917-CH3-68474 Local Cached User Authentication (used by road-warrior scenarios on the local systems): --------------------------------------------------------------------------------------- Documented on: https://developer.apple.com/library/mac/documentation/Networking/Conceptual/Open_Directory/openDirectoryConcepts/openDirectoryConcepts.html#//apple_ref/doc/uid/TP40000917-CH3-68528 Netlogon Authentication (used by Active Directory) -------------------------------------------------- ;Netlogon;razvan.vilt;MYDOMAIN iCloud Authentication (obvious) ------------------------------- ;AppleID;razvan.vilt at me.com Disabled Authentication (this needs attention) ---------------------------------------------- Basically put ";DisabledUser;;" in front of the previous authentication method. >> OK. So on Linux you do an automount map for the file server with the >> homes and state that the user home directory is in /home/$userName >> >> On Windows, you give the home folder as \\server\share\folder, but >> assume that the protocol is SMB/CIFS. >> >> On Mac OS X, you give the protocol, the server and the share\folder. >> You could use automount, but I've never seen any OS X admin do that. >> Mainly because you loose the roaming ability (they call it file >> synchronization). Mac OS X can use roaming profiles just like Windows. >> They don't have to be mounted except at logon time which is important >> for road-warriors. Since most Macs are laptops, the road-warrior >> scenario is assumed. Otherwise, you just get local homes. > If you don't provide any share details, what happens? Will Mac OS X > would fill-in the defaults based on the user name? It would create a local profile in /Users/$userName. Which in reality is what most Mac admins do anyway. Roaming profiles are not used very much. If you bind to Active Directory on a Mac, you get the following Attributes: NFSHomeDirectory: "/Users/razvan.vilt" OriginalHomeDirectory: "smb://myFileServer/usersShare/razvan.vilt/" The attributes are made by the Active Directory plugin automatically from "\\myFileServer\usersShare\razvan.vilt". > >>> I'd open one or more RFE tickets on https://fedorahosted.org/freeipa/newticket >> >> One was already opened (https://fedorahosted.org/freeipa/ticket/4813) >> and I'm in CC. Since nothing happened for 1 year after my offer to >> document it, I've decided to start this thread. > It mostly boils down to IPA developers not really having access to Mac > OS X devices. And load of other tickets to solve, of course. I can provide VMs and/or access to VMs. FreeIPA is Python, 389 DS and 389 plugins. It's overkill for me to go under the hood. From ponky at shardi.fi Wed Feb 3 17:02:47 2016 From: ponky at shardi.fi (Ossi Ahosalmi) Date: Wed, 3 Feb 2016 19:02:47 +0200 Subject: [Freeipa-users] Using external certificate in IPA 4.1 Message-ID: <56B232B7.60306@shardi.fi> I'm trying to use our organizations wildcard certificate in IPA. Certificate is signed by a trusted CA. Running: ipa-server-certinstall -w -d with next combinations: - separate .key, .crt and ca chain, all in PEM format - .crt and ca bundled into one file, .key as a separate file - everything bundled together into one .p12 pkcs12 file I always end up with this error: "The full certificate chain is not present in ." My CA file contains the whole chain and works in all other programs, just not in IPA. From rob.verduijn at gmail.com Thu Feb 4 14:52:25 2016 From: rob.verduijn at gmail.com (Rob Verduijn) Date: Thu, 4 Feb 2016 15:52:25 +0100 Subject: [Freeipa-users] what is the sudo rule runasuser local user account Message-ID: Hello, I've noticed that the sudorule-add-runasuser no longer has en --external option What is the current method to add a local service account to a sud rule list so that users may run sudo as that service account (ie apache or jboss) Cheers Rob Verudijn From prasun.gera at gmail.com Thu Feb 4 15:19:16 2016 From: prasun.gera at gmail.com (Prasun Gera) Date: Thu, 4 Feb 2016 10:19:16 -0500 Subject: [Freeipa-users] client/authentication inside a docker container Message-ID: I am trying to set up a docker image with a specific development environment. We use idm 4.2 for authentication, and non-kerberized nfs (including home) for data storage on the hosts. The goal is to run the docker container such that when the user calls docker run, it just drops into a shell with the container's environment, but everything else looks largely the same. i.e. The user gets the same uid:gid and sees the same directories and permissions as the host. I'm trying to figure out what the best way of mapping user ids is. I've looked at the following options: - ipa-client-install inside the container. This has a few problems. One is hostname and DNS. Container needs an fqdn for this to work, and the dns has to resolve this hostname. We are not using IPA's DNS. So this whole approach looks very kludgy. Besides, I'm not sure what the right way of handling these ephemeral host names is. Ideally, they should be un-enrolled when the container is destroyed, - Use ipa's fake NIS. This works, and is very simple to setup, but I think we want to phase out NIS. If we start using it inside docker, it will never die - Don't do any domain authentication. Just ask the user to create a user with the same uid:gid as the host so that they can r/w to their own directories. The ipa version is 4.2 running on RHEL 7. The container image will be based on ubuntu trusty. Hosts are a mix of different OSes. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Thu Feb 4 15:45:33 2016 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 4 Feb 2016 16:45:33 +0100 Subject: [Freeipa-users] what is the sudo rule runasuser local user account In-Reply-To: References: Message-ID: <20160204154533.GQ3654@hendrix.brq.redhat.com> On Thu, Feb 04, 2016 at 03:52:25PM +0100, Rob Verduijn wrote: > Hello, > > I've noticed that the sudorule-add-runasuser no longer has en --external option > > What is the current method to add a local service account to a sud > rule list so that users may run sudo as that service account (ie > apache or jboss) > > Cheers > Rob Verudijn I know I'm not answering your question but how did you configure the client side earlier? Did you use the native/legacy sudo ldap driver? The reason I'm asking this is that sssd only supports users it handles, so in the IPA case it only supports IPA users anyway.. From rob.verduijn at gmail.com Thu Feb 4 15:54:18 2016 From: rob.verduijn at gmail.com (Rob Verduijn) Date: Thu, 4 Feb 2016 16:54:18 +0100 Subject: [Freeipa-users] what is the sudo rule runasuser local user account In-Reply-To: <20160204154533.GQ3654@hendrix.brq.redhat.com> References: <20160204154533.GQ3654@hendrix.brq.redhat.com> Message-ID: On Centos7.2 all patches applied I used the command: ipa-client-install --enable-dns-updates Rob 2016-02-04 16:45 GMT+01:00 Jakub Hrozek : > On Thu, Feb 04, 2016 at 03:52:25PM +0100, Rob Verduijn wrote: >> Hello, >> >> I've noticed that the sudorule-add-runasuser no longer has en --external option >> >> What is the current method to add a local service account to a sud >> rule list so that users may run sudo as that service account (ie >> apache or jboss) >> >> Cheers >> Rob Verudijn > > I know I'm not answering your question but how did you configure the > client side earlier? Did you use the native/legacy sudo ldap driver? > > The reason I'm asking this is that sssd only supports users it handles, > so in the IPA case it only supports IPA users anyway.. > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project From rob.verduijn at gmail.com Thu Feb 4 15:55:42 2016 From: rob.verduijn at gmail.com (Rob Verduijn) Date: Thu, 4 Feb 2016 16:55:42 +0100 Subject: [Freeipa-users] what is the sudo rule runasuser local user account In-Reply-To: <20160204154533.GQ3654@hendrix.brq.redhat.com> References: <20160204154533.GQ3654@hendrix.brq.redhat.com> Message-ID: On Centos7.2 all patches applied I used the command: ipa-client-install --enable-dns-updates That configures the client for sudo as well if I'm not mistaken. Rob Verduijn 2016-02-04 16:45 GMT+01:00 Jakub Hrozek : > On Thu, Feb 04, 2016 at 03:52:25PM +0100, Rob Verduijn wrote: >> Hello, >> >> I've noticed that the sudorule-add-runasuser no longer has en --external option >> >> What is the current method to add a local service account to a sud >> rule list so that users may run sudo as that service account (ie >> apache or jboss) >> >> Cheers >> Rob Verudijn > > I know I'm not answering your question but how did you configure the > client side earlier? Did you use the native/legacy sudo ldap driver? > > The reason I'm asking this is that sssd only supports users it handles, > so in the IPA case it only supports IPA users anyway.. > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project From jpazdziora at redhat.com Thu Feb 4 15:56:40 2016 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Thu, 4 Feb 2016 16:56:40 +0100 Subject: [Freeipa-users] client/authentication inside a docker container In-Reply-To: References: Message-ID: <20160204155640.GF16558@redhat.com> On Thu, Feb 04, 2016 at 10:19:16AM -0500, Prasun Gera wrote: > I am trying to set up a docker image with a specific development > environment. We use idm 4.2 for authentication, and non-kerberized nfs > (including home) for data storage on the hosts. Are the hosts IPA-enrolled? > The goal is to run the > docker container such that when the user calls docker run, Is any user allowed to run docker run? That seems like a security issue. > it just drops > into a shell with the container's environment, but everything else looks > largely the same. i.e. The user gets the same uid:gid and sees the same > directories and permissions as the host. So you want bash started in the container, with the uid:gid of the person invoking the command? If the users are trusted to do docker run, they can do docker run -u $UID container bash themselves. But you likely do not want to give every user a way to run any command, why not just use sudo, and docker run -u $SUDO_UID container bash in the script invoked with the sudo (untested)? -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat From jbaird at follett.com Thu Feb 4 16:00:50 2016 From: jbaird at follett.com (Baird, Josh) Date: Thu, 4 Feb 2016 16:00:50 +0000 Subject: [Freeipa-users] what is the sudo rule runasuser local user account In-Reply-To: References: <20160204154533.GQ3654@hendrix.brq.redhat.com> Message-ID: Actually, I use local (external) users in my sudo rules in IPA 4.2 with no problem. Example: Rule name: TestDBAs Description: access for members of the TestDBAs group Enabled: TRUE Command category: all User Groups: testdbas Host Groups: corp_oracle RunAs External User: oracle In this example, 'oracle' is a local user on the server (not in IPA). I hope this functionality does not go away. Thanks, Josh > -----Original Message----- > From: freeipa-users-bounces at redhat.com [mailto:freeipa-users- > bounces at redhat.com] On Behalf Of Rob Verduijn > Sent: Thursday, February 04, 2016 10:54 AM > To: Jakub Hrozek > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] what is the sudo rule runasuser local user > account > > On Centos7.2 all patches applied I used the command: > ipa-client-install --enable-dns-updates > > Rob > > 2016-02-04 16:45 GMT+01:00 Jakub Hrozek : > > On Thu, Feb 04, 2016 at 03:52:25PM +0100, Rob Verduijn wrote: > >> Hello, > >> > >> I've noticed that the sudorule-add-runasuser no longer has en > >> --external option > >> > >> What is the current method to add a local service account to a sud > >> rule list so that users may run sudo as that service account (ie > >> apache or jboss) > >> > >> Cheers > >> Rob Verudijn > > > > I know I'm not answering your question but how did you configure the > > client side earlier? Did you use the native/legacy sudo ldap driver? > > > > The reason I'm asking this is that sssd only supports users it > > handles, so in the IPA case it only supports IPA users anyway.. > > > > -- > > Manage your subscription for the Freeipa-users mailing list: > > https://www.redhat.com/mailman/listinfo/freeipa-users > > Go to http://freeipa.org for more info on the project > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project From rob.verduijn at gmail.com Thu Feb 4 16:12:53 2016 From: rob.verduijn at gmail.com (Rob Verduijn) Date: Thu, 4 Feb 2016 17:12:53 +0100 Subject: [Freeipa-users] what is the sudo rule runasuser local user account In-Reply-To: References: <20160204154533.GQ3654@hendrix.brq.redhat.com> Message-ID: That does seem to work for me as well, however I can only add the external user via the web-gui Any idea how to do this with the command line tools ? Rob Verduijn 2016-02-04 17:00 GMT+01:00 Baird, Josh : > Actually, I use local (external) users in my sudo rules in IPA 4.2 with no problem. > > Example: > > Rule name: TestDBAs > Description: access for members of the TestDBAs group > Enabled: TRUE > Command category: all > User Groups: testdbas > Host Groups: corp_oracle > RunAs External User: oracle > > In this example, 'oracle' is a local user on the server (not in IPA). I hope this functionality does not go away. > > Thanks, > > Josh > >> -----Original Message----- >> From: freeipa-users-bounces at redhat.com [mailto:freeipa-users- >> bounces at redhat.com] On Behalf Of Rob Verduijn >> Sent: Thursday, February 04, 2016 10:54 AM >> To: Jakub Hrozek >> Cc: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] what is the sudo rule runasuser local user >> account >> >> On Centos7.2 all patches applied I used the command: >> ipa-client-install --enable-dns-updates >> >> Rob >> >> 2016-02-04 16:45 GMT+01:00 Jakub Hrozek : >> > On Thu, Feb 04, 2016 at 03:52:25PM +0100, Rob Verduijn wrote: >> >> Hello, >> >> >> >> I've noticed that the sudorule-add-runasuser no longer has en >> >> --external option >> >> >> >> What is the current method to add a local service account to a sud >> >> rule list so that users may run sudo as that service account (ie >> >> apache or jboss) >> >> >> >> Cheers >> >> Rob Verudijn >> > >> > I know I'm not answering your question but how did you configure the >> > client side earlier? Did you use the native/legacy sudo ldap driver? >> > >> > The reason I'm asking this is that sssd only supports users it >> > handles, so in the IPA case it only supports IPA users anyway.. >> > >> > -- >> > Manage your subscription for the Freeipa-users mailing list: >> > https://www.redhat.com/mailman/listinfo/freeipa-users >> > Go to http://freeipa.org for more info on the project >> >> -- >> Manage your subscription for the Freeipa-users mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-users >> Go to http://freeipa.org for more info on the project From jbaird at follett.com Thu Feb 4 16:14:14 2016 From: jbaird at follett.com (Baird, Josh) Date: Thu, 4 Feb 2016 16:14:14 +0000 Subject: [Freeipa-users] what is the sudo rule runasuser local user account In-Reply-To: References: <20160204154533.GQ3654@hendrix.brq.redhat.com> Message-ID: Yeah, this seems strange: --externaluser=STR External User the rule applies to (sudorule-find only) --runasexternaluser=STR External User the commands can run as (sudorule-find only) --runasexternalgroup=STR External Group the commands can run as (sudorule-find only) I'm not sure why those commands would be limited to sudorule-find only. Josh > -----Original Message----- > From: Rob Verduijn [mailto:rob.verduijn at gmail.com] > Sent: Thursday, February 04, 2016 11:13 AM > To: Baird, Josh > Cc: Jakub Hrozek; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] what is the sudo rule runasuser local user > account > > That does seem to work for me as well, > however I can only add the external user via the web-gui > > Any idea how to do this with the command line tools ? > > Rob Verduijn > > 2016-02-04 17:00 GMT+01:00 Baird, Josh : > > Actually, I use local (external) users in my sudo rules in IPA 4.2 with no > problem. > > > > Example: > > > > Rule name: TestDBAs > > Description: access for members of the TestDBAs group > > Enabled: TRUE > > Command category: all > > User Groups: testdbas > > Host Groups: corp_oracle > > RunAs External User: oracle > > > > In this example, 'oracle' is a local user on the server (not in IPA). I hope this > functionality does not go away. > > > > Thanks, > > > > Josh > > > >> -----Original Message----- > >> From: freeipa-users-bounces at redhat.com [mailto:freeipa-users- > >> bounces at redhat.com] On Behalf Of Rob Verduijn > >> Sent: Thursday, February 04, 2016 10:54 AM > >> To: Jakub Hrozek > >> Cc: freeipa-users at redhat.com > >> Subject: Re: [Freeipa-users] what is the sudo rule runasuser local > >> user account > >> > >> On Centos7.2 all patches applied I used the command: > >> ipa-client-install --enable-dns-updates > >> > >> Rob > >> > >> 2016-02-04 16:45 GMT+01:00 Jakub Hrozek : > >> > On Thu, Feb 04, 2016 at 03:52:25PM +0100, Rob Verduijn wrote: > >> >> Hello, > >> >> > >> >> I've noticed that the sudorule-add-runasuser no longer has en > >> >> --external option > >> >> > >> >> What is the current method to add a local service account to a sud > >> >> rule list so that users may run sudo as that service account (ie > >> >> apache or jboss) > >> >> > >> >> Cheers > >> >> Rob Verudijn > >> > > >> > I know I'm not answering your question but how did you configure > >> > the client side earlier? Did you use the native/legacy sudo ldap driver? > >> > > >> > The reason I'm asking this is that sssd only supports users it > >> > handles, so in the IPA case it only supports IPA users anyway.. > >> > > >> > -- > >> > Manage your subscription for the Freeipa-users mailing list: > >> > https://www.redhat.com/mailman/listinfo/freeipa-users > >> > Go to http://freeipa.org for more info on the project > >> > >> -- > >> Manage your subscription for the Freeipa-users mailing list: > >> https://www.redhat.com/mailman/listinfo/freeipa-users > >> Go to http://freeipa.org for more info on the project From jhrozek at redhat.com Thu Feb 4 16:33:57 2016 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 4 Feb 2016 17:33:57 +0100 Subject: [Freeipa-users] what is the sudo rule runasuser local user account In-Reply-To: References: <20160204154533.GQ3654@hendrix.brq.redhat.com> Message-ID: <20160204163357.GR3654@hendrix.brq.redhat.com> On Thu, Feb 04, 2016 at 04:00:50PM +0000, Baird, Josh wrote: > Actually, I use local (external) users in my sudo rules in IPA 4.2 with no problem. > > Example: > > Rule name: TestDBAs > Description: access for members of the TestDBAs group > Enabled: TRUE > Command category: all > User Groups: testdbas > Host Groups: corp_oracle > RunAs External User: oracle ipaSudoRunAsExtUser, ipaSudoRunAsExtGroup and ipaSudoRunAsExtUserGroup -- that's the user you want to run sudo as. That's still supported. From mkosek at redhat.com Thu Feb 4 16:45:14 2016 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 4 Feb 2016 17:45:14 +0100 Subject: [Freeipa-users] Using external certificate in IPA 4.1 In-Reply-To: <56B232B7.60306@shardi.fi> References: <56B232B7.60306@shardi.fi> Message-ID: <56B3801A.1070508@redhat.com> On 02/03/2016 06:02 PM, Ossi Ahosalmi wrote: > I'm trying to use our organizations wildcard certificate in IPA. Certificate is > signed by a trusted CA. > > Running: > ipa-server-certinstall -w -d > > with next combinations: > > - separate .key, .crt and ca chain, all in PEM format > - .crt and ca bundled into one file, .key as a separate file > - everything bundled together into one .p12 pkcs12 file > > I always end up with this error: > > "The full certificate chain is not present in ." > > My CA file contains the whole chain and works in all other programs, just not > in IPA. > > CCing Jan, but I think you are hitting https://fedorahosted.org/freeipa/ticket/5603 From abokovoy at redhat.com Thu Feb 4 16:57:52 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 4 Feb 2016 18:57:52 +0200 Subject: [Freeipa-users] Apple OpenDirectory Integration In-Reply-To: <59272774-C250-4EFD-B9E0-DF941840C659@me.com> References: <673C3518-D3FA-47C2-9FEC-E1A6F986F8FF@me.com> <56B324EE.4020403@redhat.com> <8492664F-8AC0-40EA-B749-F01E4FA2DC5A@me.com> <20160204122026.GY22179@redhat.com> <59272774-C250-4EFD-B9E0-DF941840C659@me.com> Message-ID: <20160204165752.GA22179@redhat.com> On Thu, 04 Feb 2016, "R?zvan Corneliu C.R. VILT" wrote: > >>> It's static data. It's a concatenation of multiple strings: a >>> hard-coded one, the uid and the realm. It only changes if you rename >>> the user account. It is used to route the authn phase to the Kerberos >>> account (no PAM configuration!!!). >> I wonder if we should use CoS plugin to get this data added to user >> entries instead of storing it in every single user's LDAP entry -- the >> only thing that is different is uid but the rest is the same, right? > >Right. At least for single realms with no trust domains. If you have an >identity from another realm, you need to use the KRB5 principal from >that realm. So instead of mapping to the UID, we should map to the >krbPrincipal. Yep. I've moved the ticket 4813 to needs triage basket and referenced this thread. > >The format for altSecurityIdentities is: >======================================= >"Kerberos:" + $krbPrincipal >Or for certificate logon: >"X509:" + "CN=" + $issuerRDN + "CN=" + $subject. Such as: >"X509:CN=Apple Root CA,OU=Apple Certification Authority,O=Apple Inc.,C=USCN=com.apple.idms.appleid.prd.deadbeefdeadbeefdeadbeefdeadbeef" > >It's identical to the altSecurityIdentities from MSDN and was adopted by Apple from Microsoft. See https://msdn.microsoft.com/en-us/library/cc220106.aspx >In theory it can also be used for SC Certificate logons (see above example). It is also used by iCloud for certificate logons. > > >The format for authAuthority is: >============================================= >Kerberos >-------- >Minimal Kerberos: >";Kerberosv5;;" + $krbPrincipal + ";" + $realm + ";" > >Fully compliant Kerberos: >";Kerberosv5;" + "0x"$GUID_HEX + ";" + $krbPrincipal + ";" + $realm + ";" + "Realm Public Key" >Documented on: https://developer.apple.com/library/mac/documentation/Networking/Conceptual/Open_Directory/openDirectoryConcepts/openDirectoryConcepts.html#//apple_ref/doc/uid/TP40000917-CH3-68599 > >Basic Authentication >-------------------- >Of no interest, just crypt(). Documented on: >https://developer.apple.com/library/mac/documentation/Networking/Conceptual/Open_Directory/openDirectoryConcepts/openDirectoryConcepts.html#//apple_ref/doc/uid/TP40000917-CH3-68270 > >Apple Password Server Authentication: >------------------------------------- >;ApplePasswordServer;0xfc00000000001e291a400254ba69508,1024 65537 100000735360000022652669667510124737971525265977003458292838259662475941942339637701783031842665637489899899968013535474647377427038990743911664412758698759306606987798849786426049586039725915353359580583450027978985802381494661566820916379229460639580871881869418576860074704243214464804408968770344748232621 root at ipa.example.com:172.23.36.138 >Documented on: https://developer.apple.com/library/mac/documentation/Networking/Conceptual/Open_Directory/openDirectoryConcepts/openDirectoryConcepts.html#//apple_ref/doc/uid/TP40000917-CH3-68312 >Partly implemented in https://code.google.com/archive/p/lpws but without an IPA Bridge. > >Shadow Hash Authentication (used by local accounts): >---------------------------------------------------- >;ShadowHash;HASHLIST: >Documented on: >https://developer.apple.com/library/mac/documentation/Networking/Conceptual/Open_Directory/openDirectoryConcepts/openDirectoryConcepts.html#//apple_ref/doc/uid/TP40000917-CH3-68474 > >Local Cached User Authentication (used by road-warrior scenarios on the local systems): >--------------------------------------------------------------------------------------- >Documented on: >https://developer.apple.com/library/mac/documentation/Networking/Conceptual/Open_Directory/openDirectoryConcepts/openDirectoryConcepts.html#//apple_ref/doc/uid/TP40000917-CH3-68528 > >Netlogon Authentication (used by Active Directory) >-------------------------------------------------- >;Netlogon;razvan.vilt;MYDOMAIN > >iCloud Authentication (obvious) >------------------------------- >;AppleID;razvan.vilt at me.com > >Disabled Authentication (this needs attention) >---------------------------------------------- >Basically put ";DisabledUser;;" in front of the previous authentication method. > > >>> OK. So on Linux you do an automount map for the file server with the >>> homes and state that the user home directory is in /home/$userName >>> >>> On Windows, you give the home folder as \\server\share\folder, but >>> assume that the protocol is SMB/CIFS. >>> >>> On Mac OS X, you give the protocol, the server and the share\folder. >>> You could use automount, but I've never seen any OS X admin do that. >>> Mainly because you loose the roaming ability (they call it file >>> synchronization). Mac OS X can use roaming profiles just like Windows. >>> They don't have to be mounted except at logon time which is important >>> for road-warriors. Since most Macs are laptops, the road-warrior >>> scenario is assumed. Otherwise, you just get local homes. >> If you don't provide any share details, what happens? Will Mac OS X >> would fill-in the defaults based on the user name? > >It would create a local profile in /Users/$userName. Which in reality >is what most Mac admins do anyway. Roaming profiles are not used very >much. > >If you bind to Active Directory on a Mac, you get the following Attributes: >NFSHomeDirectory: "/Users/razvan.vilt" >OriginalHomeDirectory: "smb://myFileServer/usersShare/razvan.vilt/" >The attributes are made by the Active Directory plugin automatically from "\\myFileServer\usersShare\razvan.vilt". > >> >>>> I'd open one or more RFE tickets on https://fedorahosted.org/freeipa/newticket >>> >>> One was already opened (https://fedorahosted.org/freeipa/ticket/4813) >>> and I'm in CC. Since nothing happened for 1 year after my offer to >>> document it, I've decided to start this thread. >> It mostly boils down to IPA developers not really having access to Mac >> OS X devices. And load of other tickets to solve, of course. > >I can provide VMs and/or access to VMs. FreeIPA is Python, 389 DS and >389 plugins. It's overkill for me to go under the hood. What VMs? Mac OS X? -- / Alexander Bokovoy From raubvogel at gmail.com Thu Feb 4 17:09:03 2016 From: raubvogel at gmail.com (Mauricio Tavares) Date: Thu, 4 Feb 2016 12:09:03 -0500 Subject: [Freeipa-users] Apple OpenDirectory Integration In-Reply-To: <20160204165752.GA22179@redhat.com> References: <673C3518-D3FA-47C2-9FEC-E1A6F986F8FF@me.com> <56B324EE.4020403@redhat.com> <8492664F-8AC0-40EA-B749-F01E4FA2DC5A@me.com> <20160204122026.GY22179@redhat.com> <59272774-C250-4EFD-B9E0-DF941840C659@me.com> <20160204165752.GA22179@redhat.com> Message-ID: I have a few Macs with 10.7 (mini) and 10.9 (MB air). Let me know if I can help using them as guinea piggies On Thu, Feb 4, 2016 at 11:57 AM, Alexander Bokovoy wrote: > On Thu, 04 Feb 2016, "R?zvan Corneliu C.R. VILT" wrote: >> >> >>>> It's static data. It's a concatenation of multiple strings: a >>>> hard-coded one, the uid and the realm. It only changes if you rename >>>> the user account. It is used to route the authn phase to the Kerberos >>>> account (no PAM configuration!!!). >>> >>> I wonder if we should use CoS plugin to get this data added to user >>> entries instead of storing it in every single user's LDAP entry -- the >>> only thing that is different is uid but the rest is the same, right? >> >> >> Right. At least for single realms with no trust domains. If you have an >> identity from another realm, you need to use the KRB5 principal from >> that realm. So instead of mapping to the UID, we should map to the >> krbPrincipal. > > Yep. > > I've moved the ticket 4813 to needs triage basket and referenced this > thread. > > >> >> The format for altSecurityIdentities is: >> ======================================= >> "Kerberos:" + $krbPrincipal >> Or for certificate logon: >> "X509:" + "CN=" + $issuerRDN + "CN=" + $subject. Such as: >> "X509:CN=Apple Root CA,OU=Apple Certification Authority,O=Apple >> Inc.,C=USCN=com.apple.idms.appleid.prd.deadbeefdeadbeefdeadbeefdeadbeef" >> >> It's identical to the altSecurityIdentities from MSDN and was adopted by >> Apple from Microsoft. See >> https://msdn.microsoft.com/en-us/library/cc220106.aspx >> In theory it can also be used for SC Certificate logons (see above >> example). It is also used by iCloud for certificate logons. >> >> >> The format for authAuthority is: >> ============================================= >> Kerberos >> -------- >> Minimal Kerberos: >> ";Kerberosv5;;" + $krbPrincipal + ";" + $realm + ";" >> >> Fully compliant Kerberos: >> ";Kerberosv5;" + "0x"$GUID_HEX + ";" + $krbPrincipal + ";" + $realm + ";" >> + "Realm Public Key" >> Documented on: >> https://developer.apple.com/library/mac/documentation/Networking/Conceptual/Open_Directory/openDirectoryConcepts/openDirectoryConcepts.html#//apple_ref/doc/uid/TP40000917-CH3-68599 >> >> Basic Authentication >> -------------------- >> Of no interest, just crypt(). Documented on: >> >> https://developer.apple.com/library/mac/documentation/Networking/Conceptual/Open_Directory/openDirectoryConcepts/openDirectoryConcepts.html#//apple_ref/doc/uid/TP40000917-CH3-68270 >> >> Apple Password Server Authentication: >> ------------------------------------- >> ;ApplePasswordServer;0xfc00000000001e291a400254ba69508,1024 65537 >> 100000735360000022652669667510124737971525265977003458292838259662475941942339637701783031842665637489899899968013535474647377427038990743911664412758698759306606987798849786426049586039725915353359580583450027978985802381494661566820916379229460639580871881869418576860074704243214464804408968770344748232621 >> root at ipa.example.com:172.23.36.138 >> Documented on: >> https://developer.apple.com/library/mac/documentation/Networking/Conceptual/Open_Directory/openDirectoryConcepts/openDirectoryConcepts.html#//apple_ref/doc/uid/TP40000917-CH3-68312 >> Partly implemented in https://code.google.com/archive/p/lpws but without >> an IPA Bridge. >> >> Shadow Hash Authentication (used by local accounts): >> ---------------------------------------------------- >> ;ShadowHash;HASHLIST: >> Documented on: >> >> https://developer.apple.com/library/mac/documentation/Networking/Conceptual/Open_Directory/openDirectoryConcepts/openDirectoryConcepts.html#//apple_ref/doc/uid/TP40000917-CH3-68474 >> >> Local Cached User Authentication (used by road-warrior scenarios on the >> local systems): >> >> --------------------------------------------------------------------------------------- >> Documented on: >> >> https://developer.apple.com/library/mac/documentation/Networking/Conceptual/Open_Directory/openDirectoryConcepts/openDirectoryConcepts.html#//apple_ref/doc/uid/TP40000917-CH3-68528 >> >> Netlogon Authentication (used by Active Directory) >> -------------------------------------------------- >> ;Netlogon;razvan.vilt;MYDOMAIN >> >> iCloud Authentication (obvious) >> ------------------------------- >> ;AppleID;razvan.vilt at me.com >> >> Disabled Authentication (this needs attention) >> ---------------------------------------------- >> Basically put ";DisabledUser;;" in front of the previous authentication >> method. >> >> >>>> OK. So on Linux you do an automount map for the file server with the >>>> homes and state that the user home directory is in /home/$userName >>>> >>>> On Windows, you give the home folder as \\server\share\folder, but >>>> assume that the protocol is SMB/CIFS. >>>> >>>> On Mac OS X, you give the protocol, the server and the share\folder. >>>> You could use automount, but I've never seen any OS X admin do that. >>>> Mainly because you loose the roaming ability (they call it file >>>> synchronization). Mac OS X can use roaming profiles just like Windows. >>>> They don't have to be mounted except at logon time which is important >>>> for road-warriors. Since most Macs are laptops, the road-warrior >>>> scenario is assumed. Otherwise, you just get local homes. >>> >>> If you don't provide any share details, what happens? Will Mac OS X >>> would fill-in the defaults based on the user name? >> >> >> It would create a local profile in /Users/$userName. Which in reality >> is what most Mac admins do anyway. Roaming profiles are not used very >> much. >> >> If you bind to Active Directory on a Mac, you get the following >> Attributes: >> NFSHomeDirectory: "/Users/razvan.vilt" >> OriginalHomeDirectory: >> "smb://myFileServer/usersShare/razvan.vilt/" >> The attributes are made by the Active Directory plugin automatically from >> "\\myFileServer\usersShare\razvan.vilt". >> >>> >>>>> I'd open one or more RFE tickets on >>>>> https://fedorahosted.org/freeipa/newticket >>>> >>>> >>>> One was already opened (https://fedorahosted.org/freeipa/ticket/4813) >>>> and I'm in CC. Since nothing happened for 1 year after my offer to >>>> document it, I've decided to start this thread. >>> >>> It mostly boils down to IPA developers not really having access to Mac >>> OS X devices. And load of other tickets to solve, of course. >> >> >> I can provide VMs and/or access to VMs. FreeIPA is Python, 389 DS and >> 389 plugins. It's overkill for me to go under the hood. > > What VMs? Mac OS X? > > > -- > / Alexander Bokovoy > > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project From christophe.trefois at uni.lu Thu Feb 4 17:14:28 2016 From: christophe.trefois at uni.lu (Christophe TREFOIS) Date: Thu, 4 Feb 2016 17:14:28 +0000 Subject: [Freeipa-users] OS migration from Fedora to CentOS? Message-ID: <3044CBB6-2CB9-4425-BE84-D046593903E7@uni.lu> Hi all, We are currently running a 3-replica (all are setup with the ?setup-ca flag) cluster on Fedora 21, with FreeIPA 4.1.4. We would like to slowly upgrade to the new version and move away from Fedora to CentOS 7.2. We were thinking of the following: - Create 3 CentOS machines with ?setup-ca flag so that our current cluster is 6. The first CentOS VM would then probably update the DB schema to the new FreeIPA version. - Remove the Fedora VMs 1 by 1 from the cluster using ipa-replica-manage del - Be happy? 1. Could you please advise if this is considered the safest practise? 2. Do we have to update to intermediate versions and if so how? Could we do anything else? Thank you for any hints, Kind regards, ? Christophe -------------- next part -------------- An HTML attachment was scrubbed... URL: From three18ti at gmail.com Thu Feb 4 17:28:42 2016 From: three18ti at gmail.com (Jon) Date: Thu, 4 Feb 2016 11:28:42 -0600 Subject: [Freeipa-users] [freeipa-users] Configuring Automount on Ubuntu Clients Message-ID: Hello, How do I configure automount for Ubuntu 14.04 clients? My procedure on CentOS has been: install free-ipa client, run ipa-client-install (auto configures with dns discovery), run ipa-client-automount. However, when I run this on the ubuntu client, I receive the following errors: >> root at ubuntu-1404-x8664:~# ipa-client-automount -U >> Searching for IPA server... >> IPA server: DNS discovery >> Location: default >> Configured /etc/nsswitch.conf >> Configured /etc/default/nfs-common >> Configured /etc/idmapd.conf >> rpcidmapd failed to restart: Command '/usr/sbin/service rpcidmapd restart ' returned non-zero exit status 1 >> rpcgssd failed to restart: Command '/usr/sbin/service rpcgssd restart ' returned non-zero exit status 1 As these are not the names of these services on Ubuntu, this will never work. >> root at ubuntu-1404-x8664:~# service idmapd restart >> idmapd stop/waiting >> idmapd start/running, process 428 >> root at ubuntu-1404-x8664:~# service gssd restart >> stop: Unknown instance: >> gssd start/running, process 567 Unfortunately, this appears to be hardcoded values in the install script: >> 290 if statestore.has_state('rpcidmapd'): >> 291 enabled = statestore.restore_state('rpcidmapd', 'enabled') >> 292 running = statestore.restore_state('rpcidmapd', 'running') >> 293 rpcidmapd = ipaservices.knownservices.rpcidmapd >> 294 if not enabled: >> 295 rpcidmapd.disable() >> 296 if not running: >> 297 rpcidmapd.stop() >> 298 if statestore.has_state('rpcgssd'): >> 299 enabled = statestore.restore_state('rpcgssd', 'enabled') >> 300 running = statestore.restore_state('rpcgssd', 'running') >> 301 rpcgssd = ipaservices.knownservices.rpcgssd Is Ubuntu not supported with FreeIPA? Is there an updated install script? I installed the freeipa-client from public repos. >> ii freeipa-client 3.3.4-0ubuntu3.1 amd64 FreeIPA centralized identity framework -- client >> ii python-freeipa 3.3.4-0ubuntu3.1 amd64 FreeIPA centralized identity framework -- python modules Thanks, Jon A -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasun.gera at gmail.com Thu Feb 4 17:37:07 2016 From: prasun.gera at gmail.com (Prasun Gera) Date: Thu, 4 Feb 2016 12:37:07 -0500 Subject: [Freeipa-users] client/authentication inside a docker container In-Reply-To: <20160204155640.GF16558@redhat.com> References: <20160204155640.GF16558@redhat.com> Message-ID: On Thu, Feb 4, 2016 at 10:56 AM, Jan Pazdziora wrote: > On Thu, Feb 04, 2016 at 10:19:16AM -0500, Prasun Gera wrote: > > I am trying to set up a docker image with a specific development > > environment. We use idm 4.2 for authentication, and non-kerberized nfs > > (including home) for data storage on the hosts. > > Are the hosts IPA-enrolled? > > Yes. > > The goal is to run the > > docker container such that when the user calls docker run, > > Is any user allowed to run docker run? That seems like a security > issue. > > Well any user that can do sudo should be able to run docker. Is there a security issue with that ? > > it just drops > > into a shell with the container's environment, but everything else looks > > largely the same. i.e. The user gets the same uid:gid and sees the same > > directories and permissions as the host. > > So you want bash started in the container, with the uid:gid of the > person invoking the command? If the users are trusted to do docker > run, they can do > > docker run -u $UID container bash > > themselves. > > Yes, this is similar to the 3rd point I mentioned. The problem though is that directory listings will not show names inside the container. They'll only show uids and gids. NIS solves this as a quick hack, but is there something better ? Permissions would still work since NFS is not kerberized. Another issue I haven't figured out is how the user can get sudo inside the container. If you start docker with the user's uid, I don't know if there is a safe way for that user to get sudo inside. If you start docker in the root shell, you can create the user with the uid:gid, add it to sudoers, and then change to the user's shell ? > But you likely do not want to give every user a way to run any command, > why not just use sudo, and > > docker run -u $SUDO_UID container bash > > in the script invoked with the sudo (untested)? > > I didn't follow this. Can you explain a bit more ? In the default setup, you anyway need sudo to run docker. What is the -u string here ? -- > Jan Pazdziora > Senior Principal Software Engineer, Identity Management Engineering, Red > Hat > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tgeier at accertify.com Thu Feb 4 18:13:09 2016 From: tgeier at accertify.com (Timothy Geier) Date: Thu, 4 Feb 2016 18:13:09 +0000 Subject: [Freeipa-users] IPA 4.2: pki-tomcatd in terrible shape Message-ID: Greetings all, For the record,this is a CentOS 7.2 box with all current patches. (ipa-server-4.2.0-15.el7.centos.3.x86_64, etc.) The situation is that pki-tomcatd on the lone CA server in our IPA cluster refuses to start cleanly. The issues started earlier this week after the certs subsystemCert, ocspSigningCert, and auditSigningCert all simultaneously expired without warning; apparently, certmonger failed to renew them automatically. We attempted timeshifting and following instructions for what appeared to be similar issues, but nothing at all has worked. Today, we attempted removing the certificates in question (of course, the files in /etc/pki/pki-tomcat/alias were backed up beforehand) and using certutil to issue new certificates. This process worked but pki-tomcatd is still refusing to start. We can get IPA to run on this server by manually starting pki-tomcatd, running ipactl start, and then ctrl-c?ing it when it gets to "Starting pki-tomcatd" but this is not a tenable long-term solution. Relevant log entries/information: /var/log/pki/pki-tomcat/ca/debug: Could not connect to LDAP server host ipa01.XXXXXXXXX.net port 636 Error netscape.ldap.LDAPException: IO Error creating JSS SSL Socket (-1) Internal Database Error encountered: Could not connect to LDAP server host ipa01.XXXXXXXXX.net port 636 Error netscape.ldap.LDAPException: IO Error creating JSS SSL Socket (-1) Internal Database Error encountered: Could not connect to LDAP server host ipa01.XXXXXXXXX.net port 636 Error netscape.ldap.LDAPException: Authentication failed (49) /var/log/pki/pki-tomcat/localhost.2016-02-04.log: org.apache.catalina.core.StandardContext loadOnStartup SEVERE: Servlet /ca threw load() exception java.lang.NullPointerException # getcert list: Number of certificates and requests being tracked: 8. Request ID '20151015022737': status: MONITORING ca-error: Error setting up ccache for "host" service on client using default keytab: Generic error (see e-text). stuck: no key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-XXXXXXXXX-NET',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-XXXXXXXXX-NET/pwdfile.txt' expires: 2017-10-15 02:09:06 UTC track: yes auto-renew: yes Request ID '20151015022949': status: MONITORING ca-error: Error setting up ccache for "host" service on client using default keytab: Generic error (see e-text). stuck: no key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' expires: 2017-10-15 02:09:10 UTC track: yes auto-renew: yes Request ID '20160127202548': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert cert-pki-ca',token='NSS Certificate DB',pin set certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert cert-pki-ca',token='NSS Certificate DB' expires: 2034-02-11 19:46:43 UTC track: yes auto-renew: yes Request ID '20160127202549': status: MONITORING 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' expires: 2017-12-25 04:27:49 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment track: yes auto-renew: yes Request ID '20160127202550': status: MONITORING ca-error: Server at "http://ipa01.XXXXXXXXX.net:8080/ca/ee/ca/profileSubmit" replied: Profile caServerCert Not Found stuck: no key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='Server-Cert cert-pki-ca',token='NSS Certificate DB',pin set certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='Server-Cert cert-pki-ca',token='NSS Certificate DB' expires: 2017-10-04 02:28:53 UTC track: yes auto-renew: yes Request ID '20160204165453': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB',pin set certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB' expires: 2016-05-04 16:40:23 UTC track: yes auto-renew: yes Request ID '20160204170246': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB',pin set certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB' expires: 2016-05-04 16:59:18 UTC track: yes auto-renew: yes Request ID '20160204170752': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB',pin set certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB' expires: 2016-05-04 17:05:29 UTC track: yes auto-renew: yes # certutil -L -d /var/lib/pki/pki-tomcat/alias/ Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI auditSigningCert cert-pki-ca u,u,Pu ocspSigningCert cert-pki-ca u,u,u caSigningCert cert-pki-ca CTu,Cu,Cu subsystemCert cert-pki-ca u,u,u Server-Cert cert-pki-ca u,u,u # certutil -L -d /etc/dirsrv/slapd-XXXXXXXXX-NET/ Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI Server-Cert u,u,u XXXXXXXXX.NET IPA CA CT,C,C The only thing that making new certs seemed to resolve was removing these errors from /var/log/pki/pki-tomcat/ca/system : Cannot authenticate agent with certificate Serial Subject DN CN=IPA RA,O=XXXXXXXXX.NET. Error: User not found Thus, the root cause(s) appears to be something else entirely that we are totally unfamilar with..we can provide any other required information to help with troubleshooting. Thanks much for any and all assistance, "This message and any attachments may contain confidential information. If you have received this message in error, any use or distribution is prohibited. Please notify us by reply e-mail if you have mistakenly received this message, and immediately and permanently delete it and any attachments. Thank you." From nix125432512689712 at gmail.com Thu Feb 4 18:39:07 2016 From: nix125432512689712 at gmail.com (sysadmin ofdoom) Date: Thu, 4 Feb 2016 11:39:07 -0700 Subject: [Freeipa-users] Sudo privilege inheritance in FreeIPA (3.0.x branch) Message-ID: Note: sudo rule "testSudo" fails when using user group. But succeeds when using a directly defined user. sudo rule "sudo-1" fails when user defined directly, but hosts are defined with host group. The behaviour that I'm observing is: sudo rules are not functioning any time the user or host are not defined directly in the sudo rule. And yes I have set the nisdomainname. My Failing config: ==================== [root at freeipaserver ~]# ipa user-show User login: aaaa User login: aaaa First name: bbbb Last name: bbbb Home directory: /home/aaaa Login shell: /bin/bash Email address: aaaa at example.com UID: 591700000 GID: 591700000 Account disabled: False Password: True Member of groups: ipausers, ug1-sudo Indirect Member of Sudo rule: sudo-1, testSudo Indirect Member of HBAC rule: hbac1 Kerberos keys available: True [root at freeipaserver ~]# ipa sudorule-show Rule name: sudo-1 Rule name: sudo-1 Description: Sudo privilege policy for HG1 Enabled: TRUE Command category: all RunAs User category: all RunAs Group category: all User Groups: ug1-sudo Host Groups: hg1 [root at freeipaserver ~]# ipa sudorule-show Rule name: testSudo Rule name: testSudo Enabled: TRUE Command category: all RunAs User category: all RunAs Group category: all User Groups: ug1-sudo Hosts: ipaclient.city.state.example.com [root at freeipaserver ~]# ipa hostgroup-show Host-group: hg1 Host-group: hg1 Description: Host group 1 - Contains non hardened hosts Member hosts: ipaclient.city.state.example.com Member of Sudo rule: sudo-1 Member of HBAC rule: hbac1 Working Config: =================== [root at freeipaserver~]# ipa user-show User login: aaaa User login: aaaa First name: bbbb Last name: bbbb Home directory: /home/aaaa Login shell: /bin/bash Email address: aaaa at charter.com UID: 591700000 GID: 591700000 Account disabled: False Password: True Member of groups: ipausers, ug1-sudo Member of Sudo rule: testSudo Indirect Member of Sudo rule: sudo-1 Indirect Member of HBAC rule: hbac1 Kerberos keys available: True [root at freeipaserver ~]# ipa sudorule-show Rule name: testSudo Rule name: testSudo Enabled: TRUE Command category: all RunAs User category: all RunAs Group category: all Users: aaaa Hosts: ipaclient.city.state.example.com On Wed, Jan 27, 2016 at 09:36:13AM -0700, sysadmin ofdoom wrote: > I am trying to implement FreeIPA in a larger environment. Due to the > complexity of the environment I've been constructing a user group structure > such that i have groups at the following levels: > > project --> project_at_site --> project_site_vendor I'm not sure the order of the hierarchy is correct, can you show an example with ipa group-show? > > HBAC rules are defined at the lowest level (vendor at site) and associated > with a host group at the same level. > > Each of the above user group levels will have a corresponding sudo group. > (Used to provide a vendor access to servers the vendor supports at a > specific site at a moments notice) > > HBAC rules are propagating up the chain correctly. > > When a user is added to a top level group (e.g. project or project-sudo) > the indirect membership shows up for both Sudo and HBAC rules. > > The problem is that I can't get the sudo privileges to work when the user > shows indirect membership for the sudo rule. If i make the user a direct > member of the sudo rule, i can use sudo. > > As I've looked at debug logs, i was able to see that the query used when i > was identical when i was successful at using sudo and when i i got denied. > The difference is the failure would have a message like > [sudosrv_get_sudorules_from_cache] (0x0400): Returning 1 rules for [ > user example com] The successes returned 2 rules. > > The only change made between the success and failure was making the user a > direct member of the sudo rule where the failure was an indirect member. > > Thanks for any help! sudo uses the list of groups as returned by initgroups()/getgrouplist(), so if the user is a member of that group (as reported by id $user), then the sudo rule should match. -------------- next part -------------- An HTML attachment was scrubbed... URL: From estracen at hotmail.com Thu Feb 4 19:15:17 2016 From: estracen at hotmail.com (Alan P) Date: Thu, 4 Feb 2016 13:15:17 -0600 Subject: [Freeipa-users] IPA-AD Login Message-ID: Hi, I just configured a trust between an IPA and an Active Directory to authenticate IPA users in Windows machines joined in AD domain. The login is successfull, but only after several minutes (nearly 25 minutes) in the first attempt; in the next attempts, the required time goes from 5 to 10 min. So, what can I do to reduce the time to something more acceptable? (For reference, when an AD user authenticates it only takes 10 seconds or less). My environment is: IPA server 4.2.0-15 in a RHEL 7.2 IPA domain is a subdomain of AD (like ad.example.com and ipa.ad.example.com) There are, right now, a few users but is planed to manage more than 10,000 The trust was configured as "two way" AD is in a Windows Server 2012 It has the root domain I made a domain delegation, so AD is authoritative for ad.example.com and IPA, for ipa.ad.example.com All windows client machines are joined here There are a few users, but they are only for test purposes The authentication in a windows client is: user: IPA.AD.EXAMPLE.COM\ipa.user pass: ipa user pass >From IPA console I can make kinit user.ad at AD.EXAMPLE.COM with no problem. Thanks. Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From three18ti at gmail.com Thu Feb 4 19:24:38 2016 From: three18ti at gmail.com (Jon) Date: Thu, 4 Feb 2016 13:24:38 -0600 Subject: [Freeipa-users] [freeipa-users] How to manage Linux attributes for AD users (e.g. how do I set a shell for an AD User) Message-ID: Hello, How does one manage linux attributes for AD users. Primarily in my case, I'm looking to change the default shell to either Bash or KSH depending on the user. I can create a .profile that either sources bash or ksh rcs... e.g.: >> $ cat ~/.profile >> bash ./.bashrc This is really less than ideal and just seems like the wrong way to do it, especially considering we have a tool like FreeIPA. According to Microsoft , they are no longer supporting Identity Management for Unix. Does FreeIPA honor the attributes set by IDMU? Even if it's deprecated, I suppose we could continue to use it... This previous FreeIPA thread seems to indicate you can force the shell for anyone in the domain logging into that machine, but we have some users who prefer one shell over the other. I did what I believe to be standard, I created a security group in AD, added that group to a group an external group in FreeIPA, then made an internal group and added the external group as a member to the internal group. Unfortunately, this doesn't seem to expose any of the AD attributes for management. Or maybe I'm just misunderstanding... Any thoughts? How are you managing individual AD user settings? Thanks, Jon A -------------- next part -------------- An HTML attachment was scrubbed... URL: From jbaird at follett.com Thu Feb 4 19:30:36 2016 From: jbaird at follett.com (Baird, Josh) Date: Thu, 4 Feb 2016 19:30:36 +0000 Subject: [Freeipa-users] [freeipa-users] How to manage Linux attributes for AD users (e.g. how do I set a shell for an AD User) In-Reply-To: References: Message-ID: For AD users, I believe you have two options. 1) Set the POSIX value on the user in AD for the shell 2) Set the following in your client's sssd.conf: [nss] override_shell = /bin/bash This would obviously be global per IPA client. Josh From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Jon Sent: Thursday, February 04, 2016 2:25 PM To: freeipa-users at redhat.com Subject: [Freeipa-users] [freeipa-users] How to manage Linux attributes for AD users (e.g. how do I set a shell for an AD User) Hello, How does one manage linux attributes for AD users. Primarily in my case, I'm looking to change the default shell to either Bash or KSH depending on the user. I can create a .profile that either sources bash or ksh rcs... e.g.: >> $ cat ~/.profile >> bash ./.bashrc This is really less than ideal and just seems like the wrong way to do it, especially considering we have a tool like FreeIPA. According to Microsoft, they are no longer supporting Identity Management for Unix. Does FreeIPA honor the attributes set by IDMU? Even if it's deprecated, I suppose we could continue to use it... This previous FreeIPA thread seems to indicate you can force the shell for anyone in the domain logging into that machine, but we have some users who prefer one shell over the other. I did what I believe to be standard, I created a security group in AD, added that group to a group an external group in FreeIPA, then made an internal group and added the external group as a member to the internal group. Unfortunately, this doesn't seem to expose any of the AD attributes for management. Or maybe I'm just misunderstanding... Any thoughts? How are you managing individual AD user settings? Thanks, Jon A -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob.verduijn at gmail.com Thu Feb 4 19:37:37 2016 From: rob.verduijn at gmail.com (Rob Verduijn) Date: Thu, 4 Feb 2016 20:37:37 +0100 Subject: [Freeipa-users] what is the sudo rule runasuser local user account In-Reply-To: <20160204163357.GR3654@hendrix.brq.redhat.com> References: <20160204154533.GQ3654@hendrix.brq.redhat.com> <20160204163357.GR3654@hendrix.brq.redhat.com> Message-ID: hi all, I tried and figured it out.. ipa sudorule-add-runasuser --users= Is the command syntax I was looking for. I guess that if the --users isn't an ipa user it is automatically flagged as an external user. Cheers Rob Verduijn 2016-02-04 17:33 GMT+01:00 Jakub Hrozek : > On Thu, Feb 04, 2016 at 04:00:50PM +0000, Baird, Josh wrote: >> Actually, I use local (external) users in my sudo rules in IPA 4.2 with no problem. >> >> Example: >> >> Rule name: TestDBAs >> Description: access for members of the TestDBAs group >> Enabled: TRUE >> Command category: all >> User Groups: testdbas >> Host Groups: corp_oracle >> RunAs External User: oracle > > ipaSudoRunAsExtUser, ipaSudoRunAsExtGroup and ipaSudoRunAsExtUserGroup > -- that's the user you want to run sudo as. That's still supported. From three18ti at gmail.com Thu Feb 4 19:57:20 2016 From: three18ti at gmail.com (Jon) Date: Thu, 4 Feb 2016 13:57:20 -0600 Subject: [Freeipa-users] [freeipa-users] How to manage Linux attributes for AD users (e.g. how do I set a shell for an AD User) In-Reply-To: References: Message-ID: Hi Josh, I think that's exactly the problem though, how does one set POSIX attributes in AD from Linux guests? The RedHat documentation has a big warning that the Microsoft IDMU has been deprecated. >> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/ex.sssd-ad-posix.html Surely you're not suggesting manually editing the AD Schema...? Also, another use case is ssh keys. I'm not even sure that IDMU has an option for "authorized_keys" (and FreeIPA doesn't seem to honor what's in .ssh/authorized keys... when that file exists I always get prompted for a password then access denied). I'm sure there are other per-user level attributes that are required, home directory perhaps?, but the two big ones are shell and ssh keys. I can't be the only one who has a use case for managing these attributes for Active Directory users. Thanks, Jon A On Thu, Feb 4, 2016 at 1:30 PM, Baird, Josh wrote: > For AD users, I believe you have two options. > > > > 1) Set the POSIX value on the user in AD for the shell > > 2) Set the following in your client's sssd.conf: > > > > [nss] > > override_shell = /bin/bash > > > > This would obviously be global per IPA client. > > > > Josh > > > > *From:* freeipa-users-bounces at redhat.com [mailto: > freeipa-users-bounces at redhat.com] *On Behalf Of *Jon > *Sent:* Thursday, February 04, 2016 2:25 PM > *To:* freeipa-users at redhat.com > *Subject:* [Freeipa-users] [freeipa-users] How to manage Linux attributes > for AD users (e.g. how do I set a shell for an AD User) > > > > Hello, > > > > How does one manage linux attributes for AD users. Primarily in my case, > I'm looking to change the default shell to either Bash or KSH depending on > the user. > > > > I can create a .profile that either sources bash or ksh rcs... e.g.: > > > > >> $ cat ~/.profile > > >> bash ./.bashrc > > > > This is really less than ideal and just seems like the wrong way to do it, > especially considering we have a tool like FreeIPA. > > > > According to Microsoft > , > they are no longer supporting Identity Management for Unix. Does FreeIPA > honor the attributes set by IDMU? Even if it's deprecated, I suppose we > could continue to use it... > > This previous FreeIPA thread > seems > to indicate you can force the shell for anyone in the domain logging into > that machine, but we have some users who prefer one shell over the other. > > > > I did what I believe to be standard, I created a security group in AD, > added that group to a group an external group in FreeIPA, then made an > internal group and added the external group as a member to the internal > group. Unfortunately, this doesn't seem to expose any of the AD attributes > for management. Or maybe I'm just misunderstanding... > > > > Any thoughts? How are you managing individual AD user settings? > > > > Thanks, > > Jon A > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jbaird at follett.com Thu Feb 4 20:23:08 2016 From: jbaird at follett.com (Baird, Josh) Date: Thu, 4 Feb 2016 20:23:08 +0000 Subject: [Freeipa-users] [freeipa-users] How to manage Linux attributes for AD users (e.g. how do I set a shell for an AD User) In-Reply-To: References: Message-ID: Right, I haven't messed with IDMU in quite some time, so I'm not exactly sure. Personally, I override using sssd, because all of my users use bash by default. From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Jon Sent: Thursday, February 04, 2016 2:57 PM Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] [freeipa-users] How to manage Linux attributes for AD users (e.g. how do I set a shell for an AD User) Hi Josh, I think that's exactly the problem though, how does one set POSIX attributes in AD from Linux guests? The RedHat documentation has a big warning that the Microsoft IDMU has been deprecated. >> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/ex.sssd-ad-posix.html Surely you're not suggesting manually editing the AD Schema...? Also, another use case is ssh keys. I'm not even sure that IDMU has an option for "authorized_keys" (and FreeIPA doesn't seem to honor what's in .ssh/authorized keys... when that file exists I always get prompted for a password then access denied). I'm sure there are other per-user level attributes that are required, home directory perhaps?, but the two big ones are shell and ssh keys. I can't be the only one who has a use case for managing these attributes for Active Directory users. Thanks, Jon A On Thu, Feb 4, 2016 at 1:30 PM, Baird, Josh > wrote: For AD users, I believe you have two options. 1) Set the POSIX value on the user in AD for the shell 2) Set the following in your client's sssd.conf: [nss] override_shell = /bin/bash This would obviously be global per IPA client. Josh From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Jon Sent: Thursday, February 04, 2016 2:25 PM To: freeipa-users at redhat.com Subject: [Freeipa-users] [freeipa-users] How to manage Linux attributes for AD users (e.g. how do I set a shell for an AD User) Hello, How does one manage linux attributes for AD users. Primarily in my case, I'm looking to change the default shell to either Bash or KSH depending on the user. I can create a .profile that either sources bash or ksh rcs... e.g.: >> $ cat ~/.profile >> bash ./.bashrc This is really less than ideal and just seems like the wrong way to do it, especially considering we have a tool like FreeIPA. According to Microsoft, they are no longer supporting Identity Management for Unix. Does FreeIPA honor the attributes set by IDMU? Even if it's deprecated, I suppose we could continue to use it... This previous FreeIPA thread seems to indicate you can force the shell for anyone in the domain logging into that machine, but we have some users who prefer one shell over the other. I did what I believe to be standard, I created a security group in AD, added that group to a group an external group in FreeIPA, then made an internal group and added the external group as a member to the internal group. Unfortunately, this doesn't seem to expose any of the AD attributes for management. Or maybe I'm just misunderstanding... Any thoughts? How are you managing individual AD user settings? Thanks, Jon A -------------- next part -------------- An HTML attachment was scrubbed... URL: From bnordgren at fs.fed.us Thu Feb 4 21:23:40 2016 From: bnordgren at fs.fed.us (Nordgren, Bryce L -FS) Date: Thu, 4 Feb 2016 21:23:40 +0000 Subject: [Freeipa-users] client/authentication inside a docker container In-Reply-To: References: Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E8CDB16@001FSN2MPN1-044.001f.mgd2.msft.net> An RHEL 7 host filesystem may have the same basic structure as an Ubuntu trusty container filesystem, but may have different users defined, particularly for running services and for owning the files those services must touch. To what extent do you want the same users to be enforced between the container and the host? Is it OK for service accounts to be different, as long as user/login/people accounts are the same? It almost sounds like you?re using containers to isolate user environments and processes, but you?re accumulating data from/sharing data between containers?Which implies that the processes generating the data run as the user and not as a system service. It may be easier to wrap whatever program you?re running as a web service so the users don?t have to log in and your uid:gid problem goes away. Bryce From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Prasun Gera Sent: Thursday, February 04, 2016 8:19 AM To: freeipa-users at redhat.com Subject: [Freeipa-users] client/authentication inside a docker container I am trying to set up a docker image with a specific development environment. We use idm 4.2 for authentication, and non-kerberized nfs (including home) for data storage on the hosts. The goal is to run the docker container such that when the user calls docker run, it just drops into a shell with the container's environment, but everything else looks largely the same. i.e. The user gets the same uid:gid and sees the same directories and permissions as the host. I'm trying to figure out what the best way of mapping user ids is. I've looked at the following options: * ipa-client-install inside the container. This has a few problems. One is hostname and DNS. Container needs an fqdn for this to work, and the dns has to resolve this hostname. We are not using IPA's DNS. So this whole approach looks very kludgy. Besides, I'm not sure what the right way of handling these ephemeral host names is. Ideally, they should be un-enrolled when the container is destroyed, * Use ipa's fake NIS. This works, and is very simple to setup, but I think we want to phase out NIS. If we start using it inside docker, it will never die * Don't do any domain authentication. Just ask the user to create a user with the same uid:gid as the host so that they can r/w to their own directories. The ipa version is 4.2 running on RHEL 7. The container image will be based on ubuntu trusty. Hosts are a mix of different OSes. -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasun.gera at gmail.com Fri Feb 5 01:39:05 2016 From: prasun.gera at gmail.com (Prasun Gera) Date: Thu, 4 Feb 2016 20:39:05 -0500 Subject: [Freeipa-users] client/authentication inside a docker container In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E8CDB16@001FSN2MPN1-044.001f.mgd2.msft.net> References: <82E7C9A01FD0764CACDD35D10F5DFB6E8CDB16@001FSN2MPN1-044.001f.mgd2.msft.net> Message-ID: On Thu, Feb 4, 2016 at 4:23 PM, Nordgren, Bryce L -FS wrote: > An RHEL 7 host filesystem may have the same basic structure as an Ubuntu > trusty container filesystem, but may have different users defined, > particularly for running services and for owning the files those services > must touch. To what extent do you want the same users to be enforced > between the container and the host? Is it OK for service accounts to be > different, as long as user/login/people accounts are the same? > > > Yes, that would be OK. I think all I need is that the files touched inside the container look consistent permissions-wise to files that you see on the host, and vice-versa. As such, I don't need authentication inside the container since we don't need to host any services in the container. I just need 1:1 mapping for uid:gid for regular users. > It almost sounds like you?re using containers to isolate user environments > and processes, but you?re accumulating data from/sharing data between > containers?Which implies that the processes generating the data run as the > user and not as a system service. It may be easier to wrap whatever program > you?re running as a web service so the users don?t have to log in and your > uid:gid problem goes away. > > > Yes, I've just got started with Docker, and trying to use it as a way to isolate development environment. We have a tool which has some weird toolchain dependencies (old versions of gcc, boost, bison, and possibly a few others), which would make it very hacky to compile/run it natively on all systems. I think docker solves that problem such that whenever the use wants to use that tool, they can just drop into the docker container and work there. > Bryce > > > > *From:* freeipa-users-bounces at redhat.com [mailto: > freeipa-users-bounces at redhat.com] *On Behalf Of *Prasun Gera > *Sent:* Thursday, February 04, 2016 8:19 AM > *To:* freeipa-users at redhat.com > *Subject:* [Freeipa-users] client/authentication inside a docker container > > > > I am trying to set up a docker image with a specific development > environment. We use idm 4.2 for authentication, and non-kerberized nfs > (including home) for data storage on the hosts. The goal is to run the > docker container such that when the user calls docker run, it just drops > into a shell with the container's environment, but everything else looks > largely the same. i.e. The user gets the same uid:gid and sees the same > directories and permissions as the host. I'm trying to figure out what the > best way of mapping user ids is. I've looked at the following options: > > - ipa-client-install inside the container. This has a few problems. > One is hostname and DNS. Container needs an fqdn for this to work, and the > dns has to resolve this hostname. We are not using IPA's DNS. So this whole > approach looks very kludgy. Besides, I'm not sure what the right way of > handling these ephemeral host names is. Ideally, they should be un-enrolled > when the container is destroyed, > - Use ipa's fake NIS. This works, and is very simple to setup, but I > think we want to phase out NIS. If we start using it inside docker, it will > never die > - Don't do any domain authentication. Just ask the user to create a > user with the same uid:gid as the host so that they can r/w to their own > directories. > > The ipa version is 4.2 running on RHEL 7. The container image will be > based on ubuntu trusty. Hosts are a mix of different OSes. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Fri Feb 5 07:56:22 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 5 Feb 2016 08:56:22 +0100 Subject: [Freeipa-users] [freeipa-users] Configuring Automount on Ubuntu Clients In-Reply-To: References: Message-ID: <56B455A6.7090800@redhat.com> Jon wrote: > Hello, > > How do I configure automount for Ubuntu 14.04 clients? My procedure on > CentOS has been: install free-ipa client, run ipa-client-install (auto > configures with dns discovery), run ipa-client-automount. However, when > I run this on the ubuntu client, I receive the following errors: > > >> root at ubuntu-1404-x8664:~# ipa-client-automount -U > >> Searching for IPA server... > >> IPA server: DNS discovery > >> Location: default > >> Configured /etc/nsswitch.conf > >> Configured /etc/default/nfs-common > >> Configured /etc/idmapd.conf > >> rpcidmapd failed to restart: Command '/usr/sbin/service rpcidmapd > restart ' returned non-zero exit status 1 > >> rpcgssd failed to restart: Command '/usr/sbin/service rpcgssd > restart ' returned non-zero exit status 1 > > As these are not the names of these services on Ubuntu, this will never > work. > > >> root at ubuntu-1404-x8664:~# service idmapd restart > >> idmapd stop/waiting > >> idmapd start/running, process 428 > >> root at ubuntu-1404-x8664:~# service gssd restart > >> stop: Unknown instance: > >> gssd start/running, process 567 > > Unfortunately, this appears to be hardcoded values in the install script: > > >> 290 if statestore.has_state('rpcidmapd'): > >> 291 enabled = statestore.restore_state('rpcidmapd', > 'enabled') > >> 292 running = statestore.restore_state('rpcidmapd', > 'running') > >> 293 rpcidmapd = ipaservices.knownservices.rpcidmapd > >> 294 if not enabled: > >> 295 rpcidmapd.disable() > >> 296 if not running: > >> 297 rpcidmapd.stop() > >> 298 if statestore.has_state('rpcgssd'): > >> 299 enabled = statestore.restore_state('rpcgssd', 'enabled') > >> 300 running = statestore.restore_state('rpcgssd', 'running') > >> 301 rpcgssd = ipaservices.knownservices.rpcgssd > > Is Ubuntu not supported with FreeIPA? Is there an updated install > script? I installed the freeipa-client from public repos. One guy volunteers his time porting IPA to Ubuntu. He has invested a fair bit of time in generalizing other hardcoded elements in IPA. It's possible he hasn't gotten to ipa-client-automount yet or it hasn't been pushed out in a build yet. rob From rcritten at redhat.com Fri Feb 5 08:00:44 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 5 Feb 2016 09:00:44 +0100 Subject: [Freeipa-users] IPA 4.2: pki-tomcatd in terrible shape In-Reply-To: References: Message-ID: <56B456AC.5050303@redhat.com> Timothy Geier wrote: > Greetings all, > > For the record,this is a CentOS 7.2 box with all current patches. (ipa-server-4.2.0-15.el7.centos.3.x86_64, etc.) > > The situation is that pki-tomcatd on the lone CA server in our IPA cluster refuses to start cleanly. The issues started earlier this week after the certs > subsystemCert, ocspSigningCert, and auditSigningCert all simultaneously expired without warning; apparently, certmonger failed to renew them automatically. We > attempted timeshifting and following instructions for what appeared to be similar issues, but nothing at all has worked. > > Today, we attempted removing the certificates in question (of course, the files in /etc/pki/pki-tomcat/alias were backed up beforehand) and using certutil to issue new certificates. This process worked but pki-tomcatd is still refusing to start. We can get IPA to run on this server by manually starting pki-tomcatd, running ipactl start, and then ctrl-c?ing it when it gets to "Starting pki-tomcatd" but this is not a tenable long-term solution. > > Relevant log entries/information: > > /var/log/pki/pki-tomcat/ca/debug: > Could not connect to LDAP server host ipa01.XXXXXXXXX.net port 636 Error netscape.ldap.LDAPException: IO Error creating JSS SSL Socket (-1) > Internal Database Error encountered: Could not connect to LDAP server host ipa01.XXXXXXXXX.net port 636 Error netscape.ldap.LDAPException: IO Error creating JSS SSL Socket (-1) > Internal Database Error encountered: Could not connect to LDAP server host ipa01.XXXXXXXXX.net port 636 Error netscape.ldap.LDAPException: Authentication failed (49) > > /var/log/pki/pki-tomcat/localhost.2016-02-04.log: > org.apache.catalina.core.StandardContext loadOnStartup > SEVERE: Servlet /ca threw load() exception > java.lang.NullPointerException > > # getcert list: > > Number of certificates and requests being tracked: 8. > Request ID '20151015022737': > status: MONITORING > ca-error: Error setting up ccache for "host" service on client using default keytab: Generic error (see e-text). > stuck: no > key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-XXXXXXXXX-NET',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-XXXXXXXXX-NET/pwdfile.txt' > expires: 2017-10-15 02:09:06 UTC > track: yes > auto-renew: yes > Request ID '20151015022949': > status: MONITORING > ca-error: Error setting up ccache for "host" service on client using default keytab: Generic error (see e-text). > stuck: no > key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' > expires: 2017-10-15 02:09:10 UTC > track: yes > auto-renew: yes > Request ID '20160127202548': > status: MONITORING > stuck: no > key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert cert-pki-ca',token='NSS Certificate DB',pin set > certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert cert-pki-ca',token='NSS Certificate DB' > expires: 2034-02-11 19:46:43 UTC > track: yes > auto-renew: yes > Request ID '20160127202549': > status: MONITORING > 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' > expires: 2017-12-25 04:27:49 UTC > key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > track: yes > auto-renew: yes > Request ID '20160127202550': > status: MONITORING > ca-error: Server at "http://ipa01.XXXXXXXXX.net:8080/ca/ee/ca/profileSubmit" replied: Profile caServerCert Not Found > stuck: no > key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='Server-Cert cert-pki-ca',token='NSS Certificate DB',pin set > certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='Server-Cert cert-pki-ca',token='NSS Certificate DB' > expires: 2017-10-04 02:28:53 UTC > track: yes > auto-renew: yes > Request ID '20160204165453': > status: MONITORING > stuck: no > key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB',pin set > certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB' > expires: 2016-05-04 16:40:23 UTC > track: yes > auto-renew: yes > Request ID '20160204170246': > status: MONITORING > stuck: no > key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB',pin set > certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB' > expires: 2016-05-04 16:59:18 UTC > track: yes > auto-renew: yes > Request ID '20160204170752': > status: MONITORING > stuck: no > key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB',pin set > certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB' > expires: 2016-05-04 17:05:29 UTC > track: yes > auto-renew: yes > > # certutil -L -d /var/lib/pki/pki-tomcat/alias/ > > Certificate Nickname Trust Attributes > SSL,S/MIME,JAR/XPI > auditSigningCert cert-pki-ca u,u,Pu > ocspSigningCert cert-pki-ca u,u,u > caSigningCert cert-pki-ca CTu,Cu,Cu > subsystemCert cert-pki-ca u,u,u > Server-Cert cert-pki-ca u,u,u > > # certutil -L -d /etc/dirsrv/slapd-XXXXXXXXX-NET/ > > Certificate Nickname Trust Attributes > SSL,S/MIME,JAR/XPI > Server-Cert u,u,u > XXXXXXXXX.NET IPA CA CT,C,C > > > > The only thing that making new certs seemed to resolve was removing these errors from /var/log/pki/pki-tomcat/ca/system : > > Cannot authenticate agent with certificate Serial Subject DN CN=IPA RA,O=XXXXXXXXX.NET. Error: User not found > > Thus, the root cause(s) appears to be something else entirely that we are totally unfamilar with..we can provide any other required information to help with troubleshooting. You can't manually re-issue the CA certificates using certutil. Your best bet is to restore the original database and try going back in time again and we can start troubleshooting from that point. And it is likely to fail again if you've changed the way the certificates are tracked by certmonger. There are some notable things missing from your certmonger output including the CA and the pre and post command scripts. We would definitely need to see those in order to troubleshoot. Is this your originally installed CA or did that die at some point and this is a replica of it? rob From jhrozek at redhat.com Fri Feb 5 08:32:31 2016 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 5 Feb 2016 09:32:31 +0100 Subject: [Freeipa-users] Sudo privilege inheritance in FreeIPA (3.0.x branch) In-Reply-To: References: Message-ID: <20160205083231.GT3654@hendrix.brq.redhat.com> On Thu, Feb 04, 2016 at 11:39:07AM -0700, sysadmin ofdoom wrote: > Note: sudo rule "testSudo" fails when using user group. But succeeds > when using a directly defined user. > sudo rule "sudo-1" fails when user defined directly, but hosts are > defined with host group. > > The behaviour that I'm observing is: sudo rules are not functioning any > time the user or host are not defined directly in the sudo rule. And yes I > have set the nisdomainname. Please follow: https://fedorahosted.org/sssd/wiki/HOWTO_Troubleshoot_SUDO Especially the sudo log would be helpful in this case I guess. From jhrozek at redhat.com Fri Feb 5 08:33:25 2016 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 5 Feb 2016 09:33:25 +0100 Subject: [Freeipa-users] IPA-AD Login In-Reply-To: References: Message-ID: <20160205083325.GU3654@hendrix.brq.redhat.com> On Thu, Feb 04, 2016 at 01:15:17PM -0600, Alan P wrote: > Hi, > > I just configured a trust between an IPA and an Active Directory to authenticate IPA users in Windows machines joined in AD domain. The login is successfull, but only after several minutes (nearly 25 minutes) in the first attempt; in the next attempts, the required time goes from 5 to 10 min. So, what can I do to reduce the time to something more acceptable? (For reference, when an AD user authenticates it only takes 10 seconds or less). > > My environment is: > > IPA server 4.2.0-15 in a RHEL 7.2 > IPA domain is a subdomain of AD (like ad.example.com and ipa.ad.example.com) > There are, right now, a few users but is planed to manage more than 10,000 > The trust was configured as "two way" > > AD is in a Windows Server 2012 > It has the root domain > I made a domain delegation, so AD is authoritative for ad.example.com and IPA, for ipa.ad.example.com > All windows client machines are joined here > There are a few users, but they are only for test purposes > > The authentication in a windows client is: > user: IPA.AD.EXAMPLE.COM\ipa.user > pass: ipa user pass > > >From IPA console I can make kinit user.ad at AD.EXAMPLE.COM with no problem. Please see: https://jhrozek.wordpress.com/2015/08/19/performance-tuning-sssd-for-large-ipa-ad-trust-deployments/ We're working on sssd performance fixes for the next version (1.14, will be in RHEL-7.3) From jhrozek at redhat.com Fri Feb 5 08:41:21 2016 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 5 Feb 2016 09:41:21 +0100 Subject: [Freeipa-users] [freeipa-users] How to manage Linux attributes for AD users (e.g. how do I set a shell for an AD User) In-Reply-To: References: Message-ID: <20160205084121.GV3654@hendrix.brq.redhat.com> On Thu, Feb 04, 2016 at 01:57:20PM -0600, Jon wrote: > Hi Josh, > > I think that's exactly the problem though, how does one set POSIX > attributes in AD from Linux guests? > > The RedHat documentation has a big warning that the Microsoft IDMU has been > deprecated. IIRC the UI is, the schema is not. > > >> > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/ex.sssd-ad-posix.html > > Surely you're not suggesting manually editing the AD Schema...? > > Also, another use case is ssh keys. I'm not even sure that IDMU has an > option for "authorized_keys" (and FreeIPA doesn't seem to honor what's in > .ssh/authorized keys... when that file exists I always get prompted for a > password then access denied). For per-AD-user ssh pubkeys, you can use the idviews feature: ipa idoverrideuser-add --sshpubkey=STR see: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/id-views.html same for shells, although as Josh said, shells can be set globally for all users in sssd.conf > > I'm sure there are other per-user level attributes that are required, home > directory perhaps?, but the two big ones are shell and ssh keys. I can't > be the only one who has a use case for managing these attributes for Active > Directory users. > > Thanks, > Jon A > > On Thu, Feb 4, 2016 at 1:30 PM, Baird, Josh wrote: > > > For AD users, I believe you have two options. > > > > > > > > 1) Set the POSIX value on the user in AD for the shell > > > > 2) Set the following in your client's sssd.conf: > > > > > > > > [nss] > > > > override_shell = /bin/bash > > > > > > > > This would obviously be global per IPA client. > > > > > > > > Josh > > > > > > > > *From:* freeipa-users-bounces at redhat.com [mailto: > > freeipa-users-bounces at redhat.com] *On Behalf Of *Jon > > *Sent:* Thursday, February 04, 2016 2:25 PM > > *To:* freeipa-users at redhat.com > > *Subject:* [Freeipa-users] [freeipa-users] How to manage Linux attributes > > for AD users (e.g. how do I set a shell for an AD User) > > > > > > > > Hello, > > > > > > > > How does one manage linux attributes for AD users. Primarily in my case, > > I'm looking to change the default shell to either Bash or KSH depending on > > the user. > > > > > > > > I can create a .profile that either sources bash or ksh rcs... e.g.: > > > > > > > > >> $ cat ~/.profile > > > > >> bash ./.bashrc > > > > > > > > This is really less than ideal and just seems like the wrong way to do it, > > especially considering we have a tool like FreeIPA. > > > > > > > > According to Microsoft > > , > > they are no longer supporting Identity Management for Unix. Does FreeIPA > > honor the attributes set by IDMU? Even if it's deprecated, I suppose we > > could continue to use it... > > > > This previous FreeIPA thread > > seems > > to indicate you can force the shell for anyone in the domain logging into > > that machine, but we have some users who prefer one shell over the other. > > > > > > > > I did what I believe to be standard, I created a security group in AD, > > added that group to a group an external group in FreeIPA, then made an > > internal group and added the external group as a member to the internal > > group. Unfortunately, this doesn't seem to expose any of the AD attributes > > for management. Or maybe I'm just misunderstanding... > > > > > > > > Any thoughts? How are you managing individual AD user settings? > > > > > > > > Thanks, > > > > Jon A > > > > > > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project From pvoborni at redhat.com Fri Feb 5 10:35:26 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 5 Feb 2016 11:35:26 +0100 Subject: [Freeipa-users] OS migration from Fedora to CentOS? In-Reply-To: <3044CBB6-2CB9-4425-BE84-D046593903E7@uni.lu> References: <3044CBB6-2CB9-4425-BE84-D046593903E7@uni.lu> Message-ID: <56B47AEE.2010906@redhat.com> On 02/04/2016 06:14 PM, Christophe TREFOIS wrote: > Hi all, > > We are currently running a 3-replica (all are setup with the ?setup-ca flag) cluster on Fedora 21, with FreeIPA 4.1.4. > > We would like to slowly upgrade to the new version and move away from Fedora to CentOS 7.2. > > We were thinking of the following: > > - Create 3 CentOS machines with ?setup-ca flag so that our current cluster is 6. > The first CentOS VM would then probably update the DB schema to the new FreeIPA version. > - Remove the Fedora VMs 1 by 1 from the cluster using ipa-replica-manage del > - Be happy? > > > 1. Could you please advise if this is considered the safest practise? More or less yes: 1. create First IPA 4.2 against some FreeIPA 4.1.4 with CA 2. create the other two against the newly Created CentOS - will verify if it is in a good shape 3. set new renewal CRL master: http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master 4. Migrate DNA ranges using ipa-replica-manage tool if all works well, remove all servers: 5. remove CA repl. agreements for old servers using ipa-csreplica-manage del 6. remove old servers data and repl. agreements using ipa-replica-manage del 7. uninstall old servers using ipa-server-install --uninstall > 2. Do we have to update to intermediate versions and if so how? Should not be necessary. > > Could we do anything else? > > Thank you for any hints, > > Kind regards, > > ? > Christophe > > > -- Petr Vobornik From fujisan43 at gmail.com Fri Feb 5 15:52:23 2016 From: fujisan43 at gmail.com (Fujisan) Date: Fri, 5 Feb 2016 16:52:23 +0100 Subject: [Freeipa-users] Cannot start freeipa after reboot of server Message-ID: Hello, I have a big problem here I have rebooted my freeipa server and noticed that no login screen appeared after the reboot making it impossible to log in, even through an ssh session from my desktop. I also rebooted the replica and got the same problem. I rebooted again the replica in rescue mode and tried to start freeipa manually: # systemctl restart ipa.service Error getting authority: Error initializing authority: could not connect: No such file or directory Welcome to emergency mode! After logging in, type 'journalctl -xb' to view system logs. ... Try again to boot into default mode. Give root password for maintenance (or press Control-D to continue) # systemctl status ipa.service ... ... active: Inactive (dead) ... Stopped Identity, Policy, Audit. freeipa version is 4.2.3-2 . What can I do to fix this? Thank you Fuji -------------- next part -------------- An HTML attachment was scrubbed... URL: From estracen at hotmail.com Sat Feb 6 00:21:56 2016 From: estracen at hotmail.com (Alan P) Date: Fri, 5 Feb 2016 18:21:56 -0600 Subject: [Freeipa-users] IPA-AD Login In-Reply-To: <20160205083325.GU3654@hendrix.brq.redhat.com> References: , <20160205083325.GU3654@hendrix.brq.redhat.com> Message-ID: Thanks jhrozek, I have already seen it and applied to my IPA server, but it didn't have any significant impact, at least for AD users. In krb5kdc log, when I try to login with an IPA user in Windows, I can see the next: Feb 05 17:52:12 master.ipa.ad.example.com krb5kdc[14081](info): AS_REQ (6 etypes {18 17 23 24 -135 3}) 172.19.21.37: NEEDED_PREAUTH: ipa.user at IPA.AD.EXAMPLE.COM for krbtgt/IPA.AD.EXAMPLE.COM at IPA.AD.EXAMPLE.COM, Additional pre-authentication required Feb 05 17:52:12 master.ipa.ad.example.com krb5kdc[14081](info): closing down fd 12 Feb 05 17:52:12 master.ipa.ad.example.com krb5kdc[14081](info): AS_REQ (6 etypes {18 17 23 24 -135 3}) 172.19.21.37: ISSUE: authtime 1454716332, etypes {rep=18 tkt=18 ses=18}, ipa.user at IPA.AD.EXAMPLE.COM for krbtgt/IPA.AD.EXAMPLE.COM at IPA.AD.EXAMPLE.COM Feb 05 17:52:12 master.ipa.ad.example.com krb5kdc[14081](info): closing down fd 12 Feb 05 17:52:12 master.ipa.ad.example.com krb5kdc[14081](info): TGS_REQ (5 etypes {18 17 23 24 -135}) 172.19.21.37: ISSUE: authtime 1454716332, etypes {rep=18 tkt=18 ses=18}, ipa.user at IPA.AD.EXAMPLE.COM for krbtgt/AD.EXAMPLE.COM at IPA.AD.EXAMPLE.COM Feb 05 17:52:12 master.ipa.ad.example.com krb5kdc[14081](info): closing down fd 12 Feb 05 17:58:45 master.ipa.ad.example.com krb5kdc[14081](info): TGS_REQ (5 etypes {18 17 23 24 -135}) 172.19.21.37: ISSUE: authtime 1454716332, etypes {rep=18 tkt=18 ses=18}, ipa.user at IPA.AD.EXAMPLE.COM for cifs/master.ipa.ad.example.com at IPA.AD.EXAMPLE.COM Feb 05 17:58:45 master.ipa.ad.example.com krb5kdc[14081](info): closing down fd 12 Feb 05 17:58:47 master.ipa.ad.example.com krb5kdc[14081](info): TGS_REQ (5 etypes {18 17 23 24 -135}) 172.19.21.37: LOOKING_UP_SERVER: authtime 0, ipa.user at IPA.AD.EXAMPLE.COM for ProtectedStorage/master.ipa.ad.example.com at IPA.AD.EXAMPLE.COM, Server not found in Kerberos database Feb 05 17:58:47 master.ipa.ad.example.com krb5kdc[14081](info): closing down fd 12 In Windows, I can't find something related. Any other suggestion? > Date: Fri, 5 Feb 2016 09:33:25 +0100 > From: jhrozek at redhat.com > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] IPA-AD Login > > On Thu, Feb 04, 2016 at 01:15:17PM -0600, Alan P wrote: > > Hi, > > > > I just configured a trust between an IPA and an Active Directory to authenticate IPA users in Windows machines joined in AD domain. The login is successfull, but only after several minutes (nearly 25 minutes) in the first attempt; in the next attempts, the required time goes from 5 to 10 min. So, what can I do to reduce the time to something more acceptable? (For reference, when an AD user authenticates it only takes 10 seconds or less). > > > > My environment is: > > > > IPA server 4.2.0-15 in a RHEL 7.2 > > IPA domain is a subdomain of AD (like ad.example.com and ipa.ad.example.com) > > There are, right now, a few users but is planed to manage more than 10,000 > > The trust was configured as "two way" > > > > AD is in a Windows Server 2012 > > It has the root domain > > I made a domain delegation, so AD is authoritative for ad.example.com and IPA, for ipa.ad.example.com > > All windows client machines are joined here > > There are a few users, but they are only for test purposes > > > > The authentication in a windows client is: > > user: IPA.AD.EXAMPLE.COM\ipa.user > > pass: ipa user pass > > > > >From IPA console I can make kinit user.ad at AD.EXAMPLE.COM with no problem. > > Please see: > https://jhrozek.wordpress.com/2015/08/19/performance-tuning-sssd-for-large-ipa-ad-trust-deployments/ > > We're working on sssd performance fixes for the next version (1.14, will > be in RHEL-7.3) > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Sat Feb 6 11:32:56 2016 From: mbasti at redhat.com (Martin Basti) Date: Sat, 6 Feb 2016 12:32:56 +0100 Subject: [Freeipa-users] Cannot start freeipa after reboot of server In-Reply-To: References: Message-ID: <56B5D9E8.4090606@redhat.com> On 05.02.2016 16:52, Fujisan wrote: > Hello, > > I have a big problem here > I have rebooted my freeipa server and noticed that no login screen > appeared after the reboot making it impossible to log in, even through > an ssh session from my desktop. > I also rebooted the replica and got the same problem. > > I rebooted again the replica in rescue mode and tried to start freeipa > manually: > > # systemctl restart ipa.service > Error getting authority: Error initializing authority: could not > connect: No such file or directory > Welcome to emergency mode! After logging in, type 'journalctl -xb' to > view system logs. ... > Try again to boot into default mode. > Give root password for maintenance > (or press Control-D to continue) > > # systemctl status ipa.service > ... > ... active: Inactive (dead) > ... Stopped Identity, Policy, Audit. > > freeipa version is 4.2.3-2 . > > What can I do to fix this? > > Thank you > > Fuji > > > hello, can you inspect journal why system cannot be start in normal mode? without any logs we cannot help you. Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From fujisan43 at gmail.com Sat Feb 6 12:42:57 2016 From: fujisan43 at gmail.com (Fujisan) Date: Sat, 6 Feb 2016 13:42:57 +0100 Subject: [Freeipa-users] Cannot start freeipa after reboot of server In-Reply-To: <56B5D9E8.4090606@redhat.com> References: <56B5D9E8.4090606@redhat.com> Message-ID: I couldn't login to the server (totally freezed) so no logs to show. It is a kernel problem. the server was running kernel 4.3.4-300. I had to boot kernel 4.2.6-301 to have a functional server again. # abrt-cli list id 29e33b5c96e28619dca309942a505fc8e2ef19e2 reason: BUG: unable to handle kernel NULL pointer dereference at 0000000000000060 time: Fri 05 Feb 2016 03:35:14 PM CET cmdline: BOOT_IMAGE=/vmlinuz-4.3.4-300.fc23.x86_64 root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/swap rd.lvm.lv=fedora/root rhgb quiet LANG=en_US.UTF-8 count: 289 Directory: /var/spool/abrt/oops-2016-02-05-15:35:10-1606-4 Reported: cannot be reported Regards, F. On Sat, Feb 6, 2016 at 12:32 PM, Martin Basti wrote: > > > On 05.02.2016 16:52, Fujisan wrote: > > Hello, > > I have a big problem here > I have rebooted my freeipa server and noticed that no login screen > appeared after the reboot making it impossible to log in, even through an > ssh session from my desktop. > I also rebooted the replica and got the same problem. > > I rebooted again the replica in rescue mode and tried to start freeipa > manually: > > # systemctl restart ipa.service > Error getting authority: Error initializing authority: could not connect: > No such file or directory > Welcome to emergency mode! After logging in, type 'journalctl -xb' to view > system logs. ... > Try again to boot into default mode. > Give root password for maintenance > (or press Control-D to continue) > > # systemctl status ipa.service > ... > ... active: Inactive (dead) > ... Stopped Identity, Policy, Audit. > > freeipa version is 4.2.3-2 . > > What can I do to fix this? > > Thank you > > Fuji > > > > hello, > > can you inspect journal why system cannot be start in normal mode? > > without any logs we cannot help you. > > Martin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.obaterspok at gmail.com Sat Feb 6 21:22:39 2016 From: john.obaterspok at gmail.com (John Obaterspok) Date: Sat, 6 Feb 2016 22:22:39 +0100 Subject: [Freeipa-users] nss unrecognized name alert with SAN name Message-ID: Hi, I have a ipa.my.lan and a cname gitserver.my.lan pointing to ipa.my.lan I recently started to get nss error "SSL peer has no certificate for the requested DNS name." when I'm accesing my https://gitserver.my.lan Previously this worked fine if I had set "git config --global http.sslVerify false" according to https://www.redhat.com/archives/freeipa-users/2015-November/msg00213.html Now I tried to solve this by adding a SubjectAltName to the HTTP/ipa.my.lan certitficate like this: status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=MY.LAN subject: CN=ipa.my.lan,O=MY.LAN expires: 2018-02-06 19:24:52 UTC dns: gitserver.my.lan,ipa.my.lan principal name: http/ipa.my.lan at MY.LAN key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: /usr/lib64/ipa/certmonger/restart_httpd track: yes auto-renew: yes But I still get the below error: * NSS error -12182 (SSL_ERROR_UNRECOGNIZED_NAME_ALERT) * SSL peer has no certificate for the requested DNS name Any ideas why? -- john -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Sat Feb 6 22:21:59 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Sat, 6 Feb 2016 23:21:59 +0100 Subject: [Freeipa-users] nss unrecognized name alert with SAN name In-Reply-To: References: Message-ID: <56B67207.5000805@redhat.com> John Obaterspok wrote: > Hi, > > I have a ipa.my.lan and a cname gitserver.my.lan pointing to ipa.my.lan > > I recently started to get nss error "SSL peer has no certificate for the > requested DNS name." when I'm accesing my https://gitserver.my.lan > > Previously this worked fine if I had set "git config --global > http.sslVerify false" according to > https://www.redhat.com/archives/freeipa-users/2015-November/msg00213.html > > Now I tried to solve this by adding a SubjectAltName to the > HTTP/ipa.my.lan certitficate like this: > > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > certificate: > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=MY.LAN > subject: CN=ipa.my.lan,O=MY.LAN > expires: 2018-02-06 19:24:52 UTC > dns: gitserver.my.lan,ipa.my.lan > principal name: http/ipa.my.lan at MY.LAN > key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: /usr/lib64/ipa/certmonger/restart_httpd > track: yes > auto-renew: yes > > But I still get the below error: > > * NSS error -12182 (SSL_ERROR_UNRECOGNIZED_NAME_ALERT) > * SSL peer has no certificate for the requested DNS name What version of mod_nss? It recently added support for SNI. You can try turning it off by adding NSSSNI off to /etc/httpd/conf.d/nss.conf but I'd imagine you were already relying on it. rob From rcritten at redhat.com Sat Feb 6 22:29:33 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Sat, 6 Feb 2016 23:29:33 +0100 Subject: [Freeipa-users] nss unrecognized name alert with SAN name In-Reply-To: References: Message-ID: <56B673CD.1080507@redhat.com> John Obaterspok wrote: > Hi, > > I have a ipa.my.lan and a cname gitserver.my.lan pointing to ipa.my.lan > > I recently started to get nss error "SSL peer has no certificate for the > requested DNS name." when I'm accesing my https://gitserver.my.lan > > Previously this worked fine if I had set "git config --global > http.sslVerify false" according to > https://www.redhat.com/archives/freeipa-users/2015-November/msg00213.html > > Now I tried to solve this by adding a SubjectAltName to the > HTTP/ipa.my.lan certitficate like this: > > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > certificate: > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=MY.LAN > subject: CN=ipa.my.lan,O=MY.LAN > expires: 2018-02-06 19:24:52 UTC > dns: gitserver.my.lan,ipa.my.lan > principal name: http/ipa.my.lan at MY.LAN > key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: /usr/lib64/ipa/certmonger/restart_httpd > track: yes > auto-renew: yes > > But I still get the below error: > > * NSS error -12182 (SSL_ERROR_UNRECOGNIZED_NAME_ALERT) > * SSL peer has no certificate for the requested DNS name What version of mod_nss? It recently added support for SNI. You can try turning it off by adding NSSSNI off to /etc/httpd/conf.d/nss.conf but I'd imagine you were already relying on it. rob From john.obaterspok at gmail.com Sun Feb 7 11:05:19 2016 From: john.obaterspok at gmail.com (John Obaterspok) Date: Sun, 7 Feb 2016 12:05:19 +0100 Subject: [Freeipa-users] nss unrecognized name alert with SAN name In-Reply-To: <56B673CD.1080507@redhat.com> References: <56B673CD.1080507@redhat.com> Message-ID: 2016-02-06 23:29 GMT+01:00 Rob Crittenden : > John Obaterspok wrote: > >> Hi, >> >> I have a ipa.my.lan and a cname gitserver.my.lan pointing to ipa.my.lan >> >> I recently started to get nss error "SSL peer has no certificate for the >> requested DNS name." when I'm accesing my https://gitserver.my.lan >> >> Previously this worked fine if I had set "git config --global >> http.sslVerify false" according to >> https://www.redhat.com/archives/freeipa-users/2015-November/msg00213.html >> >> Now I tried to solve this by adding a SubjectAltName to the >> HTTP/ipa.my.lan certitficate like this: >> >> status: MONITORING >> stuck: no >> key pair storage: >> type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS >> Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >> certificate: >> type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS >> Certificate DB' >> CA: IPA >> issuer: CN=Certificate Authority,O=MY.LAN >> subject: CN=ipa.my.lan,O=MY.LAN >> expires: 2018-02-06 19:24:52 UTC >> dns: gitserver.my.lan,ipa.my.lan >> principal name: http/ipa.my.lan at MY.LAN >> key usage: >> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >> eku: id-kp-serverAuth,id-kp-clientAuth >> pre-save command: >> post-save command: /usr/lib64/ipa/certmonger/restart_httpd >> track: yes >> auto-renew: yes >> >> But I still get the below error: >> >> * NSS error -12182 (SSL_ERROR_UNRECOGNIZED_NAME_ALERT) >> * SSL peer has no certificate for the requested DNS name >> > > What version of mod_nss? It recently added support for SNI. You can try > turning it off by adding NSSSNI off to /etc/httpd/conf.d/nss.conf but I'd > imagine you were already relying on it. > > Hi, Turning it off didn't help I'm on F23 with latest updates so I have mod_nss-1.0.12-1 I noticed it worked if I set "ServerName gitserver.my.lan" in gitserver.conf, but then I got the NAME ALERT when accessing ipa.my.lan. I then tried to put ipa.conf in but then I got error about SSL_ERROR_RX_RECORD_TOO_LONG gitserver.conf has this: DocumentRoot /opt/wwwgit SetEnv GIT_PROJECT_ROOT /opt/wwwgit SetEnv GIT_HTTP_EXPORT_ALL SetEnv REMOTE_USER $REDIRECT_REMOTE_USER ScriptAlias /git/ /usr/libexec/git-core/git-http-backend/ ServerName gitserver.my.lan Options Indexes AllowOverride None Require all granted Options Indexes AllowOverride None Require all granted #SSLRequireSSL AuthType Kerberos AuthName "Kerberos Login" KrbAuthRealm WIN.LAN Krb5KeyTab /etc/httpd/conf/ipa.keytab KrbMethodNegotiate on KrbMethodK5Passwd off # Set to on to query for pwd if negotiation failed due to no ticket available KrbSaveCredentials on KrbVerifyKDC on KrbServiceName HTTP/ipa.my.lan at MY.LAN AuthLDAPUrl ldaps://ipa.my.lan/dc=my,dc=lan?krbPrincipalName AuthLDAPBindDN "uid=httpbind,cn=sysaccounts,cn=etc,dc=my,dc=lan" AuthLDAPBindPassword "secret123abc" Require ldap-group cn=ipausers,cn=groups,cn=accounts,dc=my,dc=lan Any more ideas what I do wrong? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Sun Feb 7 13:12:33 2016 From: jhrozek at redhat.com (Jakub Hrozek) Date: Sun, 7 Feb 2016 14:12:33 +0100 Subject: [Freeipa-users] IPA-AD Login In-Reply-To: References: <20160205083325.GU3654@hendrix.brq.redhat.com> Message-ID: <20160207131233.GI3654@hendrix.brq.redhat.com> On Fri, Feb 05, 2016 at 06:21:56PM -0600, Alan P wrote: > Thanks jhrozek, I have already seen it and applied to my IPA server, but it didn't have any significant impact, at least for AD users. In krb5kdc log, when I try to login with an IPA user in Windows, I can see the next: > > Feb 05 17:52:12 master.ipa.ad.example.com krb5kdc[14081](info): AS_REQ (6 etypes {18 17 23 24 -135 3}) 172.19.21.37: NEEDED_PREAUTH: ipa.user at IPA.AD.EXAMPLE.COM for krbtgt/IPA.AD.EXAMPLE.COM at IPA.AD.EXAMPLE.COM, Additional pre-authentication required > Feb 05 17:52:12 master.ipa.ad.example.com krb5kdc[14081](info): closing down fd 12 > Feb 05 17:52:12 master.ipa.ad.example.com krb5kdc[14081](info): AS_REQ (6 etypes {18 17 23 24 -135 3}) 172.19.21.37: ISSUE: authtime 1454716332, etypes {rep=18 tkt=18 ses=18}, ipa.user at IPA.AD.EXAMPLE.COM for krbtgt/IPA.AD.EXAMPLE.COM at IPA.AD.EXAMPLE.COM > Feb 05 17:52:12 master.ipa.ad.example.com krb5kdc[14081](info): closing down fd 12 > Feb 05 17:52:12 master.ipa.ad.example.com krb5kdc[14081](info): TGS_REQ (5 etypes {18 17 23 24 -135}) 172.19.21.37: ISSUE: authtime 1454716332, etypes {rep=18 tkt=18 ses=18}, ipa.user at IPA.AD.EXAMPLE.COM for krbtgt/AD.EXAMPLE.COM at IPA.AD.EXAMPLE.COM > Feb 05 17:52:12 master.ipa.ad.example.com krb5kdc[14081](info): closing down fd 12 > Feb 05 17:58:45 master.ipa.ad.example.com krb5kdc[14081](info): TGS_REQ (5 etypes {18 17 23 24 -135}) 172.19.21.37: ISSUE: authtime 1454716332, etypes {rep=18 tkt=18 ses=18}, ipa.user at IPA.AD.EXAMPLE.COM for cifs/master.ipa.ad.example.com at IPA.AD.EXAMPLE.COM > Feb 05 17:58:45 master.ipa.ad.example.com krb5kdc[14081](info): closing down fd 12 > Feb 05 17:58:47 master.ipa.ad.example.com krb5kdc[14081](info): TGS_REQ (5 etypes {18 17 23 24 -135}) 172.19.21.37: LOOKING_UP_SERVER: authtime 0, ipa.user at IPA.AD.EXAMPLE.COM for ProtectedStorage/master.ipa.ad.example.com at IPA.AD.EXAMPLE.COM, Server not found in Kerberos database > Feb 05 17:58:47 master.ipa.ad.example.com krb5kdc[14081](info): closing down fd 12 > > > In Windows, I can't find something related. > > Any other suggestion? Which part of the login is slow? Acquiring ticket with kinit or establishing the user groups etc? Usually it's the latter, so looking at sssd logs and checking what takes so long is the best way forward in most cases. You can also confirm if the group resolution takes a long time with: sss_cache -E; id $aduser at addomain From jbaird at follett.com Sun Feb 7 14:21:28 2016 From: jbaird at follett.com (Baird, Josh) Date: Sun, 7 Feb 2016 14:21:28 +0000 Subject: [Freeipa-users] IPA-AD Login In-Reply-To: <20160207131233.GI3654@hendrix.brq.redhat.com> References: <20160205083325.GU3654@hendrix.brq.redhat.com> <20160207131233.GI3654@hendrix.brq.redhat.com> Message-ID: It sounds like you are trying to login to Windows AD clients using IPA credentials? If so, I do not believe this functionality is currently supported. Thanks, Josh > -----Original Message----- > From: freeipa-users-bounces at redhat.com [mailto:freeipa-users- > bounces at redhat.com] On Behalf Of Jakub Hrozek > Sent: Sunday, February 07, 2016 8:13 AM > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] IPA-AD Login > > On Fri, Feb 05, 2016 at 06:21:56PM -0600, Alan P wrote: > > Thanks jhrozek, I have already seen it and applied to my IPA server, but it > didn't have any significant impact, at least for AD users. In krb5kdc log, when > I try to login with an IPA user in Windows, I can see the next: > > > > Feb 05 17:52:12 master.ipa.ad.example.com krb5kdc[14081](info): AS_REQ > > (6 etypes {18 17 23 24 -135 3}) 172.19.21.37: NEEDED_PREAUTH: > > ipa.user at IPA.AD.EXAMPLE.COM for > > krbtgt/IPA.AD.EXAMPLE.COM at IPA.AD.EXAMPLE.COM, Additional > > pre-authentication required Feb 05 17:52:12 master.ipa.ad.example.com > > krb5kdc[14081](info): closing down fd 12 Feb 05 17:52:12 > > master.ipa.ad.example.com krb5kdc[14081](info): AS_REQ (6 etypes {18 > > 17 23 24 -135 3}) 172.19.21.37: ISSUE: authtime 1454716332, etypes > > {rep=18 tkt=18 ses=18}, ipa.user at IPA.AD.EXAMPLE.COM for > > krbtgt/IPA.AD.EXAMPLE.COM at IPA.AD.EXAMPLE.COM > > Feb 05 17:52:12 master.ipa.ad.example.com krb5kdc[14081](info): > > closing down fd 12 Feb 05 17:52:12 master.ipa.ad.example.com > > krb5kdc[14081](info): TGS_REQ (5 etypes {18 17 23 24 -135}) > > 172.19.21.37: ISSUE: authtime 1454716332, etypes {rep=18 tkt=18 > > ses=18}, ipa.user at IPA.AD.EXAMPLE.COM for > > krbtgt/AD.EXAMPLE.COM at IPA.AD.EXAMPLE.COM > > Feb 05 17:52:12 master.ipa.ad.example.com krb5kdc[14081](info): > > closing down fd 12 Feb 05 17:58:45 master.ipa.ad.example.com > > krb5kdc[14081](info): TGS_REQ (5 etypes {18 17 23 24 -135}) > > 172.19.21.37: ISSUE: authtime 1454716332, etypes {rep=18 tkt=18 > > ses=18}, ipa.user at IPA.AD.EXAMPLE.COM for > > cifs/master.ipa.ad.example.com at IPA.AD.EXAMPLE.COM > > Feb 05 17:58:45 master.ipa.ad.example.com krb5kdc[14081](info): > > closing down fd 12 Feb 05 17:58:47 master.ipa.ad.example.com > > krb5kdc[14081](info): TGS_REQ (5 etypes {18 17 23 24 -135}) > > 172.19.21.37: LOOKING_UP_SERVER: authtime 0, > > ipa.user at IPA.AD.EXAMPLE.COM for > > ProtectedStorage/master.ipa.ad.example.com at IPA.AD.EXAMPLE.COM, > Server > > not found in Kerberos database Feb 05 17:58:47 > > master.ipa.ad.example.com krb5kdc[14081](info): closing down fd 12 > > > > > > In Windows, I can't find something related. > > > > Any other suggestion? > > Which part of the login is slow? Acquiring ticket with kinit or establishing > the user groups etc? Usually it's the latter, so looking at sssd logs and > checking what takes so long is the best way forward in most cases. You can > also confirm if the group resolution takes a long time with: > sss_cache -E; id $aduser at addomain > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project From abokovoy at redhat.com Sun Feb 7 18:56:48 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sun, 7 Feb 2016 20:56:48 +0200 Subject: [Freeipa-users] devconf.cz talks about FreeIPA Message-ID: <20160207185648.GD12787@redhat.com> Hi! Every year FreeIPA/SSSD/... developers gather together in Brno, Czech Republic at the beginning of February to participate in DevConf.cz, a local conference which originally started as Red Hat's event and grew quickly into one of biggest free software events in Eastern Europe. This year devconf.cz was also joined by JBoss conference and had up to 7 talks in parallel at the same time. Overall, there were 1200+ visitors on Friday and about 2/3 of that Saturday/Sunday. We had several talks related to FreeIPA and a practical workshop dedicated to deployment of FreeIPA and use of its features. Most of the sessions were streamed live and are now available on youtube. Below are some talks, I'm trying to give links to the time when actual talk did start as often streaming started by schedule: FreeIPA workshop by Torsted Scherf and German Parente Part1: https://youtu.be/cxRK1MExMsc?t=4m57s Part2: https://www.youtube.com/watch?v=RBzL1_3nKH4 Atomic, with and without Atomic, by Jan Pazdziora: https://youtu.be/SBQpYUXLR9I?t=2m20s Enterprise desktop at home with FreeIPA and GNOME, by yours truly: https://youtu.be/L_4oiNr_mVY?t=3m5s Integrating IdM with Red Hat Openstack: Improving security in the Cloud, by Ade Lee and Rob Crittenden: https://youtu.be/utQts81V8mA?t=9m21s Ipsilon: how to deploy federation, by Patrick Uiterwijk: https://youtu.be/_S5uT3RoZgY?t=2m12s New cryptography for binding data to third parties, by Nathaniel McCallum: https://www.youtube.com/watch?v=Ixo8iOpQsNQ?t=0m34s I may have well missed other talks that mentioned or used FreeIPA under the hood, so if you were at the conference or found something about the FreeIPA in other talks recorded by https://www.youtube.com/RedHatCzech, feel free to add to the list! Happy watching! -- / Alexander Bokovoy From abokovoy at redhat.com Sun Feb 7 19:05:29 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sun, 7 Feb 2016 21:05:29 +0200 Subject: [Freeipa-users] IPA-AD Login In-Reply-To: References: Message-ID: <20160207190529.GF12787@redhat.com> On Thu, 04 Feb 2016, Alan P wrote: >Hi, > >I just configured a trust between an IPA and an Active Directory to >authenticate IPA users in Windows machines joined in AD domain. The >login is successfull, but only after several minutes (nearly 25 >minutes) in the first attempt; in the next attempts, the required time >goes from 5 to 10 min. So, what can I do to reduce the time to >something more acceptable? (For reference, when an AD user >authenticates it only takes 10 seconds or less). Alan, this is not yet supported for multiple reasons. We just have worked on this with Michael Brown at DevConf.cz over this weekend and while we have had certain progress, it requires heavily patching several key components, including CyrusSASL library, 389-ds and FreeIPA. Worse to that, we need to write Global Catalog service support in FreeIPA to allow Windows machines to actually assign proper rights to IPA users. This is a plan for FreeIPA 4.4-4.5 releases. -- / Alexander Bokovoy From abokovoy at redhat.com Sun Feb 7 19:24:19 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sun, 7 Feb 2016 21:24:19 +0200 Subject: [Freeipa-users] devconf.cz talks about FreeIPA In-Reply-To: <20160207185648.GD12787@redhat.com> References: <20160207185648.GD12787@redhat.com> Message-ID: <20160207192419.GG12787@redhat.com> On Sun, 07 Feb 2016, Alexander Bokovoy wrote: >Hi! > >Every year FreeIPA/SSSD/... developers gather together in Brno, Czech >Republic at the beginning of February to participate in DevConf.cz, a >local conference which originally started as Red Hat's event and grew >quickly into one of biggest free software events in Eastern Europe. > >This year devconf.cz was also joined by JBoss conference and had up to 7 >talks in parallel at the same time. Overall, there were 1200+ visitors >on Friday and about 2/3 of that Saturday/Sunday. > >We had several talks related to FreeIPA and a practical workshop >dedicated to deployment of FreeIPA and use of its features. Most of the >sessions were streamed live and are now available on youtube. > >Below are some talks, I'm trying to give links to the time when actual >talk did start as often streaming started by schedule: > >FreeIPA workshop by Torsted Scherf and German Parente >Part1: https://youtu.be/cxRK1MExMsc?t=4m57s >Part2: https://www.youtube.com/watch?v=RBzL1_3nKH4 > >Atomic, with and without Atomic, by Jan Pazdziora: >https://youtu.be/SBQpYUXLR9I?t=2m20s > >Enterprise desktop at home with FreeIPA and GNOME, by yours truly: >https://youtu.be/L_4oiNr_mVY?t=3m5s > >Integrating IdM with Red Hat Openstack: Improving security in the Cloud, >by Ade Lee and Rob Crittenden: >https://youtu.be/utQts81V8mA?t=9m21s > >Ipsilon: how to deploy federation, by Patrick Uiterwijk: >https://youtu.be/_S5uT3RoZgY?t=2m12s > >New cryptography for binding data to third parties, by Nathaniel >McCallum: >https://www.youtube.com/watch?v=Ixo8iOpQsNQ?t=0m34s Forgot to mention -- if you don't see the talk when accessing it with a link above, press a "switch camera" button in right bottom corner -- Youtube has put the talks as 'separate camera streams' under the same streaming view, so some of the links may be misleading. I haven't found a how to get direct link to a specific camera view. -- / Alexander Bokovoy From abokovoy at redhat.com Sun Feb 7 19:26:23 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sun, 7 Feb 2016 21:26:23 +0200 Subject: [Freeipa-users] devconf.cz talks about FreeIPA In-Reply-To: <20160207185648.GD12787@redhat.com> References: <20160207185648.GD12787@redhat.com> Message-ID: <20160207192623.GH12787@redhat.com> On Sun, 07 Feb 2016, Alexander Bokovoy wrote: >Hi! > >Every year FreeIPA/SSSD/... developers gather together in Brno, Czech >Republic at the beginning of February to participate in DevConf.cz, a >local conference which originally started as Red Hat's event and grew >quickly into one of biggest free software events in Eastern Europe. > >This year devconf.cz was also joined by JBoss conference and had up to 7 >talks in parallel at the same time. Overall, there were 1200+ visitors >on Friday and about 2/3 of that Saturday/Sunday. > >We had several talks related to FreeIPA and a practical workshop >dedicated to deployment of FreeIPA and use of its features. Most of the >sessions were streamed live and are now available on youtube. > >Below are some talks, I'm trying to give links to the time when actual >talk did start as often streaming started by schedule: > >FreeIPA workshop by Torsted Scherf and German Parente >Part1: https://youtu.be/cxRK1MExMsc?t=4m57s >Part2: https://www.youtube.com/watch?v=RBzL1_3nKH4 > >Atomic, with and without Atomic, by Jan Pazdziora: >https://youtu.be/SBQpYUXLR9I?t=2m20s > >Enterprise desktop at home with FreeIPA and GNOME, by yours truly: >https://youtu.be/L_4oiNr_mVY?t=3m5s > >Integrating IdM with Red Hat Openstack: Improving security in the Cloud, >by Ade Lee and Rob Crittenden: >https://youtu.be/utQts81V8mA?t=9m21s > >Ipsilon: how to deploy federation, by Patrick Uiterwijk: >https://youtu.be/_S5uT3RoZgY?t=2m12s > >New cryptography for binding data to third parties, by Nathaniel >McCallum: >https://www.youtube.com/watch?v=Ixo8iOpQsNQ?t=0m34s ... the last one is actually https://www.youtube.com/watch?v=p_M0YEE-esA#t=34 > >I may have well missed other talks that mentioned or used FreeIPA under >the hood, so if you were at the conference or found something about the >FreeIPA in other talks recorded by https://www.youtube.com/RedHatCzech, >feel free to add to the list! > >Happy watching! > >-- >/ Alexander Bokovoy > >-- >Manage your subscription for the Freeipa-users mailing list: >https://www.redhat.com/mailman/listinfo/freeipa-users >Go to http://freeipa.org for more info on the project -- / Alexander Bokovoy From jhrozek at redhat.com Sun Feb 7 21:03:58 2016 From: jhrozek at redhat.com (Jakub Hrozek) Date: Sun, 7 Feb 2016 22:03:58 +0100 Subject: [Freeipa-users] IPA-AD Login In-Reply-To: References: <20160205083325.GU3654@hendrix.brq.redhat.com> <20160207131233.GI3654@hendrix.brq.redhat.com> Message-ID: <20160207210358.GL3654@hendrix.brq.redhat.com> On Sun, Feb 07, 2016 at 02:21:28PM +0000, Baird, Josh wrote: > It sounds like you are trying to login to Windows AD clients using IPA credentials? > > If so, I do not believe this functionality is currently supported. You're right, for some reason I completely missed that. Thanks for noticing! From coy.hile at coyhile.com Sun Feb 7 21:27:29 2016 From: coy.hile at coyhile.com (Coy Hile) Date: Sun, 7 Feb 2016 16:27:29 -0500 Subject: [Freeipa-users] IPA-AD Login In-Reply-To: <20160207190529.GF12787@redhat.com> References: <20160207190529.GF12787@redhat.com> Message-ID: <76213C78-8367-4E5D-8CE9-4FE11301A20B@coyhile.com> > On Feb 7, 2016, at 2:05 PM, Alexander Bokovoy wrote: > > On Thu, 04 Feb 2016, Alan P wrote: >> Hi, >> >> I just configured a trust between an IPA and an Active Directory to >> authenticate IPA users in Windows machines joined in AD domain. The >> login is successfull, but only after several minutes (nearly 25 >> minutes) in the first attempt; in the next attempts, the required time >> goes from 5 to 10 min. So, what can I do to reduce the time to >> something more acceptable? (For reference, when an AD user >> authenticates it only takes 10 seconds or less). > Alan, this is not yet supported for multiple reasons. We just have > worked on this with Michael Brown at DevConf.cz over this weekend and > while we have had certain progress, it requires heavily patching several > key components, including CyrusSASL library, 389-ds and FreeIPA. Worse > to that, we need to write Global Catalog service support in FreeIPA to > allow Windows machines to actually assign proper rights to IPA users. > Wouldn?t a somewhat easier solution for dealing with Windows be to create a one-way trust so that the AD domain trusts the IPA realm? Then use AltSecurityID in Windows land to map a ?shadow? user to each real principal? In that way AD gets relegated to a second-class citizen used only for the subset of (likely comparatively unimportant) tasks where one is forced to use Windows? -- Coy Hile coy.hile at coyhile.com From jcholast at redhat.com Mon Feb 8 06:27:36 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 8 Feb 2016 07:27:36 +0100 Subject: [Freeipa-users] Using external certificate in IPA 4.1 In-Reply-To: <56B3801A.1070508@redhat.com> References: <56B232B7.60306@shardi.fi> <56B3801A.1070508@redhat.com> Message-ID: <56B83558.20501@redhat.com> Hi, On 4.2.2016 17:45, Martin Kosek wrote: > On 02/03/2016 06:02 PM, Ossi Ahosalmi wrote: >> I'm trying to use our organizations wildcard certificate in IPA. Certificate is >> signed by a trusted CA. >> >> Running: >> ipa-server-certinstall -w -d >> >> with next combinations: >> >> - separate .key, .crt and ca chain, all in PEM format >> - .crt and ca bundled into one file, .key as a separate file >> - everything bundled together into one .p12 pkcs12 file >> >> I always end up with this error: >> >> "The full certificate chain is not present in ." >> >> My CA file contains the whole chain and works in all other programs, just not >> in IPA. >> >> > > CCing Jan, but I think you are hitting > https://fedorahosted.org/freeipa/ticket/5603 Actually I think it's #4786, but if that was fixed, you would hit #5603 as well. Honza -- Jan Cholasta From rcritten at redhat.com Mon Feb 8 10:28:48 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 8 Feb 2016 11:28:48 +0100 Subject: [Freeipa-users] IPA 4.2: pki-tomcatd in terrible shape In-Reply-To: References: Message-ID: <56B86DE0.4070909@redhat.com> Timothy Geier wrote: > Greetings all, > > For the record,this is a CentOS 7.2 box with all current patches. (ipa-server-4.2.0-15.el7.centos.3.x86_64, etc.) > > The situation is that pki-tomcatd on the lone CA server in our IPA cluster refuses to start cleanly. The issues started earlier this week after the certs > subsystemCert, ocspSigningCert, and auditSigningCert all simultaneously expired without warning; apparently, certmonger failed to renew them automatically. We > attempted timeshifting and following instructions for what appeared to be similar issues, but nothing at all has worked. > > Today, we attempted removing the certificates in question (of course, the files in /etc/pki/pki-tomcat/alias were backed up beforehand) and using certutil to issue new certificates. This process worked but pki-tomcatd is still refusing to start. We can get IPA to run on this server by manually starting pki-tomcatd, running ipactl start, and then ctrl-c?ing it when it gets to "Starting pki-tomcatd" but this is not a tenable long-term solution. > > Relevant log entries/information: > > /var/log/pki/pki-tomcat/ca/debug: > Could not connect to LDAP server host ipa01.XXXXXXXXX.net port 636 Error netscape.ldap.LDAPException: IO Error creating JSS SSL Socket (-1) > Internal Database Error encountered: Could not connect to LDAP server host ipa01.XXXXXXXXX.net port 636 Error netscape.ldap.LDAPException: IO Error creating JSS SSL Socket (-1) > Internal Database Error encountered: Could not connect to LDAP server host ipa01.XXXXXXXXX.net port 636 Error netscape.ldap.LDAPException: Authentication failed (49) > > /var/log/pki/pki-tomcat/localhost.2016-02-04.log: > org.apache.catalina.core.StandardContext loadOnStartup > SEVERE: Servlet /ca threw load() exception > java.lang.NullPointerException > > # getcert list: > > Number of certificates and requests being tracked: 8. > Request ID '20151015022737': > status: MONITORING > ca-error: Error setting up ccache for "host" service on client using default keytab: Generic error (see e-text). > stuck: no > key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-XXXXXXXXX-NET',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-XXXXXXXXX-NET/pwdfile.txt' > expires: 2017-10-15 02:09:06 UTC > track: yes > auto-renew: yes > Request ID '20151015022949': > status: MONITORING > ca-error: Error setting up ccache for "host" service on client using default keytab: Generic error (see e-text). > stuck: no > key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' > expires: 2017-10-15 02:09:10 UTC > track: yes > auto-renew: yes > Request ID '20160127202548': > status: MONITORING > stuck: no > key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert cert-pki-ca',token='NSS Certificate DB',pin set > certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert cert-pki-ca',token='NSS Certificate DB' > expires: 2034-02-11 19:46:43 UTC > track: yes > auto-renew: yes > Request ID '20160127202549': > status: MONITORING > 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' > expires: 2017-12-25 04:27:49 UTC > key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > track: yes > auto-renew: yes > Request ID '20160127202550': > status: MONITORING > ca-error: Server at "http://ipa01.XXXXXXXXX.net:8080/ca/ee/ca/profileSubmit" replied: Profile caServerCert Not Found > stuck: no > key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='Server-Cert cert-pki-ca',token='NSS Certificate DB',pin set > certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='Server-Cert cert-pki-ca',token='NSS Certificate DB' > expires: 2017-10-04 02:28:53 UTC > track: yes > auto-renew: yes > Request ID '20160204165453': > status: MONITORING > stuck: no > key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB',pin set > certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB' > expires: 2016-05-04 16:40:23 UTC > track: yes > auto-renew: yes > Request ID '20160204170246': > status: MONITORING > stuck: no > key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB',pin set > certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB' > expires: 2016-05-04 16:59:18 UTC > track: yes > auto-renew: yes > Request ID '20160204170752': > status: MONITORING > stuck: no > key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB',pin set > certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB' > expires: 2016-05-04 17:05:29 UTC > track: yes > auto-renew: yes > > # certutil -L -d /var/lib/pki/pki-tomcat/alias/ > > Certificate Nickname Trust Attributes > SSL,S/MIME,JAR/XPI > auditSigningCert cert-pki-ca u,u,Pu > ocspSigningCert cert-pki-ca u,u,u > caSigningCert cert-pki-ca CTu,Cu,Cu > subsystemCert cert-pki-ca u,u,u > Server-Cert cert-pki-ca u,u,u > > # certutil -L -d /etc/dirsrv/slapd-XXXXXXXXX-NET/ > > Certificate Nickname Trust Attributes > SSL,S/MIME,JAR/XPI > Server-Cert u,u,u > XXXXXXXXX.NET IPA CA CT,C,C > > > > The only thing that making new certs seemed to resolve was removing these errors from /var/log/pki/pki-tomcat/ca/system : > > Cannot authenticate agent with certificate Serial Subject DN CN=IPA RA,O=XXXXXXXXX.NET. Error: User not found > > Thus, the root cause(s) appears to be something else entirely that we are totally unfamilar with..we can provide any other required information to help with troubleshooting. It appears that the CA is not fully starting, perhaps due to these renewal issues, perhaps something else. You'll need to dig into the logs. I'd start with /var/lib/pki/pki-ca/pki-tomcat/logs/debug and selftests.log. You mentioned privately that you renamed the IPA host. This is probably what broke half of the renewals. The hosts and keytabs and many entries in IPA have the hostname baked in so you can't simply rename the host. rob From sbose at redhat.com Mon Feb 8 12:53:41 2016 From: sbose at redhat.com (Sumit Bose) Date: Mon, 8 Feb 2016 13:53:41 +0100 Subject: [Freeipa-users] PKINIT support in FreeIPA 4.2.0 In-Reply-To: References: <20160203090821.GD20953@p.redhat.com> Message-ID: <20160208125341.GD13133@p.redhat.com> On Thu, Feb 04, 2016 at 07:25:29PM +1100, Nik Lam wrote: > On Wed, Feb 3, 2016 at 8:08 PM, Sumit Bose wrote: > > > On Wed, Feb 03, 2016 at 10:29:49AM +1100, Nik Lam wrote: > > > Hello, > > > > > > I installed ipa-server on Centos 7.1 and later did and upgrade of the > > whole > > > system to Centos 7.2. > > > > > > I think the FreeIPA version changed from 4.1.0 to 4.2.0 between these > > > Centos/RHEL minor releases. > > > > > > We'd now like to try integrating with a 2FA provider via a radius proxy > > and > > > want to use anonymous PKINIT to secure the initial communications between > > > the client and the KDC. > > > > > > We've tried following the MIT Kerberos PKINIT configuration documentation > > > > > > http://web.mit.edu/kerberos/krb5-1.14/doc/admin/pkinit.html > > > > > > generating our own certs manually with openssl but haven't had any luck. > > > We're seeing this in the kdc log: > > > > > > preauth pkinit failed to initialize: No realms configured correctly > > for > > > pkinit support > > > > Which changes did you apply to krb5.conf? Did you use the IPA CA to sign > > the certificate or some other CA? > > > > > > > > I've noticed there are many new pkinit-related options that have been > > added > > > to the ipa-server-install script in 4.2.0, so it looks like PKINIT is > > > available in this version of FreeIPA. Is that the case? > > > > Which options are you referring to? > > > > bye, > > Sumit > > > > > > > > And if it is, what is the recommended way to enable it given that it > > seems > > > to have been disabled in the original install that I did? Or would it > > just > > > be easier to start from scratch with a 4.2.0 ipa-server-install? (It's a > > > test instance that doesn't have too much in it - it will take a several > > > hours to rebuild from scratch.) > > > > > > Regards, > > > > > > Nik > > > > > > > Thanks Sumit. > > It sounds like PKINIT is available but clearly I'm doing it wrong. > > > Which changes did you apply to krb5.conf? Did you use the IPA CA to sign > the certificate or some other CA? > > Actually, I modified the kdc.conf file - placed the kdc.pem, kdckey.pem and > cacert.pem files in /var/kerberos/krb5kdc/ that I generated via openssl > commands in the MIT Kerberos documentation. The only change to kdc.conf > file was to append the location of the kdckey.pem file to pkinit_identity. > > pkinit_identity = FILE:/var/kerberos/krb5kdc/kdc.pem > pkinit_anchors = FILE:/var/kerberos/krb5kdc/cacert.pem > > became > > pkinit_identity = > FILE:/var/kerberos/krb5kdc/kdc.pem,/var/kerberos/krb5kdc/kdckey.pem > pkinit_anchors = FILE:/var/kerberos/krb5kdc/cacert.pem > > Should I have been modifying krb5.conf instead? It aslo sounds like I need no, kdc.conf is the right place, I actually meant kdc.conf but accidentially types krb5.conf. > to use a certificate signed by the IPAs CA - is this something that should > be generated using ipa-getcert? Or do I just find the IPA CA's private key > and use openssl following the MIT Kerberos documentation? > > > Which options are you referring to? > > When I looked at the --help text for 4.1.0 and 4.2.0 versions of > ipa-server-install, I noticed that 4.2.0 has these in the "certificate > system options": > > --no-pkinit disables pkinit setup steps > > --pkinit-cert-file=FILE > File containing the Kerberos KDC SSL certificate and > private key > > --pkinit-pin=PIN The password to unlock the Kerberos KDC private key > > --pkinit-cert-name=NAME > Name of the Kerberos KDC SSL certificate to install > > > Seeing that first one, I was a little hopeful that pkinit is enabled by > default in 4.2.0 but on a fresh install I just tried, I'm still seeing the no, unfortunately pkinit is currently disabled by default > following in krb5kdc.log when IPA is started up, so clearly it isn't. > > (Error): preauth pkinit failed to initialize: No realms configured > correctly for pkinit support I get the same error when I put the certificate and the key into separate files. Can you try to put both into one and use this for the pkinit_identity option? HTH bye, Sumit > > Regards, > > Nik From jlee2285 at gmail.com Wed Feb 3 17:17:46 2016 From: jlee2285 at gmail.com (Josh Pospisil) Date: Wed, 3 Feb 2016 11:17:46 -0600 Subject: [Freeipa-users] FreeIPA / AD Trust Relationship Message-ID: I have successfully set up a trust between AD (windows server 2012) and freeIPA following this guide: http://www.freeipa.org/page/Active_Directory_trust_setup My hope in doing this was to allow the users I have created on the freeIPA server to logon to our windows computers without recreating all of the users in AD, but this is not working. Can anyone verify whether or not this should be true or does the trust only work the opposite direction? If it should be true, can anyone offer any tips for troubleshooting? When I try to verify the trust on the AD server, I get the following error: "There are currently no logon servers available to service the logon request." Dns was setup as described in the guide above. Thanks in advance for any help. Josh -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbose at redhat.com Mon Feb 8 13:28:18 2016 From: sbose at redhat.com (Sumit Bose) Date: Mon, 8 Feb 2016 14:28:18 +0100 Subject: [Freeipa-users] FreeIPA / AD Trust Relationship In-Reply-To: References: Message-ID: <20160208132818.GF13133@p.redhat.com> On Wed, Feb 03, 2016 at 11:17:46AM -0600, Josh Pospisil wrote: > I have successfully set up a trust between AD (windows server 2012) and > freeIPA following this guide: > http://www.freeipa.org/page/Active_Directory_trust_setup > > My hope in doing this was to allow the users I have created on the freeIPA > server to logon to our windows computers without recreating all of the > users in AD, but this is not working. Can anyone verify whether or not > this should be true or does the trust only work the opposite direction? If > it should be true, can anyone offer any tips for troubleshooting? no, this is currently not possible because a Global Catalog is needed on the FreeIPA side. This is currently work-in-progress and tracked by https://fedorahosted.org/freeipa/ticket/3125 . > > When I try to verify the trust on the AD server, I get the following error: > "There are currently no logon servers available to service the logon > request." > > Dns was setup as described in the guide above. Did you open all the firewall ports listed at the end of ipa-adtrust-install? HTH bye, Sumit > > Thanks in advance for any help. > > > Josh > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project From jbaird at follett.com Mon Feb 8 13:30:17 2016 From: jbaird at follett.com (Baird, Josh) Date: Mon, 8 Feb 2016 13:30:17 +0000 Subject: [Freeipa-users] FreeIPA / AD Trust Relationship In-Reply-To: References: Message-ID: No, logging into Windows AD clients using IPA credentials is not currently supported. This functionality is currently under development. See this thread [1] for more information. [1] https://www.redhat.com/archives/freeipa-users/2016-February/msg00119.html Josh From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Josh Pospisil Sent: Wednesday, February 03, 2016 12:18 PM To: freeipa-users at redhat.com Subject: [Freeipa-users] FreeIPA / AD Trust Relationship I have successfully set up a trust between AD (windows server 2012) and freeIPA following this guide: http://www.freeipa.org/page/Active_Directory_trust_setup My hope in doing this was to allow the users I have created on the freeIPA server to logon to our windows computers without recreating all of the users in AD, but this is not working. Can anyone verify whether or not this should be true or does the trust only work the opposite direction? If it should be true, can anyone offer any tips for troubleshooting? When I try to verify the trust on the AD server, I get the following error: "There are currently no logon servers available to service the logon request." Dns was setup as described in the guide above. Thanks in advance for any help. Josh -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjaalton at ubuntu.com Mon Feb 8 15:56:36 2016 From: tjaalton at ubuntu.com (Timo Aaltonen) Date: Mon, 8 Feb 2016 17:56:36 +0200 Subject: [Freeipa-users] [freeipa-users] Configuring Automount on Ubuntu Clients In-Reply-To: References: Message-ID: <56B8BAB4.2080007@ubuntu.com> 04.02.2016, 19:28, Jon kirjoitti: > Is Ubuntu not supported with FreeIPA? Is there an updated install > script? I installed the freeipa-client from public repos. > >>> ii freeipa-client > 3.3.4-0ubuntu3.1 amd64 > FreeIPA centralized identity framework -- client >>> ii python-freeipa > 3.3.4-0ubuntu3.1 amd64 > FreeIPA centralized identity framework -- python modules The stock packages in 14.04 are rather old, you'd probably be happier with the 4.0.5-based client available on the PPA: https://launchpad.net/~freeipa/+archive/ubuntu/4.0 -- t From filip at pytloun.cz Mon Feb 8 17:05:05 2016 From: filip at pytloun.cz (Filip Pytloun) Date: Mon, 8 Feb 2016 18:05:05 +0100 Subject: [Freeipa-users] Failed to setup replica, slapi_ldap_bind fails Message-ID: <20160208170505.GE4331@eru> Hello, I have a weird issue setting up FreeIPA replica. Conncheck passes fine but at the end of ipa-replica-install I always get following error: slapi_ldap_bind -Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) on both master and replica without any further explanation in logs. /etc/ldap.conf is correctly setup before ipa-replica-install and IPA CA certificate is installed in system CA bundle so TLS should work just fine. Also I can manually connect just fine from replica to master and back so it's not a network or LDAP client issue. Replica agreement looks like this: http://pastebin.com/FT3p3KUk freeipa-server 4.1.4 389-ds 1.3.4.5 Has anyone idea where to look at? Filip -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From tgeier at accertify.com Mon Feb 8 17:49:05 2016 From: tgeier at accertify.com (Timothy Geier) Date: Mon, 8 Feb 2016 17:49:05 +0000 Subject: [Freeipa-users] IPA 4.2: pki-tomcatd in terrible shape In-Reply-To: <56B86DE0.4070909@redhat.com> References: <56B86DE0.4070909@redhat.com> Message-ID: <7F0EB8FC-8F2F-49D1-A124-562B5B0A55A2@accertify.com> On Feb 8, 2016, at 4:28 AM, Rob Crittenden > wrote: Timothy Geier wrote: Greetings all, For the record,this is a CentOS 7.2 box with all current patches. (ipa-server-4.2.0-15.el7.centos.3.x86_64, etc.) The situation is that pki-tomcatd on the lone CA server in our IPA cluster refuses to start cleanly. The issues started earlier this week after the certs subsystemCert, ocspSigningCert, and auditSigningCert all simultaneously expired without warning; apparently, certmonger failed to renew them automatically. We attempted timeshifting and following instructions for what appeared to be similar issues, but nothing at all has worked. Today, we attempted removing the certificates in question (of course, the files in /etc/pki/pki-tomcat/alias were backed up beforehand) and using certutil to issue new certificates. This process worked but pki-tomcatd is still refusing to start. We can get IPA to run on this server by manually starting pki-tomcatd, running ipactl start, and then ctrl-c?ing it when it gets to "Starting pki-tomcatd" but this is not a tenable long-term solution. Relevant log entries/information: /var/log/pki/pki-tomcat/ca/debug: Could not connect to LDAP server host ipa01.XXXXXXXXX.net port 636 Error netscape.ldap.LDAPException: IO Error creating JSS SSL Socket (-1) Internal Database Error encountered: Could not connect to LDAP server host ipa01.XXXXXXXXX.net port 636 Error netscape.ldap.LDAPException: IO Error creating JSS SSL Socket (-1) Internal Database Error encountered: Could not connect to LDAP server host ipa01.XXXXXXXXX.net port 636 Error netscape.ldap.LDAPException: Authentication failed (49) /var/log/pki/pki-tomcat/localhost.2016-02-04.log: org.apache.catalina.core.StandardContext loadOnStartup SEVERE: Servlet /ca threw load() exception java.lang.NullPointerException # getcert list: Number of certificates and requests being tracked: 8. Request ID '20151015022737': status: MONITORING ca-error: Error setting up ccache for "host" service on client using default keytab: Generic error (see e-text). stuck: no key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-XXXXXXXXX-NET',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-XXXXXXXXX-NET/pwdfile.txt' expires: 2017-10-15 02:09:06 UTC track: yes auto-renew: yes Request ID '20151015022949': status: MONITORING ca-error: Error setting up ccache for "host" service on client using default keytab: Generic error (see e-text). stuck: no key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' expires: 2017-10-15 02:09:10 UTC track: yes auto-renew: yes Request ID '20160127202548': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert cert-pki-ca',token='NSS Certificate DB',pin set certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert cert-pki-ca',token='NSS Certificate DB' expires: 2034-02-11 19:46:43 UTC track: yes auto-renew: yes Request ID '20160127202549': status: MONITORING 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' expires: 2017-12-25 04:27:49 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment track: yes auto-renew: yes Request ID '20160127202550': status: MONITORING ca-error: Server at "http://ipa01.XXXXXXXXX.net:8080/ca/ee/ca/profileSubmit" replied: Profile caServerCert Not Found stuck: no key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='Server-Cert cert-pki-ca',token='NSS Certificate DB',pin set certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='Server-Cert cert-pki-ca',token='NSS Certificate DB' expires: 2017-10-04 02:28:53 UTC track: yes auto-renew: yes Request ID '20160204165453': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB',pin set certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB' expires: 2016-05-04 16:40:23 UTC track: yes auto-renew: yes Request ID '20160204170246': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB',pin set certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB' expires: 2016-05-04 16:59:18 UTC track: yes auto-renew: yes Request ID '20160204170752': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB',pin set certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB' expires: 2016-05-04 17:05:29 UTC track: yes auto-renew: yes # certutil -L -d /var/lib/pki/pki-tomcat/alias/ Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI auditSigningCert cert-pki-ca u,u,Pu ocspSigningCert cert-pki-ca u,u,u caSigningCert cert-pki-ca CTu,Cu,Cu subsystemCert cert-pki-ca u,u,u Server-Cert cert-pki-ca u,u,u # certutil -L -d /etc/dirsrv/slapd-XXXXXXXXX-NET/ Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI Server-Cert u,u,u XXXXXXXXX.NET IPA CA CT,C,C The only thing that making new certs seemed to resolve was removing these errors from /var/log/pki/pki-tomcat/ca/system : Cannot authenticate agent with certificate Serial Subject DN CN=IPA RA,O=XXXXXXXXX.NET. Error: User not found Thus, the root cause(s) appears to be something else entirely that we are totally unfamilar with..we can provide any other required information to help with troubleshooting. It appears that the CA is not fully starting, perhaps due to these renewal issues, perhaps something else. You'll need to dig into the logs. I'd start with /var/lib/pki/pki-ca/pki-tomcat/logs/debug and selftests.log. The debug log has a lot of instances of: Could not connect to LDAP server host xxx.xxxx port 636 Error netscape.ldap.LDAPException: IO Error creating JSS SSL Socket (-1) Internal Database Error encountered: Could not connect to LDAP server host xxx.xxxx port 636 Error netscape.ldap.LDAPException: IO Error creating JSS SSL Socket (-1) but nothing else of note other than those errors. We?ve also noticed lots of 500 errors in /var/log/pki/pki-tomcat/localhost_access.log [08/Feb/2016:10:34:29 -0600] "GET /ca/ee/ca/profileSubmit?profileId=caServerCert&serial_num=5&renewal=true&xml=true HTTP/1.1" 500 2134 [08/Feb/2016:10:34:32 -0600] "GET /ca/ee/ca/profileSubmit?profileId=caServerCert&serial_num=2&renewal=true&xml=true HTTP/1.1" 500 2134 [08/Feb/2016:10:34:50 -0600] "GET /ca/ee/ca/profileSubmit?profileId=caServerCert&serial_num=4&renewal=true&xml=true HTTP/1.1" 500 2134 which looks like certmonger is continuously trying to renew the 3 certs. These dates and times from selftests.log are not accurate and are from an earlier attempt to renew the certs while time shifted: 0.localhost-startStop-1 - [15/Jan/2016:17:39:34 CST] [20] [1] SelfTestSubsystem: Initializing self test plugins: 0.localhost-startStop-1 - [15/Jan/2016:17:39:34 CST] [20] [1] SelfTestSubsystem: loading all self test plugin logger parameters 0.localhost-startStop-1 - [15/Jan/2016:17:39:34 CST] [20] [1] SelfTestSubsystem: loading all self test plugin instances 0.localhost-startStop-1 - [15/Jan/2016:17:39:34 CST] [20] [1] SelfTestSubsystem: loading all self test plugin instance parameters 0.localhost-startStop-1 - [15/Jan/2016:17:39:34 CST] [20] [1] SelfTestSubsystem: loading self test plugins in on-demand order 0.localhost-startStop-1 - [15/Jan/2016:17:39:34 CST] [20] [1] SelfTestSubsystem: loading self test plugins in startup order 0.localhost-startStop-1 - [15/Jan/2016:17:39:34 CST] [20] [1] SelfTestSubsystem: Self test plugins have been successfully loaded! 0.localhost-startStop-1 - [15/Jan/2016:17:39:38 CST] [20] [1] SelfTestSubsystem: Running self test plugins specified to be executed at startup: 0.localhost-startStop-1 - [15/Jan/2016:17:39:38 CST] [20] [1] CAPresence: CA is present 0.localhost-startStop-1 - [15/Jan/2016:17:39:38 CST] [20] [1] SystemCertsVerification: system certs verification success 0.localhost-startStop-1 - [15/Jan/2016:17:39:38 CST] [20] [1] SelfTestSubsystem: All CRITICAL self test plugins ran SUCCESSFULLY at startup! There?s nothing in that log with any February dates, so when we try to start pki-tomcatd in real time, it's likely not even getting this far. You mentioned privately that you renamed the IPA host. This is probably what broke half of the renewals. The hosts and keytabs and many entries in IPA have the hostname baked in so you can't simply rename the host. Technically, the host wasn?t renamed; a new CentOS 7 host was added to the existing IPA cluster that had 4 hosts (1 master CA) at CentOS 6 (using the documentation at https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html), it was promoted to the master CA, all of the C6 hosts were decommissioned/removed from replication, and then a new set of C7 hosts were created and added as replicas. Is this the correct procedure to follow when time shifted? - Stop IPA - Change the system clock (and the hardware clock) to a point before the expiration - Start IPA - Run getcert resubmit on the appropriate request IDs - Stop IPA - Return to real time - Start IPA We haven?t tried it this week yet but all attempts at it last week failed without any indication as to why the certs weren?t renewing; are there any other logs to check/other steps in the procedure? Thanks much, rob "This message and any attachments may contain confidential information. If you have received this message in error, any use or distribution is prohibited. Please notify us by reply e-mail if you have mistakenly received this message, and immediately and permanently delete it and any attachments. Thank you." -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at pakos.pl Mon Feb 8 19:38:14 2016 From: peter at pakos.pl (Peter Pakos) Date: Mon, 8 Feb 2016 19:38:14 +0000 Subject: [Freeipa-users] FreeIPA Consistency Checker In-Reply-To: <56B13F53.6020908@pakos.pl> References: <56B13F53.6020908@pakos.pl> Message-ID: <56B8EEA6.4020804@pakos.pl> Just a quick heads-up, The newest version of the ipa_check_consistency script comes with Nagios/Opsview plug-in functionality and some further improvements. Feel free to take it for a spin! https://github.com/peterpakos/ipa_check_consistency -- Kind regards, Peter Pakos From peter at pakos.pl Mon Feb 8 23:26:36 2016 From: peter at pakos.pl (Peter Pakos) Date: Mon, 8 Feb 2016 23:26:36 +0000 Subject: [Freeipa-users] CA-less vs CA-ful FreeIPA 4.2 installation Message-ID: <56B9242C.9020201@pakos.pl> Hi, I now have a CA-less installation of FreeIPA 4.2 which seems to be working OK. The initial server was installed with the following command: ipa-server-install \ -U \ -r IPA.WANDISCO.COM \ -n ipa.wandisco.com \ -p '********' \ -a '********' \ --mkhomedir \ --setup-dns \ --no-forwarders \ --no-dnssec-validation \ --dirsrv-cert-file=/root/ssl/GandiWildcardIPA.pfx \ --dirsrv-pin='********' \ --http-cert-file=/root/ssl/GandiWildcardIPA.pfx \ --http-pin='********' \ --dirsrv-cert-name=GandiWildcardIPA \ --http-cert-name=GandiWildcardIPA \ --idstart=1100 \ --ca-cert-file=/root/ssl/star.ipa.wandisco.com.crt Both LDAP and HTTP certificates are correctly installed. My question is, how do I renew LDAP/HTTP certificates? I'm struggling to find a step-by-step instructions on how to do this without breaking anything. This is one of the last tests I need to perform before moving this FreeIPA setup into production. Any info is greatly appreciated. -- Kind regards, Peter Pakos From jcholast at redhat.com Tue Feb 9 06:34:31 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 9 Feb 2016 07:34:31 +0100 Subject: [Freeipa-users] CA-less vs CA-ful FreeIPA 4.2 installation In-Reply-To: <56B9242C.9020201@pakos.pl> References: <56B9242C.9020201@pakos.pl> Message-ID: <56B98877.5030102@redhat.com> Hi Peter, On 9.2.2016 00:26, Peter Pakos wrote: > Hi, > > I now have a CA-less installation of FreeIPA 4.2 which seems to be > working OK. > > The initial server was installed with the following command: > > ipa-server-install \ > -U \ > -r IPA.WANDISCO.COM \ > -n ipa.wandisco.com \ > -p '********' \ > -a '********' \ > --mkhomedir \ > --setup-dns \ > --no-forwarders \ > --no-dnssec-validation \ > --dirsrv-cert-file=/root/ssl/GandiWildcardIPA.pfx \ > --dirsrv-pin='********' \ > --http-cert-file=/root/ssl/GandiWildcardIPA.pfx \ > --http-pin='********' \ > --dirsrv-cert-name=GandiWildcardIPA \ > --http-cert-name=GandiWildcardIPA \ > --idstart=1100 \ > --ca-cert-file=/root/ssl/star.ipa.wandisco.com.crt > > Both LDAP and HTTP certificates are correctly installed. > > My question is, how do I renew LDAP/HTTP certificates? > > I'm struggling to find a step-by-step instructions on how to do this > without breaking anything. > > This is one of the last tests I need to perform before moving this > FreeIPA setup into production. > > Any info is greatly appreciated. > Currently you have to manually replace the certificates once you manually renew them with your CA. To replace the certificates, follow the guide I posted a month ago: . Honza -- Jan Cholasta From pspacek at redhat.com Tue Feb 9 08:46:14 2016 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 9 Feb 2016 09:46:14 +0100 Subject: [Freeipa-users] FreeIPA Consistency Checker In-Reply-To: <56B8EEA6.4020804@pakos.pl> References: <56B13F53.6020908@pakos.pl> <56B8EEA6.4020804@pakos.pl> Message-ID: <56B9A756.8000506@redhat.com> On 8.2.2016 20:38, Peter Pakos wrote: > Just a quick heads-up, > > The newest version of the ipa_check_consistency script comes with > Nagios/Opsview plug-in functionality and some further improvements. > > Feel free to take it for a spin! > > https://github.com/peterpakos/ipa_check_consistency Hi! This is an interesting script. BTW an effective way how to count entries in LDAP is to request base entry and ask for 'numSubordinates' attribute, it contains number of child entries (on that particular level, it does not count recursively). Following should work, but I did not test it :-) ldapsearch -LLLx -h "${server}.${DOMAIN}" \ -D "$BINDDN" -w "$BINDPW" -b "cn=groups,cn=accounts,${SUFFIX}" -s base \ "(objectClass=*)" "numSubordinates" 2>/dev/null \ It will be way way way faster and you will be able to eradicate Perl, which is always a good thing :-) -- Petr^2 Spacek From rcritten at redhat.com Tue Feb 9 08:58:59 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 9 Feb 2016 09:58:59 +0100 Subject: [Freeipa-users] IPA 4.2: pki-tomcatd in terrible shape In-Reply-To: <7F0EB8FC-8F2F-49D1-A124-562B5B0A55A2@accertify.com> References: <56B86DE0.4070909@redhat.com> <7F0EB8FC-8F2F-49D1-A124-562B5B0A55A2@accertify.com> Message-ID: <56B9AA53.1000400@redhat.com> Timothy Geier wrote: > > > The debug log has a lot of instances of: > > Could not connect to LDAP server host xxx.xxxx port 636 Error > netscape.ldap.LDAPException: IO Error creating JSS SSL Socket (-1) > Internal Database Error encountered: Could not connect to LDAP server > host xxx.xxxx port 636 Error netscape.ldap.LDAPException: IO Error > creating JSS SSL Socket (-1) The 389-ds access log may show connection attempts and you might be able to correlate from there. > but nothing else of note other than those errors. > > We?ve also noticed lots of 500 errors in > /var/log/pki/pki-tomcat/localhost_access.log > [08/Feb/2016:10:34:29 -0600] "GET > /ca/ee/ca/profileSubmit?profileId=caServerCert&serial_num=5&renewal=true&xml=true > HTTP/1.1" 500 2134 > [08/Feb/2016:10:34:32 -0600] "GET > /ca/ee/ca/profileSubmit?profileId=caServerCert&serial_num=2&renewal=true&xml=true > HTTP/1.1" 500 2134 > [08/Feb/2016:10:34:50 -0600] "GET > /ca/ee/ca/profileSubmit?profileId=caServerCert&serial_num=4&renewal=true&xml=true > HTTP/1.1" 500 2134 > > which looks like certmonger is continuously trying to renew the 3 certs. > > These dates and times from selftests.log are not accurate and are from > an earlier attempt to renew the certs while time shifted: > > 0.localhost-startStop-1 - [15/Jan/2016:17:39:34 CST] [20] [1] > SelfTestSubsystem: Initializing self test plugins: > 0.localhost-startStop-1 - [15/Jan/2016:17:39:34 CST] [20] [1] > SelfTestSubsystem: loading all self test plugin logger parameters > 0.localhost-startStop-1 - [15/Jan/2016:17:39:34 CST] [20] [1] > SelfTestSubsystem: loading all self test plugin instances > 0.localhost-startStop-1 - [15/Jan/2016:17:39:34 CST] [20] [1] > SelfTestSubsystem: loading all self test plugin instance parameters > 0.localhost-startStop-1 - [15/Jan/2016:17:39:34 CST] [20] [1] > SelfTestSubsystem: loading self test plugins in on-demand order > 0.localhost-startStop-1 - [15/Jan/2016:17:39:34 CST] [20] [1] > SelfTestSubsystem: loading self test plugins in startup order > 0.localhost-startStop-1 - [15/Jan/2016:17:39:34 CST] [20] [1] > SelfTestSubsystem: Self test plugins have been successfully loaded! > 0.localhost-startStop-1 - [15/Jan/2016:17:39:38 CST] [20] [1] > SelfTestSubsystem: Running self test plugins specified to be executed at > startup: > 0.localhost-startStop-1 - [15/Jan/2016:17:39:38 CST] [20] [1] > CAPresence: CA is present > 0.localhost-startStop-1 - [15/Jan/2016:17:39:38 CST] [20] [1] > SystemCertsVerification: system certs verification success > 0.localhost-startStop-1 - [15/Jan/2016:17:39:38 CST] [20] [1] > SelfTestSubsystem: All CRITICAL self test plugins ran SUCCESSFULLY at > startup! > > There?s nothing in that log with any February dates, so when we try to > start pki-tomcatd in real time, it's likely not even getting this far. Some data is also stored in CS.cfg so you might ensure that the certificates stored there are correct as well. There are a few entries in ou=People,o=ipaca that need to reflect the current state of certificates as well. > >> You mentioned privately that you renamed the IPA host. This is >> probably what broke half of the renewals. The hosts and keytabs and >> many entries in IPA have the hostname baked in so you can't simply >> rename the host. >> > > Technically, the host wasn?t renamed; a new CentOS 7 host was added to > the existing IPA cluster that had 4 hosts (1 master CA) at CentOS 6 > (using the documentation at > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html), > it was promoted to the master CA, all of the C6 hosts were > decommissioned/removed from replication, and then a new set of C7 hosts > were created and added as replicas. Ok, you'll need to look at the host keytabs because something seems wrong with them. certmonger can't get a ticket using them. This could be because IPA isn't fully running but it is worth a look. > Is this the correct procedure to follow when time shifted? > > - Stop IPA > - Change the system clock (and the hardware clock) to a point before the > expiration > - Start IPA > - Run getcert resubmit on the appropriate request IDs > - Stop IPA > - Return to real time > - Start IPA > > We haven?t tried it this week yet but all attempts at it last week > failed without any indication as to why the certs weren?t renewing; are > there any other logs to check/other steps in the procedure? Yes, that is correct. rob From wdh at dds.nl Tue Feb 9 10:58:46 2016 From: wdh at dds.nl (Winfried de Heiden) Date: Tue, 9 Feb 2016 11:58:46 +0100 Subject: [Freeipa-users] Active Directory Trust = filter users Message-ID: <56B9C666.9000302@dds.nl> An HTML attachment was scrubbed... URL: From nik.eb.inc at gmail.com Tue Feb 9 15:08:55 2016 From: nik.eb.inc at gmail.com (Nik Lam) Date: Wed, 10 Feb 2016 02:08:55 +1100 Subject: [Freeipa-users] PKINIT support in FreeIPA 4.2.0 In-Reply-To: <20160208125341.GD13133@p.redhat.com> References: <20160203090821.GD20953@p.redhat.com> <20160208125341.GD13133@p.redhat.com> Message-ID: On Mon, Feb 8, 2016 at 11:53 PM, Sumit Bose wrote: > On Thu, Feb 04, 2016 at 07:25:29PM +1100, Nik Lam wrote: > > On Wed, Feb 3, 2016 at 8:08 PM, Sumit Bose wrote: > > > > > On Wed, Feb 03, 2016 at 10:29:49AM +1100, Nik Lam wrote: > > > > Hello, > > > > > > > > I installed ipa-server on Centos 7.1 and later did and upgrade of the > > > whole > > > > system to Centos 7.2. > > > > > > > > I think the FreeIPA version changed from 4.1.0 to 4.2.0 between these > > > > Centos/RHEL minor releases. > > > > > > > > We'd now like to try integrating with a 2FA provider via a radius > proxy > > > and > > > > want to use anonymous PKINIT to secure the initial communications > between > > > > the client and the KDC. > > > > > > > > We've tried following the MIT Kerberos PKINIT configuration > documentation > > > > > > > > http://web.mit.edu/kerberos/krb5-1.14/doc/admin/pkinit.html > > > > > > > > generating our own certs manually with openssl but haven't had any > luck. > > > > We're seeing this in the kdc log: > > > > > > > > preauth pkinit failed to initialize: No realms configured > correctly > > > for > > > > pkinit support > > > > > > Which changes did you apply to krb5.conf? Did you use the IPA CA to > sign > > > the certificate or some other CA? > > > > > > > > > > > I've noticed there are many new pkinit-related options that have been > > > added > > > > to the ipa-server-install script in 4.2.0, so it looks like PKINIT is > > > > available in this version of FreeIPA. Is that the case? > > > > > > Which options are you referring to? > > > > > > bye, > > > Sumit > > > > > > > > > > > And if it is, what is the recommended way to enable it given that it > > > seems > > > > to have been disabled in the original install that I did? Or would it > > > just > > > > be easier to start from scratch with a 4.2.0 ipa-server-install? > (It's a > > > > test instance that doesn't have too much in it - it will take a > several > > > > hours to rebuild from scratch.) > > > > > > > > Regards, > > > > > > > > Nik > > > > > > > > > > > Thanks Sumit. > > > > It sounds like PKINIT is available but clearly I'm doing it wrong. > > > > > Which changes did you apply to krb5.conf? Did you use the IPA CA to > sign > > the certificate or some other CA? > > > > Actually, I modified the kdc.conf file - placed the kdc.pem, kdckey.pem > and > > cacert.pem files in /var/kerberos/krb5kdc/ that I generated via openssl > > commands in the MIT Kerberos documentation. The only change to kdc.conf > > file was to append the location of the kdckey.pem file to > pkinit_identity. > > > > pkinit_identity = FILE:/var/kerberos/krb5kdc/kdc.pem > > pkinit_anchors = FILE:/var/kerberos/krb5kdc/cacert.pem > > > > became > > > > pkinit_identity = > > FILE:/var/kerberos/krb5kdc/kdc.pem,/var/kerberos/krb5kdc/kdckey.pem > > pkinit_anchors = FILE:/var/kerberos/krb5kdc/cacert.pem > > > > Should I have been modifying krb5.conf instead? It aslo sounds like I > need > > no, kdc.conf is the right place, I actually meant kdc.conf but > accidentially types krb5.conf. > > > to use a certificate signed by the IPAs CA - is this something that > should > > be generated using ipa-getcert? Or do I just find the IPA CA's private > key > > and use openssl following the MIT Kerberos documentation? > > > > > Which options are you referring to? > > > > When I looked at the --help text for 4.1.0 and 4.2.0 versions of > > ipa-server-install, I noticed that 4.2.0 has these in the "certificate > > system options": > > > > --no-pkinit disables pkinit setup steps > > > > --pkinit-cert-file=FILE > > File containing the Kerberos KDC SSL certificate > and > > private key > > > > --pkinit-pin=PIN The password to unlock the Kerberos KDC private > key > > > > --pkinit-cert-name=NAME > > Name of the Kerberos KDC SSL certificate to > install > > > > > > Seeing that first one, I was a little hopeful that pkinit is enabled by > > default in 4.2.0 but on a fresh install I just tried, I'm still seeing > the > > no, unfortunately pkinit is currently disabled by default > > > following in krb5kdc.log when IPA is started up, so clearly it isn't. > > > > (Error): preauth pkinit failed to initialize: No realms configured > > correctly for pkinit support > > I get the same error when I put the certificate and the key into > separate files. Can you try to put both into one and use this for the > pkinit_identity option? > > HTH > > bye, > Sumit > Thanks Sumit, it did! I concatenated the cert and the key into a single file and the error has indeed gone away from krb5kdc.log The odd thing is that I can't reproduce the error by splitting into two separate files and restarting ipa.service again. Ignoring that mystery, how do I go about setting up the WELLKNOWN/ANONYMOUS principal? I'm pretty sure it's needed for anonymous pkinit: $ kinit kinit: Generic preauthentication failure while getting initial credentials $ $ kinit -n kinit: Client 'WELLKNOWN/ANONYMOUS at EXAMPLE.COM' not found in Kerberos database while getting initial credentials $ Using kadmin per the MIT documentation doesn't seem to work (authenticated as an IPA admin) # kadmin -q 'addprinc -randkey WELLKNOWN/ANONYMOUS' Authenticating as principal admin/admin at EXAMPLE.COM with password. kadmin: Client not found in Kerberos database while initializing kadmin interface # # kadmin -q 'addprinc -randkey WELLKNOWN/ANONYMOUS' -p admin Authenticating as principal admin with password. Password for admin at EXAMPLE.COM: WARNING: no policy specified for WELLKNOWN/ANONYMOUS at EXAMPLE.COM; defaulting to no policy add_principal: Operation requires ``add'' privilege while creating "WELLKNOWN/ANONYMOUS at EXAMPLE.COM". # Regards, Nik -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbose at redhat.com Tue Feb 9 16:04:39 2016 From: sbose at redhat.com (Sumit Bose) Date: Tue, 9 Feb 2016 17:04:39 +0100 Subject: [Freeipa-users] PKINIT support in FreeIPA 4.2.0 In-Reply-To: References: <20160203090821.GD20953@p.redhat.com> <20160208125341.GD13133@p.redhat.com> Message-ID: <20160209160439.GD3682@p.redhat.com> On Wed, Feb 10, 2016 at 02:08:55AM +1100, Nik Lam wrote: > On Mon, Feb 8, 2016 at 11:53 PM, Sumit Bose wrote: > > > On Thu, Feb 04, 2016 at 07:25:29PM +1100, Nik Lam wrote: > > > On Wed, Feb 3, 2016 at 8:08 PM, Sumit Bose wrote: > > > > > > > On Wed, Feb 03, 2016 at 10:29:49AM +1100, Nik Lam wrote: > > > > > Hello, > > > > > > > > > > I installed ipa-server on Centos 7.1 and later did and upgrade of the > > > > whole > > > > > system to Centos 7.2. > > > > > > > > > > I think the FreeIPA version changed from 4.1.0 to 4.2.0 between these > > > > > Centos/RHEL minor releases. > > > > > > > > > > We'd now like to try integrating with a 2FA provider via a radius > > proxy > > > > and > > > > > want to use anonymous PKINIT to secure the initial communications > > between > > > > > the client and the KDC. > > > > > > > > > > We've tried following the MIT Kerberos PKINIT configuration > > documentation > > > > > > > > > > http://web.mit.edu/kerberos/krb5-1.14/doc/admin/pkinit.html > > > > > > > > > > generating our own certs manually with openssl but haven't had any > > luck. > > > > > We're seeing this in the kdc log: > > > > > > > > > > preauth pkinit failed to initialize: No realms configured > > correctly > > > > for > > > > > pkinit support > > > > > > > > Which changes did you apply to krb5.conf? Did you use the IPA CA to > > sign > > > > the certificate or some other CA? > > > > > > > > > > > > > > I've noticed there are many new pkinit-related options that have been > > > > added > > > > > to the ipa-server-install script in 4.2.0, so it looks like PKINIT is > > > > > available in this version of FreeIPA. Is that the case? > > > > > > > > Which options are you referring to? > > > > > > > > bye, > > > > Sumit > > > > > > > > > > > > > > And if it is, what is the recommended way to enable it given that it > > > > seems > > > > > to have been disabled in the original install that I did? Or would it > > > > just > > > > > be easier to start from scratch with a 4.2.0 ipa-server-install? > > (It's a > > > > > test instance that doesn't have too much in it - it will take a > > several > > > > > hours to rebuild from scratch.) > > > > > > > > > > Regards, > > > > > > > > > > Nik > > > > > > > > > > > > > > > Thanks Sumit. > > > > > > It sounds like PKINIT is available but clearly I'm doing it wrong. > > > > > > > Which changes did you apply to krb5.conf? Did you use the IPA CA to > > sign > > > the certificate or some other CA? > > > > > > Actually, I modified the kdc.conf file - placed the kdc.pem, kdckey.pem > > and > > > cacert.pem files in /var/kerberos/krb5kdc/ that I generated via openssl > > > commands in the MIT Kerberos documentation. The only change to kdc.conf > > > file was to append the location of the kdckey.pem file to > > pkinit_identity. > > > > > > pkinit_identity = FILE:/var/kerberos/krb5kdc/kdc.pem > > > pkinit_anchors = FILE:/var/kerberos/krb5kdc/cacert.pem > > > > > > became > > > > > > pkinit_identity = > > > FILE:/var/kerberos/krb5kdc/kdc.pem,/var/kerberos/krb5kdc/kdckey.pem > > > pkinit_anchors = FILE:/var/kerberos/krb5kdc/cacert.pem > > > > > > Should I have been modifying krb5.conf instead? It aslo sounds like I > > need > > > > no, kdc.conf is the right place, I actually meant kdc.conf but > > accidentially types krb5.conf. > > > > > to use a certificate signed by the IPAs CA - is this something that > > should > > > be generated using ipa-getcert? Or do I just find the IPA CA's private > > key > > > and use openssl following the MIT Kerberos documentation? > > > > > > > Which options are you referring to? > > > > > > When I looked at the --help text for 4.1.0 and 4.2.0 versions of > > > ipa-server-install, I noticed that 4.2.0 has these in the "certificate > > > system options": > > > > > > --no-pkinit disables pkinit setup steps > > > > > > --pkinit-cert-file=FILE > > > File containing the Kerberos KDC SSL certificate > > and > > > private key > > > > > > --pkinit-pin=PIN The password to unlock the Kerberos KDC private > > key > > > > > > --pkinit-cert-name=NAME > > > Name of the Kerberos KDC SSL certificate to > > install > > > > > > > > > Seeing that first one, I was a little hopeful that pkinit is enabled by > > > default in 4.2.0 but on a fresh install I just tried, I'm still seeing > > the > > > > no, unfortunately pkinit is currently disabled by default > > > > > following in krb5kdc.log when IPA is started up, so clearly it isn't. > > > > > > (Error): preauth pkinit failed to initialize: No realms configured > > > correctly for pkinit support > > > > I get the same error when I put the certificate and the key into > > separate files. Can you try to put both into one and use this for the > > pkinit_identity option? > > > > HTH > > > > bye, > > Sumit > > > > > Thanks Sumit, it did! > > I concatenated the cert and the key into a single file and the error has > indeed gone away from krb5kdc.log > > The odd thing is that I can't reproduce the error by splitting into two > separate files and restarting ipa.service again. > > Ignoring that mystery, how do I go about setting up the WELLKNOWN/ANONYMOUS > principal? > > I'm pretty sure it's needed for anonymous pkinit: > > $ kinit > kinit: Generic preauthentication failure while getting initial credentials > $ > > $ kinit -n > kinit: Client 'WELLKNOWN/ANONYMOUS at EXAMPLE.COM' not found in Kerberos > database while getting initial credentials > $ > > Using kadmin per the MIT documentation doesn't seem to work (authenticated > as an IPA admin) > > # kadmin -q 'addprinc -randkey WELLKNOWN/ANONYMOUS' > Authenticating as principal admin/admin at EXAMPLE.COM with password. > kadmin: Client not found in Kerberos database while initializing kadmin > interface > # > > # kadmin -q 'addprinc -randkey WELLKNOWN/ANONYMOUS' -p admin > Authenticating as principal admin with password. > Password for admin at EXAMPLE.COM: > WARNING: no policy specified for WELLKNOWN/ANONYMOUS at EXAMPLE.COM; > defaulting to no policy > add_principal: Operation requires ``add'' privilege while creating > "WELLKNOWN/ANONYMOUS at EXAMPLE.COM". > # Please try kadmin.local -x ipa-setup-override-restrictions bye, Sumit > > Regards, > > Nik From Ian.Collier at cs.ox.ac.uk Tue Feb 9 16:06:31 2016 From: Ian.Collier at cs.ox.ac.uk (Ian Collier) Date: Tue, 9 Feb 2016 16:06:31 +0000 Subject: [Freeipa-users] sudo runs despite being denied by HBAC rules Message-ID: <20160209160631.GC13324@cs.ox.ac.uk> Can anyone help me to understand these logs... is there maybe a bug here? The basic situation is that there is no HBAC rule that would allow sudo. When people try it, sss accepts their password but then denies them access to the sudo command. But despite this, our logs still contain some entries indicating that sudo was actually run. Of course the sudoers file then denied them access and sent the sysadmin an email. Here's a journal extract: Feb 09 11:34:58 hostname sudo[24453]: pam_unix(sudo:auth): authentication failure; logname=xxxx uid=12113 euid=0 tty=/dev/pts/1 ruser=xxxx rhost= user=xxxx Feb 09 11:34:58 hostname sudo[24453]: pam_sss(sudo:auth): authentication success; logname=xxxx uid=12113 euid=0 tty=/dev/pts/1 ruser=xxxx rhost= user=xxxx Feb 09 11:34:58 hostname audit[24453]: pid=24453 uid=12113 auid=12113 ses=54 msg='op=PAM:authentication grantors=pam_succeed_if,pam_sss acct="xxxx" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=success' Feb 09 11:34:58 hostname sudo[24453]: pam_sss(sudo:account): Access denied for user xxxx: 6 (Permission denied) Feb 09 11:34:58 hostname audit[24453]: pid=24453 uid=12113 auid=12113 ses=54 msg='op=PAM:accounting grantors=? acct="xxxx" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=failed' Feb 09 11:35:05 hostname sudo[24453]: pam_sss(sudo:auth): authentication success; logname=xxxx uid=12113 euid=0 tty=/dev/pts/1 ruser=xxxx rhost= user=xxxx Feb 09 11:35:05 hostname audit[24453]: pid=24453 uid=12113 auid=12113 ses=54 msg='op=PAM:authentication grantors=pam_succeed_if,pam_sss acct="xxxx" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=success' Feb 09 11:35:05 hostname sudo[24453]: pam_sss(sudo:account): Access denied for user xxxx: 6 (Permission denied) Feb 09 11:35:05 hostname audit[24453]: pid=24453 uid=12113 auid=12113 ses=54 msg='op=PAM:accounting grantors=? acct="xxxx" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=failed' Feb 09 11:35:08 hostname sudo[24453]: pam_unix(sudo:auth): auth could not identify password for [xxxx] Feb 09 11:35:08 hostname sudo[24453]: pam_sss(sudo:auth): authentication failure; logname=xxxx uid=12113 euid=0 tty=/dev/pts/1 ruser=xxxx rhost= user=xxxx Feb 09 11:35:08 hostname sudo[24453]: pam_sss(sudo:auth): received for user xxxx: 7 (Authentication failure) Feb 09 11:35:08 hostname audit[24453]: pid=24453 uid=12113 auid=12113 ses=54 msg='op=PAM:authentication grantors=? acct="xxxx" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=failed' Feb 09 11:35:08 hostname audit[24453]: pid=24453 uid=12113 auid=12113 ses=54 msg='cwd=2F6175xxx cmd=617074xxx terminal=pts/1 res=failed' Feb 09 11:35:08 hostname audit[24453]: pid=24453 uid=12113 auid=12113 ses=54 msg='cwd=2F6175xxx cmd=617074xxx terminal=pts/1 res=failed' Feb 09 11:35:08 hostname sudo[24453]: xxxx : user NOT in sudoers ; TTY=pts/1 ; PWD=/xxxxx ; USER=root ; COMMAND=xxxxx Feb 09 11:35:09 hostname sSMTP[24463]: Sent mail for root at cs.ox.ac.uk (221 mail.cs.ox.ac.uk closing connection) uid=0 xxxx=root outbytes=607 What this seems to say: 1. pam_unix failed the password (expected because passwords are managed by IPA) 2. pam_sss accepted the password 3. pam_sss denied access to sudo:account Presumably sudo asked the user to try again and they re-typed the password 4. pam_sss accepted the password 5. pam_sss denied access to sudo:account 6. Three seconds later pam_unix said it "could not identify password" (?) 7. This time pam_sss failed the password and returned 7 (Authentication failure) 8. sudo ran anyway! I can't duplicate this behaviour myself but looking through the logs in our computer lab there are a few of these. See for instance the following which appears to deny access three times and then just run it anyway: Feb 02 10:31:12 hostname2 sudo[24468]: pam_unix(sudo:auth): authentication failure; logname=xyyx uid=12106 euid=0 tty=/dev/pts/1 ruser=xyyx rhost= user=xyyx Feb 02 10:31:14 hostname2 sudo[24468]: pam_sss(sudo:auth): authentication success; logname=xyyx uid=12106 euid=0 tty=/dev/pts/1 ruser=xyyx rhost= user=xyyx Feb 02 10:31:14 hostname2 audit[24468]: pid=24468 uid=12106 auid=12106 ses=39 msg='op=PAM:authentication grantors=pam_succeed_if,pam_sss acct="xyyx" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=success' Feb 02 10:31:15 hostname2 sudo[24468]: pam_sss(sudo:account): Access denied for user xyyx: 6 (Permission denied) Feb 02 10:31:15 hostname2 audit[24468]: pid=24468 uid=12106 auid=12106 ses=39 msg='op=PAM:accounting grantors=? acct="xyyx" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=failed' Feb 02 10:31:26 hostname2 sudo[24468]: pam_sss(sudo:auth): authentication success; logname=xyyx uid=12106 euid=0 tty=/dev/pts/1 ruser=xyyx rhost= user=xyyx Feb 02 10:31:26 hostname2 audit[24468]: pid=24468 uid=12106 auid=12106 ses=39 msg='op=PAM:authentication grantors=pam_succeed_if,pam_sss acct="xyyx" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=success' Feb 02 10:31:26 hostname2 sudo[24468]: pam_sss(sudo:account): Access denied for user xyyx: 6 (Permission denied) Feb 02 10:31:26 hostname2 audit[24468]: pid=24468 uid=12106 auid=12106 ses=39 msg='op=PAM:accounting grantors=? acct="xyyx" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=failed' Feb 02 10:31:46 hostname2 sudo[24468]: pam_sss(sudo:auth): authentication success; logname=xyyx uid=12106 euid=0 tty=/dev/pts/1 ruser=xyyx rhost= user=xyyx Feb 02 10:31:46 hostname2 audit[24468]: pid=24468 uid=12106 auid=12106 ses=39 msg='op=PAM:authentication grantors=pam_succeed_if,pam_sss acct="xyyx" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=success' Feb 02 10:31:46 hostname2 sudo[24468]: pam_sss(sudo:account): Access denied for user xyyx: 6 (Permission denied) Feb 02 10:31:46 hostname2 audit[24468]: pid=24468 uid=12106 auid=12106 ses=39 msg='op=PAM:accounting grantors=? acct="xyyx" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=failed' Feb 02 10:31:46 hostname2 audit[24468]: pid=24468 uid=12106 auid=12106 ses=39 msg='cwd="/xxxx" cmd=6E616Exxx terminal=pts/1 res=failed' Feb 02 10:31:46 hostname2 audit[24468]: pid=24468 uid=12106 auid=12106 ses=39 msg='cwd="/xxxx" cmd=6E616Exxx terminal=pts/1 res=failed' Feb 02 10:31:46 hostname2 sudo[24468]: xyyx : user NOT in sudoers ; TTY=pts/1 ; PWD=/xxxxxx ; USER=root ; COMMAND=xxxxxx Feb 02 10:31:47 hostname2 sSMTP[24489]: Sent mail for root at cs.ox.ac.uk (221 mail.cs.ox.ac.uk closing connection) uid=0 username=root outbytes=589 Now since sudoers denies access, this isn't necessarily a security problem for us. But it's rather puzzling and it does mean a trickle of incoming emails to the sysadmin. The clients here are Fedora 22 with pam 1.1.8, sssd 1.13.3 and sudo 1.8.15. The IPA servers are RHEL 6 with ipa-server 3.0.0. Ian Collier. From tgeier at accertify.com Tue Feb 9 19:32:19 2016 From: tgeier at accertify.com (Timothy Geier) Date: Tue, 9 Feb 2016 19:32:19 +0000 Subject: [Freeipa-users] IPA 4.2: pki-tomcatd in terrible shape In-Reply-To: <56B9AA53.1000400@redhat.com> References: <56B86DE0.4070909@redhat.com> <7F0EB8FC-8F2F-49D1-A124-562B5B0A55A2@accertify.com> <56B9AA53.1000400@redhat.com> Message-ID: > On Feb 9, 2016, at 2:58 AM, Rob Crittenden wrote: > > Timothy Geier wrote: >> >> >> The debug log has a lot of instances of: >> >> Could not connect to LDAP server host xxx.xxxx port 636 Error >> netscape.ldap.LDAPException: IO Error creating JSS SSL Socket (-1) >> Internal Database Error encountered: Could not connect to LDAP server >> host xxx.xxxx port 636 Error netscape.ldap.LDAPException: IO Error >> creating JSS SSL Socket (-1) > > The 389-ds access log may show connection attempts and you might be able to correlate from there. > [09/Feb/2016:12:55:41 -0600] conn=109598 fd=287 slot=287 SSL connection from master_ip to master_ip [09/Feb/2016:12:55:41 -0600] conn=109597 op=0 EXT oid="1.3.6.1.4.1.1466.20037" name="startTLS" [09/Feb/2016:12:55:41 -0600] conn=109597 op=0 RESULT err=0 tag=120 nentries=0 etime=0 [09/Feb/2016:12:55:41 -0600] conn=109598 Netscape Portable Runtime error -8181 (Peer's Certificate has expired.); unauthenticated client CN=CA Subsystem,O=XXXXXXX.NET; issuer CN=Certificate Authority,O=XXXXXXX.NET [09/Feb/2016:12:55:41 -0600] conn=109598 op=-1 fd=287 closed - Peer's Certificate has expired. > > Some data is also stored in CS.cfg so you might ensure that the certificates stored there are correct as well. > CS.cfg is correct/restored from backup. > There are a few entries in ou=People,o=ipaca that need to reflect the current state of certificates as well. > While looking in cn=config for any o=ipaca entries, the following popped up..it looks like most of the old replicas and the old master hostnames weren?t properly cleaned up and there?s still RUVs for them..nsDS5ReplicaHost and Port also seem to be improperly set: cn=cloneAgreement1-current-master.XXXXXXXXX.net-pki-tomcat,cn=replica,cn=o\\3Dipaca,cn=mapping tree,cn=config cn: cloneAgreement1-current-master.XXXXXXXXX.net-pki-tomcat description: cloneAgreement1-current-master.XXXXXXXXX.net-pki-tomcat nsDS5ReplicaBindDN: cn=Replication Manager masterAgreement1-current-master.XXXXXXXXX.net-pki-tomcat,ou=csusers,cn=config nsDS5ReplicaBindMethod: Simple nsDS5ReplicaHost: old-master.XXXXXXXXX.net nsDS5ReplicaPort: 7389 nsDS5ReplicaRoot: o=ipaca nsDS5ReplicaTransportInfo: TLS nsds50ruv: {replicageneration} 5304e078000000600000 nsds50ruv: {replica 96 ldap://old-master.XXXXXXXXX.net:7389} 5304e084000000600000 561f3e8f000500600000 nsds50ruv: {replica 81 ldap://current-master.XXXXXXXXX.net:389} 561f361b000000510000 561f369c000000510000 nsds50ruv: {replica 86 ldap://old-replica3.XXXXXXXXX.net:7389} 53f7b70d000000560000 5616ad64000900560000 nsds50ruv: {replica 91 ldap://old-replica2.XXXXXXXXX.net:7389} 53a841e50000005b0000 5616ad5f0005005b0000 nsds50ruv: {replica 97 ldap://old-replica2.XXXXXXXXX.net:7389} 5304e080000000610000 539b4f96000100610000 nsruvReplicaLastModified: {replica 96 ldap://old-master.XXXXXXXXX.net:7389} 00000000 nsruvReplicaLastModified: {replica 81 ldap://current-master.XXXXXXXXX.net:389} 00000000 nsruvReplicaLastModified: {replica 86 ldap://old-replica3.XXXXXXXXX.net:7389} 00000000 nsruvReplicaLastModified: {replica 91 ldap://old-replica2.XXXXXXXXX.net:7389} 00000000 nsruvReplicaLastModified: {replica 97 ldap://old-replica2.XXXXXXXXX.net:7389} 00000000 objectClass: top objectClass: nsds5replicationagreement nsds5replicareapactive: 0 nsds5replicaLastUpdateStart: 19700101000000Z nsds5replicaLastUpdateEnd: 19700101000000Z nsds5replicaChangesSentSinceStartup: nsds5replicaLastUpdateStatus: -1 Unable to acquire replicaLDAP error: Can't contact LDAP server nsds5replicaUpdateInProgress: FALSE nsds5replicaLastInitStart: 19700101000000Z nsds5replicaLastInitEnd: 19700101000000Z cn=replica,cn=o\\3Dipaca,cn=mapping tree,cn=config cn: replica nsDS5Flags: 1 nsDS5ReplicaBindDN: cn=Replication Manager cloneAgreement1-current-master.XXXXXXXXX.net-pki-tomcat,ou=csusers,cn=config nsDS5ReplicaId: 81 nsDS5ReplicaName: 56db714e-72e411e5-87dbe691-e12b51f2 nsDS5ReplicaRoot: o=ipaca nsDS5ReplicaType: 3 nsState:: UQAAAAAAAADkWbdWAAAAAAAAAAAAAAAAwCYAAAAAAAABAAAAAAAAAA== objectClass: top objectClass: nsDS5Replica objectClass: extensibleobject nsds5ReplicaChangeCount: 11463 nsds5replicareapactive: 0 ou=People doesn?t seem to exist in either the main tree or cn=config. >> >>> You mentioned privately that you renamed the IPA host. This is >>> probably what broke half of the renewals. The hosts and keytabs and >>> many entries in IPA have the hostname baked in so you can't simply >>> rename the host. >>> >> >> Technically, the host wasn?t renamed; a new CentOS 7 host was added to >> the existing IPA cluster that had 4 hosts (1 master CA) at CentOS 6 >> (using the documentation at >> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html), >> it was promoted to the master CA, all of the C6 hosts were >> decommissioned/removed from replication, and then a new set of C7 hosts >> were created and added as replicas. > > Ok, you'll need to look at the host keytabs because something seems wrong with them. certmonger can't get a ticket using them. This could be because IPA isn't fully running but it is worth a look. All of the host keytabs on all of the IPA servers are correct..are there any other keytabs to check? > >> Is this the correct procedure to follow when time shifted? >> >> - Stop IPA >> - Change the system clock (and the hardware clock) to a point before the >> expiration >> - Start IPA >> - Run getcert resubmit on the appropriate request IDs >> - Stop IPA >> - Return to real time >> - Start IPA >> >> We haven?t tried it this week yet but all attempts at it last week >> failed without any indication as to why the certs weren?t renewing; are >> there any other logs to check/other steps in the procedure? > > Yes, that is correct. > Thanks for the clarification. The IPA cluster itself is still doing ok after about a week of being in this state but something else we?re wondering is if we?ll be able to add replica servers while this is going on..it?s not critical to do so, but it is going to come up fairly soon. > rob "This message and any attachments may contain confidential information. If you have received this message in error, any use or distribution is prohibited. Please notify us by reply e-mail if you have mistakenly received this message, and immediately and permanently delete it and any attachments. Thank you." From michael.rainey.ctr at nrlssc.navy.mil Tue Feb 9 22:54:55 2016 From: michael.rainey.ctr at nrlssc.navy.mil (Michael Rainey (Contractor)) Date: Tue, 9 Feb 2016 16:54:55 -0600 Subject: [Freeipa-users] Migrating NIS host to freeIPA host with smart card Message-ID: Greetings, I have a question about migrating a system from NIS to freeIPA. In my efforts of setting up a host on freeIPA I would normally use a fresh install to setup the system. I'm now at a point where I'm moving existing systems from an NIS domain to a freeIPA domain. Is it recommended to perform a clean install for every new host added to the domain? During my testing, I have found running the ipa-client-install command does a great job of adding the host to the domain, but when I try to use the smart card it is never recognized by gdm. I tried tweaking some of the configurations to get GDM to recognize the card with no luck. Is there a checklist available that I could follow to make sure everything is configured properly? All configurations work when using a username and password. -- *Michael Rainey* -------------- next part -------------- An HTML attachment was scrubbed... URL: From nik.eb.inc at gmail.com Wed Feb 10 01:07:45 2016 From: nik.eb.inc at gmail.com (Nik Lam) Date: Wed, 10 Feb 2016 12:07:45 +1100 Subject: [Freeipa-users] PKINIT support in FreeIPA 4.2.0 In-Reply-To: <20160209160439.GD3682@p.redhat.com> References: <20160203090821.GD20953@p.redhat.com> <20160208125341.GD13133@p.redhat.com> <20160209160439.GD3682@p.redhat.com> Message-ID: On Wed, Feb 10, 2016 at 3:04 AM, Sumit Bose wrote: > On Wed, Feb 10, 2016 at 02:08:55AM +1100, Nik Lam wrote: > > On Mon, Feb 8, 2016 at 11:53 PM, Sumit Bose wrote: > > > > > On Thu, Feb 04, 2016 at 07:25:29PM +1100, Nik Lam wrote: > > > > On Wed, Feb 3, 2016 at 8:08 PM, Sumit Bose wrote: > > > > > > > > > On Wed, Feb 03, 2016 at 10:29:49AM +1100, Nik Lam wrote: > > > > > > Hello, > > > > > > > > > > > > I installed ipa-server on Centos 7.1 and later did and upgrade > of the > > > > > whole > > > > > > system to Centos 7.2. > > > > > > > > > > > > I think the FreeIPA version changed from 4.1.0 to 4.2.0 between > these > > > > > > Centos/RHEL minor releases. > > > > > > > > > > > > We'd now like to try integrating with a 2FA provider via a radius > > > proxy > > > > > and > > > > > > want to use anonymous PKINIT to secure the initial communications > > > between > > > > > > the client and the KDC. > > > > > > > > > > > > We've tried following the MIT Kerberos PKINIT configuration > > > documentation > > > > > > > > > > > > http://web.mit.edu/kerberos/krb5-1.14/doc/admin/pkinit.html > > > > > > > > > > > > generating our own certs manually with openssl but haven't had > any > > > luck. > > > > > > We're seeing this in the kdc log: > > > > > > > > > > > > preauth pkinit failed to initialize: No realms configured > > > correctly > > > > > for > > > > > > pkinit support > > > > > > > > > > Which changes did you apply to krb5.conf? Did you use the IPA CA to > > > sign > > > > > the certificate or some other CA? > > > > > > > > > > > > > > > > > I've noticed there are many new pkinit-related options that have > been > > > > > added > > > > > > to the ipa-server-install script in 4.2.0, so it looks like > PKINIT is > > > > > > available in this version of FreeIPA. Is that the case? > > > > > > > > > > Which options are you referring to? > > > > > > > > > > bye, > > > > > Sumit > > > > > > > > > > > > > > > > > And if it is, what is the recommended way to enable it given > that it > > > > > seems > > > > > > to have been disabled in the original install that I did? Or > would it > > > > > just > > > > > > be easier to start from scratch with a 4.2.0 ipa-server-install? > > > (It's a > > > > > > test instance that doesn't have too much in it - it will take a > > > several > > > > > > hours to rebuild from scratch.) > > > > > > > > > > > > Regards, > > > > > > > > > > > > Nik > > > > > > > > > > > > > > > > > > > Thanks Sumit. > > > > > > > > It sounds like PKINIT is available but clearly I'm doing it wrong. > > > > > > > > > Which changes did you apply to krb5.conf? Did you use the IPA CA > to > > > sign > > > > the certificate or some other CA? > > > > > > > > Actually, I modified the kdc.conf file - placed the kdc.pem, > kdckey.pem > > > and > > > > cacert.pem files in /var/kerberos/krb5kdc/ that I generated via > openssl > > > > commands in the MIT Kerberos documentation. The only change to > kdc.conf > > > > file was to append the location of the kdckey.pem file to > > > pkinit_identity. > > > > > > > > pkinit_identity = FILE:/var/kerberos/krb5kdc/kdc.pem > > > > pkinit_anchors = FILE:/var/kerberos/krb5kdc/cacert.pem > > > > > > > > became > > > > > > > > pkinit_identity = > > > > FILE:/var/kerberos/krb5kdc/kdc.pem,/var/kerberos/krb5kdc/kdckey.pem > > > > pkinit_anchors = FILE:/var/kerberos/krb5kdc/cacert.pem > > > > > > > > Should I have been modifying krb5.conf instead? It aslo sounds like I > > > need > > > > > > no, kdc.conf is the right place, I actually meant kdc.conf but > > > accidentially types krb5.conf. > > > > > > > to use a certificate signed by the IPAs CA - is this something that > > > should > > > > be generated using ipa-getcert? Or do I just find the IPA CA's > private > > > key > > > > and use openssl following the MIT Kerberos documentation? > > > > > > > > > Which options are you referring to? > > > > > > > > When I looked at the --help text for 4.1.0 and 4.2.0 versions of > > > > ipa-server-install, I noticed that 4.2.0 has these in the > "certificate > > > > system options": > > > > > > > > --no-pkinit disables pkinit setup steps > > > > > > > > --pkinit-cert-file=FILE > > > > File containing the Kerberos KDC SSL > certificate > > > and > > > > private key > > > > > > > > --pkinit-pin=PIN The password to unlock the Kerberos KDC > private > > > key > > > > > > > > --pkinit-cert-name=NAME > > > > Name of the Kerberos KDC SSL certificate to > > > install > > > > > > > > > > > > Seeing that first one, I was a little hopeful that pkinit is enabled > by > > > > default in 4.2.0 but on a fresh install I just tried, I'm still > seeing > > > the > > > > > > no, unfortunately pkinit is currently disabled by default > > > > > > > following in krb5kdc.log when IPA is started up, so clearly it isn't. > > > > > > > > (Error): preauth pkinit failed to initialize: No realms configured > > > > correctly for pkinit support > > > > > > I get the same error when I put the certificate and the key into > > > separate files. Can you try to put both into one and use this for the > > > pkinit_identity option? > > > > > > HTH > > > > > > bye, > > > Sumit > > > > > > > > > Thanks Sumit, it did! > > > > I concatenated the cert and the key into a single file and the error has > > indeed gone away from krb5kdc.log > > > > The odd thing is that I can't reproduce the error by splitting into two > > separate files and restarting ipa.service again. > > > > Ignoring that mystery, how do I go about setting up the > WELLKNOWN/ANONYMOUS > > principal? > > > > I'm pretty sure it's needed for anonymous pkinit: > > > > $ kinit > > kinit: Generic preauthentication failure while getting initial > credentials > > $ > > > > $ kinit -n > > kinit: Client 'WELLKNOWN/ANONYMOUS at EXAMPLE.COM' not found in Kerberos > > database while getting initial credentials > > $ > > > > Using kadmin per the MIT documentation doesn't seem to work > (authenticated > > as an IPA admin) > > > > # kadmin -q 'addprinc -randkey WELLKNOWN/ANONYMOUS' > > Authenticating as principal admin/admin at EXAMPLE.COM with password. > > kadmin: Client not found in Kerberos database while initializing kadmin > > interface > > # > > > > # kadmin -q 'addprinc -randkey WELLKNOWN/ANONYMOUS' -p admin > > Authenticating as principal admin with password. > > Password for admin at EXAMPLE.COM: > > WARNING: no policy specified for WELLKNOWN/ANONYMOUS at EXAMPLE.COM; > > defaulting to no policy > > add_principal: Operation requires ``add'' privilege while creating > > "WELLKNOWN/ANONYMOUS at EXAMPLE.COM". > > # > > Please try > > kadmin.local -x ipa-setup-override-restrictions > > bye, > Sumit > > Thanks Sumit. That seems to have worked to get the principal created. # kadmin.local -x ipa-setup-override-restrictions Authenticating as principal admin/admin at EXAMPLE.COM with password. kadmin.local: addprinc -randkey WELLKNOWN/ANONYMOUS WARNING: no policy specified for WELLKNOWN/ANONYMOUS at EXAMPLE.COM; defaulting to no policy Principal "WELLKNOWN/ANONYMOUS at EXAMPLE.COM" created. kadmin.local: quit # I'm no longer seeing the error from the client about 'WELLKNOWN/ ANONYMOUS at EXAMPLE.COM' not found in Kerberos database. However, I'm being prompted for a password for the anonymous principal. $ kinit -n Password for WELLKNOWN/ANONYMOUS at EXAMPLE.COM: kinit: Password incorrect while getting initial credentials $ That doesn't sound right to me - and indeed it doesn't provide an armor cache that I can use for authenticating my client user. Here's what's in the krb5kdc.log from that attempt to use kinit -n Feb 10 00:55:46 ipa00-756701.example.com krb5kdc[4869](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 10.93.187.13: NEEDED_PREAUTH: WELLKNOWN/ ANONYMOUS at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM, Additional pre-authentication required Feb 10 00:55:46 ipa00-756701.example.com krb5kdc[4869](info): closing down fd 12 Feb 10 00:55:47 ipa00-756701.example.com krb5kdc[4869](info): preauth (encrypted_timestamp) verify failure: Decrypt integrity check failed Feb 10 00:55:47 ipa00-756701.example.com krb5kdc[4869](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 10.93.187.13: PREAUTH_FAILED: WELLKNOWN/ ANONYMOUS at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM, Decrypt integrity check failed Feb 10 00:55:47 ipa00-756701.example.com krb5kdc[4869](info): closing down fd 12 Regards, Nik -------------- next part -------------- An HTML attachment was scrubbed... URL: From supratiksekhar at gmail.com Wed Feb 10 03:11:15 2016 From: supratiksekhar at gmail.com (Supratik Goswami) Date: Wed, 10 Feb 2016 08:41:15 +0530 Subject: [Freeipa-users] Where should I create my Linux and Mac users in a AD IPA trust? Message-ID: I am currently running IPA server 4.2 in RHEL 7.2 and I have created a two-way trust between my Windows AD and IPA server. I have a heterogeneous environment where I have Windows, Linux and Mac clients. The Windows users are present in AD and they can access the resources under IPA through the trust relationship. What are the pros and cons 1. When I create Linux and Mac users in the AD. 2. When I create Linux and Mac users in IPA -- Warm Regards Supratik -------------- next part -------------- An HTML attachment was scrubbed... URL: From vani.paridhyani at freecharge.com Tue Feb 9 13:31:15 2016 From: vani.paridhyani at freecharge.com (Vani Paridhyani) Date: Tue, 9 Feb 2016 19:01:15 +0530 Subject: [Freeipa-users] Generate and download krb5.keytab from host Message-ID: Hi! I am trying to automate IPA client setup on Amazon Linux machines. Is there a way in which I can generate and download the krb5.keytab remotely from the server and get it in the host? -- Thanks, Vani P. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfenal at gmail.com Tue Feb 9 23:13:18 2016 From: jfenal at gmail.com (=?UTF-8?B?SsOpcsO0bWUgRmVuYWw=?=) Date: Wed, 10 Feb 2016 00:13:18 +0100 Subject: [Freeipa-users] Domain/real as a TLD and email validation error Message-ID: Hi all, Installing an IPA instance with domain/realm as a TLD, in my case "internal", works fine. Until I try to add a user within the domain, using the web interface, which fails with the following error: IPA Error 3009: ValidationError invalid 'email': invalid e-mail format: jf at internal The same error happens using "ipa user-add" when the --email=mail at redhat.com is not specified. Can we overcome/circumvent this error in the UI? Or should we recommend against using TLD or one domain component domains? Regards, J. -- J?r?me Fenal From pioto at pioto.org Wed Feb 10 05:16:59 2016 From: pioto at pioto.org (Mike Kelly) Date: Wed, 10 Feb 2016 05:16:59 +0000 Subject: [Freeipa-users] ID Views without AD Message-ID: Hi, I'm attempting to use ID Views as a shim, to allow me to have an existing host work with FreeIPA without having to re-chown many many files. Here's my basic strategy, and where things seem to be failing: For any truly local groups (e.g. for specific local services), I continue to manage those in /etc/groups For any users, they should be managed in FreeIPA, especially the password and SSH Pubkeys. But, they should continue to appear with their old UIDs and GIDs on the server. This means the user doesn't exist in /etc/passwd or /etc/shadow anymore (or the local password would be used, as I understand it). An ID View is created, applied to this host, and has a user override added to override the UID and GID of the user. But, when I do this, I continue to see the usual UID and GID in the output of `id $USER`, etc, even after running `sss_cache -E` and `systemctl restart sssd`. Is there some extra logging I can turn on to see why this ID View isn't being applied like I would expect? Or perhaps some extra bit of configuration I missed? I'm running a pair of CentOS 7 boxes, one acting as the FreeIPA server, and the other is the "legacy" box I want to shim FreeIPA into... Thanks. -- Mike Kelly -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Wed Feb 10 08:17:52 2016 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 10 Feb 2016 09:17:52 +0100 Subject: [Freeipa-users] Generate and download krb5.keytab from host In-Reply-To: References: Message-ID: <56BAF230.7080400@redhat.com> On 9.2.2016 14:31, Vani Paridhyani wrote: > Hi! > > I am trying to automate IPA client setup on Amazon Linux machines. Is there > a way in which I can generate and download the krb5.keytab remotely from > the server and get it in the host? ipa-client-install command is not working for you? Keytab can be obtained manually using ipa-getkeytab command. -- Petr^2 Spacek From abokovoy at redhat.com Wed Feb 10 08:18:27 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 10 Feb 2016 10:18:27 +0200 Subject: [Freeipa-users] Domain/real as a TLD and email validation error In-Reply-To: References: Message-ID: <20160210081827.GQ12787@redhat.com> On Wed, 10 Feb 2016, J?r?me Fenal wrote: >Hi all, > >Installing an IPA instance with domain/realm as a TLD, in my case >"internal", works fine. > >Until I try to add a user within the domain, using the web interface, >which fails with the following error: > >IPA Error 3009: ValidationError > >invalid 'email': invalid e-mail format: jf at internal > >The same error happens using "ipa user-add" when the >--email=mail at redhat.com is not specified. > >Can we overcome/circumvent this error in the UI? > >Or should we recommend against using TLD or one domain component domains? See https://www.redhat.com/archives/freeipa-users/2015-August/msg00078.html for inspiration. -- / Alexander Bokovoy From abokovoy at redhat.com Wed Feb 10 08:19:45 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 10 Feb 2016 10:19:45 +0200 Subject: [Freeipa-users] ID Views without AD In-Reply-To: References: Message-ID: <20160210081945.GR12787@redhat.com> On Wed, 10 Feb 2016, Mike Kelly wrote: >Hi, > >I'm attempting to use ID Views as a shim, to allow me to have an existing >host work with FreeIPA without having to re-chown many many files. > >Here's my basic strategy, and where things seem to be failing: > >For any truly local groups (e.g. for specific local services), I continue >to manage those in /etc/groups > >For any users, they should be managed in FreeIPA, especially the password >and SSH Pubkeys. But, they should continue to appear with their old UIDs >and GIDs on the server. This means the user doesn't exist in /etc/passwd or >/etc/shadow anymore (or the local password would be used, as I understand >it). > >An ID View is created, applied to this host, and has a user override added >to override the UID and GID of the user. > >But, when I do this, I continue to see the usual UID and GID in the output >of `id $USER`, etc, even after running `sss_cache -E` and `systemctl >restart sssd`. > >Is there some extra logging I can turn on to see why this ID View isn't >being applied like I would expect? Or perhaps some extra bit of >configuration I missed? Level 7 or 9 debug logs in SSSD on the client might help. >I'm running a pair of CentOS 7 boxes, one acting as the FreeIPA server, and >the other is the "legacy" box I want to shim FreeIPA into... ID Views are only applied on machines where you have SSSD that supports them, just to make sure. -- / Alexander Bokovoy From pspacek at redhat.com Wed Feb 10 08:23:33 2016 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 10 Feb 2016 09:23:33 +0100 Subject: [Freeipa-users] Domain/real as a TLD and email validation error In-Reply-To: <20160210081827.GQ12787@redhat.com> References: <20160210081827.GQ12787@redhat.com> Message-ID: <56BAF385.40106@redhat.com> On 10.2.2016 09:18, Alexander Bokovoy wrote: > On Wed, 10 Feb 2016, J?r?me Fenal wrote: >> Hi all, >> >> Installing an IPA instance with domain/realm as a TLD, in my case >> "internal", works fine. >> >> Until I try to add a user within the domain, using the web interface, >> which fails with the following error: >> >> IPA Error 3009: ValidationError >> >> invalid 'email': invalid e-mail format: jf at internal >> >> The same error happens using "ipa user-add" when the >> --email=mail at redhat.com is not specified. >> >> Can we overcome/circumvent this error in the UI? >> >> Or should we recommend against using TLD or one domain component domains? > See > https://www.redhat.com/archives/freeipa-users/2015-August/msg00078.html > for inspiration. Hold on! Use of made-up domains in inherently broken and recommended against by official documentation: Please see https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/prerequisites.html#dns-reqs and also https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/sec-Securing_DNS_Traffic_with_DNSSEC.html#sec-Recommended_Naming_Practices Long story short, do not use anything else than a domain you actually bought. -- Petr^2 Spacek From nik.eb.inc at gmail.com Wed Feb 10 08:23:36 2016 From: nik.eb.inc at gmail.com (Nik Lam) Date: Wed, 10 Feb 2016 19:23:36 +1100 Subject: [Freeipa-users] Generate and download krb5.keytab from host In-Reply-To: <56BAF230.7080400@redhat.com> References: <56BAF230.7080400@redhat.com> Message-ID: On Wed, Feb 10, 2016 at 7:17 PM, Petr Spacek wrote: > On 9.2.2016 14:31, Vani Paridhyani wrote: > > Hi! > > > > I am trying to automate IPA client setup on Amazon Linux machines. Is > there > > a way in which I can generate and download the krb5.keytab remotely from > > the server and get it in the host? > > ipa-client-install command is not working for you? > > Keytab can be obtained manually using ipa-getkeytab command. > > - > You might also like to consider using a password, like this kickstart example https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/kickstart.html Nik -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Wed Feb 10 08:42:28 2016 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 10 Feb 2016 09:42:28 +0100 Subject: [Freeipa-users] Active Directory Trust = filter users In-Reply-To: <56B9C666.9000302@dds.nl> References: <56B9C666.9000302@dds.nl> Message-ID: <20160210084228.GY29883@hendrix.redhat.com> On Tue, Feb 09, 2016 at 11:58:46AM +0100, Winfried de Heiden wrote: > Hi all, > > Using an Active Directory Trust with IPA all works fine but there's an > disadvantage: it might brong in lots and lots of groups I am not > interested in since it mainly hit Windows and/or Office stuff. Why are you concerned about this in the first place? Is it about performance needed to process these groups or about resources that can be owned by these groups? > > Now, is it possible to filter AD-groups? or: can I use an AD search base > filter? (something like cn=linuxgroups,ou=allgroups,dc=example,dc=com) Not at the moment, the subdomains are autoconfigured and not configurable. > > On a small scale ID views can be used, but it not a great solution. (for > all new groups appearing in AD the ID view must be modified) > > Some sugestions or documentation on filtering AD groups? > > Winny > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project From sbose at redhat.com Wed Feb 10 08:43:17 2016 From: sbose at redhat.com (Sumit Bose) Date: Wed, 10 Feb 2016 09:43:17 +0100 Subject: [Freeipa-users] PKINIT support in FreeIPA 4.2.0 In-Reply-To: References: <20160203090821.GD20953@p.redhat.com> <20160208125341.GD13133@p.redhat.com> <20160209160439.GD3682@p.redhat.com> Message-ID: <20160210084317.GE3682@p.redhat.com> On Wed, Feb 10, 2016 at 12:07:45PM +1100, Nik Lam wrote: > On Wed, Feb 10, 2016 at 3:04 AM, Sumit Bose wrote: > > > On Wed, Feb 10, 2016 at 02:08:55AM +1100, Nik Lam wrote: > > > On Mon, Feb 8, 2016 at 11:53 PM, Sumit Bose wrote: > > > > > > > On Thu, Feb 04, 2016 at 07:25:29PM +1100, Nik Lam wrote: > > > > > On Wed, Feb 3, 2016 at 8:08 PM, Sumit Bose wrote: > > > > > > > > > > > On Wed, Feb 03, 2016 at 10:29:49AM +1100, Nik Lam wrote: > > > > > > > Hello, > > > > > > > > > > > > > > I installed ipa-server on Centos 7.1 and later did and upgrade > > of the > > > > > > whole > > > > > > > system to Centos 7.2. > > > > > > > > > > > > > > I think the FreeIPA version changed from 4.1.0 to 4.2.0 between > > these > > > > > > > Centos/RHEL minor releases. > > > > > > > > > > > > > > We'd now like to try integrating with a 2FA provider via a radius > > > > proxy > > > > > > and > > > > > > > want to use anonymous PKINIT to secure the initial communications > > > > between > > > > > > > the client and the KDC. > > > > > > > > > > > > > > We've tried following the MIT Kerberos PKINIT configuration > > > > documentation > > > > > > > > > > > > > > http://web.mit.edu/kerberos/krb5-1.14/doc/admin/pkinit.html > > > > > > > > > > > > > > generating our own certs manually with openssl but haven't had > > any > > > > luck. > > > > > > > We're seeing this in the kdc log: > > > > > > > > > > > > > > preauth pkinit failed to initialize: No realms configured > > > > correctly > > > > > > for > > > > > > > pkinit support > > > > > > > > > > > > Which changes did you apply to krb5.conf? Did you use the IPA CA to > > > > sign > > > > > > the certificate or some other CA? > > > > > > > > > > > > > > > > > > > > I've noticed there are many new pkinit-related options that have > > been > > > > > > added > > > > > > > to the ipa-server-install script in 4.2.0, so it looks like > > PKINIT is > > > > > > > available in this version of FreeIPA. Is that the case? > > > > > > > > > > > > Which options are you referring to? > > > > > > > > > > > > bye, > > > > > > Sumit > > > > > > > > > > > > > > > > > > > > And if it is, what is the recommended way to enable it given > > that it > > > > > > seems > > > > > > > to have been disabled in the original install that I did? Or > > would it > > > > > > just > > > > > > > be easier to start from scratch with a 4.2.0 ipa-server-install? > > > > (It's a > > > > > > > test instance that doesn't have too much in it - it will take a > > > > several > > > > > > > hours to rebuild from scratch.) > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > Nik > > > > > > > > > > > > > > > > > > > > > > > Thanks Sumit. > > > > > > > > > > It sounds like PKINIT is available but clearly I'm doing it wrong. > > > > > > > > > > > Which changes did you apply to krb5.conf? Did you use the IPA CA > > to > > > > sign > > > > > the certificate or some other CA? > > > > > > > > > > Actually, I modified the kdc.conf file - placed the kdc.pem, > > kdckey.pem > > > > and > > > > > cacert.pem files in /var/kerberos/krb5kdc/ that I generated via > > openssl > > > > > commands in the MIT Kerberos documentation. The only change to > > kdc.conf > > > > > file was to append the location of the kdckey.pem file to > > > > pkinit_identity. > > > > > > > > > > pkinit_identity = FILE:/var/kerberos/krb5kdc/kdc.pem > > > > > pkinit_anchors = FILE:/var/kerberos/krb5kdc/cacert.pem > > > > > > > > > > became > > > > > > > > > > pkinit_identity = > > > > > FILE:/var/kerberos/krb5kdc/kdc.pem,/var/kerberos/krb5kdc/kdckey.pem > > > > > pkinit_anchors = FILE:/var/kerberos/krb5kdc/cacert.pem > > > > > > > > > > Should I have been modifying krb5.conf instead? It aslo sounds like I > > > > need > > > > > > > > no, kdc.conf is the right place, I actually meant kdc.conf but > > > > accidentially types krb5.conf. > > > > > > > > > to use a certificate signed by the IPAs CA - is this something that > > > > should > > > > > be generated using ipa-getcert? Or do I just find the IPA CA's > > private > > > > key > > > > > and use openssl following the MIT Kerberos documentation? > > > > > > > > > > > Which options are you referring to? > > > > > > > > > > When I looked at the --help text for 4.1.0 and 4.2.0 versions of > > > > > ipa-server-install, I noticed that 4.2.0 has these in the > > "certificate > > > > > system options": > > > > > > > > > > --no-pkinit disables pkinit setup steps > > > > > > > > > > --pkinit-cert-file=FILE > > > > > File containing the Kerberos KDC SSL > > certificate > > > > and > > > > > private key > > > > > > > > > > --pkinit-pin=PIN The password to unlock the Kerberos KDC > > private > > > > key > > > > > > > > > > --pkinit-cert-name=NAME > > > > > Name of the Kerberos KDC SSL certificate to > > > > install > > > > > > > > > > > > > > > Seeing that first one, I was a little hopeful that pkinit is enabled > > by > > > > > default in 4.2.0 but on a fresh install I just tried, I'm still > > seeing > > > > the > > > > > > > > no, unfortunately pkinit is currently disabled by default > > > > > > > > > following in krb5kdc.log when IPA is started up, so clearly it isn't. > > > > > > > > > > (Error): preauth pkinit failed to initialize: No realms configured > > > > > correctly for pkinit support > > > > > > > > I get the same error when I put the certificate and the key into > > > > separate files. Can you try to put both into one and use this for the > > > > pkinit_identity option? > > > > > > > > HTH > > > > > > > > bye, > > > > Sumit > > > > > > > > > > > > > Thanks Sumit, it did! > > > > > > I concatenated the cert and the key into a single file and the error has > > > indeed gone away from krb5kdc.log > > > > > > The odd thing is that I can't reproduce the error by splitting into two > > > separate files and restarting ipa.service again. > > > > > > Ignoring that mystery, how do I go about setting up the > > WELLKNOWN/ANONYMOUS > > > principal? > > > > > > I'm pretty sure it's needed for anonymous pkinit: > > > > > > $ kinit > > > kinit: Generic preauthentication failure while getting initial > > credentials > > > $ > > > > > > $ kinit -n > > > kinit: Client 'WELLKNOWN/ANONYMOUS at EXAMPLE.COM' not found in Kerberos > > > database while getting initial credentials > > > $ > > > > > > Using kadmin per the MIT documentation doesn't seem to work > > (authenticated > > > as an IPA admin) > > > > > > # kadmin -q 'addprinc -randkey WELLKNOWN/ANONYMOUS' > > > Authenticating as principal admin/admin at EXAMPLE.COM with password. > > > kadmin: Client not found in Kerberos database while initializing kadmin > > > interface > > > # > > > > > > # kadmin -q 'addprinc -randkey WELLKNOWN/ANONYMOUS' -p admin > > > Authenticating as principal admin with password. > > > Password for admin at EXAMPLE.COM: > > > WARNING: no policy specified for WELLKNOWN/ANONYMOUS at EXAMPLE.COM; > > > defaulting to no policy > > > add_principal: Operation requires ``add'' privilege while creating > > > "WELLKNOWN/ANONYMOUS at EXAMPLE.COM". > > > # > > > > Please try > > > > kadmin.local -x ipa-setup-override-restrictions > > > > bye, > > Sumit > > > > > Thanks Sumit. > > That seems to have worked to get the principal created. > > # kadmin.local -x ipa-setup-override-restrictions > Authenticating as principal admin/admin at EXAMPLE.COM with password. > kadmin.local: addprinc -randkey WELLKNOWN/ANONYMOUS > WARNING: no policy specified for WELLKNOWN/ANONYMOUS at EXAMPLE.COM; > defaulting to no policy > Principal "WELLKNOWN/ANONYMOUS at EXAMPLE.COM" created. > kadmin.local: quit > # > > I'm no longer seeing the error from the client about 'WELLKNOWN/ > ANONYMOUS at EXAMPLE.COM' not found in Kerberos database. > > However, I'm being prompted for a password for the anonymous principal. > > $ kinit -n > Password for WELLKNOWN/ANONYMOUS at EXAMPLE.COM: > kinit: Password incorrect while getting initial credentials > $ > > That doesn't sound right to me - and indeed it doesn't provide an armor > cache that I can use for authenticating my client user. Can you run KRB5_TRACE=/dev/stdout kinit -n this will show the list of preauthentication methods offered to the client and I would suspect that pkinit is not among of them. My guess is that there is something wrong with the certificate or the configuration, e.g. did you try to set pkinit_kdc_hostname to the hostname matching the one in the KDC certificate? Maybe pkinit_eku_checking = none might help as well?. To analyse this further the most easy way is an instrumented build of the pkinit module with debugging enabled. If you can tell me the exact version of your krb5-pkinit package I can prepare a build for you. HTH bye, Sumit > > Here's what's in the krb5kdc.log from that attempt to use kinit -n > > Feb 10 00:55:46 ipa00-756701.example.com krb5kdc[4869](info): AS_REQ (6 > etypes {18 17 16 23 25 26}) 10.93.187.13: NEEDED_PREAUTH: WELLKNOWN/ > ANONYMOUS at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM, Additional > pre-authentication required > Feb 10 00:55:46 ipa00-756701.example.com krb5kdc[4869](info): closing down > fd 12 > Feb 10 00:55:47 ipa00-756701.example.com krb5kdc[4869](info): preauth > (encrypted_timestamp) verify failure: Decrypt integrity check failed > Feb 10 00:55:47 ipa00-756701.example.com krb5kdc[4869](info): AS_REQ (6 > etypes {18 17 16 23 25 26}) 10.93.187.13: PREAUTH_FAILED: WELLKNOWN/ > ANONYMOUS at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM, Decrypt integrity > check failed > Feb 10 00:55:47 ipa00-756701.example.com krb5kdc[4869](info): closing down > fd 12 > > Regards, > > Nik From jhrozek at redhat.com Wed Feb 10 08:52:26 2016 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 10 Feb 2016 09:52:26 +0100 Subject: [Freeipa-users] Where should I create my Linux and Mac users in a AD IPA trust? In-Reply-To: References: Message-ID: <20160210085226.GZ29883@hendrix.redhat.com> On Wed, Feb 10, 2016 at 08:41:15AM +0530, Supratik Goswami wrote: > I am currently running IPA server 4.2 in RHEL 7.2 and I have created a > two-way trust between > my Windows AD and IPA server. > > I have a heterogeneous environment where I have Windows, Linux and Mac > clients. > > The Windows users are present in AD and they can access the resources under > IPA through the trust relationship. > > What are the pros and cons > > 1. When I create Linux and Mac users in the AD. I'd say the management might be a slightly more complex than native IPA users due to having to use the IPA external groups to nest AD users and groups into IPA groups and eventually IPA policy resources like sudo rules or HBAC rules. > > 2. When I create Linux and Mac users in IPA Even though the trust is described as two-way, it is really not possible to access Windows resources or log in to Windows computers for IPA users. From jhrozek at redhat.com Wed Feb 10 08:54:34 2016 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 10 Feb 2016 09:54:34 +0100 Subject: [Freeipa-users] Generate and download krb5.keytab from host In-Reply-To: <56BAF230.7080400@redhat.com> References: <56BAF230.7080400@redhat.com> Message-ID: <20160210085434.GA29883@hendrix.redhat.com> On Wed, Feb 10, 2016 at 09:17:52AM +0100, Petr Spacek wrote: > On 9.2.2016 14:31, Vani Paridhyani wrote: > > Hi! > > > > I am trying to automate IPA client setup on Amazon Linux machines. Is there > > a way in which I can generate and download the krb5.keytab remotely from > > the server and get it in the host? > > ipa-client-install command is not working for you? Amazon Linux does not package ipa-client IIRC (they even didn't package sssd's IPA backend although that may have changed..) > > Keytab can be obtained manually using ipa-getkeytab command. From rcritten at redhat.com Wed Feb 10 09:01:34 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 10 Feb 2016 10:01:34 +0100 Subject: [Freeipa-users] IPA 4.2: pki-tomcatd in terrible shape In-Reply-To: References: <56B86DE0.4070909@redhat.com> <7F0EB8FC-8F2F-49D1-A124-562B5B0A55A2@accertify.com> <56B9AA53.1000400@redhat.com> Message-ID: <56BAFC6E.6030605@redhat.com> Timothy Geier wrote: > >> On Feb 9, 2016, at 2:58 AM, Rob Crittenden wrote: >> >> Timothy Geier wrote: >>> >>> >>> The debug log has a lot of instances of: >>> >>> Could not connect to LDAP server host xxx.xxxx port 636 Error >>> netscape.ldap.LDAPException: IO Error creating JSS SSL Socket (-1) >>> Internal Database Error encountered: Could not connect to LDAP server >>> host xxx.xxxx port 636 Error netscape.ldap.LDAPException: IO Error >>> creating JSS SSL Socket (-1) >> >> The 389-ds access log may show connection attempts and you might be able to correlate from there. >> > > [09/Feb/2016:12:55:41 -0600] conn=109598 fd=287 slot=287 SSL connection from master_ip to master_ip > [09/Feb/2016:12:55:41 -0600] conn=109597 op=0 EXT oid="1.3.6.1.4.1.1466.20037" name="startTLS" > [09/Feb/2016:12:55:41 -0600] conn=109597 op=0 RESULT err=0 tag=120 nentries=0 etime=0 > [09/Feb/2016:12:55:41 -0600] conn=109598 Netscape Portable Runtime error -8181 (Peer's Certificate has expired.); unauthenticated client CN=CA Subsystem,O=XXXXXXX.NET; issuer CN=Certificate Authority,O=XXXXXXX.NET > [09/Feb/2016:12:55:41 -0600] conn=109598 op=-1 fd=287 closed - Peer's Certificate has expired. > Ok, right. The subsystem cert expired on Feb 1 so you'd have to back at least that far in time to do the renewals. > > >> >> Some data is also stored in CS.cfg so you might ensure that the certificates stored there are correct as well. >> > > CS.cfg is correct/restored from backup. > >> There are a few entries in ou=People,o=ipaca that need to reflect the current state of certificates as well. >> > > While looking in cn=config for any o=ipaca entries, the following popped up..it looks like most of the old replicas and the old master hostnames weren?t properly cleaned up and there?s still RUVs for them..nsDS5ReplicaHost and Port also seem to be improperly set: A problem for a future day I think. > > ou=People doesn?t seem to exist in either the main tree or cn=config. The base is ou=People,o=ipaca >> Ok, you'll need to look at the host keytabs because something seems wrong with them. certmonger can't get a ticket using them. This could be because IPA isn't fully running but it is worth a look. > > All of the host keytabs on all of the IPA servers are correct..are there any other keytabs to check? No, just /etc/krb5.keytab. I think you should focus on getting the CA subsystem certs renewed and then we can look at the other things. So I'd go back in time to Jan 30 or so and just restart certmonger. rob > >> >>> Is this the correct procedure to follow when time shifted? >>> >>> - Stop IPA >>> - Change the system clock (and the hardware clock) to a point before the >>> expiration >>> - Start IPA >>> - Run getcert resubmit on the appropriate request IDs >>> - Stop IPA >>> - Return to real time >>> - Start IPA >>> >>> We haven?t tried it this week yet but all attempts at it last week >>> failed without any indication as to why the certs weren?t renewing; are >>> there any other logs to check/other steps in the procedure? >> >> Yes, that is correct. >> > > Thanks for the clarification. The IPA cluster itself is still doing ok after about a week of being in this state but something else we?re wondering is if we?ll be able to add replica servers while this is going on..it?s not critical to do so, but it is going to come up fairly soon. > >> rob > > > > "This message and any attachments may contain confidential information. If you > have received this message in error, any use or distribution is prohibited. > Please notify us by reply e-mail if you have mistakenly received this message, > and immediately and permanently delete it and any attachments. Thank you." > From mkosek at redhat.com Wed Feb 10 09:32:03 2016 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 10 Feb 2016 10:32:03 +0100 Subject: [Freeipa-users] OS migration from Fedora to CentOS? In-Reply-To: <56B47AEE.2010906@redhat.com> References: <3044CBB6-2CB9-4425-BE84-D046593903E7@uni.lu> <56B47AEE.2010906@redhat.com> Message-ID: <56BB0393.8010900@redhat.com> On 02/05/2016 11:35 AM, Petr Vobornik wrote: > On 02/04/2016 06:14 PM, Christophe TREFOIS wrote: >> Hi all, >> >> We are currently running a 3-replica (all are setup with the ?setup-ca flag) >> cluster on Fedora 21, with FreeIPA 4.1.4. >> >> We would like to slowly upgrade to the new version and move away from Fedora >> to CentOS 7.2. >> >> We were thinking of the following: >> >> - Create 3 CentOS machines with ?setup-ca flag so that our current cluster is 6. >> The first CentOS VM would then probably update the DB schema to the new >> FreeIPA version. >> - Remove the Fedora VMs 1 by 1 from the cluster using ipa-replica-manage del >> >> - Be happy? >> >> >> 1. Could you please advise if this is considered the safest practise? > > More or less yes: > > 1. create First IPA 4.2 against some FreeIPA 4.1.4 with CA > 2. create the other two against the newly Created CentOS - will verify if it is > in a good shape > 3. set new renewal CRL master: > http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master > 4. Migrate DNA ranges using ipa-replica-manage tool > > if all works well, remove all servers: > > 5. remove CA repl. agreements for old servers using ipa-csreplica-manage del > 6. remove old servers data and repl. agreements using ipa-replica-manage del > 7. uninstall old servers using ipa-server-install --uninstall > >> 2. Do we have to update to intermediate versions and if so how? > > Should not be necessary. Some advise is also present in the RHEL official docs: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html#migrating-ipa-proc From nik.eb.inc at gmail.com Wed Feb 10 12:07:14 2016 From: nik.eb.inc at gmail.com (Nik Lam) Date: Wed, 10 Feb 2016 23:07:14 +1100 Subject: [Freeipa-users] PKINIT support in FreeIPA 4.2.0 In-Reply-To: <20160210084317.GE3682@p.redhat.com> References: <20160203090821.GD20953@p.redhat.com> <20160208125341.GD13133@p.redhat.com> <20160209160439.GD3682@p.redhat.com> <20160210084317.GE3682@p.redhat.com> Message-ID: On Wed, Feb 10, 2016 at 7:43 PM, Sumit Bose wrote: > On Wed, Feb 10, 2016 at 12:07:45PM +1100, Nik Lam wrote: > > On Wed, Feb 10, 2016 at 3:04 AM, Sumit Bose wrote: > > > > > On Wed, Feb 10, 2016 at 02:08:55AM +1100, Nik Lam wrote: > > > > On Mon, Feb 8, 2016 at 11:53 PM, Sumit Bose > wrote: > > > > > > > > > On Thu, Feb 04, 2016 at 07:25:29PM +1100, Nik Lam wrote: > > > > > > On Wed, Feb 3, 2016 at 8:08 PM, Sumit Bose > wrote: > > > > > > > > > > > > > On Wed, Feb 03, 2016 at 10:29:49AM +1100, Nik Lam wrote: > > > > > > > > Hello, > > > > > > > > > > > > > > > > I installed ipa-server on Centos 7.1 and later did and > upgrade > > > of the > > > > > > > whole > > > > > > > > system to Centos 7.2. > > > > > > > > > > > > > > > > I think the FreeIPA version changed from 4.1.0 to 4.2.0 > between > > > these > > > > > > > > Centos/RHEL minor releases. > > > > > > > > > > > > > > > > We'd now like to try integrating with a 2FA provider via a > radius > > > > > proxy > > > > > > > and > > > > > > > > want to use anonymous PKINIT to secure the initial > communications > > > > > between > > > > > > > > the client and the KDC. > > > > > > > > > > > > > > > > We've tried following the MIT Kerberos PKINIT configuration > > > > > documentation > > > > > > > > > > > > > > > > > http://web.mit.edu/kerberos/krb5-1.14/doc/admin/pkinit.html > > > > > > > > > > > > > > > > generating our own certs manually with openssl but haven't > had > > > any > > > > > luck. > > > > > > > > We're seeing this in the kdc log: > > > > > > > > > > > > > > > > preauth pkinit failed to initialize: No realms configured > > > > > correctly > > > > > > > for > > > > > > > > pkinit support > > > > > > > > > > > > > > Which changes did you apply to krb5.conf? Did you use the IPA > CA to > > > > > sign > > > > > > > the certificate or some other CA? > > > > > > > > > > > > > > > > > > > > > > > I've noticed there are many new pkinit-related options that > have > > > been > > > > > > > added > > > > > > > > to the ipa-server-install script in 4.2.0, so it looks like > > > PKINIT is > > > > > > > > available in this version of FreeIPA. Is that the case? > > > > > > > > > > > > > > Which options are you referring to? > > > > > > > > > > > > > > bye, > > > > > > > Sumit > > > > > > > > > > > > > > > > > > > > > > > And if it is, what is the recommended way to enable it given > > > that it > > > > > > > seems > > > > > > > > to have been disabled in the original install that I did? Or > > > would it > > > > > > > just > > > > > > > > be easier to start from scratch with a 4.2.0 > ipa-server-install? > > > > > (It's a > > > > > > > > test instance that doesn't have too much in it - it will > take a > > > > > several > > > > > > > > hours to rebuild from scratch.) > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > Nik > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks Sumit. > > > > > > > > > > > > It sounds like PKINIT is available but clearly I'm doing it > wrong. > > > > > > > > > > > > > Which changes did you apply to krb5.conf? Did you use the IPA > CA > > > to > > > > > sign > > > > > > the certificate or some other CA? > > > > > > > > > > > > Actually, I modified the kdc.conf file - placed the kdc.pem, > > > kdckey.pem > > > > > and > > > > > > cacert.pem files in /var/kerberos/krb5kdc/ that I generated via > > > openssl > > > > > > commands in the MIT Kerberos documentation. The only change to > > > kdc.conf > > > > > > file was to append the location of the kdckey.pem file to > > > > > pkinit_identity. > > > > > > > > > > > > pkinit_identity = FILE:/var/kerberos/krb5kdc/kdc.pem > > > > > > pkinit_anchors = FILE:/var/kerberos/krb5kdc/cacert.pem > > > > > > > > > > > > became > > > > > > > > > > > > pkinit_identity = > > > > > > > FILE:/var/kerberos/krb5kdc/kdc.pem,/var/kerberos/krb5kdc/kdckey.pem > > > > > > pkinit_anchors = FILE:/var/kerberos/krb5kdc/cacert.pem > > > > > > > > > > > > Should I have been modifying krb5.conf instead? It aslo sounds > like I > > > > > need > > > > > > > > > > no, kdc.conf is the right place, I actually meant kdc.conf but > > > > > accidentially types krb5.conf. > > > > > > > > > > > to use a certificate signed by the IPAs CA - is this something > that > > > > > should > > > > > > be generated using ipa-getcert? Or do I just find the IPA CA's > > > private > > > > > key > > > > > > and use openssl following the MIT Kerberos documentation? > > > > > > > > > > > > > Which options are you referring to? > > > > > > > > > > > > When I looked at the --help text for 4.1.0 and 4.2.0 versions of > > > > > > ipa-server-install, I noticed that 4.2.0 has these in the > > > "certificate > > > > > > system options": > > > > > > > > > > > > --no-pkinit disables pkinit setup steps > > > > > > > > > > > > --pkinit-cert-file=FILE > > > > > > File containing the Kerberos KDC SSL > > > certificate > > > > > and > > > > > > private key > > > > > > > > > > > > --pkinit-pin=PIN The password to unlock the Kerberos KDC > > > private > > > > > key > > > > > > > > > > > > --pkinit-cert-name=NAME > > > > > > Name of the Kerberos KDC SSL certificate > to > > > > > install > > > > > > > > > > > > > > > > > > Seeing that first one, I was a little hopeful that pkinit is > enabled > > > by > > > > > > default in 4.2.0 but on a fresh install I just tried, I'm still > > > seeing > > > > > the > > > > > > > > > > no, unfortunately pkinit is currently disabled by default > > > > > > > > > > > following in krb5kdc.log when IPA is started up, so clearly it > isn't. > > > > > > > > > > > > (Error): preauth pkinit failed to initialize: No realms > configured > > > > > > correctly for pkinit support > > > > > > > > > > I get the same error when I put the certificate and the key into > > > > > separate files. Can you try to put both into one and use this for > the > > > > > pkinit_identity option? > > > > > > > > > > HTH > > > > > > > > > > bye, > > > > > Sumit > > > > > > > > > > > > > > > > > Thanks Sumit, it did! > > > > > > > > I concatenated the cert and the key into a single file and the error > has > > > > indeed gone away from krb5kdc.log > > > > > > > > The odd thing is that I can't reproduce the error by splitting into > two > > > > separate files and restarting ipa.service again. > > > > > > > > Ignoring that mystery, how do I go about setting up the > > > WELLKNOWN/ANONYMOUS > > > > principal? > > > > > > > > I'm pretty sure it's needed for anonymous pkinit: > > > > > > > > $ kinit > > > > kinit: Generic preauthentication failure while getting initial > > > credentials > > > > $ > > > > > > > > $ kinit -n > > > > kinit: Client 'WELLKNOWN/ANONYMOUS at EXAMPLE.COM' not found in > Kerberos > > > > database while getting initial credentials > > > > $ > > > > > > > > Using kadmin per the MIT documentation doesn't seem to work > > > (authenticated > > > > as an IPA admin) > > > > > > > > # kadmin -q 'addprinc -randkey WELLKNOWN/ANONYMOUS' > > > > Authenticating as principal admin/admin at EXAMPLE.COM with password. > > > > kadmin: Client not found in Kerberos database while initializing > kadmin > > > > interface > > > > # > > > > > > > > # kadmin -q 'addprinc -randkey WELLKNOWN/ANONYMOUS' -p admin > > > > Authenticating as principal admin with password. > > > > Password for admin at EXAMPLE.COM: > > > > WARNING: no policy specified for WELLKNOWN/ANONYMOUS at EXAMPLE.COM; > > > > defaulting to no policy > > > > add_principal: Operation requires ``add'' privilege while creating > > > > "WELLKNOWN/ANONYMOUS at EXAMPLE.COM". > > > > # > > > > > > Please try > > > > > > kadmin.local -x ipa-setup-override-restrictions > > > > > > bye, > > > Sumit > > > > > > > > Thanks Sumit. > > > > That seems to have worked to get the principal created. > > > > # kadmin.local -x ipa-setup-override-restrictions > > Authenticating as principal admin/admin at EXAMPLE.COM with password. > > kadmin.local: addprinc -randkey WELLKNOWN/ANONYMOUS > > WARNING: no policy specified for WELLKNOWN/ANONYMOUS at EXAMPLE.COM; > > defaulting to no policy > > Principal "WELLKNOWN/ANONYMOUS at EXAMPLE.COM" created. > > kadmin.local: quit > > # > > > > I'm no longer seeing the error from the client about 'WELLKNOWN/ > > ANONYMOUS at EXAMPLE.COM' not found in Kerberos database. > > > > However, I'm being prompted for a password for the anonymous principal. > > > > $ kinit -n > > Password for WELLKNOWN/ANONYMOUS at EXAMPLE.COM: > > kinit: Password incorrect while getting initial credentials > > $ > > > > That doesn't sound right to me - and indeed it doesn't provide an armor > > cache that I can use for authenticating my client user. > > Can you run > > KRB5_TRACE=/dev/stdout kinit -n > > this will show the list of preauthentication methods offered to the > client and I would suspect that pkinit is not among of them. > > My guess is that there is something wrong with the certificate or the > configuration, e.g. did you try to set pkinit_kdc_hostname to the > hostname matching the one in the KDC certificate? Maybe > pkinit_eku_checking = none might help as well?. > > To analyse this further the most easy way is an instrumented build of > the pkinit module with debugging enabled. If you can tell me the exact > version of your krb5-pkinit package I can prepare a build for you. > > HTH > > bye, > Sumit > Thank you Sumit. I've checked that the hostname in the KDC's cert matches what I've put in the client's krb.conf's pkinit_hostname. I've also tried setting pkinit_eku_checking = none in there. $ KRB5_TRACE=/dev/stdout kinit -n [9199] 1455105392.574916: Getting initial credentials for WELLKNOWN/ ANONYMOUS at EXAMPLE.COM [9199] 1455105392.575132: Sending request (186 bytes) to EXAMPLE.COM [9199] 1455105392.575314: Initiating TCP connection to stream 10.93.178.73:88 [9199] 1455105392.576513: Sending TCP request to stream 10.93.178.73:88 [9199] 1455105393.370873: Received answer (483 bytes) from stream 10.93.178.73:88 [9199] 1455105393.370885: Terminating TCP connection to stream 10.93.178.73:88 [9199] 1455105393.370956: Response was from master KDC [9199] 1455105393.370977: Received error from KDC: -1765328359/Additional pre-authentication required [9199] 1455105393.371014: Processing preauth types: 16, 15, 14, 136, 19, 147, 2, 133 [9199] 1455105393.371040: Selected etype info: etype aes256-cts, salt "EXAMPLE.COMWELLKNOWNANONYMOUS", params "" [9199] 1455105393.371046: Received cookie: MIT Password for WELLKNOWN/ANONYMOUS at EXAMPLE.COM: [9199] 1455105400.912468: AS key obtained for encrypted timestamp: aes256-cts/09BF [9199] 1455105400.912546: Encrypted timestamp (for 1455105400.914484): plain 301AA011180F32303136303231303131353634305AA10502030DF434, encrypted DD840BC3D6F697529D987E73EDD1C9FF82FEC91A0FB408179E6FA9AF49627912BEF49BA4E4EE8FF469BED5672943592A1E7DFBBF781C1E5B [9199] 1455105400.912576: Preauth module encrypted_timestamp (2) (real) returned: 0/Success [9199] 1455105400.912581: Produced preauth for next request: 133, 2 [9199] 1455105400.912601: Sending request (281 bytes) to EXAMPLE.COM [9199] 1455105400.912674: Initiating TCP connection to stream 10.93.178.73:88 [9199] 1455105400.913894: Sending TCP request to stream 10.93.178.73:88 [9199] 1455105400.937778: Received answer (197 bytes) from stream 10.93.178.73:88 [9199] 1455105400.937788: Terminating TCP connection to stream 10.93.178.73:88 [9199] 1455105400.937835: Response was from master KDC [9199] 1455105400.937852: Received error from KDC: -1765328353/Decrypt integrity check failed kinit: Password incorrect while getting initial credentials $ The module package we're using right now is krb5-pkinit-1.13.2-10.el7.x86_64. Regards, Nik -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbose at redhat.com Wed Feb 10 12:07:44 2016 From: sbose at redhat.com (Sumit Bose) Date: Wed, 10 Feb 2016 13:07:44 +0100 Subject: [Freeipa-users] Active Directory Trust = filter users In-Reply-To: <20160210084228.GY29883@hendrix.redhat.com> References: <56B9C666.9000302@dds.nl> <20160210084228.GY29883@hendrix.redhat.com> Message-ID: <20160210120744.GM3682@p.redhat.com> On Wed, Feb 10, 2016 at 09:42:28AM +0100, Jakub Hrozek wrote: > On Tue, Feb 09, 2016 at 11:58:46AM +0100, Winfried de Heiden wrote: > > Hi all, > > > > Using an Active Directory Trust with IPA all works fine but there's an > > disadvantage: it might brong in lots and lots of groups I am not > > interested in since it mainly hit Windows and/or Office stuff. > > Why are you concerned about this in the first place? Is it about > performance needed to process these groups or about resources that can > be owned by these groups? > > > > > Now, is it possible to filter AD-groups? or: can I use an AD search base > > filter? (something like cn=linuxgroups,ou=allgroups,dc=example,dc=com) > > Not at the moment, the subdomains are autoconfigured and not > configurable. Additionally please note that some of the more advances schemes we use for group-membership lookups in AD like PAC data or the tokenGroups request just return all groups a user is a member of in a single call, no need to walk through the AD directory tree to resolve nested groups. We still have to look up the groups to get their name and maybe the GID but if we would apply a filter we had to look them up as well because we only know the SID. Falling back to a different scheme would not improve the situation performance wise because we have to read all groups even the outside the given search base to be able to resolve nested groups correctly. HTH bye, Sumit > > > > > On a small scale ID views can be used, but it not a great solution. (for > > all new groups appearing in AD the ID view must be modified) > > > > Some sugestions or documentation on filtering AD groups? > > > > Winny > > > -- > > Manage your subscription for the Freeipa-users mailing list: > > https://www.redhat.com/mailman/listinfo/freeipa-users > > Go to http://freeipa.org for more info on the project > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project From wdh at dds.nl Wed Feb 10 12:21:04 2016 From: wdh at dds.nl (Winfried de Heiden) Date: Wed, 10 Feb 2016 13:21:04 +0100 Subject: [Freeipa-users] Active Directory Trust = filter users In-Reply-To: <20160210084228.GY29883@hendrix.redhat.com> References: <56B9C666.9000302@dds.nl> <20160210084228.GY29883@hendrix.redhat.com> Message-ID: <56BB2B30.108@dds.nl> An HTML attachment was scrubbed... URL: From sbose at redhat.com Wed Feb 10 12:35:17 2016 From: sbose at redhat.com (Sumit Bose) Date: Wed, 10 Feb 2016 13:35:17 +0100 Subject: [Freeipa-users] Migrating NIS host to freeIPA host with smart card In-Reply-To: References: Message-ID: <20160210123517.GN3682@p.redhat.com> On Tue, Feb 09, 2016 at 04:54:55PM -0600, Michael Rainey (Contractor) wrote: > Greetings, > > I have a question about migrating a system from NIS to freeIPA. In my > efforts of setting up a host on freeIPA I would normally use a fresh install > to setup the system. I'm now at a point where I'm moving existing systems > from an NIS domain to a freeIPA domain. Is it recommended to perform a > clean install for every new host added to the domain? > > During my testing, I have found running the ipa-client-install command does > a great job of adding the host to the domain, but when I try to use the > smart card it is never recognized by gdm. I tried tweaking some of the > configurations to get GDM to recognize the card with no luck. Is there a > checklist available that I could follow to make sure everything is All you have to do after running ipa-client-install is to add 'pam_cert_auth = True' to the [pam] section of sssd.conf. This is not enabled by default since checking the Smartcard in the reader takes some time and will slow down authentication. If new a user tries to login which has his certificates stored in the user entry on the IPA server and a Smartcard with a certificate in the reader gdm will not ask for a password but for the Smartcard pin. HTH bye, Sumit > configured properly? All configurations work when using a username and > password. > -- > *Michael Rainey* > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project From abokovoy at redhat.com Wed Feb 10 12:46:46 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 10 Feb 2016 14:46:46 +0200 Subject: [Freeipa-users] Active Directory Trust = filter users In-Reply-To: <56BB2B30.108@dds.nl> References: <56B9C666.9000302@dds.nl> <20160210084228.GY29883@hendrix.redhat.com> <56BB2B30.108@dds.nl> Message-ID: <20160210124646.GE28065@redhat.com> On Wed, 10 Feb 2016, Winfried de Heiden wrote: >Hi all, > >"hy are you concerned about this in the first place? " > >It started from a practical point of view: if one is using the DC of the Office >Automation, Ad users will get all sorts of AD groups I am never going to use. >so why do I want to see them anyway? My screen get's a bit messy as for >"user at ad.example.com"? when this user belongs tot 25 or something groups... It >would be nice to hide these... > >Can I blacklist some of the groups? (Trusts? --> ad.example.com --> Settings) >by using the SID? Yes, you can filter out certain SIDs at the KDC side by using settings of the trust. Theoretically, SSSD would need to remove the group membership for groups not existing in the MS-PAC. -- / Alexander Bokovoy From sbose at redhat.com Wed Feb 10 14:42:05 2016 From: sbose at redhat.com (Sumit Bose) Date: Wed, 10 Feb 2016 15:42:05 +0100 Subject: [Freeipa-users] PKINIT support in FreeIPA 4.2.0 In-Reply-To: References: <20160203090821.GD20953@p.redhat.com> <20160208125341.GD13133@p.redhat.com> <20160209160439.GD3682@p.redhat.com> <20160210084317.GE3682@p.redhat.com> Message-ID: <20160210144205.GA12933@p.redhat.com> On Wed, Feb 10, 2016 at 11:07:14PM +1100, Nik Lam wrote: > On Wed, Feb 10, 2016 at 7:43 PM, Sumit Bose wrote: > > > On Wed, Feb 10, 2016 at 12:07:45PM +1100, Nik Lam wrote: > > > On Wed, Feb 10, 2016 at 3:04 AM, Sumit Bose wrote: > > > > > > > On Wed, Feb 10, 2016 at 02:08:55AM +1100, Nik Lam wrote: > > > > > On Mon, Feb 8, 2016 at 11:53 PM, Sumit Bose > > wrote: > > > > > > > > > > > On Thu, Feb 04, 2016 at 07:25:29PM +1100, Nik Lam wrote: > > > > > > > On Wed, Feb 3, 2016 at 8:08 PM, Sumit Bose > > wrote: > > > > > > > > > > > > > > > On Wed, Feb 03, 2016 at 10:29:49AM +1100, Nik Lam wrote: > > > > > > > > > Hello, > > > > > > > > > > > > > > > > > > I installed ipa-server on Centos 7.1 and later did and > > upgrade > > > > of the > > > > > > > > whole > > > > > > > > > system to Centos 7.2. > > > > > > > > > > > > > > > > > > I think the FreeIPA version changed from 4.1.0 to 4.2.0 > > between > > > > these > > > > > > > > > Centos/RHEL minor releases. > > > > > > > > > > > > > > > > > > We'd now like to try integrating with a 2FA provider via a > > radius > > > > > > proxy > > > > > > > > and > > > > > > > > > want to use anonymous PKINIT to secure the initial > > communications > > > > > > between > > > > > > > > > the client and the KDC. > > > > > > > > > > > > > > > > > > We've tried following the MIT Kerberos PKINIT configuration > > > > > > documentation > > > > > > > > > > > > > > > > > > > > http://web.mit.edu/kerberos/krb5-1.14/doc/admin/pkinit.html > > > > > > > > > > > > > > > > > > generating our own certs manually with openssl but haven't > > had > > > > any > > > > > > luck. > > > > > > > > > We're seeing this in the kdc log: > > > > > > > > > > > > > > > > > > preauth pkinit failed to initialize: No realms configured > > > > > > correctly > > > > > > > > for > > > > > > > > > pkinit support > > > > > > > > > > > > > > > > Which changes did you apply to krb5.conf? Did you use the IPA > > CA to > > > > > > sign > > > > > > > > the certificate or some other CA? > > > > > > > > > > > > > > > > > > > > > > > > > > I've noticed there are many new pkinit-related options that > > have > > > > been > > > > > > > > added > > > > > > > > > to the ipa-server-install script in 4.2.0, so it looks like > > > > PKINIT is > > > > > > > > > available in this version of FreeIPA. Is that the case? > > > > > > > > > > > > > > > > Which options are you referring to? > > > > > > > > > > > > > > > > bye, > > > > > > > > Sumit > > > > > > > > > > > > > > > > > > > > > > > > > > And if it is, what is the recommended way to enable it given > > > > that it > > > > > > > > seems > > > > > > > > > to have been disabled in the original install that I did? Or > > > > would it > > > > > > > > just > > > > > > > > > be easier to start from scratch with a 4.2.0 > > ipa-server-install? > > > > > > (It's a > > > > > > > > > test instance that doesn't have too much in it - it will > > take a > > > > > > several > > > > > > > > > hours to rebuild from scratch.) > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > Nik > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks Sumit. > > > > > > > > > > > > > > It sounds like PKINIT is available but clearly I'm doing it > > wrong. > > > > > > > > > > > > > > > Which changes did you apply to krb5.conf? Did you use the IPA > > CA > > > > to > > > > > > sign > > > > > > > the certificate or some other CA? > > > > > > > > > > > > > > Actually, I modified the kdc.conf file - placed the kdc.pem, > > > > kdckey.pem > > > > > > and > > > > > > > cacert.pem files in /var/kerberos/krb5kdc/ that I generated via > > > > openssl > > > > > > > commands in the MIT Kerberos documentation. The only change to > > > > kdc.conf > > > > > > > file was to append the location of the kdckey.pem file to > > > > > > pkinit_identity. > > > > > > > > > > > > > > pkinit_identity = FILE:/var/kerberos/krb5kdc/kdc.pem > > > > > > > pkinit_anchors = FILE:/var/kerberos/krb5kdc/cacert.pem > > > > > > > > > > > > > > became > > > > > > > > > > > > > > pkinit_identity = > > > > > > > > > FILE:/var/kerberos/krb5kdc/kdc.pem,/var/kerberos/krb5kdc/kdckey.pem > > > > > > > pkinit_anchors = FILE:/var/kerberos/krb5kdc/cacert.pem > > > > > > > > > > > > > > Should I have been modifying krb5.conf instead? It aslo sounds > > like I > > > > > > need > > > > > > > > > > > > no, kdc.conf is the right place, I actually meant kdc.conf but > > > > > > accidentially types krb5.conf. > > > > > > > > > > > > > to use a certificate signed by the IPAs CA - is this something > > that > > > > > > should > > > > > > > be generated using ipa-getcert? Or do I just find the IPA CA's > > > > private > > > > > > key > > > > > > > and use openssl following the MIT Kerberos documentation? > > > > > > > > > > > > > > > Which options are you referring to? > > > > > > > > > > > > > > When I looked at the --help text for 4.1.0 and 4.2.0 versions of > > > > > > > ipa-server-install, I noticed that 4.2.0 has these in the > > > > "certificate > > > > > > > system options": > > > > > > > > > > > > > > --no-pkinit disables pkinit setup steps > > > > > > > > > > > > > > --pkinit-cert-file=FILE > > > > > > > File containing the Kerberos KDC SSL > > > > certificate > > > > > > and > > > > > > > private key > > > > > > > > > > > > > > --pkinit-pin=PIN The password to unlock the Kerberos KDC > > > > private > > > > > > key > > > > > > > > > > > > > > --pkinit-cert-name=NAME > > > > > > > Name of the Kerberos KDC SSL certificate > > to > > > > > > install > > > > > > > > > > > > > > > > > > > > > Seeing that first one, I was a little hopeful that pkinit is > > enabled > > > > by > > > > > > > default in 4.2.0 but on a fresh install I just tried, I'm still > > > > seeing > > > > > > the > > > > > > > > > > > > no, unfortunately pkinit is currently disabled by default > > > > > > > > > > > > > following in krb5kdc.log when IPA is started up, so clearly it > > isn't. > > > > > > > > > > > > > > (Error): preauth pkinit failed to initialize: No realms > > configured > > > > > > > correctly for pkinit support > > > > > > > > > > > > I get the same error when I put the certificate and the key into > > > > > > separate files. Can you try to put both into one and use this for > > the > > > > > > pkinit_identity option? > > > > > > > > > > > > HTH > > > > > > > > > > > > bye, > > > > > > Sumit > > > > > > > > > > > > > > > > > > > > > Thanks Sumit, it did! > > > > > > > > > > I concatenated the cert and the key into a single file and the error > > has > > > > > indeed gone away from krb5kdc.log > > > > > > > > > > The odd thing is that I can't reproduce the error by splitting into > > two > > > > > separate files and restarting ipa.service again. > > > > > > > > > > Ignoring that mystery, how do I go about setting up the > > > > WELLKNOWN/ANONYMOUS > > > > > principal? > > > > > > > > > > I'm pretty sure it's needed for anonymous pkinit: > > > > > > > > > > $ kinit > > > > > kinit: Generic preauthentication failure while getting initial > > > > credentials > > > > > $ > > > > > > > > > > $ kinit -n > > > > > kinit: Client 'WELLKNOWN/ANONYMOUS at EXAMPLE.COM' not found in > > Kerberos > > > > > database while getting initial credentials > > > > > $ > > > > > > > > > > Using kadmin per the MIT documentation doesn't seem to work > > > > (authenticated > > > > > as an IPA admin) > > > > > > > > > > # kadmin -q 'addprinc -randkey WELLKNOWN/ANONYMOUS' > > > > > Authenticating as principal admin/admin at EXAMPLE.COM with password. > > > > > kadmin: Client not found in Kerberos database while initializing > > kadmin > > > > > interface > > > > > # > > > > > > > > > > # kadmin -q 'addprinc -randkey WELLKNOWN/ANONYMOUS' -p admin > > > > > Authenticating as principal admin with password. > > > > > Password for admin at EXAMPLE.COM: > > > > > WARNING: no policy specified for WELLKNOWN/ANONYMOUS at EXAMPLE.COM; > > > > > defaulting to no policy > > > > > add_principal: Operation requires ``add'' privilege while creating > > > > > "WELLKNOWN/ANONYMOUS at EXAMPLE.COM". > > > > > # > > > > > > > > Please try > > > > > > > > kadmin.local -x ipa-setup-override-restrictions > > > > > > > > bye, > > > > Sumit > > > > > > > > > > > Thanks Sumit. > > > > > > That seems to have worked to get the principal created. > > > > > > # kadmin.local -x ipa-setup-override-restrictions > > > Authenticating as principal admin/admin at EXAMPLE.COM with password. > > > kadmin.local: addprinc -randkey WELLKNOWN/ANONYMOUS > > > WARNING: no policy specified for WELLKNOWN/ANONYMOUS at EXAMPLE.COM; > > > defaulting to no policy > > > Principal "WELLKNOWN/ANONYMOUS at EXAMPLE.COM" created. > > > kadmin.local: quit > > > # > > > > > > I'm no longer seeing the error from the client about 'WELLKNOWN/ > > > ANONYMOUS at EXAMPLE.COM' not found in Kerberos database. > > > > > > However, I'm being prompted for a password for the anonymous principal. > > > > > > $ kinit -n > > > Password for WELLKNOWN/ANONYMOUS at EXAMPLE.COM: > > > kinit: Password incorrect while getting initial credentials > > > $ > > > > > > That doesn't sound right to me - and indeed it doesn't provide an armor > > > cache that I can use for authenticating my client user. > > > > Can you run > > > > KRB5_TRACE=/dev/stdout kinit -n > > > > this will show the list of preauthentication methods offered to the > > client and I would suspect that pkinit is not among of them. > > > > My guess is that there is something wrong with the certificate or the > > configuration, e.g. did you try to set pkinit_kdc_hostname to the > > hostname matching the one in the KDC certificate? Maybe > > pkinit_eku_checking = none might help as well?. > > > > To analyse this further the most easy way is an instrumented build of > > the pkinit module with debugging enabled. If you can tell me the exact > > version of your krb5-pkinit package I can prepare a build for you. > > > > HTH > > > > bye, > > Sumit > > > > Thank you Sumit. > > I've checked that the hostname in the KDC's cert matches what I've put in > the client's krb.conf's pkinit_hostname. > > I've also tried setting pkinit_eku_checking = none in there. > > $ KRB5_TRACE=/dev/stdout kinit -n > [9199] 1455105392.574916: Getting initial credentials for WELLKNOWN/ > ANONYMOUS at EXAMPLE.COM > [9199] 1455105392.575132: Sending request (186 bytes) to EXAMPLE.COM > [9199] 1455105392.575314: Initiating TCP connection to stream > 10.93.178.73:88 > [9199] 1455105392.576513: Sending TCP request to stream 10.93.178.73:88 > [9199] 1455105393.370873: Received answer (483 bytes) from stream > 10.93.178.73:88 > [9199] 1455105393.370885: Terminating TCP connection to stream > 10.93.178.73:88 > [9199] 1455105393.370956: Response was from master KDC > [9199] 1455105393.370977: Received error from KDC: -1765328359/Additional > pre-authentication required > [9199] 1455105393.371014: Processing preauth types: 16, 15, 14, 136, 19, > 147, 2, 133 ok, 147 means that the server added the needed preauthentication data for anonymous pkinit. Did you set pkinit_anchors = FILE:/var/kerberos/krb5kdc/cacert.pem in /etc/krb5.conf as well becasue the client must know the CA certificate as well? > [9199] 1455105393.371040: Selected etype info: etype aes256-cts, salt > "EXAMPLE.COMWELLKNOWNANONYMOUS", params "" > [9199] 1455105393.371046: Received cookie: MIT > Password for WELLKNOWN/ANONYMOUS at EXAMPLE.COM: > [9199] 1455105400.912468: AS key obtained for encrypted timestamp: > aes256-cts/09BF > [9199] 1455105400.912546: Encrypted timestamp (for 1455105400.914484): > plain 301AA011180F32303136303231303131353634305AA10502030DF434, encrypted > DD840BC3D6F697529D987E73EDD1C9FF82FEC91A0FB408179E6FA9AF49627912BEF49BA4E4EE8FF469BED5672943592A1E7DFBBF781C1E5B > [9199] 1455105400.912576: Preauth module encrypted_timestamp (2) (real) > returned: 0/Success > [9199] 1455105400.912581: Produced preauth for next request: 133, 2 > [9199] 1455105400.912601: Sending request (281 bytes) to EXAMPLE.COM > [9199] 1455105400.912674: Initiating TCP connection to stream > 10.93.178.73:88 > [9199] 1455105400.913894: Sending TCP request to stream 10.93.178.73:88 > [9199] 1455105400.937778: Received answer (197 bytes) from stream > 10.93.178.73:88 > [9199] 1455105400.937788: Terminating TCP connection to stream > 10.93.178.73:88 > [9199] 1455105400.937835: Response was from master KDC > [9199] 1455105400.937852: Received error from KDC: -1765328353/Decrypt > integrity check failed > kinit: Password incorrect while getting initial credentials > $ > > The module package we're using right now is > krb5-pkinit-1.13.2-10.el7.x86_64. Please find the package with debugging enabled at https://kojipkgs.fedoraproject.org//work/tasks/8127/12928127/krb5-pkinit-1.13.2-10.el7sb.x86_64.rpm It might be possible to install it with rpm -Uhv --nodeps krb5-pkinit-1.13.2-10.el7sb.x86_64.rpm to get around yum's dependency checking but after testing yum downgrade krb5-pkinit should be able to install the original version again. Please do not forget to revert to the original version, otherwise SSSD's Kerberos authentication might break because the pkinit module will print the debug messages just to stdout. As an alternative you can just extract /usr/lib64/krb5/plugins/preauth/pkinit.so with rpm2cpio from the package and replace the original one. Do not forget to make a copy of the original module in a different directory to be able to revert the change. HTH bye, Sumit > > Regards, > > Nik From pdomineaux at gmail.com Wed Feb 10 17:03:45 2016 From: pdomineaux at gmail.com (Domineaux Philippe) Date: Wed, 10 Feb 2016 18:03:45 +0100 Subject: [Freeipa-users] nfsnobody with ubuntu 14.04 in trusted relationship with AD Message-ID: Hello all, I have several virtual machines ( on virtualbox ) running freeipa-client and freeipa-server in a trust domain relationship with an Active Directory (AD) also on a virtual machine. Here is the details of the machines : ### Freeipa-server : - Centos 7.2 - ipa-server-install 4.2.0 ### client1 : - centos 7.2 - ipa-client-install 4.2.0 ### Nfs-server : - centos 7.2 - ipa-client-install 4.2.0 ### Client2 : - Ubuntu 14.04 (trusty) - ipa-client-install 3.3.4 also try the unofficial 4.0.x backport ( https://launchpad.net/~freeipa/+archive/ubuntu/4.0) Everything works fine except for the ubuntu client and the nfs mount : - I can mount the share using ""-o sec=krb5" option but the owner of the folders is nobody. It seems just a display error because the permissions on the files are good. user1 cannot write on the folder of user2 and vice versa. If I mount without kinit I get this (syslog ubuntu client): Feb 10 17:09:38 client2 rpc.idmapd[417]: New client: 0 Feb 10 17:09:38 client2 kernel: [ 2709.796390] NFS: Registering the id_resolver key type Feb 10 17:09:38 client2 kernel: [ 2709.796399] Key type id_resolver registered Feb 10 17:09:38 client2 kernel: [ 2709.796399] Key type id_legacy registered Feb 10 17:09:38 client2 rpc.idmapd[417]: Opened /run/rpc_pipefs/nfs/clnt0/idmap Feb 10 17:09:38 client2 rpc.idmapd[417]: New client: 1 Feb 10 17:09:38 client2 nfsidmap[2714]: key: 0x261c251d type: uid value: root at ipa.local timeout 600 Feb 10 17:09:38 client2 nfsidmap[2714]: nfs4_name_to_uid: calling nsswitch->name_to_uid Feb 10 17:09:38 client2 nfsidmap[2714]: nss_getpwnam: name 'root at ipa.local' domain 'ipa.local': resulting localname 'root' Feb 10 17:09:38 client2 nfsidmap[2714]: nfs4_name_to_uid: nsswitch->name_to_uid returned 0 Feb 10 17:09:38 client2 nfsidmap[2714]: nfs4_name_to_uid: final return value is 0 Feb 10 17:09:38 client2 nfsidmap[2716]: key: 0x314352bb type: gid value: root at ipa.local timeout 600 Feb 10 17:09:38 client2 nfsidmap[2716]: nfs4_name_to_gid: calling nsswitch->name_to_gid Feb 10 17:09:38 client2 nfsidmap[2716]: nfs4_name_to_gid: nsswitch->name_to_gid returned 0 Feb 10 17:09:38 client2 nfsidmap[2716]: nfs4_name_to_gid: final return value is 0 Feb 10 17:09:55 client2 nfsidmap[2722]: key: 0x29600d2b type: uid value: adipa at domino.local@ipa.local timeout 600 Feb 10 17:09:55 client2 nfsidmap[2722]: nfs4_name_to_uid: calling nsswitch->name_to_uid Feb 10 17:09:55 client2 nfsidmap[2722]: nss_getpwnam: name 'adipa at domino.local@ipa.local' domain 'ipa.local': resulting localname '(null)' Feb 10 17:09:55 client2 nfsidmap[2722]: nss_getpwnam: name 'adipa at domino.local@ipa.local' does not map into domain 'ipa.local' Feb 10 17:09:55 client2 nfsidmap[2722]: nfs4_name_to_uid: nsswitch->name_to_uid returned -22 Feb 10 17:09:55 client2 nfsidmap[2722]: nfs4_name_to_uid: final return value is -22 Feb 10 17:09:55 client2 nfsidmap[2722]: nfs4_name_to_uid: calling nsswitch->name_to_uid Feb 10 17:09:55 client2 nfsidmap[2722]: nss_getpwnam: name 'nobody at ipa.local' domain 'ipa.local': resulting localname 'nobody' Feb 10 17:09:55 client2 nfsidmap[2722]: nfs4_name_to_uid: nsswitch->name_to_uid returned 0 Feb 10 17:09:55 client2 nfsidmap[2722]: nfs4_name_to_uid: final return value is 0 Feb 10 17:09:55 client2 nfsidmap[2724]: key: 0x398852c2 type: gid value: posix_users at domino.local@ipa.local timeout 600 Feb 10 17:09:55 client2 nfsidmap[2724]: nfs4_name_to_gid: calling nsswitch->name_to_gid Feb 10 17:09:55 client2 nfsidmap[2724]: nfs4_name_to_gid: nsswitch->name_to_gid returned -22 Feb 10 17:09:55 client2 nfsidmap[2724]: nfs4_name_to_gid: final return value is -22 Feb 10 17:09:55 client2 nfsidmap[2724]: nfs4_name_to_gid: calling nsswitch->name_to_gid Feb 10 17:09:56 client2 nfsidmap[2724]: nfs4_name_to_gid: nsswitch->name_to_gid returned -2 Feb 10 17:09:56 client2 nfsidmap[2724]: nfs4_name_to_gid: final return value is -2 But if I mount with let's say kinit admin no logs in the syslog file of the ubuntu client. Another thing is, when mounting on both clients (ubuntu and centos), the NFS server output : "nfsserver gssproxy: gssproxy[659]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure. Minor code may provide more information, No credentials cache found" But it works for the centos but not for the ubuntu. ### NFS server logs for client 2 (Ubuntu) : Feb 10 17:30:01 nfsserver systemd: Created slice user-0.slice. Feb 10 17:30:01 nfsserver systemd: Starting user-0.slice. Feb 10 17:30:01 nfsserver systemd: Started Session 14 of user root. Feb 10 17:30:01 nfsserver systemd: Starting Session 14 of user root. Feb 10 17:30:01 nfsserver systemd: Removed slice user-0.slice. Feb 10 17:30:01 nfsserver systemd: Stopping user-0.slice. Feb 10 17:30:21 nfsserver rpc.gssd[756]: Closing 'gssd' pipe for /var/lib/nfs/rpc_pipefs/nfsd4_cb/clnt5 Feb 10 17:30:21 nfsserver rpc.gssd[756]: destroying client /var/lib/nfs/rpc_pipefs/nfsd4_cb/clnt5 Feb 10 17:30:21 nfsserver rpc.gssd[756]: handling gssd upcall (/var/lib/nfs/rpc_pipefs/nfsd4_cb/clnt6) Feb 10 17:30:21 nfsserver rpc.gssd[756]: handle_gssd_upcall: 'mech=krb5 uid=0 target=host at client2.ipa.local service=nfs enctypes=18,17,16,23,3,1,2 ' Feb 10 17:30:21 nfsserver rpc.gssd[756]: handling krb5 upcall (/var/lib/nfs/rpc_pipefs/nfsd4_cb/clnt6) Feb 10 17:30:21 nfsserver rpc.gssd[756]: process_krb5_upcall: service is 'nfs' Feb 10 17:30:21 nfsserver rpc.gssd[756]: krb5_use_machine_creds: uid 0 tgtname host at client2.ipa.local Feb 10 17:30:21 nfsserver rpc.gssd[756]: Full hostname for 'client2.ipa.local' is 'client2.ipa.local' Feb 10 17:30:21 nfsserver rpc.gssd[756]: Full hostname for 'nfsserver.ipa.local' is 'nfsserver.ipa.local' Feb 10 17:30:21 nfsserver rpc.gssd[756]: Success getting keytab entry for 'nfs/nfsserver.ipa.local at IPA.LOCAL' Feb 10 17:30:21 nfsserver rpc.gssd[756]: INFO: Credentials in CC 'FILE:/tmp/krb5ccmachine_IPA.LOCAL' are good until 1455202622 Feb 10 17:30:21 nfsserver rpc.gssd[756]: INFO: Credentials in CC 'FILE:/tmp/krb5ccmachine_IPA.LOCAL' are good until 1455202622 Feb 10 17:30:21 nfsserver rpc.gssd[756]: using FILE:/tmp/krb5ccmachine_IPA.LOCAL as credentials cache for machine creds Feb 10 17:30:21 nfsserver rpc.gssd[756]: using environment variable to select krb5 ccache FILE:/tmp/krb5ccmachine_IPA.LOCAL Feb 10 17:30:21 nfsserver gssproxy: gssproxy[659]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure. Minor code may provide more information, No credentials cache found Feb 10 17:30:21 nfsserver rpc.gssd[756]: creating tcp client for server client2.ipa.local Feb 10 17:30:21 nfsserver rpc.gssd[756]: DEBUG: port already set to 50270 Feb 10 17:30:21 nfsserver rpc.gssd[756]: creating context with server host at client2.ipa.local Feb 10 17:30:21 nfsserver rpc.gssd[756]: WARNING: Failed to create krb5 context for user with uid 0 for server host at client2.ipa.local Feb 10 17:30:21 nfsserver rpc.gssd[756]: WARNING: Failed to create machine krb5context with cred cache FILE:/tmp/krb5ccmachine_IPA.LOCAL for server client2.ipa.local Feb 10 17:30:21 nfsserver rpc.gssd[756]: WARNING: Machine cache prematurelyexpired or corrupted trying torecreate cache for server client2.ipa.local Feb 10 17:30:21 nfsserver rpc.gssd[756]: Full hostname for 'client2.ipa.local' is 'client2.ipa.local' Feb 10 17:30:21 nfsserver rpc.gssd[756]: Full hostname for 'nfsserver.ipa.local' is 'nfsserver.ipa.local' Feb 10 17:30:21 nfsserver rpc.gssd[756]: Success getting keytab entry for 'nfs/nfsserver.ipa.local at IPA.LOCAL' Feb 10 17:30:21 nfsserver rpc.gssd[756]: INFO: Credentials in CC 'FILE:/tmp/krb5ccmachine_IPA.LOCAL' are good until 1455202622 Feb 10 17:30:21 nfsserver rpc.gssd[756]: INFO: Credentials in CC 'FILE:/tmp/krb5ccmachine_IPA.LOCAL' are good until 1455202622 Feb 10 17:30:21 nfsserver rpc.gssd[756]: using FILE:/tmp/krb5ccmachine_IPA.LOCAL as credentials cache for machine creds Feb 10 17:30:21 nfsserver rpc.gssd[756]: using environment variable to select krb5 ccache FILE:/tmp/krb5ccmachine_IPA.LOCAL Feb 10 17:30:21 nfsserver rpc.gssd[756]: creating tcp client for server client2.ipa.local Feb 10 17:30:21 nfsserver rpc.gssd[756]: DEBUG: port already set to 50270 Feb 10 17:30:21 nfsserver rpc.gssd[756]: creating context with server host at client2.ipa.local Feb 10 17:30:21 nfsserver rpc.gssd[756]: WARNING: Failed to create krb5 context for user with uid 0 for server host at client2.ipa.local Feb 10 17:30:21 nfsserver rpc.gssd[756]: WARNING: Failed to create machine krb5context with cred cache FILE:/tmp/krb5ccmachine_IPA.LOCAL for server client2.ipa.local Feb 10 17:30:21 nfsserver gssproxy: gssproxy[659]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure. Minor code may provide more information, No credentials cache found Feb 10 17:30:21 nfsserver rpc.gssd[756]: WARNING: Failed to create machinekrb5 context with any credentialscache for server client2.ipa.local Feb 10 17:30:21 nfsserver rpc.gssd[756]: doing error downcall ### NFS server logs for client 1 (centos 7) : Feb 10 17:34:00 nfsserver rpc.gssd[756]: Closing 'gssd' pipe for /var/lib/nfs/rpc_pipefs/nfsd4_cb/clnt0 Feb 10 17:34:00 nfsserver rpc.gssd[756]: destroying client /var/lib/nfs/rpc_pipefs/nfsd4_cb/clnt0 Feb 10 17:34:00 nfsserver rpc.gssd[756]: handling gssd upcall (/var/lib/nfs/rpc_pipefs/nfsd4_cb/clnt8) Feb 10 17:34:00 nfsserver rpc.gssd[756]: handle_gssd_upcall: 'mech=krb5 uid=0 target=nfs at client1.ipa.local service=nfs enctypes=18,17,16,23,3,1,2 ' Feb 10 17:34:00 nfsserver rpc.gssd[756]: handling krb5 upcall (/var/lib/nfs/rpc_pipefs/nfsd4_cb/clnt8) Feb 10 17:34:00 nfsserver rpc.gssd[756]: process_krb5_upcall: service is 'nfs' Feb 10 17:34:00 nfsserver rpc.gssd[756]: krb5_use_machine_creds: uid 0 tgtname nfs at client1.ipa.local Feb 10 17:34:00 nfsserver rpc.gssd[756]: Full hostname for 'client1.ipa.local' is 'client1.ipa.local' Feb 10 17:34:00 nfsserver rpc.gssd[756]: Full hostname for 'nfsserver.ipa.local' is 'nfsserver.ipa.local' Feb 10 17:34:00 nfsserver rpc.gssd[756]: Success getting keytab entry for 'nfs/nfsserver.ipa.local at IPA.LOCAL' Feb 10 17:34:00 nfsserver rpc.gssd[756]: INFO: Credentials in CC 'FILE:/tmp/krb5ccmachine_IPA.LOCAL' are good until 1455202622 Feb 10 17:34:00 nfsserver rpc.gssd[756]: INFO: Credentials in CC 'FILE:/tmp/krb5ccmachine_IPA.LOCAL' are good until 1455202622 Feb 10 17:34:00 nfsserver rpc.gssd[756]: using FILE:/tmp/krb5ccmachine_IPA.LOCAL as credentials cache for machine creds Feb 10 17:34:00 nfsserver rpc.gssd[756]: using environment variable to select krb5 ccache FILE:/tmp/krb5ccmachine_IPA.LOCAL Feb 10 17:34:00 nfsserver rpc.gssd[756]: creating tcp client for server client1.ipa.local Feb 10 17:34:00 nfsserver rpc.gssd[756]: DEBUG: port already set to 42165 Feb 10 17:34:00 nfsserver rpc.gssd[756]: WARNING: can't create tcp rpc_clnt to server client1.ipa.local for user with uid 0: RPC: Remote system error - No route to host Feb 10 17:34:00 nfsserver rpc.gssd[756]: WARNING: Failed to create machine krb5context with cred cache FILE:/tmp/krb5ccmachine_IPA.LOCAL for server client1.ipa.local Feb 10 17:34:00 nfsserver rpc.gssd[756]: WARNING: Machine cache prematurelyexpired or corrupted trying torecreate cache for server client1.ipa.local Feb 10 17:34:00 nfsserver gssproxy: gssproxy[659]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure. Minor code may provide more information, No credentials cache found Feb 10 17:34:00 nfsserver rpc.gssd[756]: Full hostname for 'client1.ipa.local' is 'client1.ipa.local' Feb 10 17:34:00 nfsserver rpc.gssd[756]: Full hostname for 'nfsserver.ipa.local' is 'nfsserver.ipa.local' Feb 10 17:34:00 nfsserver rpc.gssd[756]: Success getting keytab entry for 'nfs/nfsserver.ipa.local at IPA.LOCAL' Feb 10 17:34:00 nfsserver rpc.gssd[756]: INFO: Credentials in CC 'FILE:/tmp/krb5ccmachine_IPA.LOCAL' are good until 1455202622 Feb 10 17:34:00 nfsserver rpc.gssd[756]: INFO: Credentials in CC 'FILE:/tmp/krb5ccmachine_IPA.LOCAL' are good until 1455202622 Feb 10 17:34:00 nfsserver rpc.gssd[756]: using FILE:/tmp/krb5ccmachine_IPA.LOCAL as credentials cache for machine creds Feb 10 17:34:00 nfsserver rpc.gssd[756]: using environment variable to select krb5 ccache FILE:/tmp/krb5ccmachine_IPA.LOCAL Feb 10 17:34:00 nfsserver rpc.gssd[756]: creating tcp client for server client1.ipa.local Feb 10 17:34:00 nfsserver rpc.gssd[756]: DEBUG: port already set to 42165 Feb 10 17:34:00 nfsserver gssproxy: gssproxy[659]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure. Minor code may provide more information, No credentials cache found Feb 10 17:34:00 nfsserver rpc.gssd[756]: WARNING: can't create tcp rpc_clnt to server client1.ipa.local for user with uid 0: RPC: Remote system error - No route to host Feb 10 17:34:00 nfsserver rpc.gssd[756]: WARNING: Failed to create machine krb5context with cred cache FILE:/tmp/krb5ccmachine_IPA.LOCAL for server client1.ipa.local Feb 10 17:34:00 nfsserver rpc.gssd[756]: WARNING: Failed to create machinekrb5 context with any credentialscache for server client1.ipa.local Feb 10 17:34:00 nfsserver rpc.gssd[756]: doing error downcall So my question is : How can I deal with this display problem? -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at etriptrader.com Wed Feb 10 19:05:44 2016 From: chris at etriptrader.com (Chris Lajoie) Date: Wed, 10 Feb 2016 19:05:44 +0000 Subject: [Freeipa-users] BIND apparently not loading ldap.so Message-ID: <77c8b66eb6614184b9d80045cae4d0c6@etriptrader.com> Hi, I am using the bind-dyndb-ldap package (not full FreeIPA) and I am having a problem where it appears that the plugin is not getting loaded by BIND at all. I have nothing in the logs at all from the plugin. No failures of any kind, just regular named startup. I would have expected BIND to provide a log message saying it is loading an external plugin, or at least some kind of initialization message from the plugin itself, but I see neither. What am I doing wrong here? This is the relevant portion of my named.conf file: logging { channel default_debug { file "/var/log/named/named.log" versions 4 size 5m; severity info; print-time yes; }; }; dynamic-db "ldap" { library "ldap.so"; arg "uri ldap://ldap.ett.local"; arg "base ou=dns,dc=ett,dc=local"; arg "auth_method simple"; arg "bind_dn cn=admin,dc=ett,dc=local"; arg "password secret"; arg "verbose_checks yes"; arg "serial_autoincrement yes"; }; Thanks, Chris From michael.rainey.ctr at nrlssc.navy.mil Wed Feb 10 22:05:20 2016 From: michael.rainey.ctr at nrlssc.navy.mil (Michael Rainey (Contractor)) Date: Wed, 10 Feb 2016 16:05:20 -0600 Subject: [Freeipa-users] smart cards caintaining multiple certificates Message-ID: Greetings, I'm curious as to how IPA handles smart cards containing multiple certificates. When I follow the steps listed at https://fedorahosted.org/sssd/wiki/DesignDocs/SmartcardAuthenticationStep1 when installing my certificate, I notice the certutil command dumps all installed certificates, and dumps the certificates in a different order depending on which certificate is selected. When the server tries to match a certificate does it compare all certificates as one long continuous string, or does it compare one certificate at a time? I'm curious if this presents a problem for the end-user or has this problem been addressed? -- *Michael Rainey* -------------- next part -------------- An HTML attachment was scrubbed... URL: From nik.eb.inc at gmail.com Thu Feb 11 00:16:14 2016 From: nik.eb.inc at gmail.com (Nik Lam) Date: Thu, 11 Feb 2016 11:16:14 +1100 Subject: [Freeipa-users] PKINIT support in FreeIPA 4.2.0 In-Reply-To: <20160210144205.GA12933@p.redhat.com> References: <20160203090821.GD20953@p.redhat.com> <20160208125341.GD13133@p.redhat.com> <20160209160439.GD3682@p.redhat.com> <20160210084317.GE3682@p.redhat.com> <20160210144205.GA12933@p.redhat.com> Message-ID: On Thu, Feb 11, 2016 at 1:42 AM, Sumit Bose wrote: > On Wed, Feb 10, 2016 at 11:07:14PM +1100, Nik Lam wrote: > > On Wed, Feb 10, 2016 at 7:43 PM, Sumit Bose wrote: > > > > > On Wed, Feb 10, 2016 at 12:07:45PM +1100, Nik Lam wrote: > > > > On Wed, Feb 10, 2016 at 3:04 AM, Sumit Bose > wrote: > > > > > > > > > On Wed, Feb 10, 2016 at 02:08:55AM +1100, Nik Lam wrote: > > > > > > On Mon, Feb 8, 2016 at 11:53 PM, Sumit Bose > > > wrote: > > > > > > > > > > > > > On Thu, Feb 04, 2016 at 07:25:29PM +1100, Nik Lam wrote: > > > > > > > > On Wed, Feb 3, 2016 at 8:08 PM, Sumit Bose > > > > wrote: > > > > > > > > > > > > > > > > > On Wed, Feb 03, 2016 at 10:29:49AM +1100, Nik Lam wrote: > > > > > > > > > > Hello, > > > > > > > > > > > > > > > > > > > > I installed ipa-server on Centos 7.1 and later did and > > > upgrade > > > > > of the > > > > > > > > > whole > > > > > > > > > > system to Centos 7.2. > > > > > > > > > > > > > > > > > > > > I think the FreeIPA version changed from 4.1.0 to 4.2.0 > > > between > > > > > these > > > > > > > > > > Centos/RHEL minor releases. > > > > > > > > > > > > > > > > > > > > We'd now like to try integrating with a 2FA provider via > a > > > radius > > > > > > > proxy > > > > > > > > > and > > > > > > > > > > want to use anonymous PKINIT to secure the initial > > > communications > > > > > > > between > > > > > > > > > > the client and the KDC. > > > > > > > > > > > > > > > > > > > > We've tried following the MIT Kerberos PKINIT > configuration > > > > > > > documentation > > > > > > > > > > > > > > > > > > > > > > > http://web.mit.edu/kerberos/krb5-1.14/doc/admin/pkinit.html > > > > > > > > > > > > > > > > > > > > generating our own certs manually with openssl but > haven't > > > had > > > > > any > > > > > > > luck. > > > > > > > > > > We're seeing this in the kdc log: > > > > > > > > > > > > > > > > > > > > preauth pkinit failed to initialize: No realms > configured > > > > > > > correctly > > > > > > > > > for > > > > > > > > > > pkinit support > > > > > > > > > > > > > > > > > > Which changes did you apply to krb5.conf? Did you use the > IPA > > > CA to > > > > > > > sign > > > > > > > > > the certificate or some other CA? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I've noticed there are many new pkinit-related options > that > > > have > > > > > been > > > > > > > > > added > > > > > > > > > > to the ipa-server-install script in 4.2.0, so it looks > like > > > > > PKINIT is > > > > > > > > > > available in this version of FreeIPA. Is that the case? > > > > > > > > > > > > > > > > > > Which options are you referring to? > > > > > > > > > > > > > > > > > > bye, > > > > > > > > > Sumit > > > > > > > > > > > > > > > > > > > > > > > > > > > > > And if it is, what is the recommended way to enable it > given > > > > > that it > > > > > > > > > seems > > > > > > > > > > to have been disabled in the original install that I > did? Or > > > > > would it > > > > > > > > > just > > > > > > > > > > be easier to start from scratch with a 4.2.0 > > > ipa-server-install? > > > > > > > (It's a > > > > > > > > > > test instance that doesn't have too much in it - it will > > > take a > > > > > > > several > > > > > > > > > > hours to rebuild from scratch.) > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > > > Nik > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks Sumit. > > > > > > > > > > > > > > > > It sounds like PKINIT is available but clearly I'm doing it > > > wrong. > > > > > > > > > > > > > > > > > Which changes did you apply to krb5.conf? Did you use the > IPA > > > CA > > > > > to > > > > > > > sign > > > > > > > > the certificate or some other CA? > > > > > > > > > > > > > > > > Actually, I modified the kdc.conf file - placed the kdc.pem, > > > > > kdckey.pem > > > > > > > and > > > > > > > > cacert.pem files in /var/kerberos/krb5kdc/ that I generated > via > > > > > openssl > > > > > > > > commands in the MIT Kerberos documentation. The only change > to > > > > > kdc.conf > > > > > > > > file was to append the location of the kdckey.pem file to > > > > > > > pkinit_identity. > > > > > > > > > > > > > > > > pkinit_identity = FILE:/var/kerberos/krb5kdc/kdc.pem > > > > > > > > pkinit_anchors = FILE:/var/kerberos/krb5kdc/cacert.pem > > > > > > > > > > > > > > > > became > > > > > > > > > > > > > > > > pkinit_identity = > > > > > > > > > > > FILE:/var/kerberos/krb5kdc/kdc.pem,/var/kerberos/krb5kdc/kdckey.pem > > > > > > > > pkinit_anchors = FILE:/var/kerberos/krb5kdc/cacert.pem > > > > > > > > > > > > > > > > Should I have been modifying krb5.conf instead? It aslo > sounds > > > like I > > > > > > > need > > > > > > > > > > > > > > no, kdc.conf is the right place, I actually meant kdc.conf but > > > > > > > accidentially types krb5.conf. > > > > > > > > > > > > > > > to use a certificate signed by the IPAs CA - is this > something > > > that > > > > > > > should > > > > > > > > be generated using ipa-getcert? Or do I just find the IPA > CA's > > > > > private > > > > > > > key > > > > > > > > and use openssl following the MIT Kerberos documentation? > > > > > > > > > > > > > > > > > Which options are you referring to? > > > > > > > > > > > > > > > > When I looked at the --help text for 4.1.0 and 4.2.0 > versions of > > > > > > > > ipa-server-install, I noticed that 4.2.0 has these in the > > > > > "certificate > > > > > > > > system options": > > > > > > > > > > > > > > > > --no-pkinit disables pkinit setup steps > > > > > > > > > > > > > > > > --pkinit-cert-file=FILE > > > > > > > > File containing the Kerberos KDC SSL > > > > > certificate > > > > > > > and > > > > > > > > private key > > > > > > > > > > > > > > > > --pkinit-pin=PIN The password to unlock the Kerberos > KDC > > > > > private > > > > > > > key > > > > > > > > > > > > > > > > --pkinit-cert-name=NAME > > > > > > > > Name of the Kerberos KDC SSL > certificate > > > to > > > > > > > install > > > > > > > > > > > > > > > > > > > > > > > > Seeing that first one, I was a little hopeful that pkinit is > > > enabled > > > > > by > > > > > > > > default in 4.2.0 but on a fresh install I just tried, I'm > still > > > > > seeing > > > > > > > the > > > > > > > > > > > > > > no, unfortunately pkinit is currently disabled by default > > > > > > > > > > > > > > > following in krb5kdc.log when IPA is started up, so clearly > it > > > isn't. > > > > > > > > > > > > > > > > (Error): preauth pkinit failed to initialize: No realms > > > configured > > > > > > > > correctly for pkinit support > > > > > > > > > > > > > > I get the same error when I put the certificate and the key > into > > > > > > > separate files. Can you try to put both into one and use this > for > > > the > > > > > > > pkinit_identity option? > > > > > > > > > > > > > > HTH > > > > > > > > > > > > > > bye, > > > > > > > Sumit > > > > > > > > > > > > > > > > > > > > > > > > > Thanks Sumit, it did! > > > > > > > > > > > > I concatenated the cert and the key into a single file and the > error > > > has > > > > > > indeed gone away from krb5kdc.log > > > > > > > > > > > > The odd thing is that I can't reproduce the error by splitting > into > > > two > > > > > > separate files and restarting ipa.service again. > > > > > > > > > > > > Ignoring that mystery, how do I go about setting up the > > > > > WELLKNOWN/ANONYMOUS > > > > > > principal? > > > > > > > > > > > > I'm pretty sure it's needed for anonymous pkinit: > > > > > > > > > > > > $ kinit > > > > > > kinit: Generic preauthentication failure while getting initial > > > > > credentials > > > > > > $ > > > > > > > > > > > > $ kinit -n > > > > > > kinit: Client 'WELLKNOWN/ANONYMOUS at EXAMPLE.COM' not found in > > > Kerberos > > > > > > database while getting initial credentials > > > > > > $ > > > > > > > > > > > > Using kadmin per the MIT documentation doesn't seem to work > > > > > (authenticated > > > > > > as an IPA admin) > > > > > > > > > > > > # kadmin -q 'addprinc -randkey WELLKNOWN/ANONYMOUS' > > > > > > Authenticating as principal admin/admin at EXAMPLE.COM with > password. > > > > > > kadmin: Client not found in Kerberos database while initializing > > > kadmin > > > > > > interface > > > > > > # > > > > > > > > > > > > # kadmin -q 'addprinc -randkey WELLKNOWN/ANONYMOUS' -p admin > > > > > > Authenticating as principal admin with password. > > > > > > Password for admin at EXAMPLE.COM: > > > > > > WARNING: no policy specified for WELLKNOWN/ANONYMOUS at EXAMPLE.COM > ; > > > > > > defaulting to no policy > > > > > > add_principal: Operation requires ``add'' privilege while > creating > > > > > > "WELLKNOWN/ANONYMOUS at EXAMPLE.COM". > > > > > > # > > > > > > > > > > Please try > > > > > > > > > > kadmin.local -x ipa-setup-override-restrictions > > > > > > > > > > bye, > > > > > Sumit > > > > > > > > > > > > > > Thanks Sumit. > > > > > > > > That seems to have worked to get the principal created. > > > > > > > > # kadmin.local -x ipa-setup-override-restrictions > > > > Authenticating as principal admin/admin at EXAMPLE.COM with password. > > > > kadmin.local: addprinc -randkey WELLKNOWN/ANONYMOUS > > > > WARNING: no policy specified for WELLKNOWN/ANONYMOUS at EXAMPLE.COM; > > > > defaulting to no policy > > > > Principal "WELLKNOWN/ANONYMOUS at EXAMPLE.COM" created. > > > > kadmin.local: quit > > > > # > > > > > > > > I'm no longer seeing the error from the client about 'WELLKNOWN/ > > > > ANONYMOUS at EXAMPLE.COM' not found in Kerberos database. > > > > > > > > However, I'm being prompted for a password for the anonymous > principal. > > > > > > > > $ kinit -n > > > > Password for WELLKNOWN/ANONYMOUS at EXAMPLE.COM: > > > > kinit: Password incorrect while getting initial credentials > > > > $ > > > > > > > > That doesn't sound right to me - and indeed it doesn't provide an > armor > > > > cache that I can use for authenticating my client user. > > > > > > Can you run > > > > > > KRB5_TRACE=/dev/stdout kinit -n > > > > > > this will show the list of preauthentication methods offered to the > > > client and I would suspect that pkinit is not among of them. > > > > > > My guess is that there is something wrong with the certificate or the > > > configuration, e.g. did you try to set pkinit_kdc_hostname to the > > > hostname matching the one in the KDC certificate? Maybe > > > pkinit_eku_checking = none might help as well?. > > > > > > To analyse this further the most easy way is an instrumented build of > > > the pkinit module with debugging enabled. If you can tell me the exact > > > version of your krb5-pkinit package I can prepare a build for you. > > > > > > HTH > > > > > > bye, > > > Sumit > > > > > > > Thank you Sumit. > > > > I've checked that the hostname in the KDC's cert matches what I've put in > > the client's krb.conf's pkinit_hostname. > > > > I've also tried setting pkinit_eku_checking = none in there. > > > > $ KRB5_TRACE=/dev/stdout kinit -n > > [9199] 1455105392.574916: Getting initial credentials for WELLKNOWN/ > > ANONYMOUS at EXAMPLE.COM > > [9199] 1455105392.575132: Sending request (186 bytes) to EXAMPLE.COM > > [9199] 1455105392.575314: Initiating TCP connection to stream > > 10.93.178.73:88 > > [9199] 1455105392.576513: Sending TCP request to stream 10.93.178.73:88 > > [9199] 1455105393.370873: Received answer (483 bytes) from stream > > 10.93.178.73:88 > > [9199] 1455105393.370885: Terminating TCP connection to stream > > 10.93.178.73:88 > > [9199] 1455105393.370956: Response was from master KDC > > [9199] 1455105393.370977: Received error from KDC: -1765328359/Additional > > pre-authentication required > > [9199] 1455105393.371014: Processing preauth types: 16, 15, 14, 136, 19, > > 147, 2, 133 > > ok, 147 means that the server added the needed preauthentication data > for anonymous pkinit. > > Did you set > > pkinit_anchors = FILE:/var/kerberos/krb5kdc/cacert.pem > > in /etc/krb5.conf as well becasue the client must know the CA > certificate as well? > > > [9199] 1455105393.371040: Selected etype info: etype aes256-cts, salt > > "EXAMPLE.COMWELLKNOWNANONYMOUS", params "" > > [9199] 1455105393.371046: Received cookie: MIT > > Password for WELLKNOWN/ANONYMOUS at EXAMPLE.COM: > > [9199] 1455105400.912468: AS key obtained for encrypted timestamp: > > aes256-cts/09BF > > [9199] 1455105400.912546: Encrypted timestamp (for 1455105400.914484): > > plain 301AA011180F32303136303231303131353634305AA10502030DF434, encrypted > > > DD840BC3D6F697529D987E73EDD1C9FF82FEC91A0FB408179E6FA9AF49627912BEF49BA4E4EE8FF469BED5672943592A1E7DFBBF781C1E5B > > [9199] 1455105400.912576: Preauth module encrypted_timestamp (2) (real) > > returned: 0/Success > > [9199] 1455105400.912581: Produced preauth for next request: 133, 2 > > [9199] 1455105400.912601: Sending request (281 bytes) to EXAMPLE.COM > > [9199] 1455105400.912674: Initiating TCP connection to stream > > 10.93.178.73:88 > > [9199] 1455105400.913894: Sending TCP request to stream 10.93.178.73:88 > > [9199] 1455105400.937778: Received answer (197 bytes) from stream > > 10.93.178.73:88 > > [9199] 1455105400.937788: Terminating TCP connection to stream > > 10.93.178.73:88 > > [9199] 1455105400.937835: Response was from master KDC > > [9199] 1455105400.937852: Received error from KDC: -1765328353/Decrypt > > integrity check failed > > kinit: Password incorrect while getting initial credentials > > $ > > > > The module package we're using right now is > > krb5-pkinit-1.13.2-10.el7.x86_64. > > Please find the package with debugging enabled at > > https://kojipkgs.fedoraproject.org//work/tasks/8127/12928127/krb5-pkinit-1.13.2-10.el7sb.x86_64.rpm > > It might be possible to install it with > > rpm -Uhv --nodeps krb5-pkinit-1.13.2-10.el7sb.x86_64.rpm > > to get around yum's dependency checking but after testing > > yum downgrade krb5-pkinit > > should be able to install the original version again. Please do not > forget to revert to the original version, otherwise SSSD's Kerberos > authentication might break because the pkinit module will print the > debug messages just to stdout. > > As an alternative you can just extract > /usr/lib64/krb5/plugins/preauth/pkinit.so with rpm2cpio from the package > and replace the original one. Do not forget to make a copy of the > original module in a different directory to be able to revert the > change. > > HTH > > bye, > Sumit > Thanks so much Sumit. I've upgraded that package on both the IdM server and the (problem) client. I haven't looked *really* closely at the logs or the trace output, but it doesn't look like I'm getting any additional output. However, on a whim, went to another client. This time I went to check what version of krb5-pkinit was installed, and discovered it wasn't installed along with the rest of the ipa-client package dependencies. I installed the GA version of krb5-pkinit and it all just works! [testuser at client01-756712 ~]$ kinit -n [testuser at client01-756712 ~]$ [testuser at client01-756712 ~]$ [testuser at client01-756712 ~]$ klist Ticket cache: FILE:/tmp/krb5cc_842000006 Default principal: WELLKNOWN/ANONYMOUS at WELLKNOWN:ANONYMOUS Valid starting Expires Service principal 02/10/2016 23:28:46 02/11/2016 23:28:46 krbtgt/EXAMPLE.COM at EXAMPLE.COM [testuser at client01-756712 ~]$ [testuser at client01-756712 ~]$ [testuser at client01-756712 ~]$ kinit -T /tmp/krb5cc_842000006 testuser Enter OTP Token Value: [testuser at client01-756712 ~]$ [testuser at client01-756712 ~]$ [testuser at client01-756712 ~]$ klist Ticket cache: FILE:/tmp/krb5cc_842000006 Default principal: testuser at EXAMPLE.COM Valid starting Expires Service principal 02/10/2016 23:29:14 02/11/2016 23:29:07 krbtgt/EXAMPLE.COM at EXAMPLE.COM [testuser at client01-756712 ~]$ So it looks like the absence of the krb5-pkinit package was the reason why kinit was prompting for the WELLKNOWN/ANONYMOUS password. To confirm, all that is needed on the client's krb5.conf file is to have pkinit_anchors pointing to a copy of the belonging to the CA that was used to create the KDC's cert (which in our case was a self-generated one not freeIPA/Dogtag's one). So, I think we've got everything we need to start using it. Thanks again for your help. With respect to the future plans - is there anything we need to beware of in terms of our manual creation of the WELLKNOWN/ANONYMOUS principal via "kadmin.local -x ipa-setup-override-restrictions"? Is freeIPA likely to have a fully-integrated anonymous PKINIT solution in the near future? You people have done such a great job of making the rest of this stuff easy and well-documented. Hats off to the developers (and Red Hat for sponsoring the project). Cheers, Nik -------------- next part -------------- An HTML attachment was scrubbed... URL: From ftweedal at redhat.com Thu Feb 11 00:34:08 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 11 Feb 2016 10:34:08 +1000 Subject: [Freeipa-users] nss unrecognized name alert with SAN name In-Reply-To: References: <56B673CD.1080507@redhat.com> Message-ID: <20160211003408.GL12524@dhcp-40-8.bne.redhat.com> On Sun, Feb 07, 2016 at 12:05:19PM +0100, John Obaterspok wrote: > 2016-02-06 23:29 GMT+01:00 Rob Crittenden : > > > John Obaterspok wrote: > > > >> Hi, > >> > >> I have a ipa.my.lan and a cname gitserver.my.lan pointing to ipa.my.lan > >> > >> I recently started to get nss error "SSL peer has no certificate for the > >> requested DNS name." when I'm accesing my https://gitserver.my.lan > >> > >> Previously this worked fine if I had set "git config --global > >> http.sslVerify false" according to > >> https://www.redhat.com/archives/freeipa-users/2015-November/msg00213.html > >> > >> Now I tried to solve this by adding a SubjectAltName to the > >> HTTP/ipa.my.lan certitficate like this: > >> > >> status: MONITORING > >> stuck: no > >> key pair storage: > >> type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > >> Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > >> certificate: > >> type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > >> Certificate DB' > >> CA: IPA > >> issuer: CN=Certificate Authority,O=MY.LAN > >> subject: CN=ipa.my.lan,O=MY.LAN > >> expires: 2018-02-06 19:24:52 UTC > >> dns: gitserver.my.lan,ipa.my.lan > >> principal name: http/ipa.my.lan at MY.LAN > >> key usage: > >> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > >> eku: id-kp-serverAuth,id-kp-clientAuth > >> pre-save command: > >> post-save command: /usr/lib64/ipa/certmonger/restart_httpd > >> track: yes > >> auto-renew: yes > >> > >> But I still get the below error: > >> > >> * NSS error -12182 (SSL_ERROR_UNRECOGNIZED_NAME_ALERT) > >> * SSL peer has no certificate for the requested DNS name > >> > > > > What version of mod_nss? It recently added support for SNI. You can try > > turning it off by adding NSSSNI off to /etc/httpd/conf.d/nss.conf but I'd > > imagine you were already relying on it. > > > > > Hi, > > Turning it off didn't help > > I'm on F23 with latest updates so I have mod_nss-1.0.12-1 > I noticed it worked if I set "ServerName gitserver.my.lan" in > gitserver.conf, but then I got the NAME ALERT when accessing ipa.my.lan. > > I then tried to put ipa.conf in but then I got error > about SSL_ERROR_RX_RECORD_TOO_LONG > > gitserver.conf has this: > > > DocumentRoot /opt/wwwgit > SetEnv GIT_PROJECT_ROOT /opt/wwwgit > SetEnv GIT_HTTP_EXPORT_ALL > SetEnv REMOTE_USER $REDIRECT_REMOTE_USER > ScriptAlias /git/ /usr/libexec/git-core/git-http-backend/ > > ServerName gitserver.my.lan > > > Options Indexes > AllowOverride None > Require all granted > > > > Options Indexes > AllowOverride None > Require all granted > > > > #SSLRequireSSL > AuthType Kerberos > AuthName "Kerberos Login" > KrbAuthRealm WIN.LAN > Krb5KeyTab /etc/httpd/conf/ipa.keytab > KrbMethodNegotiate on > KrbMethodK5Passwd off # Set to on to query for pwd if negotiation > failed due to no ticket available > KrbSaveCredentials on > KrbVerifyKDC on > KrbServiceName HTTP/ipa.my.lan at MY.LAN > > AuthLDAPUrl ldaps://ipa.my.lan/dc=my,dc=lan?krbPrincipalName > AuthLDAPBindDN "uid=httpbind,cn=sysaccounts,cn=etc,dc=my,dc=lan" > AuthLDAPBindPassword "secret123abc" > Require ldap-group cn=ipausers,cn=groups,cn=accounts,dc=my,dc=lan > > > > > > Any more ideas what I do wrong? It was suggested that this may be due to the certificate not being compliant with RFC 2818. This is likely true, but I think it is not likely to be the problem. You can use `openssl s_client` to confirm what certificate the server is sending: openssl s_client -showcerts \ -servername gitserver.my.lan -connect gitserver.my.lan:443 This will dump the certificates (in PEM format), which you can copy to a file examine with `opeenssl x509 -text < cert.pem`. Feel free to reply with the output; I am happy to have a closer look. Cheers, Fraser From tgeier at accertify.com Thu Feb 11 05:06:30 2016 From: tgeier at accertify.com (Timothy Geier) Date: Thu, 11 Feb 2016 05:06:30 +0000 Subject: [Freeipa-users] IPA 4.2: pki-tomcatd in terrible shape In-Reply-To: <56BAFC6E.6030605@redhat.com> References: <56B86DE0.4070909@redhat.com> <7F0EB8FC-8F2F-49D1-A124-562B5B0A55A2@accertify.com> <56B9AA53.1000400@redhat.com> <56BAFC6E.6030605@redhat.com> Message-ID: On Feb 10, 2016, at 3:01 AM, Rob Crittenden > wrote: [09/Feb/2016:12:55:41 -0600] conn=109598 fd=287 slot=287 SSL connection from master_ip to master_ip [09/Feb/2016:12:55:41 -0600] conn=109597 op=0 EXT oid="1.3.6.1.4.1.1466.20037" name="startTLS" [09/Feb/2016:12:55:41 -0600] conn=109597 op=0 RESULT err=0 tag=120 nentries=0 etime=0 [09/Feb/2016:12:55:41 -0600] conn=109598 Netscape Portable Runtime error -8181 (Peer's Certificate has expired.); unauthenticated client CN=CA Subsystem,O=XXXXXXX.NET; issuer CN=Certificate Authority,O=XXXXXXX.NET [09/Feb/2016:12:55:41 -0600] conn=109598 op=-1 fd=287 closed - Peer's Certificate has expired. Ok, right. The subsystem cert expired on Feb 1 so you'd have to back at least that far in time to do the renewals. There are a few entries in ou=People,o=ipaca that need to reflect the current state of certificates as well. Ah, right, just realized that that?s a base that can looked up separately in LDAP..is there anything in particular to look for in there? All of the host keytabs on all of the IPA servers are correct..are there any other keytabs to check? No, just /etc/krb5.keytab. I think you should focus on getting the CA subsystem certs renewed and then we can look at the other things. So I'd go back in time to Jan 30 or so and just restart certmonger. After doing so, certmonger appears to run smoothly and goes from SUBMITTING to MONITORING but the expiration date on all of the certs stays the same. (It?s the same result if ipa-getcert resubmit is run against all of the request IDs..quite perplexing) If we do a total shutdown/rewind/restart, getcert list produces the following for these 3 certs during the time shift after the restart: Request ID '20160209194022': status: CA_UNREACHABLE ca-error: Internal error stuck: no key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB',pin set certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-ca-renew-agent issuer: CN=Certificate Authority,O=XXXXXXX.NET subject: CN=CA Audit,O=XXXXXXX.NET expires: 2016-02-01 19:46:48 UTC key usage: digitalSignature,nonRepudiation pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert "auditSigningCert cert-pki-ca" track: yes auto-renew: yes Request ID '20160209194023': status: CA_UNREACHABLE ca-error: Internal error stuck: no key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB',pin set certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-ca-renew-agent issuer: CN=Certificate Authority,O=XXXXXXX.NET subject: CN=OCSP Subsystem,O=XXXXXXX.NET expires: 2016-02-01 19:46:47 UTC key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign eku: id-kp-OCSPSigning pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert "ocspSigningCert cert-pki-ca" track: yes auto-renew: yes Request ID '20160209194024': status: CA_UNREACHABLE ca-error: Internal error stuck: no key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB',pin set certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-ca-renew-agent issuer: CN=Certificate Authority,O=XXXXXXX.NET subject: CN=CA Subsystem,O=XXXXXXX.NET expires: 2016-02-01 19:46:47 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment 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 The most puzzling thing (in my opinion) about this issue is that timeshifting doesn?t seem to make any difference at all; pki-tomcatd still doesn?t start cleanly (the log entries are very similar) even though in theory those certs are no longer expired at that point..it seems as if something else is also the issue. Your ongoing assistance with this matter is much appreciated. rob "This message and any attachments may contain confidential information. If you have received this message in error, any use or distribution is prohibited. Please notify us by reply e-mail if you have mistakenly received this message, and immediately and permanently delete it and any attachments. Thank you." -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Thu Feb 11 08:21:37 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 11 Feb 2016 10:21:37 +0200 Subject: [Freeipa-users] ID Views without AD In-Reply-To: References: <20160210081945.GR12787@redhat.com> Message-ID: <20160211082137.GA28898@redhat.com> On Wed, 10 Feb 2016, Mike Kelly wrote: >On Wed, Feb 10, 2016 at 3:19 AM Alexander Bokovoy >wrote: > >> On Wed, 10 Feb 2016, Mike Kelly wrote: >> >> >Is there some extra logging I can turn on to see why this ID View isn't >> >being applied like I would expect? Or perhaps some extra bit of >> >configuration I missed? >> Level 7 or 9 debug logs in SSSD on the client might help. >> > >Thanks. > >Here's what looks like the relevant bits in /var/log/sssd/sssd_nss.log, >after I ran `sss_cache -E ; id pioto`: Please provide content of sssd_.log, this is where the actual work is done when user information is obtained and processed. sssd_nss.log is merely a requestor. -- / Alexander Bokovoy From sbose at redhat.com Thu Feb 11 08:28:52 2016 From: sbose at redhat.com (Sumit Bose) Date: Thu, 11 Feb 2016 09:28:52 +0100 Subject: [Freeipa-users] PKINIT support in FreeIPA 4.2.0 In-Reply-To: References: <20160203090821.GD20953@p.redhat.com> <20160208125341.GD13133@p.redhat.com> <20160209160439.GD3682@p.redhat.com> <20160210084317.GE3682@p.redhat.com> <20160210144205.GA12933@p.redhat.com> Message-ID: <20160211082852.GE12933@p.redhat.com> On Thu, Feb 11, 2016 at 11:16:14AM +1100, Nik Lam wrote: > On Thu, Feb 11, 2016 at 1:42 AM, Sumit Bose wrote: > > > On Wed, Feb 10, 2016 at 11:07:14PM +1100, Nik Lam wrote: > > > On Wed, Feb 10, 2016 at 7:43 PM, Sumit Bose wrote: > > > > > > > On Wed, Feb 10, 2016 at 12:07:45PM +1100, Nik Lam wrote: > > > > > On Wed, Feb 10, 2016 at 3:04 AM, Sumit Bose > > wrote: > > > > > > > > > > > On Wed, Feb 10, 2016 at 02:08:55AM +1100, Nik Lam wrote: > > > > > > > On Mon, Feb 8, 2016 at 11:53 PM, Sumit Bose > > > > wrote: > > > > > > > > > > > > > > > On Thu, Feb 04, 2016 at 07:25:29PM +1100, Nik Lam wrote: > > > > > > > > > On Wed, Feb 3, 2016 at 8:08 PM, Sumit Bose > > > > > > wrote: > > > > > > > > > > > > > > > > > > > On Wed, Feb 03, 2016 at 10:29:49AM +1100, Nik Lam wrote: > > > > > > > > > > > Hello, > > > > > > > > > > > > > > > > > > > > > > I installed ipa-server on Centos 7.1 and later did and > > > > upgrade > > > > > > of the > > > > > > > > > > whole > > > > > > > > > > > system to Centos 7.2. > > > > > > > > > > > > > > > > > > > > > > I think the FreeIPA version changed from 4.1.0 to 4.2.0 > > > > between > > > > > > these > > > > > > > > > > > Centos/RHEL minor releases. > > > > > > > > > > > > > > > > > > > > > > We'd now like to try integrating with a 2FA provider via > > a > > > > radius > > > > > > > > proxy > > > > > > > > > > and > > > > > > > > > > > want to use anonymous PKINIT to secure the initial > > > > communications > > > > > > > > between > > > > > > > > > > > the client and the KDC. > > > > > > > > > > > > > > > > > > > > > > We've tried following the MIT Kerberos PKINIT > > configuration > > > > > > > > documentation > > > > > > > > > > > > > > > > > > > > > > > > > > http://web.mit.edu/kerberos/krb5-1.14/doc/admin/pkinit.html > > > > > > > > > > > > > > > > > > > > > > generating our own certs manually with openssl but > > haven't > > > > had > > > > > > any > > > > > > > > luck. > > > > > > > > > > > We're seeing this in the kdc log: > > > > > > > > > > > > > > > > > > > > > > preauth pkinit failed to initialize: No realms > > configured > > > > > > > > correctly > > > > > > > > > > for > > > > > > > > > > > pkinit support > > > > > > > > > > > > > > > > > > > > Which changes did you apply to krb5.conf? Did you use the > > IPA > > > > CA to > > > > > > > > sign > > > > > > > > > > the certificate or some other CA? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I've noticed there are many new pkinit-related options > > that > > > > have > > > > > > been > > > > > > > > > > added > > > > > > > > > > > to the ipa-server-install script in 4.2.0, so it looks > > like > > > > > > PKINIT is > > > > > > > > > > > available in this version of FreeIPA. Is that the case? > > > > > > > > > > > > > > > > > > > > Which options are you referring to? > > > > > > > > > > > > > > > > > > > > bye, > > > > > > > > > > Sumit > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > And if it is, what is the recommended way to enable it > > given > > > > > > that it > > > > > > > > > > seems > > > > > > > > > > > to have been disabled in the original install that I > > did? Or > > > > > > would it > > > > > > > > > > just > > > > > > > > > > > be easier to start from scratch with a 4.2.0 > > > > ipa-server-install? > > > > > > > > (It's a > > > > > > > > > > > test instance that doesn't have too much in it - it will > > > > take a > > > > > > > > several > > > > > > > > > > > hours to rebuild from scratch.) > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > > > > > Nik > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks Sumit. > > > > > > > > > > > > > > > > > > It sounds like PKINIT is available but clearly I'm doing it > > > > wrong. > > > > > > > > > > > > > > > > > > > Which changes did you apply to krb5.conf? Did you use the > > IPA > > > > CA > > > > > > to > > > > > > > > sign > > > > > > > > > the certificate or some other CA? > > > > > > > > > > > > > > > > > > Actually, I modified the kdc.conf file - placed the kdc.pem, > > > > > > kdckey.pem > > > > > > > > and > > > > > > > > > cacert.pem files in /var/kerberos/krb5kdc/ that I generated > > via > > > > > > openssl > > > > > > > > > commands in the MIT Kerberos documentation. The only change > > to > > > > > > kdc.conf > > > > > > > > > file was to append the location of the kdckey.pem file to > > > > > > > > pkinit_identity. > > > > > > > > > > > > > > > > > > pkinit_identity = FILE:/var/kerberos/krb5kdc/kdc.pem > > > > > > > > > pkinit_anchors = FILE:/var/kerberos/krb5kdc/cacert.pem > > > > > > > > > > > > > > > > > > became > > > > > > > > > > > > > > > > > > pkinit_identity = > > > > > > > > > > > > > FILE:/var/kerberos/krb5kdc/kdc.pem,/var/kerberos/krb5kdc/kdckey.pem > > > > > > > > > pkinit_anchors = FILE:/var/kerberos/krb5kdc/cacert.pem > > > > > > > > > > > > > > > > > > Should I have been modifying krb5.conf instead? It aslo > > sounds > > > > like I > > > > > > > > need > > > > > > > > > > > > > > > > no, kdc.conf is the right place, I actually meant kdc.conf but > > > > > > > > accidentially types krb5.conf. > > > > > > > > > > > > > > > > > to use a certificate signed by the IPAs CA - is this > > something > > > > that > > > > > > > > should > > > > > > > > > be generated using ipa-getcert? Or do I just find the IPA > > CA's > > > > > > private > > > > > > > > key > > > > > > > > > and use openssl following the MIT Kerberos documentation? > > > > > > > > > > > > > > > > > > > Which options are you referring to? > > > > > > > > > > > > > > > > > > When I looked at the --help text for 4.1.0 and 4.2.0 > > versions of > > > > > > > > > ipa-server-install, I noticed that 4.2.0 has these in the > > > > > > "certificate > > > > > > > > > system options": > > > > > > > > > > > > > > > > > > --no-pkinit disables pkinit setup steps > > > > > > > > > > > > > > > > > > --pkinit-cert-file=FILE > > > > > > > > > File containing the Kerberos KDC SSL > > > > > > certificate > > > > > > > > and > > > > > > > > > private key > > > > > > > > > > > > > > > > > > --pkinit-pin=PIN The password to unlock the Kerberos > > KDC > > > > > > private > > > > > > > > key > > > > > > > > > > > > > > > > > > --pkinit-cert-name=NAME > > > > > > > > > Name of the Kerberos KDC SSL > > certificate > > > > to > > > > > > > > install > > > > > > > > > > > > > > > > > > > > > > > > > > > Seeing that first one, I was a little hopeful that pkinit is > > > > enabled > > > > > > by > > > > > > > > > default in 4.2.0 but on a fresh install I just tried, I'm > > still > > > > > > seeing > > > > > > > > the > > > > > > > > > > > > > > > > no, unfortunately pkinit is currently disabled by default > > > > > > > > > > > > > > > > > following in krb5kdc.log when IPA is started up, so clearly > > it > > > > isn't. > > > > > > > > > > > > > > > > > > (Error): preauth pkinit failed to initialize: No realms > > > > configured > > > > > > > > > correctly for pkinit support > > > > > > > > > > > > > > > > I get the same error when I put the certificate and the key > > into > > > > > > > > separate files. Can you try to put both into one and use this > > for > > > > the > > > > > > > > pkinit_identity option? > > > > > > > > > > > > > > > > HTH > > > > > > > > > > > > > > > > bye, > > > > > > > > Sumit > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks Sumit, it did! > > > > > > > > > > > > > > I concatenated the cert and the key into a single file and the > > error > > > > has > > > > > > > indeed gone away from krb5kdc.log > > > > > > > > > > > > > > The odd thing is that I can't reproduce the error by splitting > > into > > > > two > > > > > > > separate files and restarting ipa.service again. > > > > > > > > > > > > > > Ignoring that mystery, how do I go about setting up the > > > > > > WELLKNOWN/ANONYMOUS > > > > > > > principal? > > > > > > > > > > > > > > I'm pretty sure it's needed for anonymous pkinit: > > > > > > > > > > > > > > $ kinit > > > > > > > kinit: Generic preauthentication failure while getting initial > > > > > > credentials > > > > > > > $ > > > > > > > > > > > > > > $ kinit -n > > > > > > > kinit: Client 'WELLKNOWN/ANONYMOUS at EXAMPLE.COM' not found in > > > > Kerberos > > > > > > > database while getting initial credentials > > > > > > > $ > > > > > > > > > > > > > > Using kadmin per the MIT documentation doesn't seem to work > > > > > > (authenticated > > > > > > > as an IPA admin) > > > > > > > > > > > > > > # kadmin -q 'addprinc -randkey WELLKNOWN/ANONYMOUS' > > > > > > > Authenticating as principal admin/admin at EXAMPLE.COM with > > password. > > > > > > > kadmin: Client not found in Kerberos database while initializing > > > > kadmin > > > > > > > interface > > > > > > > # > > > > > > > > > > > > > > # kadmin -q 'addprinc -randkey WELLKNOWN/ANONYMOUS' -p admin > > > > > > > Authenticating as principal admin with password. > > > > > > > Password for admin at EXAMPLE.COM: > > > > > > > WARNING: no policy specified for WELLKNOWN/ANONYMOUS at EXAMPLE.COM > > ; > > > > > > > defaulting to no policy > > > > > > > add_principal: Operation requires ``add'' privilege while > > creating > > > > > > > "WELLKNOWN/ANONYMOUS at EXAMPLE.COM". > > > > > > > # > > > > > > > > > > > > Please try > > > > > > > > > > > > kadmin.local -x ipa-setup-override-restrictions > > > > > > > > > > > > bye, > > > > > > Sumit > > > > > > > > > > > > > > > > > Thanks Sumit. > > > > > > > > > > That seems to have worked to get the principal created. > > > > > > > > > > # kadmin.local -x ipa-setup-override-restrictions > > > > > Authenticating as principal admin/admin at EXAMPLE.COM with password. > > > > > kadmin.local: addprinc -randkey WELLKNOWN/ANONYMOUS > > > > > WARNING: no policy specified for WELLKNOWN/ANONYMOUS at EXAMPLE.COM; > > > > > defaulting to no policy > > > > > Principal "WELLKNOWN/ANONYMOUS at EXAMPLE.COM" created. > > > > > kadmin.local: quit > > > > > # > > > > > > > > > > I'm no longer seeing the error from the client about 'WELLKNOWN/ > > > > > ANONYMOUS at EXAMPLE.COM' not found in Kerberos database. > > > > > > > > > > However, I'm being prompted for a password for the anonymous > > principal. > > > > > > > > > > $ kinit -n > > > > > Password for WELLKNOWN/ANONYMOUS at EXAMPLE.COM: > > > > > kinit: Password incorrect while getting initial credentials > > > > > $ > > > > > > > > > > That doesn't sound right to me - and indeed it doesn't provide an > > armor > > > > > cache that I can use for authenticating my client user. > > > > > > > > Can you run > > > > > > > > KRB5_TRACE=/dev/stdout kinit -n > > > > > > > > this will show the list of preauthentication methods offered to the > > > > client and I would suspect that pkinit is not among of them. > > > > > > > > My guess is that there is something wrong with the certificate or the > > > > configuration, e.g. did you try to set pkinit_kdc_hostname to the > > > > hostname matching the one in the KDC certificate? Maybe > > > > pkinit_eku_checking = none might help as well?. > > > > > > > > To analyse this further the most easy way is an instrumented build of > > > > the pkinit module with debugging enabled. If you can tell me the exact > > > > version of your krb5-pkinit package I can prepare a build for you. > > > > > > > > HTH > > > > > > > > bye, > > > > Sumit > > > > > > > > > > Thank you Sumit. > > > > > > I've checked that the hostname in the KDC's cert matches what I've put in > > > the client's krb.conf's pkinit_hostname. > > > > > > I've also tried setting pkinit_eku_checking = none in there. > > > > > > $ KRB5_TRACE=/dev/stdout kinit -n > > > [9199] 1455105392.574916: Getting initial credentials for WELLKNOWN/ > > > ANONYMOUS at EXAMPLE.COM > > > [9199] 1455105392.575132: Sending request (186 bytes) to EXAMPLE.COM > > > [9199] 1455105392.575314: Initiating TCP connection to stream > > > 10.93.178.73:88 > > > [9199] 1455105392.576513: Sending TCP request to stream 10.93.178.73:88 > > > [9199] 1455105393.370873: Received answer (483 bytes) from stream > > > 10.93.178.73:88 > > > [9199] 1455105393.370885: Terminating TCP connection to stream > > > 10.93.178.73:88 > > > [9199] 1455105393.370956: Response was from master KDC > > > [9199] 1455105393.370977: Received error from KDC: -1765328359/Additional > > > pre-authentication required > > > [9199] 1455105393.371014: Processing preauth types: 16, 15, 14, 136, 19, > > > 147, 2, 133 > > > > ok, 147 means that the server added the needed preauthentication data > > for anonymous pkinit. > > > > Did you set > > > > pkinit_anchors = FILE:/var/kerberos/krb5kdc/cacert.pem > > > > in /etc/krb5.conf as well becasue the client must know the CA > > certificate as well? > > > > > [9199] 1455105393.371040: Selected etype info: etype aes256-cts, salt > > > "EXAMPLE.COMWELLKNOWNANONYMOUS", params "" > > > [9199] 1455105393.371046: Received cookie: MIT > > > Password for WELLKNOWN/ANONYMOUS at EXAMPLE.COM: > > > [9199] 1455105400.912468: AS key obtained for encrypted timestamp: > > > aes256-cts/09BF > > > [9199] 1455105400.912546: Encrypted timestamp (for 1455105400.914484): > > > plain 301AA011180F32303136303231303131353634305AA10502030DF434, encrypted > > > > > DD840BC3D6F697529D987E73EDD1C9FF82FEC91A0FB408179E6FA9AF49627912BEF49BA4E4EE8FF469BED5672943592A1E7DFBBF781C1E5B > > > [9199] 1455105400.912576: Preauth module encrypted_timestamp (2) (real) > > > returned: 0/Success > > > [9199] 1455105400.912581: Produced preauth for next request: 133, 2 > > > [9199] 1455105400.912601: Sending request (281 bytes) to EXAMPLE.COM > > > [9199] 1455105400.912674: Initiating TCP connection to stream > > > 10.93.178.73:88 > > > [9199] 1455105400.913894: Sending TCP request to stream 10.93.178.73:88 > > > [9199] 1455105400.937778: Received answer (197 bytes) from stream > > > 10.93.178.73:88 > > > [9199] 1455105400.937788: Terminating TCP connection to stream > > > 10.93.178.73:88 > > > [9199] 1455105400.937835: Response was from master KDC > > > [9199] 1455105400.937852: Received error from KDC: -1765328353/Decrypt > > > integrity check failed > > > kinit: Password incorrect while getting initial credentials > > > $ > > > > > > The module package we're using right now is > > > krb5-pkinit-1.13.2-10.el7.x86_64. > > > > Please find the package with debugging enabled at > > > > https://kojipkgs.fedoraproject.org//work/tasks/8127/12928127/krb5-pkinit-1.13.2-10.el7sb.x86_64.rpm > > > > It might be possible to install it with > > > > rpm -Uhv --nodeps krb5-pkinit-1.13.2-10.el7sb.x86_64.rpm > > > > to get around yum's dependency checking but after testing > > > > yum downgrade krb5-pkinit > > > > should be able to install the original version again. Please do not > > forget to revert to the original version, otherwise SSSD's Kerberos > > authentication might break because the pkinit module will print the > > debug messages just to stdout. > > > > As an alternative you can just extract > > /usr/lib64/krb5/plugins/preauth/pkinit.so with rpm2cpio from the package > > and replace the original one. Do not forget to make a copy of the > > original module in a different directory to be able to revert the > > change. > > > > HTH > > > > bye, > > Sumit > > > > Thanks so much Sumit. > > I've upgraded that package on both the IdM server and the (problem) client. > > I haven't looked *really* closely at the logs or the trace output, but it > doesn't look like I'm getting any additional output. ok, please do not forget to replace the debug packages which the original version. > > However, on a whim, went to another client. This time I went to check what > version of krb5-pkinit was installed, and discovered it wasn't installed > along with the rest of the ipa-client package dependencies. > > I installed the GA version of krb5-pkinit and it all just works! > > [testuser at client01-756712 ~]$ kinit -n > [testuser at client01-756712 ~]$ > [testuser at client01-756712 ~]$ > [testuser at client01-756712 ~]$ klist > Ticket cache: FILE:/tmp/krb5cc_842000006 > Default principal: WELLKNOWN/ANONYMOUS at WELLKNOWN:ANONYMOUS > > Valid starting Expires Service principal > 02/10/2016 23:28:46 02/11/2016 23:28:46 krbtgt/EXAMPLE.COM at EXAMPLE.COM > [testuser at client01-756712 ~]$ > [testuser at client01-756712 ~]$ > [testuser at client01-756712 ~]$ kinit -T /tmp/krb5cc_842000006 testuser > Enter OTP Token Value: > [testuser at client01-756712 ~]$ > [testuser at client01-756712 ~]$ > [testuser at client01-756712 ~]$ klist > Ticket cache: FILE:/tmp/krb5cc_842000006 > Default principal: testuser at EXAMPLE.COM > > Valid starting Expires Service principal > 02/10/2016 23:29:14 02/11/2016 23:29:07 krbtgt/EXAMPLE.COM at EXAMPLE.COM > [testuser at client01-756712 ~]$ > > So it looks like the absence of the krb5-pkinit package was the reason why > kinit was prompting for the WELLKNOWN/ANONYMOUS password. that makes sense > > To confirm, all that is needed on the client's krb5.conf file is to have > pkinit_anchors pointing to a copy of the belonging to the CA that was used > to create the KDC's cert (which in our case was a self-generated one not > freeIPA/Dogtag's one). > > So, I think we've got everything we need to start using it. Thanks again > for your help. you're welcome, glad I could help. > > With respect to the future plans - is there anything we need to beware of > in terms of our manual creation of the WELLKNOWN/ANONYMOUS principal via > "kadmin.local -x ipa-setup-override-restrictions"? > Is freeIPA likely to have a fully-integrated anonymous PKINIT solution in > the near future? You people have done such a great job of making the rest yes, anonymous PKINIT somewhat felt between the cracks after some changes to the FreeIPA CA some time ago. All the code is still there, we just need to make sure we have a proper certificate for the KDC. > of this stuff easy and well-documented. Hats off to the developers (and Red > Hat for sponsoring the project). Thank you. bye, Sumit > > Cheers, > > Nik From jhrozek at redhat.com Thu Feb 11 08:35:27 2016 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 11 Feb 2016 09:35:27 +0100 Subject: [Freeipa-users] ID Views without AD In-Reply-To: <20160211082137.GA28898@redhat.com> References: <20160210081945.GR12787@redhat.com> <20160211082137.GA28898@redhat.com> Message-ID: <20160211083527.GH29883@hendrix.redhat.com> On Thu, Feb 11, 2016 at 10:21:37AM +0200, Alexander Bokovoy wrote: > On Wed, 10 Feb 2016, Mike Kelly wrote: > >On Wed, Feb 10, 2016 at 3:19 AM Alexander Bokovoy > >wrote: > > > >>On Wed, 10 Feb 2016, Mike Kelly wrote: > >> > >>>Is there some extra logging I can turn on to see why this ID View isn't > >>>being applied like I would expect? Or perhaps some extra bit of > >>>configuration I missed? > >>Level 7 or 9 debug logs in SSSD on the client might help. > >> > > > >Thanks. > > > >Here's what looks like the relevant bits in /var/log/sssd/sssd_nss.log, > >after I ran `sss_cache -E ; id pioto`: > Please provide content of sssd_.log, this is where the actual > work is done when user information is obtained and processed. > sssd_nss.log is merely a requestor. This wiki page might be helpful: https://fedorahosted.org/sssd/wiki/Troubleshooting From abokovoy at redhat.com Thu Feb 11 08:42:19 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 11 Feb 2016 10:42:19 +0200 Subject: [Freeipa-users] PKINIT support in FreeIPA 4.2.0 In-Reply-To: References: <20160203090821.GD20953@p.redhat.com> <20160208125341.GD13133@p.redhat.com> <20160209160439.GD3682@p.redhat.com> <20160210084317.GE3682@p.redhat.com> <20160210144205.GA12933@p.redhat.com> Message-ID: <20160211084219.GB28898@redhat.com> On Thu, 11 Feb 2016, Nik Lam wrote: >I've upgraded that package on both the IdM server and the (problem) client. > >I haven't looked *really* closely at the logs or the trace output, but it >doesn't look like I'm getting any additional output. > >However, on a whim, went to another client. This time I went to check what >version of krb5-pkinit was installed, and discovered it wasn't installed >along with the rest of the ipa-client package dependencies. > >I installed the GA version of krb5-pkinit and it all just works! > >[testuser at client01-756712 ~]$ kinit -n >[testuser at client01-756712 ~]$ >[testuser at client01-756712 ~]$ >[testuser at client01-756712 ~]$ klist >Ticket cache: FILE:/tmp/krb5cc_842000006 >Default principal: WELLKNOWN/ANONYMOUS at WELLKNOWN:ANONYMOUS > >Valid starting Expires Service principal >02/10/2016 23:28:46 02/11/2016 23:28:46 krbtgt/EXAMPLE.COM at EXAMPLE.COM >[testuser at client01-756712 ~]$ >[testuser at client01-756712 ~]$ >[testuser at client01-756712 ~]$ kinit -T /tmp/krb5cc_842000006 testuser >Enter OTP Token Value: >[testuser at client01-756712 ~]$ >[testuser at client01-756712 ~]$ >[testuser at client01-756712 ~]$ klist >Ticket cache: FILE:/tmp/krb5cc_842000006 >Default principal: testuser at EXAMPLE.COM > >Valid starting Expires Service principal >02/10/2016 23:29:14 02/11/2016 23:29:07 krbtgt/EXAMPLE.COM at EXAMPLE.COM >[testuser at client01-756712 ~]$ > >So it looks like the absence of the krb5-pkinit package was the reason why >kinit was prompting for the WELLKNOWN/ANONYMOUS password. > >To confirm, all that is needed on the client's krb5.conf file is to have >pkinit_anchors pointing to a copy of the belonging to the CA that was used >to create the KDC's cert (which in our case was a self-generated one not >freeIPA/Dogtag's one). > >So, I think we've got everything we need to start using it. Thanks again >for your help. > >With respect to the future plans - is there anything we need to beware of >in terms of our manual creation of the WELLKNOWN/ANONYMOUS principal via >"kadmin.local -x ipa-setup-override-restrictions"? >Is freeIPA likely to have a fully-integrated anonymous PKINIT solution in >the near future? You people have done such a great job of making the rest >of this stuff easy and well-documented. Hats off to the developers (and Red >Hat for sponsoring the project). Creating the principal will change, for sure -- we'll most likely add a generation of it as a special command and will most likely generate it during the install phase as well. It shouldn't be something that you need to care about, though, the currently created principal would just work. Regarding the rest, we need to discuss with MIT folks some changes to KDB API to allow KDB drivers to receive client certificates to do actual PKINIT with certificates which don't have specific extensions. This is what would be driving the work even though this all might not be needed for anonymous PKINIT by itself. -- / Alexander Bokovoy From sbose at redhat.com Thu Feb 11 08:46:15 2016 From: sbose at redhat.com (Sumit Bose) Date: Thu, 11 Feb 2016 09:46:15 +0100 Subject: [Freeipa-users] smart cards caintaining multiple certificates In-Reply-To: References: Message-ID: <20160211084615.GF12933@p.redhat.com> On Wed, Feb 10, 2016 at 04:05:20PM -0600, Michael Rainey (Contractor) wrote: > Greetings, > > I'm curious as to how IPA handles smart cards containing multiple > certificates. When I follow the steps listed at > https://fedorahosted.org/sssd/wiki/DesignDocs/SmartcardAuthenticationStep1 > when installing my certificate, I notice the certutil command dumps all > installed certificates, and dumps the certificates in a different order > depending on which certificate is selected. When the server tries to match > a certificate does it compare all certificates as one long continuous > string, or does it compare one certificate at a time? I'm curious if this > presents a problem for the end-user or has this problem been addressed? SSSD looks for valid certificates which have client authentication set in the extended key usage. If multiple certificate are found currently just the "first" one is used. More option to configure the certificate selection are planned for the next release. If you have a specific selection of certificates on the Smartcards you use which currently do not work as expected with SSSD feel free to send me a dump of the certificates on the card or a description so that I can see what kind of configuration options might be needed to select the right one. If you prefer you can send this data to me directly. HTH bye, Sumit > -- > *Michael Rainey* > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project From pspacek at redhat.com Thu Feb 11 09:46:23 2016 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 11 Feb 2016 10:46:23 +0100 Subject: [Freeipa-users] BIND apparently not loading ldap.so In-Reply-To: <77c8b66eb6614184b9d80045cae4d0c6@etriptrader.com> References: <77c8b66eb6614184b9d80045cae4d0c6@etriptrader.com> Message-ID: <56BC586F.4080902@redhat.com> On 10.2.2016 20:05, Chris Lajoie wrote: > Hi, I am using the bind-dyndb-ldap package (not full FreeIPA) and I am having a problem where it appears that the plugin is not getting loaded by BIND at all. I have nothing in the logs at all from the plugin. No failures of any kind, just regular named startup. I would have expected BIND to provide a log message saying it is loading an external plugin, or at least some kind of initialization message from the plugin itself, but I see neither. What am I doing wrong here? > > This is the relevant portion of my named.conf file: > > logging { > channel default_debug { > file "/var/log/named/named.log" versions 4 size 5m; > severity info; > print-time yes; > }; > }; > > dynamic-db "ldap" { > library "ldap.so"; > arg "uri ldap://ldap.ett.local"; > arg "base ou=dns,dc=ett,dc=local"; > arg "auth_method simple"; > arg "bind_dn cn=admin,dc=ett,dc=local"; > arg "password secret"; > arg "verbose_checks yes"; > arg "serial_autoincrement yes"; > }; Interesting ... What version of BIND and bind-dyndb-ldap packages are you using? $ rpm -q bind bind-dyndb-ldap I'm not sure how exactly the logging magic in BIND works so I would recommend you to to run BIND using command: $ named -g -u named and check output in the console to see if it contains line like 'bind-dyndb-ldap version 8.0 compiled at 16:09:02 Jan 20 2016, compiler 5.3.1 20151207 (Red Hat 5.3.1-2)' This message is logged at info level. If it fails, I would recommend you to double-check that BIND is actually reading the right configuration file :-) Add line "thismustsurelyfail" to random places in named.conf and see ;-) I hope it helps. -- Petr^2 Spacek From quasar7 at gmail.com Thu Feb 11 09:46:39 2016 From: quasar7 at gmail.com (Quasar) Date: Thu, 11 Feb 2016 10:46:39 +0100 Subject: [Freeipa-users] Failing to add Fedora 20 replica to Centos6.7 ipa server Message-ID: Hi, I desperately need your help/advice with our ipa update process. Briefly, we'd like to update our IPA 3.0 installation based on CentOS 6.7 to a newer version, and I read that the way of doing it is to create a new replica with a newer version of IPA server. Before writing this post, I browsed for similar issues (there are many of them with similar outcome) and tried to apply the suggested solutions but no luck. I also tried previous versions of Fedora (18 and 19) but again no luck. It seems I'm stuck and I don't know how to proceed :( Thank you in advance to anyhow who will take the time to read my message :) Let's start! Right now we have a single running on Centos 6.7, and we are planning to create a replica with Fedora 20 which has IPA 3.3 Here are the details of the master (CentOS 6.7, hostname ipaserver) [root at ipaserver ~]# uname -a Linux ipaserver.it.fx.lan 2.6.32-279.el6.x86_64 #1 SMP Fri Jun 22 12:19:21 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux [root at ipaserver ~]# rpm -qa|grep -E 'freeipa-server|pki-ca' ipa-pki-ca-theme-9.0.3-7.el6.noarch pki-ca-9.0.3-43.el6.noarch And here are the details of the replica (Fedoraa 20, hostname ipaserver-ha2) [root at ipaserver-ha2 ~]# uname -a Linux ipaserver-ha2.it.fx.lan 3.19.8-100.fc20.x86_64 #1 SMP Tue May 12 17:08:50 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux [root at ipaserver-ha2 ~]# rpm -qa|grep -E 'freeipa-server|pki-ca' pki-ca-10.1.2-7.fc20.noarch freeipa-server-3.3.5-1.fc20.x86_64 Here are the steps I made: Before starting the replica I updated the schema of the master with the copy-schema-to-ca.py script I prepared the replica certificates on the server ("ipa-replica-prepare ipaserver-ha2.it.fx.lan --ip-address 10.0.0.10") and transferred to the replica server on the same folder The I ran the replica install and here's the output: [root at ipaserver-ha2 ~]# ipa-replica-install --setup-ca --setup-dns --no-forwarders --no-ntp /var/lib/ipa/replica-info-ipaserver-ha2.it.fx.lan.gpg Directory Manager (existing master) password: Run connection check to master Check connection from replica to remote master 'ipaserver.it.fx.lan': Directory Service: Unsecure port (389): OK Directory Service: Secure port (636): OK Kerberos KDC: TCP (88): OK Kerberos Kpasswd: TCP (464): OK HTTP Server: Unsecure port (80): OK HTTP Server: Secure port (443): OK PKI-CA: Directory Service port (7389): OK The following list of ports use UDP protocol and would need to be checked manually: Kerberos KDC: UDP (88): SKIPPED Kerberos Kpasswd: UDP (464): SKIPPED Connection from replica to master is OK. Start listening on required ports for remote master check Get credentials to log in to remote master admin at IT.FX.LAN password: Check SSH connection to remote master Execute check on remote master Check connection from master to remote replica 'ipaserver-ha2.it.fx.lan': Directory Service: Unsecure port (389): OK Directory Service: Secure port (636): OK Kerberos KDC: TCP (88): OK Kerberos KDC: UDP (88): OK Kerberos Kpasswd: TCP (464): OK Kerberos Kpasswd: UDP (464): OK HTTP Server: Unsecure port (80): OK HTTP Server: Secure port (443): OK Connection from master to replica is OK. Connection check OK Configuring directory server (dirsrv): Estimated time 1 minute [1/34]: creating directory server user [2/34]: creating directory server instance [3/34]: adding default schema [4/34]: enabling memberof plugin [5/34]: enabling winsync plugin [6/34]: configuring replication version plugin [7/34]: enabling IPA enrollment plugin [8/34]: enabling ldapi [9/34]: configuring uniqueness plugin [10/34]: configuring uuid plugin [11/34]: configuring modrdn plugin [12/34]: configuring DNS plugin [13/34]: enabling entryUSN plugin [14/34]: configuring lockout plugin [15/34]: creating indices [16/34]: enabling referential integrity plugin [17/34]: configuring ssl for ds instance [18/34]: configuring certmap.conf [19/34]: configure autobind for root [20/34]: configure new location for managed entries [21/34]: configure dirsrv ccache [22/34]: enable SASL mapping fallback [23/34]: restarting directory server [24/34]: setting up initial replication Starting replication, please wait until this has completed. Update in progress, 3 seconds elapsed Update succeeded [25/34]: updating schema [26/34]: setting Auto Member configuration [27/34]: enabling S4U2Proxy delegation [28/34]: initializing group membership [29/34]: adding master entry [30/34]: configuring Posix uid/gid generation [31/34]: adding replication acis [32/34]: enabling compatibility plugin [33/34]: tuning directory server [34/34]: configuring directory to start on boot Done configuring directory server (dirsrv). Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds [1/19]: creating certificate server user [2/19]: configuring certificate server instance ipa : CRITICAL failed to configure ca instance Command '/usr/sbin/pkispawn -s CA -f /tmp/tmpoqFGBW' returned non-zero exit status 1 Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. Configuration of CA failed Log files on the replica server are attached. On the master I extraced the access log of the http server: 10.0.0.10 - - [09/Feb/2016:15:30:23 +0100] "GET /ca/rest/securityDomain/domainInfo HTTP/1.1" 404 317 10.0.0.10 - - [09/Feb/2016:15:30:23 +0100] "GET /ca/admin/ca/getDomainXML HTTP/1.1" 200 1593 10.0.0.10 - - [09/Feb/2016:15:30:23 +0100] "GET /ca/rest/account/login HTTP/1.1" 404 305 10.0.0.10 - - [09/Feb/2016:15:30:45 +0100] "POST /ca/admin/ca/getCertChain HTTP/1.0" 200 1410 10.0.0.10 - - [09/Feb/2016:15:30:46 +0100] "GET /ca/rest/account/login HTTP/1.1" 404 305 10.0.0.10 - - [09/Feb/2016:15:30:46 +0100] "POST /ca/admin/ca/getCookie HTTP/1.1" 200 4092 10.0.0.10 - - [09/Feb/2016:15:30:47 +0100] "POST /ca/admin/ca/getDomainXML HTTP/1.0" 200 1593 10.0.0.10 - - [09/Feb/2016:15:30:47 +0100] "POST /ca/admin/ca/getCertChain HTTP/1.0" 200 1410 10.0.0.10 - - [09/Feb/2016:15:30:47 +0100] "POST /ca/admin/ca/updateNumberRange HTTP/1.0" 404 313 10.0.0.8 - - [09/Feb/2016:15:30:47 +0100] "POST /ca/ee/ca/tokenAuthenticate HTTP/1.0" 200 154 10.0.0.10 - - [09/Feb/2016:15:30:48 +0100] "POST /ca/admin/ca/updateNumberRange HTTP/1.0" 404 313 10.0.0.10 - - [09/Feb/2016:15:30:47 +0100] "POST /ca/ee/ca/updateNumberRange HTTP/1.0" 200 163 10.0.0.8 - - [09/Feb/2016:15:30:48 +0100] "POST /ca/ee/ca/tokenAuthenticate HTTP/1.0" 200 154 10.0.0.10 - - [09/Feb/2016:15:30:48 +0100] "POST /ca/ee/ca/updateNumberRange HTTP/1.0" 200 163 10.0.0.10 - - [09/Feb/2016:15:30:49 +0100] "POST /ca/admin/ca/updateNumberRange HTTP/1.0" 404 313 10.0.0.8 - - [09/Feb/2016:15:30:49 +0100] "POST /ca/ee/ca/tokenAuthenticate HTTP/1.0" 200 154 10.0.0.10 - - [09/Feb/2016:15:30:49 +0100] "POST /ca/ee/ca/updateNumberRange HTTP/1.0" 200 157 10.0.0.8 - - [09/Feb/2016:15:30:50 +0100] "POST /ca/ee/ca/tokenAuthenticate HTTP/1.0" 200 154 10.0.0.10 - - [09/Feb/2016:15:30:50 +0100] "POST /ca/admin/ca/getConfigEntries HTTP/1.0" 200 13746 10.0.0.8 - - [09/Feb/2016:15:31:41 +0100] "POST /ca/ee/ca/tokenAuthenticate HTTP/1.0" 200 154 10.0.0.10 - - [09/Feb/2016:15:31:41 +0100] "POST /ca/ee/ca/profileSubmit HTTP/1.0" 200 1459 10.0.0.10 - - [09/Feb/2016:15:31:42 +0100] "POST /ca/admin/ca/getDomainXML HTTP/1.0" 200 1593 10.0.0.10 - - [09/Feb/2016:15:31:42 +0100] "POST /ca/admin/ca/updateDomainXML HTTP/1.0" 404 311 10.0.0.10 - - [09/Feb/2016:15:31:42 +0100] "POST /ca/agent/ca/updateDomainXML HTTP/1.0" 200 115 -- Giuseppe Calignano -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: debug Type: application/octet-stream Size: 212597 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ipareplica-install.log Type: text/x-log Size: 153830 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-ca-spawn.20160209153022.log Type: text/x-log Size: 421105 bytes Desc: not available URL: From mbasti at redhat.com Thu Feb 11 10:05:29 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 11 Feb 2016 11:05:29 +0100 Subject: [Freeipa-users] Failing to add Fedora 20 replica to Centos6.7 ipa server In-Reply-To: References: Message-ID: <56BC5CE9.7080402@redhat.com> Hello, comments inline. On 11.02.2016 10:46, Quasar wrote: > Hi, I desperately need your help/advice with our ipa update process. > Briefly, we'd like to update our IPA 3.0 installation based on CentOS > 6.7 to a newer version, and I read that the way of doing it is to > create a new replica with a newer version of IPA server. > Before writing this post, I browsed for similar issues (there are many > of them with similar outcome) and tried to apply the suggested > solutions but no luck. I also tried previous versions of Fedora (18 > and 19) but again no luck. > It seems I'm stuck and I don't know how to proceed :( > > Thank you in advance to anyhow who will take the time to read my > message :) Let's start! > > Right now we have a single running on Centos 6.7, and we are planning > to create a replica with Fedora 20 which has IPA 3.3 Fedora 20 is end of life, why you use that old fedora? Why not Centos7 or F23 ? Upgrade path from CentOS to Fedora is supported or tested, there might be issues because versions of FreeIPA are different due backporting patches to CentOS I suggest to use new FreeIPA 4.2 on centos 7. > > Here are the details of the master (CentOS 6.7, hostname ipaserver) > [root at ipaserver ~]# uname -a > Linux ipaserver.it.fx.lan 2.6.32-279.el6.x86_64 #1 SMP Fri Jun 22 > 12:19:21 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux > > [root at ipaserver ~]# rpm -qa|grep -E 'freeipa-server|pki-ca' > ipa-pki-ca-theme-9.0.3-7.el6.noarch > pki-ca-9.0.3-43.el6.noarch > > And here are the details of the replica (Fedoraa 20, hostname > ipaserver-ha2) > [root at ipaserver-ha2 ~]# uname -a > Linux ipaserver-ha2.it.fx.lan 3.19.8-100.fc20.x86_64 #1 SMP Tue May 12 > 17:08:50 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux > > [root at ipaserver-ha2 ~]# rpm -qa|grep -E 'freeipa-server|pki-ca' > pki-ca-10.1.2-7.fc20.noarch > freeipa-server-3.3.5-1.fc20.x86_64 > > Here are the steps I made: > Before starting the replica I updated the schema of the master with > the copy-schema-to-ca.py script > I prepared the replica certificates on the server > ("ipa-replica-prepare ipaserver-ha2.it.fx.lan --ip-address 10.0.0.10") > and transferred to the replica server on the same folder > The I ran the replica install and here's the output: > [root at ipaserver-ha2 ~]# ipa-replica-install --setup-ca --setup-dns > --no-forwarders --no-ntp > /var/lib/ipa/replica-info-ipaserver-ha2.it.fx.lan.gpg > Directory Manager (existing master) password: > > Run connection check to master > Check connection from replica to remote master 'ipaserver.it.fx.lan': > Directory Service: Unsecure port (389): OK > Directory Service: Secure port (636): OK > Kerberos KDC: TCP (88): OK > Kerberos Kpasswd: TCP (464): OK > HTTP Server: Unsecure port (80): OK > HTTP Server: Secure port (443): OK > PKI-CA: Directory Service port (7389): OK > > The following list of ports use UDP protocol and would need to be > checked manually: > Kerberos KDC: UDP (88): SKIPPED > Kerberos Kpasswd: UDP (464): SKIPPED > > Connection from replica to master is OK. > Start listening on required ports for remote master check > Get credentials to log in to remote master > admin at IT.FX.LAN password: > > Check SSH connection to remote master > Execute check on remote master > Check connection from master to remote replica 'ipaserver-ha2.it.fx.lan': > Directory Service: Unsecure port (389): OK > Directory Service: Secure port (636): OK > Kerberos KDC: TCP (88): OK > Kerberos KDC: UDP (88): OK > Kerberos Kpasswd: TCP (464): OK > Kerberos Kpasswd: UDP (464): OK > HTTP Server: Unsecure port (80): OK > HTTP Server: Secure port (443): OK > > Connection from master to replica is OK. > > Connection check OK > Configuring directory server (dirsrv): Estimated time 1 minute > [1/34]: creating directory server user > [2/34]: creating directory server instance > [3/34]: adding default schema > [4/34]: enabling memberof plugin > [5/34]: enabling winsync plugin > [6/34]: configuring replication version plugin > [7/34]: enabling IPA enrollment plugin > [8/34]: enabling ldapi > [9/34]: configuring uniqueness plugin > [10/34]: configuring uuid plugin > [11/34]: configuring modrdn plugin > [12/34]: configuring DNS plugin > [13/34]: enabling entryUSN plugin > [14/34]: configuring lockout plugin > [15/34]: creating indices > [16/34]: enabling referential integrity plugin > [17/34]: configuring ssl for ds instance > [18/34]: configuring certmap.conf > [19/34]: configure autobind for root > [20/34]: configure new location for managed entries > [21/34]: configure dirsrv ccache > [22/34]: enable SASL mapping fallback > [23/34]: restarting directory server > [24/34]: setting up initial replication > Starting replication, please wait until this has completed. > Update in progress, 3 seconds elapsed > Update succeeded > > [25/34]: updating schema > [26/34]: setting Auto Member configuration > [27/34]: enabling S4U2Proxy delegation > [28/34]: initializing group membership > [29/34]: adding master entry > [30/34]: configuring Posix uid/gid generation > [31/34]: adding replication acis > [32/34]: enabling compatibility plugin > [33/34]: tuning directory server > [34/34]: configuring directory to start on boot > Done configuring directory server (dirsrv). > Configuring certificate server (pki-tomcatd): Estimated time 3 minutes > 30 seconds > [1/19]: creating certificate server user > [2/19]: configuring certificate server instance > ipa : CRITICAL failed to configure ca instance Command > '/usr/sbin/pkispawn -s CA -f /tmp/tmpoqFGBW' returned non-zero exit > status 1 > > Your system may be partly configured. > Run /usr/sbin/ipa-server-install --uninstall to clean up. > > Configuration of CA failed > > > Log files on the replica server are attached. > > > On the master I extraced the access log of the http server: > 10.0.0.10 - - [09/Feb/2016:15:30:23 +0100] "GET > /ca/rest/securityDomain/domainInfo HTTP/1.1" 404 317 > 10.0.0.10 - - [09/Feb/2016:15:30:23 +0100] "GET > /ca/admin/ca/getDomainXML HTTP/1.1" 200 1593 > 10.0.0.10 - - [09/Feb/2016:15:30:23 +0100] "GET /ca/rest/account/login > HTTP/1.1" 404 305 > 10.0.0.10 - - [09/Feb/2016:15:30:45 +0100] "POST > /ca/admin/ca/getCertChain HTTP/1.0" 200 1410 > 10.0.0.10 - - [09/Feb/2016:15:30:46 +0100] "GET /ca/rest/account/login > HTTP/1.1" 404 305 > 10.0.0.10 - - [09/Feb/2016:15:30:46 +0100] "POST > /ca/admin/ca/getCookie HTTP/1.1" 200 4092 > 10.0.0.10 - - [09/Feb/2016:15:30:47 +0100] "POST > /ca/admin/ca/getDomainXML HTTP/1.0" 200 1593 > 10.0.0.10 - - [09/Feb/2016:15:30:47 +0100] "POST > /ca/admin/ca/getCertChain HTTP/1.0" 200 1410 > 10.0.0.10 - - [09/Feb/2016:15:30:47 +0100] "POST > /ca/admin/ca/updateNumberRange HTTP/1.0" 404 313 > 10.0.0.8 - - [09/Feb/2016:15:30:47 +0100] "POST > /ca/ee/ca/tokenAuthenticate HTTP/1.0" 200 154 > 10.0.0.10 - - [09/Feb/2016:15:30:48 +0100] "POST > /ca/admin/ca/updateNumberRange HTTP/1.0" 404 313 > 10.0.0.10 - - [09/Feb/2016:15:30:47 +0100] "POST > /ca/ee/ca/updateNumberRange HTTP/1.0" 200 163 > 10.0.0.8 - - [09/Feb/2016:15:30:48 +0100] "POST > /ca/ee/ca/tokenAuthenticate HTTP/1.0" 200 154 > 10.0.0.10 - - [09/Feb/2016:15:30:48 +0100] "POST > /ca/ee/ca/updateNumberRange HTTP/1.0" 200 163 > 10.0.0.10 - - [09/Feb/2016:15:30:49 +0100] "POST > /ca/admin/ca/updateNumberRange HTTP/1.0" 404 313 > 10.0.0.8 - - [09/Feb/2016:15:30:49 +0100] "POST > /ca/ee/ca/tokenAuthenticate HTTP/1.0" 200 154 > 10.0.0.10 - - [09/Feb/2016:15:30:49 +0100] "POST > /ca/ee/ca/updateNumberRange HTTP/1.0" 200 157 > 10.0.0.8 - - [09/Feb/2016:15:30:50 +0100] "POST > /ca/ee/ca/tokenAuthenticate HTTP/1.0" 200 154 > 10.0.0.10 - - [09/Feb/2016:15:30:50 +0100] "POST > /ca/admin/ca/getConfigEntries HTTP/1.0" 200 13746 > 10.0.0.8 - - [09/Feb/2016:15:31:41 +0100] "POST > /ca/ee/ca/tokenAuthenticate HTTP/1.0" 200 154 > 10.0.0.10 - - [09/Feb/2016:15:31:41 +0100] "POST > /ca/ee/ca/profileSubmit HTTP/1.0" 200 1459 > 10.0.0.10 - - [09/Feb/2016:15:31:42 +0100] "POST > /ca/admin/ca/getDomainXML HTTP/1.0" 200 1593 > 10.0.0.10 - - [09/Feb/2016:15:31:42 +0100] "POST > /ca/admin/ca/updateDomainXML HTTP/1.0" 404 311 > 10.0.0.10 - - [09/Feb/2016:15:31:42 +0100] "POST > /ca/agent/ca/updateDomainXML HTTP/1.0" 200 115 > Can you post debug log of CA? /var/log/pki/pki-tomcat/ca/debug It may contains more information Martin > > -- > Giuseppe Calignano > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Thu Feb 11 10:10:00 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 11 Feb 2016 11:10:00 +0100 Subject: [Freeipa-users] Failing to add Fedora 20 replica to Centos6.7 ipa server In-Reply-To: <56BC5CE9.7080402@redhat.com> References: <56BC5CE9.7080402@redhat.com> Message-ID: <56BC5DF8.5080809@redhat.com> On 11.02.2016 11:05, Martin Basti wrote: > Hello, > comments inline. > > On 11.02.2016 10:46, Quasar wrote: >> Hi, I desperately need your help/advice with our ipa update process. >> Briefly, we'd like to update our IPA 3.0 installation based on CentOS >> 6.7 to a newer version, and I read that the way of doing it is to >> create a new replica with a newer version of IPA server. >> Before writing this post, I browsed for similar issues (there are >> many of them with similar outcome) and tried to apply the suggested >> solutions but no luck. I also tried previous versions of Fedora (18 >> and 19) but again no luck. >> It seems I'm stuck and I don't know how to proceed :( >> >> Thank you in advance to anyhow who will take the time to read my >> message :) Let's start! >> >> Right now we have a single running on Centos 6.7, and we are planning >> to create a replica with Fedora 20 which has IPA 3.3 > > Fedora 20 is end of life, why you use that old fedora? > Why not Centos7 or F23 ? > > Upgrade path from CentOS to Fedora is supported or tested, there might > be issues because versions of FreeIPA are different due backporting > patches to CentOS * is NOT supported sorry > > I suggest to use new FreeIPA 4.2 on centos 7. >> >> Here are the details of the master (CentOS 6.7, hostname ipaserver) >> [root at ipaserver ~]# uname -a >> Linux ipaserver.it.fx.lan 2.6.32-279.el6.x86_64 #1 SMP Fri Jun 22 >> 12:19:21 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux >> >> [root at ipaserver ~]# rpm -qa|grep -E 'freeipa-server|pki-ca' >> ipa-pki-ca-theme-9.0.3-7.el6.noarch >> pki-ca-9.0.3-43.el6.noarch >> >> And here are the details of the replica (Fedoraa 20, hostname >> ipaserver-ha2) >> [root at ipaserver-ha2 ~]# uname -a >> Linux ipaserver-ha2.it.fx.lan 3.19.8-100.fc20.x86_64 #1 SMP Tue May >> 12 17:08:50 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux >> >> [root at ipaserver-ha2 ~]# rpm -qa|grep -E 'freeipa-server|pki-ca' >> pki-ca-10.1.2-7.fc20.noarch >> freeipa-server-3.3.5-1.fc20.x86_64 >> >> Here are the steps I made: >> Before starting the replica I updated the schema of the master with >> the copy-schema-to-ca.py script >> I prepared the replica certificates on the server >> ("ipa-replica-prepare ipaserver-ha2.it.fx.lan --ip-address >> 10.0.0.10") and transferred to the replica server on the same folder >> The I ran the replica install and here's the output: >> [root at ipaserver-ha2 ~]# ipa-replica-install --setup-ca --setup-dns >> --no-forwarders --no-ntp >> /var/lib/ipa/replica-info-ipaserver-ha2.it.fx.lan.gpg >> Directory Manager (existing master) password: >> >> Run connection check to master >> Check connection from replica to remote master 'ipaserver.it.fx.lan': >> Directory Service: Unsecure port (389): OK >> Directory Service: Secure port (636): OK >> Kerberos KDC: TCP (88): OK >> Kerberos Kpasswd: TCP (464): OK >> HTTP Server: Unsecure port (80): OK >> HTTP Server: Secure port (443): OK >> PKI-CA: Directory Service port (7389): OK >> >> The following list of ports use UDP protocol and would need to be >> checked manually: >> Kerberos KDC: UDP (88): SKIPPED >> Kerberos Kpasswd: UDP (464): SKIPPED >> >> Connection from replica to master is OK. >> Start listening on required ports for remote master check >> Get credentials to log in to remote master >> admin at IT.FX.LAN password: >> >> Check SSH connection to remote master >> Execute check on remote master >> Check connection from master to remote replica 'ipaserver-ha2.it.fx.lan': >> Directory Service: Unsecure port (389): OK >> Directory Service: Secure port (636): OK >> Kerberos KDC: TCP (88): OK >> Kerberos KDC: UDP (88): OK >> Kerberos Kpasswd: TCP (464): OK >> Kerberos Kpasswd: UDP (464): OK >> HTTP Server: Unsecure port (80): OK >> HTTP Server: Secure port (443): OK >> >> Connection from master to replica is OK. >> >> Connection check OK >> Configuring directory server (dirsrv): Estimated time 1 minute >> [1/34]: creating directory server user >> [2/34]: creating directory server instance >> [3/34]: adding default schema >> [4/34]: enabling memberof plugin >> [5/34]: enabling winsync plugin >> [6/34]: configuring replication version plugin >> [7/34]: enabling IPA enrollment plugin >> [8/34]: enabling ldapi >> [9/34]: configuring uniqueness plugin >> [10/34]: configuring uuid plugin >> [11/34]: configuring modrdn plugin >> [12/34]: configuring DNS plugin >> [13/34]: enabling entryUSN plugin >> [14/34]: configuring lockout plugin >> [15/34]: creating indices >> [16/34]: enabling referential integrity plugin >> [17/34]: configuring ssl for ds instance >> [18/34]: configuring certmap.conf >> [19/34]: configure autobind for root >> [20/34]: configure new location for managed entries >> [21/34]: configure dirsrv ccache >> [22/34]: enable SASL mapping fallback >> [23/34]: restarting directory server >> [24/34]: setting up initial replication >> Starting replication, please wait until this has completed. >> Update in progress, 3 seconds elapsed >> Update succeeded >> >> [25/34]: updating schema >> [26/34]: setting Auto Member configuration >> [27/34]: enabling S4U2Proxy delegation >> [28/34]: initializing group membership >> [29/34]: adding master entry >> [30/34]: configuring Posix uid/gid generation >> [31/34]: adding replication acis >> [32/34]: enabling compatibility plugin >> [33/34]: tuning directory server >> [34/34]: configuring directory to start on boot >> Done configuring directory server (dirsrv). >> Configuring certificate server (pki-tomcatd): Estimated time 3 >> minutes 30 seconds >> [1/19]: creating certificate server user >> [2/19]: configuring certificate server instance >> ipa : CRITICAL failed to configure ca instance Command >> '/usr/sbin/pkispawn -s CA -f /tmp/tmpoqFGBW' returned non-zero exit >> status 1 >> >> Your system may be partly configured. >> Run /usr/sbin/ipa-server-install --uninstall to clean up. >> >> Configuration of CA failed >> >> >> Log files on the replica server are attached. >> >> >> On the master I extraced the access log of the http server: >> 10.0.0.10 - - [09/Feb/2016:15:30:23 +0100] "GET >> /ca/rest/securityDomain/domainInfo HTTP/1.1" 404 317 >> 10.0.0.10 - - [09/Feb/2016:15:30:23 +0100] "GET >> /ca/admin/ca/getDomainXML HTTP/1.1" 200 1593 >> 10.0.0.10 - - [09/Feb/2016:15:30:23 +0100] "GET >> /ca/rest/account/login HTTP/1.1" 404 305 >> 10.0.0.10 - - [09/Feb/2016:15:30:45 +0100] "POST >> /ca/admin/ca/getCertChain HTTP/1.0" 200 1410 >> 10.0.0.10 - - [09/Feb/2016:15:30:46 +0100] "GET >> /ca/rest/account/login HTTP/1.1" 404 305 >> 10.0.0.10 - - [09/Feb/2016:15:30:46 +0100] "POST >> /ca/admin/ca/getCookie HTTP/1.1" 200 4092 >> 10.0.0.10 - - [09/Feb/2016:15:30:47 +0100] "POST >> /ca/admin/ca/getDomainXML HTTP/1.0" 200 1593 >> 10.0.0.10 - - [09/Feb/2016:15:30:47 +0100] "POST >> /ca/admin/ca/getCertChain HTTP/1.0" 200 1410 >> 10.0.0.10 - - [09/Feb/2016:15:30:47 +0100] "POST >> /ca/admin/ca/updateNumberRange HTTP/1.0" 404 313 >> 10.0.0.8 - - [09/Feb/2016:15:30:47 +0100] "POST >> /ca/ee/ca/tokenAuthenticate HTTP/1.0" 200 154 >> 10.0.0.10 - - [09/Feb/2016:15:30:48 +0100] "POST >> /ca/admin/ca/updateNumberRange HTTP/1.0" 404 313 >> 10.0.0.10 - - [09/Feb/2016:15:30:47 +0100] "POST >> /ca/ee/ca/updateNumberRange HTTP/1.0" 200 163 >> 10.0.0.8 - - [09/Feb/2016:15:30:48 +0100] "POST >> /ca/ee/ca/tokenAuthenticate HTTP/1.0" 200 154 >> 10.0.0.10 - - [09/Feb/2016:15:30:48 +0100] "POST >> /ca/ee/ca/updateNumberRange HTTP/1.0" 200 163 >> 10.0.0.10 - - [09/Feb/2016:15:30:49 +0100] "POST >> /ca/admin/ca/updateNumberRange HTTP/1.0" 404 313 >> 10.0.0.8 - - [09/Feb/2016:15:30:49 +0100] "POST >> /ca/ee/ca/tokenAuthenticate HTTP/1.0" 200 154 >> 10.0.0.10 - - [09/Feb/2016:15:30:49 +0100] "POST >> /ca/ee/ca/updateNumberRange HTTP/1.0" 200 157 >> 10.0.0.8 - - [09/Feb/2016:15:30:50 +0100] "POST >> /ca/ee/ca/tokenAuthenticate HTTP/1.0" 200 154 >> 10.0.0.10 - - [09/Feb/2016:15:30:50 +0100] "POST >> /ca/admin/ca/getConfigEntries HTTP/1.0" 200 13746 >> 10.0.0.8 - - [09/Feb/2016:15:31:41 +0100] "POST >> /ca/ee/ca/tokenAuthenticate HTTP/1.0" 200 154 >> 10.0.0.10 - - [09/Feb/2016:15:31:41 +0100] "POST >> /ca/ee/ca/profileSubmit HTTP/1.0" 200 1459 >> 10.0.0.10 - - [09/Feb/2016:15:31:42 +0100] "POST >> /ca/admin/ca/getDomainXML HTTP/1.0" 200 1593 >> 10.0.0.10 - - [09/Feb/2016:15:31:42 +0100] "POST >> /ca/admin/ca/updateDomainXML HTTP/1.0" 404 311 >> 10.0.0.10 - - [09/Feb/2016:15:31:42 +0100] "POST >> /ca/agent/ca/updateDomainXML HTTP/1.0" 200 115 >> > Can you post debug log of CA? > /var/log/pki/pki-tomcat/ca/debug > > It may contains more information > > Martin >> >> -- >> Giuseppe Calignano >> >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From quasar7 at gmail.com Thu Feb 11 10:28:47 2016 From: quasar7 at gmail.com (Quasar) Date: Thu, 11 Feb 2016 11:28:47 +0100 Subject: [Freeipa-users] Failing to add Fedora 20 replica to Centos6.7 ipa server In-Reply-To: <56BC5CE9.7080402@redhat.com> References: <56BC5CE9.7080402@redhat.com> Message-ID: Hi Martin, first of all thanks for taking some time to read and provide feedback, much appreciated. I firstly tried with CentOS 7.x (build 1511) but got the same errore during CA configuration. Then I supposed I had to upgrade step-by-step, from 3.0 to 3.3 (instead of 3.0 to 4.x) and used Fedora 23, 20, 19 and 18 but with no luck. If you need the exact log from CentOS 7.x migration I can provide them to you. About the debug log file, it was attached and these are the final lines containing the error: [09/Feb/2016:15:31:42][http-bio-8443-exec-3]: getDomainXML: domainInfo=IPAipaserver.it.fx.lan44344344344380FALSEpki-cadTRUEipaserver-ha.it.fx.lan44344344380443TRUETRUEpki-cad200000 [09/Feb/2016:15:31:42][http-bio-8443-exec-3]: Cloning a domain master [09/Feb/2016:15:31:42][http-bio-8443-exec-3]: WizardPanelBase updateDomainXML start hostname=ipaserver.it.fx.lan port=443 [09/Feb/2016:15:31:42][http-bio-8443-exec-3]: updateSecurityDomain: failed to update security domain using admin port 443: org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 50; White spaces are required between publicId and systemId. [09/Feb/2016:15:31:42][http-bio-8443-exec-3]: updateSecurityDomain: now trying agent port with client auth [09/Feb/2016:15:31:42][http-bio-8443-exec-3]: WizardPanelBase updateDomainXML start hostname=ipaserver.it.fx.lan port=443 [09/Feb/2016:15:31:42][http-bio-8443-exec-3]: updateDomainXML() nickname=subsystemCert cert-pki-ca [09/Feb/2016:15:31:43][http-bio-8443-exec-3]: WizardPanelBase updateDomainXML: status=1 -- Giuseppe Calignano -------------- next part -------------- An HTML attachment was scrubbed... URL: From quasar7 at gmail.com Thu Feb 11 11:51:04 2016 From: quasar7 at gmail.com (Quasar) Date: Thu, 11 Feb 2016 12:51:04 +0100 Subject: [Freeipa-users] Failing to add Fedora 20 replica to Centos6.7 ipa server In-Reply-To: References: <56BC5CE9.7080402@redhat.com> Message-ID: Martin, I've re-tested the replica with a freshly-installed CentOS 7 (1511). Installation still fails (damn!) and the log is a bit more verbose. I suppose it has something to do with certificate in my master server proably due to incremental updates did in the past. 2016-02-11T11:09:21Z DEBUG Starting external process 2016-02-11T11:09:21Z DEBUG args='/usr/sbin/pkispawn' '-s' 'CA' '-f' '/tmp/tmpRHosRn' 2016-02-11T11:10:58Z DEBUG Process finished, return code=1 2016-02-11T11:10:58Z DEBUG stdout=Log file: /var/log/pki/pki-ca-spawn.20160211120921.log Loading deployment configuration from /tmp/tmpRHosRn. Installing CA into /var/lib/pki/pki-tomcat. Storing deployment configuration into /etc/sysconfig/pki/tomcat/pki-tomcat/ca/deployment.cfg. Installation failed. 2016-02-11T11:10:58Z DEBUG stderr=/usr/lib/python2.7/site-packages/urllib3/connectionpool.py:769: InsecureRequestWarning: Unverified HTTPS request is being made. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.org/en/latest/security.html InsecureRequestWarning) pkispawn : WARNING ....... unable to validate security domain user/password through REST interface. Interface not available pkispawn : ERROR ....... Exception from Java Configuration Servlet: 500 Server Error: Internal Server Error pkispawn : ERROR ....... ParseError: not well-formed (invalid token): line 1, column 0: {"Attributes":{"Attribute":[]},"ClassName":"com.netscape.certsrv.base.PKIException","Code":500,"Message":"Error while updating security domain: java.io.IOException: 2"} 2016-02-11T11:10:58Z CRITICAL Failed to configure CA instance: Command ''/usr/sbin/pkispawn' '-s' 'CA' '-f' '/tmp/tmpRHosRn'' returned non-zero exit status 1 2016-02-11T11:10:58Z CRITICAL See the installation logs and the following files/directories for more information: 2016-02-11T11:10:58Z CRITICAL /var/log/pki-ca-install.log 2016-02-11T11:10:58Z CRITICAL /var/log/pki/pki-tomcat 2016-02-11T11:10:58Z DEBUG Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 418, in start_creation run_step(full_msg, method) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 408, in run_step method() File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 620, in __spawn_instance DogtagInstance.spawn_instance(self, cfg_file) File "/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py", line 201, in spawn_instance self.handle_setup_error(e) File "/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py", line 465, in handle_setup_error raise RuntimeError("%s configuration failed." % self.subsystem) RuntimeError: CA configuration failed. I'm attaching the 3 log files, as usual: On Thu, Feb 11, 2016 at 11:28 AM, Quasar wrote: > Hi Martin, > > first of all thanks for taking some time to read and provide feedback, > much appreciated. > > I firstly tried with CentOS 7.x (build 1511) but got the same errore > during CA configuration. Then I supposed I had to upgrade step-by-step, > from 3.0 to 3.3 (instead of 3.0 to 4.x) and used Fedora 23, 20, 19 and 18 > but with no luck. > If you need the exact log from CentOS 7.x migration I can provide them to > you. > > About the debug log file, it was attached and these are the final lines > containing the error: > > [09/Feb/2016:15:31:42][http-bio-8443-exec-3]: getDomainXML: > domainInfo= standalone="no"?>IPAipaserver.it.fx.lan44344344344380FALSEpki-cadTRUEipaserver-ha.it.fx.lan44344344380443TRUETRUEpki-cad200000 > [09/Feb/2016:15:31:42][http-bio-8443-exec-3]: Cloning a domain master > [09/Feb/2016:15:31:42][http-bio-8443-exec-3]: WizardPanelBase > updateDomainXML start hostname=ipaserver.it.fx.lan port=443 > [09/Feb/2016:15:31:42][http-bio-8443-exec-3]: updateSecurityDomain: failed > to update security domain using admin port 443: > org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 50; White > spaces are required between publicId and systemId. > [09/Feb/2016:15:31:42][http-bio-8443-exec-3]: updateSecurityDomain: now > trying agent port with client auth > [09/Feb/2016:15:31:42][http-bio-8443-exec-3]: WizardPanelBase > updateDomainXML start hostname=ipaserver.it.fx.lan port=443 > [09/Feb/2016:15:31:42][http-bio-8443-exec-3]: updateDomainXML() > nickname=subsystemCert cert-pki-ca > [09/Feb/2016:15:31:43][http-bio-8443-exec-3]: WizardPanelBase > updateDomainXML: status=1 > > > > -- > Giuseppe Calignano > -- Giuseppe Calignano -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: debug Type: application/octet-stream Size: 88289 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ipareplica-install.log Type: text/x-log Size: 191748 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-ca-spawn.20160211120921.log Type: text/x-log Size: 156026 bytes Desc: not available URL: From mbasti at redhat.com Thu Feb 11 12:25:58 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 11 Feb 2016 13:25:58 +0100 Subject: [Freeipa-users] CA: Failing to add Centos7 replica to Centos6.7 ipa server In-Reply-To: References: <56BC5CE9.7080402@redhat.com> Message-ID: <56BC7DD6.80204@redhat.com> On 11.02.2016 12:51, Quasar wrote: > Martin, > > I've re-tested the replica with a freshly-installed CentOS 7 (1511). > Installation still fails (damn!) and the log is a bit more verbose. I > suppose it has something to do with certificate in my master server > proably due to incremental updates did in the past. > > 2016-02-11T11:09:21Z DEBUG Starting external process > 2016-02-11T11:09:21Z DEBUG args='/usr/sbin/pkispawn' '-s' 'CA' '-f' > '/tmp/tmpRHosRn' > 2016-02-11T11:10:58Z DEBUG Process finished, return code=1 > 2016-02-11T11:10:58Z DEBUG stdout=Log file: > /var/log/pki/pki-ca-spawn.20160211120921.log > Loading deployment configuration from /tmp/tmpRHosRn. > Installing CA into /var/lib/pki/pki-tomcat. > Storing deployment configuration into > /etc/sysconfig/pki/tomcat/pki-tomcat/ca/deployment.cfg. > > Installation failed. > > > 2016-02-11T11:10:58Z DEBUG > stderr=/usr/lib/python2.7/site-packages/urllib3/connectionpool.py:769: > InsecureRequestWarning: Unverified HTTPS request is being made. Adding > certificate verification is strongly advised. See: > https://urllib3.readthedocs.org/en/latest/security.html > InsecureRequestWarning) > pkispawn : WARNING ....... unable to validate security domain > user/password through REST interface. Interface not available > pkispawn : ERROR ....... Exception from Java Configuration > Servlet: 500 Server Error: Internal Server Error > pkispawn : ERROR ....... ParseError: not well-formed (invalid > token): line 1, column 0: > {"Attributes":{"Attribute":[]},"ClassName":"com.netscape.certsrv.base.PKIException","Code":500,"Message":"Error > while updating security domain: java.io.IOException: 2"} > > 2016-02-11T11:10:58Z CRITICAL Failed to configure CA instance: Command > ''/usr/sbin/pkispawn' '-s' 'CA' '-f' '/tmp/tmpRHosRn'' returned > non-zero exit status 1 > 2016-02-11T11:10:58Z CRITICAL See the installation logs and the > following files/directories for more information: > 2016-02-11T11:10:58Z CRITICAL /var/log/pki-ca-install.log > 2016-02-11T11:10:58Z CRITICAL /var/log/pki/pki-tomcat > 2016-02-11T11:10:58Z DEBUG Traceback (most recent call last): > File > "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line > 418, in start_creation > run_step(full_msg, method) > File > "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line > 408, in run_step > method() > File > "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", > line 620, in __spawn_instance > DogtagInstance.spawn_instance(self, cfg_file) > File > "/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py", line > 201, in spawn_instance > self.handle_setup_error(e) > File > "/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py", line > 465, in handle_setup_error > raise RuntimeError("%s configuration failed." % self.subsystem) > RuntimeError: CA configuration failed. > > I'm attaching the 3 log files, as usual: > > > > On Thu, Feb 11, 2016 at 11:28 AM, Quasar > wrote: > > Hi Martin, > > first of all thanks for taking some time to read and provide > feedback, much appreciated. > > I firstly tried with CentOS 7.x (build 1511) but got the same > errore during CA configuration. Then I supposed I had to upgrade > step-by-step, from 3.0 to 3.3 (instead of 3.0 to 4.x) and used > Fedora 23, 20, 19 and 18 but with no luck. > If you need the exact log from CentOS 7.x migration I can provide > them to you. > > About the debug log file, it was attached and these are the final > lines containing the error: > > [09/Feb/2016:15:31:42][http-bio-8443-exec-3]: getDomainXML: > domainInfo= standalone="no"?>IPAipaserver.it.fx.lan44344344344380FALSEpki-cadTRUEipaserver-ha.it.fx.lan44344344380443TRUETRUEpki-cad200000 > [09/Feb/2016:15:31:42][http-bio-8443-exec-3]: Cloning a domain master > [09/Feb/2016:15:31:42][http-bio-8443-exec-3]: WizardPanelBase > updateDomainXML start hostname=ipaserver.it.fx.lan port=443 > [09/Feb/2016:15:31:42][http-bio-8443-exec-3]: > updateSecurityDomain: failed to update security domain using admin > port 443: org.xml.sax.SAXParseException; lineNumber: 1; > columnNumber: 50; White spaces are required between publicId and > systemId. > [09/Feb/2016:15:31:42][http-bio-8443-exec-3]: > updateSecurityDomain: now trying agent port with client auth > [09/Feb/2016:15:31:42][http-bio-8443-exec-3]: WizardPanelBase > updateDomainXML start hostname=ipaserver.it.fx.lan port=443 > [09/Feb/2016:15:31:42][http-bio-8443-exec-3]: updateDomainXML() > nickname=subsystemCert cert-pki-ca > [09/Feb/2016:15:31:43][http-bio-8443-exec-3]: WizardPanelBase > updateDomainXML: status=1 > > > > -- > Giuseppe Calignano > > > > > -- > Giuseppe Calignano I'm not sure but it looks like the known bug in dogtag 9 and 10 compatibility (I will try to find related bugzillas). This should be already fixed in RHEL, so I do not know when it will hit CentOS or if it is already there. pkispawn : WARNING ....... unable to validate security domain user/password through REST interface. Interface not available pkispawn : ERROR ....... Exception from Java Configuration Servlet: 500 Server Error: Internal Server Error pkispawn : ERROR ....... ParseError: not well-formed (invalid token): line 1, column 0: {"Attributes":{"Attribute":[]},"ClassName":"com.netscape.certsrv.base.PKIException","Code":500,"Message":"Error while updating security domain: java.io.IOException: 2"} But I might be wrong, Dogtag guys can you look at it please? :-) Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From quasar7 at gmail.com Thu Feb 11 12:33:50 2016 From: quasar7 at gmail.com (Quasar) Date: Thu, 11 Feb 2016 12:33:50 +0000 Subject: [Freeipa-users] CA: Failing to add Centos7 replica to Centos6.7 ipa server In-Reply-To: <56BC7DD6.80204@redhat.com> References: <56BC5CE9.7080402@redhat.com> <56BC7DD6.80204@redhat.com> Message-ID: Thank you! Dodgig the dogtag guys, then ;-) Il giorno Gio 11 Feb 2016 13:26 Martin Basti ha scritto: > > > On 11.02.2016 12:51, Quasar wrote: > > Martin, > > I've re-tested the replica with a freshly-installed CentOS 7 (1511). > Installation still fails (damn!) and the log is a bit more verbose. I > suppose it has something to do with certificate in my master server proably > due to incremental updates did in the past. > > 2016-02-11T11:09:21Z DEBUG Starting external process > 2016-02-11T11:09:21Z DEBUG args='/usr/sbin/pkispawn' '-s' 'CA' '-f' > '/tmp/tmpRHosRn' > 2016-02-11T11:10:58Z DEBUG Process finished, return code=1 > 2016-02-11T11:10:58Z DEBUG stdout=Log file: > /var/log/pki/pki-ca-spawn.20160211120921.log > Loading deployment configuration from /tmp/tmpRHosRn. > Installing CA into /var/lib/pki/pki-tomcat. > Storing deployment configuration into > /etc/sysconfig/pki/tomcat/pki-tomcat/ca/deployment.cfg. > > Installation failed. > > > 2016-02-11T11:10:58Z DEBUG > stderr=/usr/lib/python2.7/site-packages/urllib3/connectionpool.py:769: > InsecureRequestWarning: Unverified HTTPS request is being made. Adding > certificate verification is strongly advised. See: > https://urllib3.readthedocs.org/en/latest/security.html > InsecureRequestWarning) > pkispawn : WARNING ....... unable to validate security domain > user/password through REST interface. Interface not available > pkispawn : ERROR ....... Exception from Java Configuration Servlet: > 500 Server Error: Internal Server Error > pkispawn : ERROR ....... ParseError: not well-formed (invalid > token): line 1, column 0: > {"Attributes":{"Attribute":[]},"ClassName":"com.netscape.certsrv.base.PKIException","Code":500,"Message":"Error > while updating security domain: java.io.IOException: 2"} > > 2016-02-11T11:10:58Z CRITICAL Failed to configure CA instance: Command > ''/usr/sbin/pkispawn' '-s' 'CA' '-f' '/tmp/tmpRHosRn'' returned non-zero > exit status 1 > 2016-02-11T11:10:58Z CRITICAL See the installation logs and the following > files/directories for more information: > 2016-02-11T11:10:58Z CRITICAL /var/log/pki-ca-install.log > 2016-02-11T11:10:58Z CRITICAL /var/log/pki/pki-tomcat > 2016-02-11T11:10:58Z DEBUG Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", > line 418, in start_creation > run_step(full_msg, method) > File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", > line 408, in run_step > method() > File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", > line 620, in __spawn_instance > DogtagInstance.spawn_instance(self, cfg_file) > File > "/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py", > line 201, in spawn_instance > self.handle_setup_error(e) > File > "/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py", > line 465, in handle_setup_error > raise RuntimeError("%s configuration failed." % self.subsystem) > RuntimeError: CA configuration failed. > > I'm attaching the 3 log files, as usual: > > > > On Thu, Feb 11, 2016 at 11:28 AM, Quasar wrote: > >> Hi Martin, >> >> first of all thanks for taking some time to read and provide feedback, >> much appreciated. >> >> I firstly tried with CentOS 7.x (build 1511) but got the same errore >> during CA configuration. Then I supposed I had to upgrade step-by-step, >> from 3.0 to 3.3 (instead of 3.0 to 4.x) and used Fedora 23, 20, 19 and 18 >> but with no luck. >> If you need the exact log from CentOS 7.x migration I can provide them to >> you. >> >> About the debug log file, it was attached and these are the final lines >> containing the error: >> >> [09/Feb/2016:15:31:42][http-bio-8443-exec-3]: getDomainXML: >> domainInfo=> standalone="no"?>IPAipaserver.it.fx.lan44344344344380FALSEpki-cadTRUEipaserver-ha.it.fx.lan44344344380443TRUETRUEpki-cad2&l! >> t;/Subsyst >> emCount>00000 >> [09/Feb/2016:15:31:42][http-bio-8443-exec-3]: Cloning a domain master >> [09/Feb/2016:15:31:42][http-bio-8443-exec-3]: WizardPanelBase >> updateDomainXML start hostname=ipaserver.it.fx.lan port=443 >> [09/Feb/2016:15:31:42][http-bio-8443-exec-3]: updateSecurityDomain: >> failed to update security domain using admin port 443: >> org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 50; White >> spaces are required between publicId and systemId. >> [09/Feb/2016:15:31:42][http-bio-8443-exec-3]: updateSecurityDomain: now >> trying agent port with client auth >> [09/Feb/2016:15:31:42][http-bio-8443-exec-3]: WizardPanelBase >> updateDomainXML start hostname=ipaserver.it.fx.lan port=443 >> [09/Feb/2016:15:31:42][http-bio-8443-exec-3]: updateDomainXML() >> nickname=subsystemCert cert-pki-ca >> [09/Feb/2016:15:31:43][http-bio-8443-exec-3]: WizardPanelBase >> updateDomainXML: status=1 >> >> >> >> -- >> Giuseppe Calignano >> > > > > -- > Giuseppe Calignano > > > I'm not sure but it looks like the known bug in dogtag 9 and 10 > compatibility (I will try to find related bugzillas). > This should be already fixed in RHEL, so I do not know when it will hit > CentOS or if it is already there. > > pkispawn : WARNING ....... unable to validate security domain > user/password through REST interface. Interface not available > pkispawn : ERROR ....... Exception from Java Configuration Servlet: > 500 Server Error: Internal Server Error > pkispawn : ERROR ....... ParseError: not well-formed (invalid > token): line 1, column 0: > {"Attributes":{"Attribute":[]},"ClassName":"com.netscape.certsrv.base.PKIException","Code":500,"Message":"Error > while updating security domain: java.io.IOException: 2"} > > But I might be wrong, Dogtag guys can you look at it please? :-) > > > Martin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Thu Feb 11 13:04:31 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 11 Feb 2016 14:04:31 +0100 Subject: [Freeipa-users] CA: Failing to add Centos7 replica to Centos6.7 ipa server In-Reply-To: References: <56BC5CE9.7080402@redhat.com> <56BC7DD6.80204@redhat.com> Message-ID: <56BC86DF.9020003@redhat.com> On 11.02.2016 13:33, Quasar wrote: > > Thank you! > Dodgig the dogtag guys, then ;-) > Do you have CA configured as external CA? It could be: https://bugzilla.redhat.com/show_bug.cgi?id=1291747 I don't think that it is already in CentOS > > Il giorno Gio 11 Feb 2016 13:26 Martin Basti > ha scritto: > > > > On 11.02.2016 12:51, Quasar wrote: >> Martin, >> >> I've re-tested the replica with a freshly-installed CentOS 7 (1511). >> Installation still fails (damn!) and the log is a bit more >> verbose. I suppose it has something to do with certificate in my >> master server proably due to incremental updates did in the past. >> >> 2016-02-11T11:09:21Z DEBUG Starting external process >> 2016-02-11T11:09:21Z DEBUG args='/usr/sbin/pkispawn' '-s' 'CA' >> '-f' '/tmp/tmpRHosRn' >> 2016-02-11T11:10:58Z DEBUG Process finished, return code=1 >> 2016-02-11T11:10:58Z DEBUG stdout=Log file: >> /var/log/pki/pki-ca-spawn.20160211120921.log >> Loading deployment configuration from /tmp/tmpRHosRn. >> Installing CA into /var/lib/pki/pki-tomcat. >> Storing deployment configuration into >> /etc/sysconfig/pki/tomcat/pki-tomcat/ca/deployment.cfg. >> >> Installation failed. >> >> >> 2016-02-11T11:10:58Z DEBUG >> stderr=/usr/lib/python2.7/site-packages/urllib3/connectionpool.py:769: >> InsecureRequestWarning: Unverified HTTPS request is being made. >> Adding certificate verification is strongly advised. See: >> https://urllib3.readthedocs.org/en/latest/security.html >> InsecureRequestWarning) >> pkispawn : WARNING ....... unable to validate security domain >> user/password through REST interface. Interface not available >> pkispawn : ERROR ....... Exception from Java Configuration >> Servlet: 500 Server Error: Internal Server Error >> pkispawn : ERROR ....... ParseError: not well-formed >> (invalid token): line 1, column 0: >> {"Attributes":{"Attribute":[]},"ClassName":"com.netscape.certsrv.base.PKIException","Code":500,"Message":"Error >> while updating security domain: java.io.IOException: 2"} >> >> 2016-02-11T11:10:58Z CRITICAL Failed to configure CA instance: >> Command ''/usr/sbin/pkispawn' '-s' 'CA' '-f' '/tmp/tmpRHosRn'' >> returned non-zero exit status 1 >> 2016-02-11T11:10:58Z CRITICAL See the installation logs and the >> following files/directories for more information: >> 2016-02-11T11:10:58Z CRITICAL /var/log/pki-ca-install.log >> 2016-02-11T11:10:58Z CRITICAL /var/log/pki/pki-tomcat >> 2016-02-11T11:10:58Z DEBUG Traceback (most recent call last): >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >> line 418, in start_creation >> run_step(full_msg, method) >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >> line 408, in run_step >> method() >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", >> line 620, in __spawn_instance >> DogtagInstance.spawn_instance(self, cfg_file) >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py", >> line 201, in spawn_instance >> self.handle_setup_error(e) >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py", >> line 465, in handle_setup_error >> raise RuntimeError("%s configuration failed." % self.subsystem) >> RuntimeError: CA configuration failed. >> >> I'm attaching the 3 log files, as usual: >> >> >> >> On Thu, Feb 11, 2016 at 11:28 AM, Quasar > > wrote: >> >> Hi Martin, >> >> first of all thanks for taking some time to read and provide >> feedback, much appreciated. >> >> I firstly tried with CentOS 7.x (build 1511) but got the same >> errore during CA configuration. Then I supposed I had to >> upgrade step-by-step, from 3.0 to 3.3 (instead of 3.0 to 4.x) >> and used Fedora 23, 20, 19 and 18 but with no luck. >> If you need the exact log from CentOS 7.x migration I can >> provide them to you. >> >> About the debug log file, it was attached and these are the >> final lines containing the error: >> >> [09/Feb/2016:15:31:42][http-bio-8443-exec-3]: getDomainXML: >> domainInfo=> standalone="no"?>IPAipaserver.it.fx.lan44344344344380FALSEpki-cadTRUEipaserver-ha.it.fx.lan44344344380443TRUETRUEpki-cad2&l! >> t;/Subsyst >> emCount>00000 >> [09/Feb/2016:15:31:42][http-bio-8443-exec-3]: Cloning a >> domain master >> [09/Feb/2016:15:31:42][http-bio-8443-exec-3]: WizardPanelBase >> updateDomainXML start hostname=ipaserver.it.fx.lan port=443 >> [09/Feb/2016:15:31:42][http-bio-8443-exec-3]: >> updateSecurityDomain: failed to update security domain using >> admin port 443: org.xml.sax.SAXParseException; lineNumber: 1; >> columnNumber: 50; White spaces are required between publicId >> and systemId. >> [09/Feb/2016:15:31:42][http-bio-8443-exec-3]: >> updateSecurityDomain: now trying agent port with client auth >> [09/Feb/2016:15:31:42][http-bio-8443-exec-3]: WizardPanelBase >> updateDomainXML start hostname=ipaserver.it.fx.lan port=443 >> [09/Feb/2016:15:31:42][http-bio-8443-exec-3]: >> updateDomainXML() nickname=subsystemCert cert-pki-ca >> [09/Feb/2016:15:31:43][http-bio-8443-exec-3]: WizardPanelBase >> updateDomainXML: status=1 >> >> >> >> -- >> Giuseppe Calignano >> >> >> >> >> -- >> Giuseppe Calignano > > I'm not sure but it looks like the known bug in dogtag 9 and 10 > compatibility (I will try to find related bugzillas). > This should be already fixed in RHEL, so I do not know when it > will hit CentOS or if it is already there. > > pkispawn : WARNING ....... unable to validate security domain > user/password through REST interface. Interface not available > pkispawn : ERROR ....... Exception from Java Configuration > Servlet: 500 Server Error: Internal Server Error > pkispawn : ERROR ....... ParseError: not well-formed > (invalid token): line 1, column 0: > {"Attributes":{"Attribute":[]},"ClassName":"com.netscape.certsrv.base.PKIException","Code":500,"Message":"Error > while updating security domain: java.io.IOException: 2"} > > But I might be wrong, Dogtag guys can you look at it please? :-) > > > Martin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From giuseppe.calignano at finantix.com Tue Feb 9 15:26:26 2016 From: giuseppe.calignano at finantix.com (giuseppe.calignano at finantix.com) Date: Tue, 9 Feb 2016 16:26:26 +0100 Subject: [Freeipa-users] Failing to add Fedora 20 replica to Centos6.7 ipa server Message-ID: Hi, I desperately need your help/advice with our ipa update process. Briefly, we'd like to update our IPA 3.0 installation based on CentOS 6.7 to a newer version, and I read that the way of doing it is to create a new replica with a newer version of IPA server. Before writing this post, I browsed for similar issues (there are many of them with similar outcome) and tried to apply the suggested solutions but no luck. I also tried previous versions of Fedora (18 and 19) but again no luck. It seems I'm stuck and I don't know how to proceed :( Thank you in advance to anyhow who will take the time to read my message :) Let's start! Right now we have a single running on Centos 6.7, and we are planning to create a replica with Fedora 20 which has IPA 3.3 Here are the details of the master (ipaserver) [root at ipaserver ~]# uname -a Linux ipaserver.it.fx.lan 2.6.32-279.el6.x86_64 #1 SMP Fri Jun 22 12:19:21 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux [root at ipaserver ~]# rpm -qa|grep -E 'freeipa-server|pki-ca' ipa-pki-ca-theme-9.0.3-7.el6.noarch pki-ca-9.0.3-43.el6.noarch And here are the details of the replica (ipaserver-ha2 Replica server on Fedora 20: [root at ipaserver-ha2 ~]# uname -a Linux ipaserver-ha2.it.fx.lan 3.19.8-100.fc20.x86_64 #1 SMP Tue May 12 17:08:50 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux [root at ipaserver-ha2 ~]# rpm -qa|grep -E 'freeipa-server|pki-ca' pki-ca-10.1.2-7.fc20.noarch freeipa-server-3.3.5-1.fc20.x86_64 Here are the steps I made: Before starting the replica I updated the schema of the master with the copy-schema-to-ca.py script I prepared the replica certificates on the server ("ipa-replica-prepare ipaserver-ha2.it.fx.lan --ip-address 10.0.0.10") and transferred to the replica server on the same folder The I ran the replica install and here's the output: [root at ipaserver-ha2 ~]# ipa-replica-install --setup-ca --setup-dns --no-forwarders --no-ntp /var/lib/ipa/replica-info-ipaserver-ha2.it.fx.lan.gpg Directory Manager (existing master) password: Run connection check to master Check connection from replica to remote master 'ipaserver.it.fx.lan': Directory Service: Unsecure port (389): OK Directory Service: Secure port (636): OK Kerberos KDC: TCP (88): OK Kerberos Kpasswd: TCP (464): OK HTTP Server: Unsecure port (80): OK HTTP Server: Secure port (443): OK PKI-CA: Directory Service port (7389): OK The following list of ports use UDP protocol and would need to be checked manually: Kerberos KDC: UDP (88): SKIPPED Kerberos Kpasswd: UDP (464): SKIPPED Connection from replica to master is OK. Start listening on required ports for remote master check Get credentials to log in to remote master admin at IT.FX.LAN password: Check SSH connection to remote master Execute check on remote master Check connection from master to remote replica 'ipaserver-ha2.it.fx.lan': Directory Service: Unsecure port (389): OK Directory Service: Secure port (636): OK Kerberos KDC: TCP (88): OK Kerberos KDC: UDP (88): OK Kerberos Kpasswd: TCP (464): OK Kerberos Kpasswd: UDP (464): OK HTTP Server: Unsecure port (80): OK HTTP Server: Secure port (443): OK Connection from master to replica is OK. Connection check OK Configuring directory server (dirsrv): Estimated time 1 minute [1/34]: creating directory server user [2/34]: creating directory server instance [3/34]: adding default schema [4/34]: enabling memberof plugin [5/34]: enabling winsync plugin [6/34]: configuring replication version plugin [7/34]: enabling IPA enrollment plugin [8/34]: enabling ldapi [9/34]: configuring uniqueness plugin [10/34]: configuring uuid plugin [11/34]: configuring modrdn plugin [12/34]: configuring DNS plugin [13/34]: enabling entryUSN plugin [14/34]: configuring lockout plugin [15/34]: creating indices [16/34]: enabling referential integrity plugin [17/34]: configuring ssl for ds instance [18/34]: configuring certmap.conf [19/34]: configure autobind for root [20/34]: configure new location for managed entries [21/34]: configure dirsrv ccache [22/34]: enable SASL mapping fallback [23/34]: restarting directory server [24/34]: setting up initial replication Starting replication, please wait until this has completed. Update in progress, 3 seconds elapsed Update succeeded [25/34]: updating schema [26/34]: setting Auto Member configuration [27/34]: enabling S4U2Proxy delegation [28/34]: initializing group membership [29/34]: adding master entry [30/34]: configuring Posix uid/gid generation [31/34]: adding replication acis [32/34]: enabling compatibility plugin [33/34]: tuning directory server [34/34]: configuring directory to start on boot Done configuring directory server (dirsrv). Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds [1/19]: creating certificate server user [2/19]: configuring certificate server instance ipa : CRITICAL failed to configure ca instance Command '/usr/sbin/pkispawn -s CA -f /tmp/tmpoqFGBW' returned non-zero exit status 1 Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. Configuration of CA failed Here are the log files on the replica server: On the master I extraced the access log of the http server: 10.0.0.10 - - [09/Feb/2016:15:30:23 +0100] "GET /ca/rest/securityDomain/domainInfo HTTP/1.1" 404 317 10.0.0.10 - - [09/Feb/2016:15:30:23 +0100] "GET /ca/admin/ca/getDomainXML HTTP/1.1" 200 1593 10.0.0.10 - - [09/Feb/2016:15:30:23 +0100] "GET /ca/rest/account/login HTTP/1.1" 404 305 10.0.0.10 - - [09/Feb/2016:15:30:45 +0100] "POST /ca/admin/ca/getCertChain HTTP/1.0" 200 1410 10.0.0.10 - - [09/Feb/2016:15:30:46 +0100] "GET /ca/rest/account/login HTTP/1.1" 404 305 10.0.0.10 - - [09/Feb/2016:15:30:46 +0100] "POST /ca/admin/ca/getCookie HTTP/1.1" 200 4092 10.0.0.10 - - [09/Feb/2016:15:30:47 +0100] "POST /ca/admin/ca/getDomainXML HTTP/1.0" 200 1593 10.0.0.10 - - [09/Feb/2016:15:30:47 +0100] "POST /ca/admin/ca/getCertChain HTTP/1.0" 200 1410 10.0.0.10 - - [09/Feb/2016:15:30:47 +0100] "POST /ca/admin/ca/updateNumberRange HTTP/1.0" 404 313 10.0.0.8 - - [09/Feb/2016:15:30:47 +0100] "POST /ca/ee/ca/tokenAuthenticate HTTP/1.0" 200 154 10.0.0.10 - - [09/Feb/2016:15:30:48 +0100] "POST /ca/admin/ca/updateNumberRange HTTP/1.0" 404 313 10.0.0.10 - - [09/Feb/2016:15:30:47 +0100] "POST /ca/ee/ca/updateNumberRange HTTP/1.0" 200 163 10.0.0.8 - - [09/Feb/2016:15:30:48 +0100] "POST /ca/ee/ca/tokenAuthenticate HTTP/1.0" 200 154 10.0.0.10 - - [09/Feb/2016:15:30:48 +0100] "POST /ca/ee/ca/updateNumberRange HTTP/1.0" 200 163 10.0.0.10 - - [09/Feb/2016:15:30:49 +0100] "POST /ca/admin/ca/updateNumberRange HTTP/1.0" 404 313 10.0.0.8 - - [09/Feb/2016:15:30:49 +0100] "POST /ca/ee/ca/tokenAuthenticate HTTP/1.0" 200 154 10.0.0.10 - - [09/Feb/2016:15:30:49 +0100] "POST /ca/ee/ca/updateNumberRange HTTP/1.0" 200 157 10.0.0.8 - - [09/Feb/2016:15:30:50 +0100] "POST /ca/ee/ca/tokenAuthenticate HTTP/1.0" 200 154 10.0.0.10 - - [09/Feb/2016:15:30:50 +0100] "POST /ca/admin/ca/getConfigEntries HTTP/1.0" 200 13746 10.0.0.8 - - [09/Feb/2016:15:31:41 +0100] "POST /ca/ee/ca/tokenAuthenticate HTTP/1.0" 200 154 10.0.0.10 - - [09/Feb/2016:15:31:41 +0100] "POST /ca/ee/ca/profileSubmit HTTP/1.0" 200 1459 10.0.0.10 - - [09/Feb/2016:15:31:42 +0100] "POST /ca/admin/ca/getDomainXML HTTP/1.0" 200 1593 10.0.0.10 - - [09/Feb/2016:15:31:42 +0100] "POST /ca/admin/ca/updateDomainXML HTTP/1.0" 404 311 10.0.0.10 - - [09/Feb/2016:15:31:42 +0100] "POST /ca/agent/ca/updateDomainXML HTTP/1.0" 200 115 Best regards, Giuseppe Calignano IT Manager Mobile: +39 335 7864 963 | Office: + 39 041 258 7618 | Email: giuseppe.calignano at finantix.com | skype: quasaro Via della Pila, 13 | I-30175 Marghera | Venezia | Italy CONFIDENTIALITY NOTICE - This message may contain privileged and confidential information intended only for the use of the addressee named above. If you are not the intended recipient of this message, you are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. If you have received this message in error, please notify Finantix immediately via email to the sender. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1185 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ipareplica-install.log Type: application/octet-stream Size: 153830 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-ca-spawn.20160209153022.log Type: application/octet-stream Size: 421105 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: debug Type: application/octet-stream Size: 212597 bytes Desc: not available URL: From pioto at pioto.org Wed Feb 10 20:18:51 2016 From: pioto at pioto.org (Mike Kelly) Date: Wed, 10 Feb 2016 20:18:51 +0000 Subject: [Freeipa-users] ID Views without AD In-Reply-To: <20160210081945.GR12787@redhat.com> References: <20160210081945.GR12787@redhat.com> Message-ID: On Wed, Feb 10, 2016 at 3:19 AM Alexander Bokovoy wrote: > On Wed, 10 Feb 2016, Mike Kelly wrote: > > >Is there some extra logging I can turn on to see why this ID View isn't > >being applied like I would expect? Or perhaps some extra bit of > >configuration I missed? > Level 7 or 9 debug logs in SSSD on the client might help. > Thanks. Here's what looks like the relevant bits in /var/log/sssd/sssd_nss.log, after I ran `sss_cache -E ; id pioto`: (Wed Feb 10 15:06:45 2016) [sssd[nss]] [nss_cmd_getbynam] (0x0400): Running command [17] with input [pioto]. (Wed Feb 10 15:06:45 2016) [sssd[nss]] [sss_parse_name_for_domains] (0x0200): name 'pioto' matched without domain, user is pioto (Wed Feb 10 15:06:45 2016) [sssd[nss]] [nss_cmd_getbynam] (0x0100): Requesting info for [pioto] from [] (Wed Feb 10 15:06:45 2016) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [pioto at home.pioto.org] (Wed Feb 10 15:06:45 2016) [sssd[nss]] [get_dp_name_and_id] (0x0400): Not a LOCAL view, continuing with provided values. (Wed Feb 10 15:06:45 2016) [sssd[nss]] [sss_dp_issue_request] (0x0400): Issuing request for [0x7f9b482220e0:1:pioto at home.pioto.org] (Wed Feb 10 15:06:45 2016) [sssd[nss]] [sss_dp_get_account_msg] (0x0400): Creating request for [home.pioto.org][4097][1][name=pioto] (Wed Feb 10 15:06:45 2016) [sssd[nss]] [sss_dp_internal_get_send] (0x0400): Entering request [0x7f9b482220e0:1:pioto at home.pioto.org] (Wed Feb 10 15:06:45 2016) [sssd[nss]] [sss_dp_get_reply] (0x1000): Got reply from Data Provider - DP error code: 0 errno: 0 error message: Success (Success) (Wed Feb 10 15:06:45 2016) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [pioto at home.pioto.org] (Wed Feb 10 15:06:45 2016) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0400): Returning info for user [pioto at home.pioto.org] (Wed Feb 10 15:06:45 2016) [sssd[nss]] [sss_dp_req_destructor] (0x0400): Deleting request: [0x7f9b482220e0:1:pioto at home.pioto.org] (Wed Feb 10 15:06:45 2016) [sssd[nss]] [nss_cmd_getbyid] (0x0400): Running command [34] with id [1403400001]. (Wed Feb 10 15:06:45 2016) [sssd[nss]] [nss_cmd_getgrgid_search] (0x0100): Requesting info for [1403400001 at home.pioto.org] ---- So, if I'm reading that right, it looks like we first query the server to find the user with name 'pioto', and then get back a response containing my IPA-assigned UID, and do a further lookup on that... it mentions "Not a LOCAL view, ...", but I'm not sure that's related? So, I wonder if there's some bit of client-side configuration that I'm missing? But, the bit that I see in /var/log/sssd/sssd_home.pioto.org.log seems to match up with what I can see in LDAP: (Wed Feb 10 13:09:52 2016) [sssd[be[home.pioto.org]]] [dp_copy_options_ex] (0x0400): Option ipa_views_search_base has value cn=views,cn=accounts,dc=home,dc=pioto,dc=org >I'm running a pair of CentOS 7 boxes, one acting as the FreeIPA server, and > >the other is the "legacy" box I want to shim FreeIPA into... > ID Views are only applied on machines where you have SSSD that supports > them, just to make sure. > Thanks. Both server and client are running: $ sssd --version 1.13.0 -- Mike Kelly -------------- next part -------------- An HTML attachment was scrubbed... URL: From pioto at pioto.org Thu Feb 11 11:17:01 2016 From: pioto at pioto.org (Mike Kelly) Date: Thu, 11 Feb 2016 11:17:01 +0000 Subject: [Freeipa-users] ID Views without AD In-Reply-To: <20160211082137.GA28898@redhat.com> References: <20160210081945.GR12787@redhat.com> <20160211082137.GA28898@redhat.com> Message-ID: On Thu, Feb 11, 2016 at 3:21 AM Alexander Bokovoy wrote: > On Wed, 10 Feb 2016, Mike Kelly wrote: > >On Wed, Feb 10, 2016 at 3:19 AM Alexander Bokovoy > >wrote: > > > >> On Wed, 10 Feb 2016, Mike Kelly wrote: > >> > >> >Is there some extra logging I can turn on to see why this ID View isn't > >> >being applied like I would expect? Or perhaps some extra bit of > >> >configuration I missed? > >> Level 7 or 9 debug logs in SSSD on the client might help. > >> > > > >Thanks. > > > >Here's what looks like the relevant bits in /var/log/sssd/sssd_nss.log, > >after I ran `sss_cache -E ; id pioto`: > Please provide content of sssd_.log, this is where the actual > work is done when user information is obtained and processed. > sssd_nss.log is merely a requestor. > Thanks. Here's what is hopefully the relevant lines: (Thu Feb 11 06:05:13 2016) [sssd[be[home.pioto.org]]] [sdap_search_user_next_base] (0x0400): Searching for users with base [cn=accounts,dc=home,dc=pioto,dc=org] (Thu Feb 11 06:05:13 2016) [sssd[be[home.pioto.org]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(uid=pioto)(objectclass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNumber=0 ))))][cn=accounts,dc=home,dc=pioto,dc=org]. (Thu Feb 11 06:05:13 2016) [sssd[be[home.pioto.org]]] [sdap_parse_entry] (0x1000): OriginalDN: [uid=pioto,cn=users,cn=accounts,dc=home,dc=pioto,dc=org]. (Thu Feb 11 06:05:13 2016) [sssd[be[home.pioto.org]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set (Thu Feb 11 06:05:13 2016) [sssd[be[home.pioto.org]]] [sdap_search_user_process] (0x0400): Search for users, returned 1 results. (Thu Feb 11 06:05:13 2016) [sssd[be[home.pioto.org]]] [sdap_save_user] (0x0400): Save user (Thu Feb 11 06:05:13 2016) [sssd[be[home.pioto.org]]] [sdap_attrs_get_sid_str] (0x1000): No [objectSIDString] attribute. [0][Success] (Thu Feb 11 06:05:13 2016) [sssd[be[home.pioto.org]]] [sdap_get_primary_name] (0x0400): Processing object pioto (Thu Feb 11 06:05:13 2016) [sssd[be[home.pioto.org]]] [sdap_save_user] (0x0400): Processing user pioto (Thu Feb 11 06:05:13 2016) [sssd[be[home.pioto.org]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Thu Feb 11 06:05:13 2016) [sssd[be[home.pioto.org]]] [sdap_save_user] (0x0400): Adding original memberOf attributes to [pioto]. (Thu Feb 11 06:05:13 2016) [sssd[be[home.pioto.org]]] [sdap_save_user] (0x0400): Adding user principal [pioto at HOME.PIOTO.ORG] to attributes of [pioto]. (Thu Feb 11 06:05:13 2016) [sssd[be[home.pioto.org]]] [sdap_save_user] (0x0400): Storing info for user pioto (Thu Feb 11 06:05:13 2016) [sssd[be[home.pioto.org]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success (Success) -- so, looks like i don't see any evidence of an id view being searched for or applied? (Thu Feb 11 06:05:13 2016) [sssd[be[home.pioto.org]]] [be_get_account_info] (0x0200): Got request for [0x1002][1][idnumber=1403400001] (Thu Feb 11 06:05:13 2016) [sssd[be[home.pioto.org]]] [sdap_get_groups_next_base] (0x0400): Searching for groups with base [cn=accounts,dc=home,dc=pioto,dc=org] (Thu Feb 11 06:05:13 2016) [sssd[be[home.pioto.org]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(gidNumber=1403400001)(|(objectClass=ipaUserGroup)(objectClass=posixGroup ))(cn=*)(&(gidNumber=*)(!(gidNumber=0))))][cn=accounts,dc=home,dc=pioto,dc=org]. -- and here, looks like nss is requesting the details from my FreeIPA default GID... The only log entries I see in /var/log/sssd/sssd_.log that are related to views seem to be from when I last restarted sssd: (Wed Feb 10 13:09:52 2016) [sssd[be[home.pioto.org]]] [dp_get_options] (0x0400): Option ipa_views_search_base has no value (Wed Feb 10 13:09:52 2016) [sssd[be[home.pioto.org]]] [ipa_get_id_options] (0x0100): Option ipa_views_search_base set to cn=views,cn=accounts,dc=home,dc=pioto,dc=org (Wed Feb 10 13:09:52 2016) [sssd[be[home.pioto.org]]] [common_parse_search_base] (0x0100): Search base added: [IPA_VIEWS][cn=views,cn=accounts,dc=home,dc=pioto,dc=org][SUBTREE][] (Wed Feb 10 13:09:52 2016) [sssd[be[home.pioto.org]]] [sdap_get_map] (0x0400): Option ipa_view_class has value nsContainer (Wed Feb 10 13:09:52 2016) [sssd[be[home.pioto.org]]] [sdap_get_map] (0x0400): Option ipa_view_name has value cn (Wed Feb 10 13:09:52 2016) [sssd[be[home.pioto.org]]] [sssm_ipa_id_init] (0x0020): Cannot find view name in the cache. Will do online lookup later. (Wed Feb 10 13:09:52 2016) [sssd[be[home.pioto.org]]] [dp_copy_options_ex] (0x0400): Option ipa_views_search_base has value cn=views,cn=accounts,dc=home,dc=pioto,dc=org (Wed Feb 10 13:09:52 2016) [sssd[be[home.pioto.org]]] [dp_copy_options_ex] (0x0400): Option ipa_views_search_base has value cn=views,cn=accounts,dc=home,dc=pioto,dc=org ---- When I search LDAP under that search base, I get 3 DNs I'd expect to see: dn: cn=views,cn=accounts,dc=home,dc=pioto,dc=org dn: cn=oldservers,cn=views,cn=accounts,dc=home,dc=pioto,dc=org dn: ipaanchoruuid=:IPA:home.pioto.org: fc07446e-ce52-11e5-8a98-52540092d8fc,cn= oldservers,cn=views,cn=accounts,dc=home,dc=pioto,dc=org And, under the servers tree, I see a corresponding ipaAssignedIDView: dn: fqdn=data.home.pioto.org ,cn=computers,cn=accounts,dc=home,dc=pioto,dc=org ipaAssignedIDView: cn=oldservers,cn=views,cn=accounts,dc=home,dc=pioto,dc=org -- Mike Kelly -------------- next part -------------- An HTML attachment was scrubbed... URL: From quasar7 at gmail.com Thu Feb 11 13:49:05 2016 From: quasar7 at gmail.com (Quasar) Date: Thu, 11 Feb 2016 14:49:05 +0100 Subject: [Freeipa-users] CA: Failing to add Centos7 replica to Centos6.7 ipa server In-Reply-To: <56BC86DF.9020003@redhat.com> References: <56BC5CE9.7080402@redhat.com> <56BC7DD6.80204@redhat.com> <56BC86DF.9020003@redhat.com> Message-ID: ? Excellent news Martin! After checking the bug you shared with me, I tried to check if pki-core-9.0.3-45.el6_7 was released for CentOS 6.7 and I was quite lucky this time! After a "yum update" I retried the teplica and this time everything went smoothly! Thanks a lot for your help and time! Cheers! On Thu, Feb 11, 2016 at 2:04 PM, Martin Basti wrote: > > > On 11.02.2016 13:33, Quasar wrote: > > Thank you! > Dodgig the dogtag guys, then ;-) > > Do you have CA configured as external CA? > > It could be: > https://bugzilla.redhat.com/show_bug.cgi?id=1291747 > > I don't think that it is already in CentOS > > -- Giuseppe Calignano -------------- next part -------------- An HTML attachment was scrubbed... URL: From quasar7 at gmail.com Thu Feb 11 13:57:04 2016 From: quasar7 at gmail.com (Quasar) Date: Thu, 11 Feb 2016 14:57:04 +0100 Subject: [Freeipa-users] Failing to add Fedora 20 replica to Centos6.7 ipa server In-Reply-To: References: Message-ID: Please disregard this email, as it was duplicated. Sorry for the incovenience On Tue, Feb 9, 2016 at 4:26 PM, wrote: > Hi, I desperately need your help/advice with our ipa update process. > Briefly, we'd like to update our IPA 3.0 installation based on CentOS 6.7 > to a newer version, and I read that the way of doing it is to create a new > replica with a newer version of IPA server. > Before writing this post, I browsed for similar issues (there are many of > them with similar outcome) and tried to apply the suggested solutions but > no luck. I also tried previous versions of Fedora (18 and 19) but again no > luck. > It seems I'm stuck and I don't know how to proceed :( > > Thank you in advance to anyhow who will take the time to read my message > :) Let's start! > > Right now we have a single running on Centos 6.7, and we are planning to > create a replica with Fedora 20 which has IPA 3.3 > > Here are the details of the master (ipaserver) > [root at ipaserver ~]# uname -a > Linux ipaserver.it.fx.lan 2.6.32-279.el6.x86_64 #1 SMP Fri Jun 22 12:19:21 > UTC 2012 x86_64 x86_64 x86_64 GNU/Linux > > [root at ipaserver ~]# rpm -qa|grep -E 'freeipa-server|pki-ca' > ipa-pki-ca-theme-9.0.3-7.el6.noarch > pki-ca-9.0.3-43.el6.noarch > > And here are the details of the replica (ipaserver-ha2 > Replica server on Fedora 20: > [root at ipaserver-ha2 ~]# uname -a > Linux ipaserver-ha2.it.fx.lan 3.19.8-100.fc20.x86_64 #1 SMP Tue May 12 > 17:08:50 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux > > [root at ipaserver-ha2 ~]# rpm -qa|grep -E 'freeipa-server|pki-ca' > pki-ca-10.1.2-7.fc20.noarch > freeipa-server-3.3.5-1.fc20.x86_64 > > Here are the steps I made: > > - Before starting the replica I updated the schema of the master with > the copy-schema-to-ca.py script > - I prepared the replica certificates on the server > ("ipa-replica-prepare ipaserver-ha2.it.fx.lan --ip-address 10.0.0.10") and > transferred to the replica server on the same folder > - The I ran the replica install and here's the output: > > [root at ipaserver-ha2 ~]# ipa-replica-install --setup-ca --setup-dns > --no-forwarders --no-ntp > /var/lib/ipa/replica-info-ipaserver-ha2.it.fx.lan.gpg > Directory Manager (existing master) password: > > Run connection check to master > Check connection from replica to remote master 'ipaserver.it.fx.lan': > Directory Service: Unsecure port (389): OK > Directory Service: Secure port (636): OK > Kerberos KDC: TCP (88): OK > Kerberos Kpasswd: TCP (464): OK > HTTP Server: Unsecure port (80): OK > HTTP Server: Secure port (443): OK > PKI-CA: Directory Service port (7389): OK > > The following list of ports use UDP protocol and would need to be > checked manually: > Kerberos KDC: UDP (88): SKIPPED > Kerberos Kpasswd: UDP (464): SKIPPED > > Connection from replica to master is OK. > Start listening on required ports for remote master check > Get credentials to log in to remote master > admin at IT.FX.LAN password: > > Check SSH connection to remote master > Execute check on remote master > Check connection from master to remote replica 'ipaserver-ha2.it.fx.lan': > Directory Service: Unsecure port (389): OK > Directory Service: Secure port (636): OK > Kerberos KDC: TCP (88): OK > Kerberos KDC: UDP (88): OK > Kerberos Kpasswd: TCP (464): OK > Kerberos Kpasswd: UDP (464): OK > HTTP Server: Unsecure port (80): OK > HTTP Server: Secure port (443): OK > > Connection from master to replica is OK. > > Connection check OK > Configuring directory server (dirsrv): Estimated time 1 minute > [1/34]: creating directory server user > [2/34]: creating directory server instance > [3/34]: adding default schema > [4/34]: enabling memberof plugin > [5/34]: enabling winsync plugin > [6/34]: configuring replication version plugin > [7/34]: enabling IPA enrollment plugin > [8/34]: enabling ldapi > [9/34]: configuring uniqueness plugin > [10/34]: configuring uuid plugin > [11/34]: configuring modrdn plugin > [12/34]: configuring DNS plugin > [13/34]: enabling entryUSN plugin > [14/34]: configuring lockout plugin > [15/34]: creating indices > [16/34]: enabling referential integrity plugin > [17/34]: configuring ssl for ds instance > [18/34]: configuring certmap.conf > [19/34]: configure autobind for root > [20/34]: configure new location for managed entries > [21/34]: configure dirsrv ccache > [22/34]: enable SASL mapping fallback > [23/34]: restarting directory server > [24/34]: setting up initial replication > Starting replication, please wait until this has completed. > Update in progress, 3 seconds elapsed > Update succeeded > > [25/34]: updating schema > [26/34]: setting Auto Member configuration > [27/34]: enabling S4U2Proxy delegation > [28/34]: initializing group membership > [29/34]: adding master entry > [30/34]: configuring Posix uid/gid generation > [31/34]: adding replication acis > [32/34]: enabling compatibility plugin > [33/34]: tuning directory server > [34/34]: configuring directory to start on boot > Done configuring directory server (dirsrv). > Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 > seconds > [1/19]: creating certificate server user > [2/19]: configuring certificate server instance > ipa : CRITICAL failed to configure ca instance Command > '/usr/sbin/pkispawn -s CA -f /tmp/tmpoqFGBW' returned non-zero exit status 1 > > Your system may be partly configured. > Run /usr/sbin/ipa-server-install --uninstall to clean up. > > Configuration of CA failed > > > Here are the log files on the replica server: > > > > > > On the master I extraced the access log of the http server: > 10.0.0.10 - - [09/Feb/2016:15:30:23 +0100] "GET > /ca/rest/securityDomain/domainInfo HTTP/1.1" 404 317 > 10.0.0.10 - - [09/Feb/2016:15:30:23 +0100] "GET /ca/admin/ca/getDomainXML > HTTP/1.1" 200 1593 > 10.0.0.10 - - [09/Feb/2016:15:30:23 +0100] "GET /ca/rest/account/login > HTTP/1.1" 404 305 > 10.0.0.10 - - [09/Feb/2016:15:30:45 +0100] "POST /ca/admin/ca/getCertChain > HTTP/1.0" 200 1410 > 10.0.0.10 - - [09/Feb/2016:15:30:46 +0100] "GET /ca/rest/account/login > HTTP/1.1" 404 305 > 10.0.0.10 - - [09/Feb/2016:15:30:46 +0100] "POST /ca/admin/ca/getCookie > HTTP/1.1" 200 4092 > 10.0.0.10 - - [09/Feb/2016:15:30:47 +0100] "POST /ca/admin/ca/getDomainXML > HTTP/1.0" 200 1593 > 10.0.0.10 - - [09/Feb/2016:15:30:47 +0100] "POST /ca/admin/ca/getCertChain > HTTP/1.0" 200 1410 > 10.0.0.10 - - [09/Feb/2016:15:30:47 +0100] "POST > /ca/admin/ca/updateNumberRange HTTP/1.0" 404 313 > 10.0.0.8 - - [09/Feb/2016:15:30:47 +0100] "POST > /ca/ee/ca/tokenAuthenticate HTTP/1.0" 200 154 > 10.0.0.10 - - [09/Feb/2016:15:30:48 +0100] "POST > /ca/admin/ca/updateNumberRange HTTP/1.0" 404 313 > 10.0.0.10 - - [09/Feb/2016:15:30:47 +0100] "POST > /ca/ee/ca/updateNumberRange HTTP/1.0" 200 163 > 10.0.0.8 - - [09/Feb/2016:15:30:48 +0100] "POST > /ca/ee/ca/tokenAuthenticate HTTP/1.0" 200 154 > 10.0.0.10 - - [09/Feb/2016:15:30:48 +0100] "POST > /ca/ee/ca/updateNumberRange HTTP/1.0" 200 163 > 10.0.0.10 - - [09/Feb/2016:15:30:49 +0100] "POST > /ca/admin/ca/updateNumberRange HTTP/1.0" 404 313 > 10.0.0.8 - - [09/Feb/2016:15:30:49 +0100] "POST > /ca/ee/ca/tokenAuthenticate HTTP/1.0" 200 154 > 10.0.0.10 - - [09/Feb/2016:15:30:49 +0100] "POST > /ca/ee/ca/updateNumberRange HTTP/1.0" 200 157 > 10.0.0.8 - - [09/Feb/2016:15:30:50 +0100] "POST > /ca/ee/ca/tokenAuthenticate HTTP/1.0" 200 154 > 10.0.0.10 - - [09/Feb/2016:15:30:50 +0100] "POST > /ca/admin/ca/getConfigEntries HTTP/1.0" 200 13746 > 10.0.0.8 - - [09/Feb/2016:15:31:41 +0100] "POST > /ca/ee/ca/tokenAuthenticate HTTP/1.0" 200 154 > 10.0.0.10 - - [09/Feb/2016:15:31:41 +0100] "POST /ca/ee/ca/profileSubmit > HTTP/1.0" 200 1459 > 10.0.0.10 - - [09/Feb/2016:15:31:42 +0100] "POST /ca/admin/ca/getDomainXML > HTTP/1.0" 200 1593 > 10.0.0.10 - - [09/Feb/2016:15:31:42 +0100] "POST > /ca/admin/ca/updateDomainXML HTTP/1.0" 404 311 > 10.0.0.10 - - [09/Feb/2016:15:31:42 +0100] "POST > /ca/agent/ca/updateDomainXML HTTP/1.0" 200 115 > > > > Best regards, > > *Giuseppe Calignano* > IT Manager > > > Mobile: +39 335 7864 963 | Office: + 39 041 258 7618 | Email: > giuseppe.calignano at finantix.com | skype: quasaro > Via della Pila, 13 | I-30175 Marghera | Venezia | Italy > > CONFIDENTIALITY NOTICE - This message may contain privileged and > confidential information intended only for the use of the addressee named > above. If you are not the intended recipient of this message, you are > hereby notified that any use, dissemination, distribution or reproduction > of this message is prohibited. If you have received this message in error, > please notify Finantix immediately via email to the sender. > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project > -- Giuseppe Calignano -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1185 bytes Desc: not available URL: From mbasti at redhat.com Thu Feb 11 15:49:45 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 11 Feb 2016 16:49:45 +0100 Subject: [Freeipa-users] CA: Failing to add Centos7 replica to Centos6.7 ipa server [solved] In-Reply-To: References: <56BC5CE9.7080402@redhat.com> <56BC7DD6.80204@redhat.com> <56BC86DF.9020003@redhat.com> Message-ID: <56BCAD99.3060905@redhat.com> On 11.02.2016 14:49, Quasar wrote: > ? > Excellent news Martin! After checking the bug you shared with me, I > tried to check if pki-core-9.0.3-45.el6_7 was released for CentOS 6.7 > and I was quite lucky this time! > After a "yum update" I retried the teplica and this time everything > went smoothly! > > Thanks a lot for your help and time! > > Cheers! > You are welcome Just note: If you plan to retire old server, do not forget to set new IPA CA server as CRL master and renewal master http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master > > > On Thu, Feb 11, 2016 at 2:04 PM, Martin Basti > wrote: > > > > On 11.02.2016 13:33, Quasar wrote: >> >> Thank you! >> Dodgig the dogtag guys, then ;-) >> > Do you have CA configured as external CA? > > It could be: > https://bugzilla.redhat.com/show_bug.cgi?id=1291747 > > I don't think that it is already in CentOS > > > > > -- > Giuseppe Calignano -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at etriptrader.com Thu Feb 11 18:32:57 2016 From: chris at etriptrader.com (Chris Lajoie) Date: Thu, 11 Feb 2016 11:32:57 -0700 Subject: [Freeipa-users] BIND apparently not loading ldap.so In-Reply-To: <56BC586F.4080902@redhat.com> References: <77c8b66eb6614184b9d80045cae4d0c6@etriptrader.com> <56BC586F.4080902@redhat.com> Message-ID: <56BCD3D9.2050405@etriptrader.com> On 02/11/2016 02:46 AM, Petr Spacek wrote: > What version of BIND and bind-dyndb-ldap packages are you using? > $ rpm -q bind bind-dyndb-ldap bind-9.9.4-29.el7_2.2.x86_64 bind-dyndb-ldap-8.0-1.el7.x86_64 > > I'm not sure how exactly the logging magic in BIND works so I would recommend > you to to run BIND using command: > $ named -g -u named > and check output in the console to see if it contains line like > 'bind-dyndb-ldap version 8.0 compiled at 16:09:02 Jan 20 2016, compiler 5.3.1 > 20151207 (Red Hat 5.3.1-2)' I get nothing like that. Here is the output I get from running named: https://gist.github.com/ctlajoie/0ed4e97e72aec3172a8d > > This message is logged at info level. > > > If it fails, I would recommend you to double-check that BIND is actually > reading the right configuration file :-) Add line "thismustsurelyfail" to > random places in named.conf and see ;-) I had previously been thinking along the same lines and I tried this (I actually just removed the semicolon from the end of the dynamic-db block). As expected, named fails to start with a configuration error. I tried it again just now to confirm.. same result. Thank you Petr, I appreciate you taking the time to help. From pspacek at redhat.com Fri Feb 12 07:53:45 2016 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 12 Feb 2016 08:53:45 +0100 Subject: [Freeipa-users] BIND apparently not loading ldap.so In-Reply-To: <56BCD3D9.2050405@etriptrader.com> References: <77c8b66eb6614184b9d80045cae4d0c6@etriptrader.com> <56BC586F.4080902@redhat.com> <56BCD3D9.2050405@etriptrader.com> Message-ID: <56BD8F89.3060008@redhat.com> On 11.2.2016 19:32, Chris Lajoie wrote: > On 02/11/2016 02:46 AM, Petr Spacek wrote: >> What version of BIND and bind-dyndb-ldap packages are you using? $ rpm >> -q bind bind-dyndb-ldap > bind-9.9.4-29.el7_2.2.x86_64 bind-dyndb-ldap-8.0-1.el7.x86_64 >> >> I'm not sure how exactly the logging magic in BIND works so I would >> recommend you to to run BIND using command: $ named -g -u named and >> check output in the console to see if it contains line like >> 'bind-dyndb-ldap version 8.0 compiled at 16:09:02 Jan 20 2016, >> compiler 5.3.1 20151207 (Red Hat 5.3.1-2)' > I get nothing like that. Here is the output I get from running named: > https://gist.github.com/ctlajoie/0ed4e97e72aec3172a8d Oh, wait, it seems that you are using views! Generally we do not test bind-dyndb-ldap with views so there be dragons. Could you share your named.conf with us? If you do not want to send it to mailing list feel free to send it to me privately. My GPG key is attached just for the case you wish to encrypt it. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x1CB2BB71.asc Type: application/pgp-keys Size: 3607 bytes Desc: not available URL: From jhrozek at redhat.com Fri Feb 12 09:59:03 2016 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 12 Feb 2016 10:59:03 +0100 Subject: [Freeipa-users] ID Views without AD In-Reply-To: References: <20160210081945.GR12787@redhat.com> <20160211082137.GA28898@redhat.com> Message-ID: <20160212095903.GR29883@hendrix.redhat.com> On Thu, Feb 11, 2016 at 11:17:01AM +0000, Mike Kelly wrote: > On Thu, Feb 11, 2016 at 3:21 AM Alexander Bokovoy > wrote: > > > On Wed, 10 Feb 2016, Mike Kelly wrote: > > >On Wed, Feb 10, 2016 at 3:19 AM Alexander Bokovoy > > >wrote: > > > > > >> On Wed, 10 Feb 2016, Mike Kelly wrote: > > >> > > >> >Is there some extra logging I can turn on to see why this ID View isn't > > >> >being applied like I would expect? Or perhaps some extra bit of > > >> >configuration I missed? > > >> Level 7 or 9 debug logs in SSSD on the client might help. > > >> > > > > > >Thanks. > > > > > >Here's what looks like the relevant bits in /var/log/sssd/sssd_nss.log, > > >after I ran `sss_cache -E ; id pioto`: > > Please provide content of sssd_.log, this is where the actual > > work is done when user information is obtained and processed. > > sssd_nss.log is merely a requestor. > > > > Thanks. Here's what is hopefully the relevant lines: I'm sorry, but these logs only capture how the original entry was searched, not the overrides. Can you capture the full logs since the sssd startup? Also please make sure the cache was invalidated prior to the request with sss_cache -E. From wdh at dds.nl Fri Feb 12 11:15:25 2016 From: wdh at dds.nl (wdh at dds.nl) Date: Fri, 12 Feb 2016 12:15:25 +0100 Subject: [Freeipa-users] Active Directory Trust = filter users In-Reply-To: <20160210124646.GE28065@redhat.com> References: <56B9C666.9000302@dds.nl> <20160210084228.GY29883@hendrix.redhat.com> <56BB2B30.108@dds.nl> <20160210124646.GE28065@redhat.com> Message-ID: <6071ced0e74ac185b5819d96d898cd9d@dds.nl> Hi all, Yes, you can filter out certain SIDs--> I tried, but cannot get it to work. For example, I don't need "Domain Users": Found out the SID by: [root at suacri10103 ~]# getent group domain\ users at ad.example.org domain users at example.org:*:1012600513:someuser at ad.example.org [root at suacri10103 ~]# ldbsearch -H /var/lib/sss/db/cache_ipa.ad%s/example.org.ldb gidNumber=1012600513 | grep objectSIDString asq: Unable to register control with rootdse! objectSIDString: S-1-5-21-1447349426-2906170142-3196411423-513 and put the SID in the blacklist; yes it is blacklisted: admin01 at ipa ~]$ ipa trust-show ad.example.com --all | grep "SID blacklist incoming" SID blacklist incoming: S-1-5-20, S-1-5-21-1447349426-2906170142-3196411423-513, S-1-5-3, S-1-5-2, S-1-5-1, S-1-5-7, S-1-5-6, S-1-5-5, S-1-5-4, S-1-5-9, S-1-5-8, S-1-5-17, S-1-5-16, S-1-5-15, S-1-5-14, S-1-5-13, S-1-5-12, S-1-5-11, S-1-5-10, S-1-3, S-1-2, S-1-1, S-1-0, S-1-5-19, S-1-5-18 However, the group is still there if I do a n "id someuser at ad.example.com" (yep, whiped cache, restarted ipa etc.) Shouldn't the group be disappeared since the SID is blacklisted...? Winny Alexander Bokovoy schreef op 10-02-2016 13:46: > On Wed, 10 Feb 2016, Winfried de Heiden wrote: >> Hi all, >> >> "hy are you concerned about this in the first place? " >> >> It started from a practical point of view: if one is using the DC of >> the Office >> Automation, Ad users will get all sorts of AD groups I am never going >> to use. >> so why do I want to see them anyway? My screen get's a bit messy as >> for >> "user at ad.example.com"? when this user belongs tot 25 or something >> groups... It >> would be nice to hide these... >> >> Can I blacklist some of the groups? (Trusts? --> ad.example.com --> >> Settings) >> by using the SID? > Yes, you can filter out certain SIDs at the KDC side by using settings > of the trust. Theoretically, SSSD would need to remove the group > membership for groups not existing in the MS-PAC. From abokovoy at redhat.com Fri Feb 12 11:29:47 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 12 Feb 2016 13:29:47 +0200 Subject: [Freeipa-users] Active Directory Trust = filter users In-Reply-To: <6071ced0e74ac185b5819d96d898cd9d@dds.nl> References: <56B9C666.9000302@dds.nl> <20160210084228.GY29883@hendrix.redhat.com> <56BB2B30.108@dds.nl> <20160210124646.GE28065@redhat.com> <6071ced0e74ac185b5819d96d898cd9d@dds.nl> Message-ID: <20160212112947.GG28898@redhat.com> On Fri, 12 Feb 2016, wdh at dds.nl wrote: >Hi all, > >Yes, you can filter out certain SIDs--> I tried, but cannot get it to >work. For example, I don't need "Domain Users": > >Found out the SID by: > >[root at suacri10103 ~]# getent group domain\ users at ad.example.org >domain users at example.org:*:1012600513:someuser at ad.example.org >[root at suacri10103 ~]# ldbsearch -H >/var/lib/sss/db/cache_ipa.ad%s/example.org.ldb gidNumber=1012600513 | >grep objectSIDString >asq: Unable to register control with rootdse! >objectSIDString: S-1-5-21-1447349426-2906170142-3196411423-513 > >and put the SID in the blacklist; yes it is blacklisted: > >admin01 at ipa ~]$ ipa trust-show ad.example.com --all | grep "SID >blacklist incoming" > SID blacklist incoming: S-1-5-20, >S-1-5-21-1447349426-2906170142-3196411423-513, S-1-5-3, S-1-5-2, >S-1-5-1, S-1-5-7, S-1-5-6, S-1-5-5, S-1-5-4, S-1-5-9, S-1-5-8, >S-1-5-17, S-1-5-16, S-1-5-15, S-1-5-14, S-1-5-13, S-1-5-12, S-1-5-11, >S-1-5-10, S-1-3, S-1-2, S-1-1, S-1-0, S-1-5-19, S-1-5-18 > >However, the group is still there if I do a n "id >someuser at ad.example.com" (yep, whiped cache, restarted ipa etc.) > >Shouldn't the group be disappeared since the SID is blacklisted...? Only from Kerberos tickets. I don't think SSSD in ipa_server_mode consults this list. Instead, when AD users logins with Kerberos ticket, the resulting ticket already has blacklisted SIDs filtered out by IPA KDC and SSSD will see that these tickets' MS-PAC doesn't have additional groups in it. -- / Alexander Bokovoy From pdomineaux at gmail.com Fri Feb 12 13:17:10 2016 From: pdomineaux at gmail.com (Domineaux Philippe) Date: Fri, 12 Feb 2016 14:17:10 +0100 Subject: [Freeipa-users] Fwd: nfsnobody with ubuntu 14.04 in trusted relationship with AD In-Reply-To: References: Message-ID: Hello, Did you received my last post? Maybe I've missed something because I can't see my post on the forum. ---------- Forwarded message ---------- From: Domineaux Philippe Date: 2016-02-10 18:03 GMT+01:00 Subject: [Freeipa-users] nfsnobody with ubuntu 14.04 in trusted relationship with AD To: freeipa-users at redhat.com Hello all, I have several virtual machines ( on virtualbox ) running freeipa-client and freeipa-server in a trust domain relationship with an Active Directory (AD) also on a virtual machine. Here is the details of the machines : ### Freeipa-server : - Centos 7.2 - ipa-server-install 4.2.0 ### client1 : - centos 7.2 - ipa-client-install 4.2.0 ### Nfs-server : - centos 7.2 - ipa-client-install 4.2.0 ### Client2 : - Ubuntu 14.04 (trusty) - ipa-client-install 3.3.4 also try the unofficial 4.0.x backport ( https://launchpad.net/~freeipa/+archive/ubuntu/4.0) Everything works fine except for the ubuntu client and the nfs mount : - I can mount the share using ""-o sec=krb5" option but the owner of the folders is nobody. It seems just a display error because the permissions on the files are good. user1 cannot write on the folder of user2 and vice versa. If I mount without kinit I get this (syslog ubuntu client): Feb 10 17:09:38 client2 rpc.idmapd[417]: New client: 0 Feb 10 17:09:38 client2 kernel: [ 2709.796390] NFS: Registering the id_resolver key type Feb 10 17:09:38 client2 kernel: [ 2709.796399] Key type id_resolver registered Feb 10 17:09:38 client2 kernel: [ 2709.796399] Key type id_legacy registered Feb 10 17:09:38 client2 rpc.idmapd[417]: Opened /run/rpc_pipefs/nfs/clnt0/idmap Feb 10 17:09:38 client2 rpc.idmapd[417]: New client: 1 Feb 10 17:09:38 client2 nfsidmap[2714]: key: 0x261c251d type: uid value: root at ipa.local timeout 600 Feb 10 17:09:38 client2 nfsidmap[2714]: nfs4_name_to_uid: calling nsswitch->name_to_uid Feb 10 17:09:38 client2 nfsidmap[2714]: nss_getpwnam: name 'root at ipa.local' domain 'ipa.local': resulting localname 'root' Feb 10 17:09:38 client2 nfsidmap[2714]: nfs4_name_to_uid: nsswitch->name_to_uid returned 0 Feb 10 17:09:38 client2 nfsidmap[2714]: nfs4_name_to_uid: final return value is 0 Feb 10 17:09:38 client2 nfsidmap[2716]: key: 0x314352bb type: gid value: root at ipa.local timeout 600 Feb 10 17:09:38 client2 nfsidmap[2716]: nfs4_name_to_gid: calling nsswitch->name_to_gid Feb 10 17:09:38 client2 nfsidmap[2716]: nfs4_name_to_gid: nsswitch->name_to_gid returned 0 Feb 10 17:09:38 client2 nfsidmap[2716]: nfs4_name_to_gid: final return value is 0 Feb 10 17:09:55 client2 nfsidmap[2722]: key: 0x29600d2b type: uid value: adipa at domino.local@ipa.local timeout 600 Feb 10 17:09:55 client2 nfsidmap[2722]: nfs4_name_to_uid: calling nsswitch->name_to_uid Feb 10 17:09:55 client2 nfsidmap[2722]: nss_getpwnam: name 'adipa at domino.local@ipa.local' domain 'ipa.local': resulting localname '(null)' Feb 10 17:09:55 client2 nfsidmap[2722]: nss_getpwnam: name 'adipa at domino.local@ipa.local' does not map into domain 'ipa.local' Feb 10 17:09:55 client2 nfsidmap[2722]: nfs4_name_to_uid: nsswitch->name_to_uid returned -22 Feb 10 17:09:55 client2 nfsidmap[2722]: nfs4_name_to_uid: final return value is -22 Feb 10 17:09:55 client2 nfsidmap[2722]: nfs4_name_to_uid: calling nsswitch->name_to_uid Feb 10 17:09:55 client2 nfsidmap[2722]: nss_getpwnam: name 'nobody at ipa.local' domain 'ipa.local': resulting localname 'nobody' Feb 10 17:09:55 client2 nfsidmap[2722]: nfs4_name_to_uid: nsswitch->name_to_uid returned 0 Feb 10 17:09:55 client2 nfsidmap[2722]: nfs4_name_to_uid: final return value is 0 Feb 10 17:09:55 client2 nfsidmap[2724]: key: 0x398852c2 type: gid value: posix_users at domino.local@ipa.local timeout 600 Feb 10 17:09:55 client2 nfsidmap[2724]: nfs4_name_to_gid: calling nsswitch->name_to_gid Feb 10 17:09:55 client2 nfsidmap[2724]: nfs4_name_to_gid: nsswitch->name_to_gid returned -22 Feb 10 17:09:55 client2 nfsidmap[2724]: nfs4_name_to_gid: final return value is -22 Feb 10 17:09:55 client2 nfsidmap[2724]: nfs4_name_to_gid: calling nsswitch->name_to_gid Feb 10 17:09:56 client2 nfsidmap[2724]: nfs4_name_to_gid: nsswitch->name_to_gid returned -2 Feb 10 17:09:56 client2 nfsidmap[2724]: nfs4_name_to_gid: final return value is -2 But if I mount with let's say kinit admin no logs in the syslog file of the ubuntu client. Another thing is, when mounting on both clients (ubuntu and centos), the NFS server output : "nfsserver gssproxy: gssproxy[659]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure. Minor code may provide more information, No credentials cache found" But it works for the centos but not for the ubuntu. ### NFS server logs for client 2 (Ubuntu) : Feb 10 17:30:01 nfsserver systemd: Created slice user-0.slice. Feb 10 17:30:01 nfsserver systemd: Starting user-0.slice. Feb 10 17:30:01 nfsserver systemd: Started Session 14 of user root. Feb 10 17:30:01 nfsserver systemd: Starting Session 14 of user root. Feb 10 17:30:01 nfsserver systemd: Removed slice user-0.slice. Feb 10 17:30:01 nfsserver systemd: Stopping user-0.slice. Feb 10 17:30:21 nfsserver rpc.gssd[756]: Closing 'gssd' pipe for /var/lib/nfs/rpc_pipefs/nfsd4_cb/clnt5 Feb 10 17:30:21 nfsserver rpc.gssd[756]: destroying client /var/lib/nfs/rpc_pipefs/nfsd4_cb/clnt5 Feb 10 17:30:21 nfsserver rpc.gssd[756]: handling gssd upcall (/var/lib/nfs/rpc_pipefs/nfsd4_cb/clnt6) Feb 10 17:30:21 nfsserver rpc.gssd[756]: handle_gssd_upcall: 'mech=krb5 uid=0 target=host at client2.ipa.local service=nfs enctypes=18,17,16,23,3,1,2 ' Feb 10 17:30:21 nfsserver rpc.gssd[756]: handling krb5 upcall (/var/lib/nfs/rpc_pipefs/nfsd4_cb/clnt6) Feb 10 17:30:21 nfsserver rpc.gssd[756]: process_krb5_upcall: service is 'nfs' Feb 10 17:30:21 nfsserver rpc.gssd[756]: krb5_use_machine_creds: uid 0 tgtname host at client2.ipa.local Feb 10 17:30:21 nfsserver rpc.gssd[756]: Full hostname for 'client2.ipa.local' is 'client2.ipa.local' Feb 10 17:30:21 nfsserver rpc.gssd[756]: Full hostname for 'nfsserver.ipa.local' is 'nfsserver.ipa.local' Feb 10 17:30:21 nfsserver rpc.gssd[756]: Success getting keytab entry for 'nfs/nfsserver.ipa.local at IPA.LOCAL' Feb 10 17:30:21 nfsserver rpc.gssd[756]: INFO: Credentials in CC 'FILE:/tmp/krb5ccmachine_IPA.LOCAL' are good until 1455202622 Feb 10 17:30:21 nfsserver rpc.gssd[756]: INFO: Credentials in CC 'FILE:/tmp/krb5ccmachine_IPA.LOCAL' are good until 1455202622 Feb 10 17:30:21 nfsserver rpc.gssd[756]: using FILE:/tmp/krb5ccmachine_IPA.LOCAL as credentials cache for machine creds Feb 10 17:30:21 nfsserver rpc.gssd[756]: using environment variable to select krb5 ccache FILE:/tmp/krb5ccmachine_IPA.LOCAL Feb 10 17:30:21 nfsserver gssproxy: gssproxy[659]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure. Minor code may provide more information, No credentials cache found Feb 10 17:30:21 nfsserver rpc.gssd[756]: creating tcp client for server client2.ipa.local Feb 10 17:30:21 nfsserver rpc.gssd[756]: DEBUG: port already set to 50270 Feb 10 17:30:21 nfsserver rpc.gssd[756]: creating context with server host at client2.ipa.local Feb 10 17:30:21 nfsserver rpc.gssd[756]: WARNING: Failed to create krb5 context for user with uid 0 for server host at client2.ipa.local Feb 10 17:30:21 nfsserver rpc.gssd[756]: WARNING: Failed to create machine krb5context with cred cache FILE:/tmp/krb5ccmachine_IPA.LOCAL for server client2.ipa.local Feb 10 17:30:21 nfsserver rpc.gssd[756]: WARNING: Machine cache prematurelyexpired or corrupted trying torecreate cache for server client2.ipa.local Feb 10 17:30:21 nfsserver rpc.gssd[756]: Full hostname for 'client2.ipa.local' is 'client2.ipa.local' Feb 10 17:30:21 nfsserver rpc.gssd[756]: Full hostname for 'nfsserver.ipa.local' is 'nfsserver.ipa.local' Feb 10 17:30:21 nfsserver rpc.gssd[756]: Success getting keytab entry for 'nfs/nfsserver.ipa.local at IPA.LOCAL' Feb 10 17:30:21 nfsserver rpc.gssd[756]: INFO: Credentials in CC 'FILE:/tmp/krb5ccmachine_IPA.LOCAL' are good until 1455202622 Feb 10 17:30:21 nfsserver rpc.gssd[756]: INFO: Credentials in CC 'FILE:/tmp/krb5ccmachine_IPA.LOCAL' are good until 1455202622 Feb 10 17:30:21 nfsserver rpc.gssd[756]: using FILE:/tmp/krb5ccmachine_IPA.LOCAL as credentials cache for machine creds Feb 10 17:30:21 nfsserver rpc.gssd[756]: using environment variable to select krb5 ccache FILE:/tmp/krb5ccmachine_IPA.LOCAL Feb 10 17:30:21 nfsserver rpc.gssd[756]: creating tcp client for server client2.ipa.local Feb 10 17:30:21 nfsserver rpc.gssd[756]: DEBUG: port already set to 50270 Feb 10 17:30:21 nfsserver rpc.gssd[756]: creating context with server host at client2.ipa.local Feb 10 17:30:21 nfsserver rpc.gssd[756]: WARNING: Failed to create krb5 context for user with uid 0 for server host at client2.ipa.local Feb 10 17:30:21 nfsserver rpc.gssd[756]: WARNING: Failed to create machine krb5context with cred cache FILE:/tmp/krb5ccmachine_IPA.LOCAL for server client2.ipa.local Feb 10 17:30:21 nfsserver gssproxy: gssproxy[659]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure. Minor code may provide more information, No credentials cache found Feb 10 17:30:21 nfsserver rpc.gssd[756]: WARNING: Failed to create machinekrb5 context with any credentialscache for server client2.ipa.local Feb 10 17:30:21 nfsserver rpc.gssd[756]: doing error downcall ### NFS server logs for client 1 (centos 7) : Feb 10 17:34:00 nfsserver rpc.gssd[756]: Closing 'gssd' pipe for /var/lib/nfs/rpc_pipefs/nfsd4_cb/clnt0 Feb 10 17:34:00 nfsserver rpc.gssd[756]: destroying client /var/lib/nfs/rpc_pipefs/nfsd4_cb/clnt0 Feb 10 17:34:00 nfsserver rpc.gssd[756]: handling gssd upcall (/var/lib/nfs/rpc_pipefs/nfsd4_cb/clnt8) Feb 10 17:34:00 nfsserver rpc.gssd[756]: handle_gssd_upcall: 'mech=krb5 uid=0 target=nfs at client1.ipa.local service=nfs enctypes=18,17,16,23,3,1,2 ' Feb 10 17:34:00 nfsserver rpc.gssd[756]: handling krb5 upcall (/var/lib/nfs/rpc_pipefs/nfsd4_cb/clnt8) Feb 10 17:34:00 nfsserver rpc.gssd[756]: process_krb5_upcall: service is 'nfs' Feb 10 17:34:00 nfsserver rpc.gssd[756]: krb5_use_machine_creds: uid 0 tgtname nfs at client1.ipa.local Feb 10 17:34:00 nfsserver rpc.gssd[756]: Full hostname for 'client1.ipa.local' is 'client1.ipa.local' Feb 10 17:34:00 nfsserver rpc.gssd[756]: Full hostname for 'nfsserver.ipa.local' is 'nfsserver.ipa.local' Feb 10 17:34:00 nfsserver rpc.gssd[756]: Success getting keytab entry for 'nfs/nfsserver.ipa.local at IPA.LOCAL' Feb 10 17:34:00 nfsserver rpc.gssd[756]: INFO: Credentials in CC 'FILE:/tmp/krb5ccmachine_IPA.LOCAL' are good until 1455202622 Feb 10 17:34:00 nfsserver rpc.gssd[756]: INFO: Credentials in CC 'FILE:/tmp/krb5ccmachine_IPA.LOCAL' are good until 1455202622 Feb 10 17:34:00 nfsserver rpc.gssd[756]: using FILE:/tmp/krb5ccmachine_IPA.LOCAL as credentials cache for machine creds Feb 10 17:34:00 nfsserver rpc.gssd[756]: using environment variable to select krb5 ccache FILE:/tmp/krb5ccmachine_IPA.LOCAL Feb 10 17:34:00 nfsserver rpc.gssd[756]: creating tcp client for server client1.ipa.local Feb 10 17:34:00 nfsserver rpc.gssd[756]: DEBUG: port already set to 42165 Feb 10 17:34:00 nfsserver rpc.gssd[756]: WARNING: can't create tcp rpc_clnt to server client1.ipa.local for user with uid 0: RPC: Remote system error - No route to host Feb 10 17:34:00 nfsserver rpc.gssd[756]: WARNING: Failed to create machine krb5context with cred cache FILE:/tmp/krb5ccmachine_IPA.LOCAL for server client1.ipa.local Feb 10 17:34:00 nfsserver rpc.gssd[756]: WARNING: Machine cache prematurelyexpired or corrupted trying torecreate cache for server client1.ipa.local Feb 10 17:34:00 nfsserver gssproxy: gssproxy[659]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure. Minor code may provide more information, No credentials cache found Feb 10 17:34:00 nfsserver rpc.gssd[756]: Full hostname for 'client1.ipa.local' is 'client1.ipa.local' Feb 10 17:34:00 nfsserver rpc.gssd[756]: Full hostname for 'nfsserver.ipa.local' is 'nfsserver.ipa.local' Feb 10 17:34:00 nfsserver rpc.gssd[756]: Success getting keytab entry for 'nfs/nfsserver.ipa.local at IPA.LOCAL' Feb 10 17:34:00 nfsserver rpc.gssd[756]: INFO: Credentials in CC 'FILE:/tmp/krb5ccmachine_IPA.LOCAL' are good until 1455202622 Feb 10 17:34:00 nfsserver rpc.gssd[756]: INFO: Credentials in CC 'FILE:/tmp/krb5ccmachine_IPA.LOCAL' are good until 1455202622 Feb 10 17:34:00 nfsserver rpc.gssd[756]: using FILE:/tmp/krb5ccmachine_IPA.LOCAL as credentials cache for machine creds Feb 10 17:34:00 nfsserver rpc.gssd[756]: using environment variable to select krb5 ccache FILE:/tmp/krb5ccmachine_IPA.LOCAL Feb 10 17:34:00 nfsserver rpc.gssd[756]: creating tcp client for server client1.ipa.local Feb 10 17:34:00 nfsserver rpc.gssd[756]: DEBUG: port already set to 42165 Feb 10 17:34:00 nfsserver gssproxy: gssproxy[659]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure. Minor code may provide more information, No credentials cache found Feb 10 17:34:00 nfsserver rpc.gssd[756]: WARNING: can't create tcp rpc_clnt to server client1.ipa.local for user with uid 0: RPC: Remote system error - No route to host Feb 10 17:34:00 nfsserver rpc.gssd[756]: WARNING: Failed to create machine krb5context with cred cache FILE:/tmp/krb5ccmachine_IPA.LOCAL for server client1.ipa.local Feb 10 17:34:00 nfsserver rpc.gssd[756]: WARNING: Failed to create machinekrb5 context with any credentialscache for server client1.ipa.local Feb 10 17:34:00 nfsserver rpc.gssd[756]: doing error downcall So my question is : How can I deal with this display problem? -------------- next part -------------- An HTML attachment was scrubbed... URL: From filip at pytloun.cz Fri Feb 12 14:06:13 2016 From: filip at pytloun.cz (Filip Pytloun) Date: Fri, 12 Feb 2016 15:06:13 +0100 Subject: [Freeipa-users] Failed to setup replica, slapi_ldap_bind fails In-Reply-To: <20160208170505.GE4331@eru> References: <20160208170505.GE4331@eru> Message-ID: <20160212140613.GC16168@eru> Hello, even when enabling replication logging, I get nothing useful in logs: [12/Feb/2016:14:57:00 +0100] NSMMReplicationPlugin - agmt="cn=meToidm02.tcpcloud.eu" (idm02:389): Trying secure startTLS slapi_ldap_init_ext [12/Feb/2016:14:57:00 +0100] NSMMReplicationPlugin - agmt="cn=meToidm02.tcpcloud.eu" (idm02:389): binddn = cn=replication manager,cn=config, passwd = {AES-some_encrypted_password [12/Feb/2016:14:57:01 +0100] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) [12/Feb/2016:14:57:01 +0100] NSMMReplicationPlugin - agmt="cn=meToidm02.tcpcloud.eu" (idm02:389): Replication bind with SIMPLE auth failed: LDAP error -11 (Connect error) ((unknown error code)) [12/Feb/2016:14:57:01 +0100] NSMMReplicationPlugin - agmt="cn=meToidm02.tcpcloud.eu" (idm02:389): Disconnected from the consumer But I can bind just fine manually: ldapsearch -D "cn=replication manager,cn=config" -w some_password -b cn=config -h idm02 -ZZ I am starting to be clueless, nobody has an idea what could be wrong? - DNS including PTR records are set up fine - /etc/hosts is setup fine - conncheck passes fine between nodes - I can bind manually just fine On 2016/02/08 18:05, Filip Pytloun wrote: > Hello, > > I have a weird issue setting up FreeIPA replica. Conncheck passes fine > but at the end of ipa-replica-install I always get following error: > > slapi_ldap_bind -Error: could not send startTLS request: error -11 > (Connect error) errno 0 (Success) > > on both master and replica without any further explanation in logs. > > /etc/ldap.conf is correctly setup before ipa-replica-install and IPA CA > certificate is installed in system CA bundle so TLS should work just > fine. > > Also I can manually connect just fine from replica to master and back so > it's not a network or LDAP client issue. > > Replica agreement looks like this: http://pastebin.com/FT3p3KUk > > freeipa-server 4.1.4 > 389-ds 1.3.4.5 > > Has anyone idea where to look at? > > Filip -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From lkrispen at redhat.com Fri Feb 12 14:22:07 2016 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Fri, 12 Feb 2016 15:22:07 +0100 Subject: [Freeipa-users] Failed to setup replica, slapi_ldap_bind fails In-Reply-To: <20160212140613.GC16168@eru> References: <20160208170505.GE4331@eru> <20160212140613.GC16168@eru> Message-ID: <56BDEA8F.2040506@redhat.com> On 02/12/2016 03:06 PM, Filip Pytloun wrote: > Hello, > > even when enabling replication logging, I get nothing useful in logs: > > [12/Feb/2016:14:57:00 +0100] NSMMReplicationPlugin - agmt="cn=meToidm02.tcpcloud.eu" (idm02:389): Trying secure startTLS slapi_ldap_init_ext > [12/Feb/2016:14:57:00 +0100] NSMMReplicationPlugin - agmt="cn=meToidm02.tcpcloud.eu" (idm02:389): binddn = cn=replication manager,cn=config, passwd = {AES-some_encrypted_password > [12/Feb/2016:14:57:01 +0100] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) > [12/Feb/2016:14:57:01 +0100] NSMMReplicationPlugin - agmt="cn=meToidm02.tcpcloud.eu" (idm02:389): Replication bind with SIMPLE auth failed: LDAP error -11 (Connect error) ((unknown error code)) > [12/Feb/2016:14:57:01 +0100] NSMMReplicationPlugin - agmt="cn=meToidm02.tcpcloud.eu" (idm02:389): Disconnected from the consumer what is in the access and error logs of idm02 for this time ? > > But I can bind just fine manually: > > ldapsearch -D "cn=replication manager,cn=config" -w some_password -b cn=config -h idm02 -ZZ > > I am starting to be clueless, nobody has an idea what could be wrong? > > - DNS including PTR records are set up fine > - /etc/hosts is setup fine > - conncheck passes fine between nodes > - I can bind manually just fine > > On 2016/02/08 18:05, Filip Pytloun wrote: >> Hello, >> >> I have a weird issue setting up FreeIPA replica. Conncheck passes fine >> but at the end of ipa-replica-install I always get following error: >> >> slapi_ldap_bind -Error: could not send startTLS request: error -11 >> (Connect error) errno 0 (Success) >> >> on both master and replica without any further explanation in logs. >> >> /etc/ldap.conf is correctly setup before ipa-replica-install and IPA CA >> certificate is installed in system CA bundle so TLS should work just >> fine. >> >> Also I can manually connect just fine from replica to master and back so >> it's not a network or LDAP client issue. >> >> Replica agreement looks like this: http://pastebin.com/FT3p3KUk >> >> freeipa-server 4.1.4 >> 389-ds 1.3.4.5 >> >> Has anyone idea where to look at? >> >> Filip > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From filip at pytloun.cz Fri Feb 12 14:35:03 2016 From: filip at pytloun.cz (Filip Pytloun) Date: Fri, 12 Feb 2016 15:35:03 +0100 Subject: [Freeipa-users] Failed to setup replica, slapi_ldap_bind fails In-Reply-To: <56BDEA8F.2040506@redhat.com> References: <20160208170505.GE4331@eru> <20160212140613.GC16168@eru> <56BDEA8F.2040506@redhat.com> Message-ID: <20160212143503.GD16168@eru> It's the same as for idm01: [12/Feb/2016:15:24:26 +0100] NSMMReplicationPlugin - agmt="cn=meToidm01.tcpcloud.eu" (idm01:389): Replication bind with SIMPLE auth failed: LDAP error -11 (Connect error) ((unknown error code)) [12/Feb/2016:15:24:27 +0100] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) In access logs I can't read much interesting, just that TLS connection happened from idm01: [12/Feb/2016:15:33:11 +0100] conn=14 fd=64 slot=64 connection from 185.22.97.19 to 172.10.10.192 [12/Feb/2016:15:33:11 +0100] conn=14 op=0 EXT oid="1.3.6.1.4.1.1466.20037" name="startTLS" [12/Feb/2016:15:33:11 +0100] conn=14 op=0 RESULT err=0 tag=120 nentries=0 etime=0 [12/Feb/2016:15:33:11 +0100] conn=14 TLS1.2 128-bit AES-GCM [12/Feb/2016:15:33:11 +0100] conn=14 op=-1 fd=64 closed - B1 [12/Feb/2016:15:33:59 +0100] conn=15 fd=64 slot=64 connection from 185.22.97.19 to 172.10.10.192 [12/Feb/2016:15:33:59 +0100] conn=15 op=0 EXT oid="1.3.6.1.4.1.1466.20037" name="startTLS" [12/Feb/2016:15:33:59 +0100] conn=15 op=0 RESULT err=0 tag=120 nentries=0 etime=0 [12/Feb/2016:15:34:00 +0100] conn=15 TLS1.2 128-bit AES-GCM [12/Feb/2016:15:34:00 +0100] conn=15 op=-1 fd=64 closed - B1 On 2016/02/12 15:22, Ludwig Krispenz wrote: > > On 02/12/2016 03:06 PM, Filip Pytloun wrote: > >Hello, > > > >even when enabling replication logging, I get nothing useful in logs: > > > >[12/Feb/2016:14:57:00 +0100] NSMMReplicationPlugin - agmt="cn=meToidm02.tcpcloud.eu" (idm02:389): Trying secure startTLS slapi_ldap_init_ext > >[12/Feb/2016:14:57:00 +0100] NSMMReplicationPlugin - agmt="cn=meToidm02.tcpcloud.eu" (idm02:389): binddn = cn=replication manager,cn=config, passwd = {AES-some_encrypted_password > >[12/Feb/2016:14:57:01 +0100] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) > >[12/Feb/2016:14:57:01 +0100] NSMMReplicationPlugin - agmt="cn=meToidm02.tcpcloud.eu" (idm02:389): Replication bind with SIMPLE auth failed: LDAP error -11 (Connect error) ((unknown error code)) > >[12/Feb/2016:14:57:01 +0100] NSMMReplicationPlugin - agmt="cn=meToidm02.tcpcloud.eu" (idm02:389): Disconnected from the consumer > what is in the access and error logs of idm02 for this time ? > > > >But I can bind just fine manually: > > > >ldapsearch -D "cn=replication manager,cn=config" -w some_password -b cn=config -h idm02 -ZZ > > > >I am starting to be clueless, nobody has an idea what could be wrong? > > > >- DNS including PTR records are set up fine > >- /etc/hosts is setup fine > >- conncheck passes fine between nodes > >- I can bind manually just fine > > > >On 2016/02/08 18:05, Filip Pytloun wrote: > >>Hello, > >> > >>I have a weird issue setting up FreeIPA replica. Conncheck passes fine > >>but at the end of ipa-replica-install I always get following error: > >> > >>slapi_ldap_bind -Error: could not send startTLS request: error -11 > >>(Connect error) errno 0 (Success) > >> > >>on both master and replica without any further explanation in logs. > >> > >>/etc/ldap.conf is correctly setup before ipa-replica-install and IPA CA > >>certificate is installed in system CA bundle so TLS should work just > >>fine. > >> > >>Also I can manually connect just fine from replica to master and back so > >>it's not a network or LDAP client issue. > >> > >>Replica agreement looks like this: http://pastebin.com/FT3p3KUk > >> > >>freeipa-server 4.1.4 > >>389-ds 1.3.4.5 > >> > >>Has anyone idea where to look at? > >> > >>Filip > > > > > > > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From michael.rainey.ctr at nrlssc.navy.mil Fri Feb 12 15:33:01 2016 From: michael.rainey.ctr at nrlssc.navy.mil (Michael Rainey (Contractor)) Date: Fri, 12 Feb 2016 09:33:01 -0600 Subject: [Freeipa-users] smart cards caintaining multiple certificates In-Reply-To: <20160211084615.GF12933@p.redhat.com> References: <20160211084615.GF12933@p.redhat.com> Message-ID: I recently discovered something that may be a little off in the SSSD Design Docs . When using the certutil command shown below to dump the PEM encoded certificates from the smart card. The output is not the certificate which is being read by the SSSD daemon. ( I hope the terminology is correct.) * certutil -L -d /etc/pki/nssdb -n 'Certificate Nick-Name' -a | grep -v -- '----' |tr -d '[\n\r]' *When the command is run I am prompted for my pin and after my pin is entered, what I believe is returned are the private keys on the card. After conducting some further research and testing, I eventually settled on the following command to extract the correct public keys. *pkcs15-tool --read-certificate | grep -v -- '----' | tr -d '[\n\r]' * I don't know if this has been noted in the past, but I do feel it is important to mention in either case. *Thanks, Michael Rainey* On 02/11/2016 02:46 AM, Sumit Bose wrote: > On Wed, Feb 10, 2016 at 04:05:20PM -0600, Michael Rainey (Contractor) wrote: >> Greetings, >> >> I'm curious as to how IPA handles smart cards containing multiple >> certificates. When I follow the steps listed at >> https://fedorahosted.org/sssd/wiki/DesignDocs/SmartcardAuthenticationStep1 >> when installing my certificate, I notice the certutil command dumps all >> installed certificates, and dumps the certificates in a different order >> depending on which certificate is selected. When the server tries to match >> a certificate does it compare all certificates as one long continuous >> string, or does it compare one certificate at a time? I'm curious if this >> presents a problem for the end-user or has this problem been addressed? > SSSD looks for valid certificates which have client authentication set > in the extended key usage. If multiple certificate are found currently > just the "first" one is used. More option to configure the certificate > selection are planned for the next release. > > If you have a specific selection of certificates on the Smartcards you > use which currently do not work as expected with SSSD feel free to send > me a dump of the certificates on the card or a description so that I can > see what kind of configuration options might be needed to select the > right one. If you prefer you can send this data to me directly. > > HTH > > bye, > Sumit > >> -- >> *Michael Rainey* >> -- >> Manage your subscription for the Freeipa-users mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-users >> Go to http://freeipa.org for more info on the project -------------- next part -------------- An HTML attachment was scrubbed... URL: From lkrispen at redhat.com Fri Feb 12 15:57:21 2016 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Fri, 12 Feb 2016 16:57:21 +0100 Subject: [Freeipa-users] Failed to setup replica, slapi_ldap_bind fails In-Reply-To: <20160212143503.GD16168@eru> References: <20160208170505.GE4331@eru> <20160212140613.GC16168@eru> <56BDEA8F.2040506@redhat.com> <20160212143503.GD16168@eru> Message-ID: <56BE00E1.5080303@redhat.com> On 02/12/2016 03:35 PM, Filip Pytloun wrote: > It's the same as for idm01: > > [12/Feb/2016:15:24:26 +0100] NSMMReplicationPlugin - agmt="cn=meToidm01.tcpcloud.eu" (idm01:389): Replication bind with SIMPLE auth failed: LDAP error -11 (Connect error) ((unknown error code)) > [12/Feb/2016:15:24:27 +0100] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) you can get this connect error if the client side cannot verify the cert the server sends, could you check what you have in /etc/openldap/ldap.conf > > In access logs I can't read much interesting, just that TLS connection happened from idm01: > > [12/Feb/2016:15:33:11 +0100] conn=14 fd=64 slot=64 connection from 185.22.97.19 to 172.10.10.192 > [12/Feb/2016:15:33:11 +0100] conn=14 op=0 EXT oid="1.3.6.1.4.1.1466.20037" name="startTLS" > [12/Feb/2016:15:33:11 +0100] conn=14 op=0 RESULT err=0 tag=120 nentries=0 etime=0 > [12/Feb/2016:15:33:11 +0100] conn=14 TLS1.2 128-bit AES-GCM > [12/Feb/2016:15:33:11 +0100] conn=14 op=-1 fd=64 closed - B1 > [12/Feb/2016:15:33:59 +0100] conn=15 fd=64 slot=64 connection from 185.22.97.19 to 172.10.10.192 > [12/Feb/2016:15:33:59 +0100] conn=15 op=0 EXT oid="1.3.6.1.4.1.1466.20037" name="startTLS" > [12/Feb/2016:15:33:59 +0100] conn=15 op=0 RESULT err=0 tag=120 nentries=0 etime=0 > [12/Feb/2016:15:34:00 +0100] conn=15 TLS1.2 128-bit AES-GCM > [12/Feb/2016:15:34:00 +0100] conn=15 op=-1 fd=64 closed - B1 > > On 2016/02/12 15:22, Ludwig Krispenz wrote: >> On 02/12/2016 03:06 PM, Filip Pytloun wrote: >>> Hello, >>> >>> even when enabling replication logging, I get nothing useful in logs: >>> >>> [12/Feb/2016:14:57:00 +0100] NSMMReplicationPlugin - agmt="cn=meToidm02.tcpcloud.eu" (idm02:389): Trying secure startTLS slapi_ldap_init_ext >>> [12/Feb/2016:14:57:00 +0100] NSMMReplicationPlugin - agmt="cn=meToidm02.tcpcloud.eu" (idm02:389): binddn = cn=replication manager,cn=config, passwd = {AES-some_encrypted_password >>> [12/Feb/2016:14:57:01 +0100] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) >>> [12/Feb/2016:14:57:01 +0100] NSMMReplicationPlugin - agmt="cn=meToidm02.tcpcloud.eu" (idm02:389): Replication bind with SIMPLE auth failed: LDAP error -11 (Connect error) ((unknown error code)) >>> [12/Feb/2016:14:57:01 +0100] NSMMReplicationPlugin - agmt="cn=meToidm02.tcpcloud.eu" (idm02:389): Disconnected from the consumer >> what is in the access and error logs of idm02 for this time ? >>> But I can bind just fine manually: >>> >>> ldapsearch -D "cn=replication manager,cn=config" -w some_password -b cn=config -h idm02 -ZZ >>> >>> I am starting to be clueless, nobody has an idea what could be wrong? >>> >>> - DNS including PTR records are set up fine >>> - /etc/hosts is setup fine >>> - conncheck passes fine between nodes >>> - I can bind manually just fine >>> >>> On 2016/02/08 18:05, Filip Pytloun wrote: >>>> Hello, >>>> >>>> I have a weird issue setting up FreeIPA replica. Conncheck passes fine >>>> but at the end of ipa-replica-install I always get following error: >>>> >>>> slapi_ldap_bind -Error: could not send startTLS request: error -11 >>>> (Connect error) errno 0 (Success) >>>> >>>> on both master and replica without any further explanation in logs. >>>> >>>> /etc/ldap.conf is correctly setup before ipa-replica-install and IPA CA >>>> certificate is installed in system CA bundle so TLS should work just >>>> fine. >>>> >>>> Also I can manually connect just fine from replica to master and back so >>>> it's not a network or LDAP client issue. >>>> >>>> Replica agreement looks like this: http://pastebin.com/FT3p3KUk >>>> >>>> freeipa-server 4.1.4 >>>> 389-ds 1.3.4.5 >>>> >>>> Has anyone idea where to look at? >>>> >>>> Filip >>> >>> >> -- >> Manage your subscription for the Freeipa-users mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-users >> Go to http://freeipa.org for more info on the project > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Fri Feb 12 16:04:35 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 12 Feb 2016 11:04:35 -0500 Subject: [Freeipa-users] smart cards caintaining multiple certificates In-Reply-To: References: <20160211084615.GF12933@p.redhat.com> Message-ID: <56BE0293.6040406@redhat.com> Michael Rainey (Contractor) wrote: > I recently discovered something that may be a little off in the SSSD > Design Docs > . > When using the certutil command shown below to dump the PEM encoded > certificates from the smart card. The output is not the certificate > which is being read by the SSSD daemon. ( I hope the terminology is > correct.) > > * certutil -L -d /etc/pki/nssdb -n 'Certificate Nick-Name' -a | grep > -v -- '----' |tr -d '[\n\r]' > > *When the command is run I am prompted for my pin and after my pin is > entered, what I believe is returned are the private keys on the card. -L lists certs, not keys, so I'd be very surprised to find it let the private key go. AFAIK the only way to get a private key out of NSS is using pk12util. What does the PEM header say when you don't grep it out? rob > > After conducting some further research and testing, I eventually settled > on the following command to extract the correct public keys. > *pkcs15-tool --read-certificate | grep -v -- '----' | tr -d > '[\n\r]' > * > > I don't know if this has been noted in the past, but I do feel it is > important to mention in either case. > > *Thanks, > > Michael Rainey* > > On 02/11/2016 02:46 AM, Sumit Bose wrote: >> On Wed, Feb 10, 2016 at 04:05:20PM -0600, Michael Rainey (Contractor) wrote: >>> Greetings, >>> >>> I'm curious as to how IPA handles smart cards containing multiple >>> certificates. When I follow the steps listed at >>> https://fedorahosted.org/sssd/wiki/DesignDocs/SmartcardAuthenticationStep1 >>> when installing my certificate, I notice the certutil command dumps all >>> installed certificates, and dumps the certificates in a different order >>> depending on which certificate is selected. When the server tries to match >>> a certificate does it compare all certificates as one long continuous >>> string, or does it compare one certificate at a time? I'm curious if this >>> presents a problem for the end-user or has this problem been addressed? >> SSSD looks for valid certificates which have client authentication set >> in the extended key usage. If multiple certificate are found currently >> just the "first" one is used. More option to configure the certificate >> selection are planned for the next release. >> >> If you have a specific selection of certificates on the Smartcards you >> use which currently do not work as expected with SSSD feel free to send >> me a dump of the certificates on the card or a description so that I can >> see what kind of configuration options might be needed to select the >> right one. If you prefer you can send this data to me directly. >> >> HTH >> >> bye, >> Sumit >> >>> -- >>> *Michael Rainey* >>> -- >>> Manage your subscription for the Freeipa-users mailing list: >>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> Go to http://freeipa.org for more info on the project > > > From rcritten at redhat.com Fri Feb 12 16:13:33 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 12 Feb 2016 11:13:33 -0500 Subject: [Freeipa-users] IPA 4.2: pki-tomcatd in terrible shape In-Reply-To: References: <56B86DE0.4070909@redhat.com> <7F0EB8FC-8F2F-49D1-A124-562B5B0A55A2@accertify.com> <56B9AA53.1000400@redhat.com> <56BAFC6E.6030605@redhat.com> Message-ID: <56BE04AD.2020700@redhat.com> Timothy Geier wrote: > >> On Feb 10, 2016, at 3:01 AM, Rob Crittenden > > wrote: >>> >>> [09/Feb/2016:12:55:41 -0600] conn=109598 fd=287 slot=287 SSL >>> connection from master_ip to master_ip >>> [09/Feb/2016:12:55:41 -0600] conn=109597 op=0 EXT >>> oid="1.3.6.1.4.1.1466.20037" name="startTLS" >>> [09/Feb/2016:12:55:41 -0600] conn=109597 op=0 RESULT err=0 tag=120 >>> nentries=0 etime=0 >>> [09/Feb/2016:12:55:41 -0600] conn=109598 Netscape Portable Runtime >>> error -8181 (Peer's Certificate has expired.); unauthenticated client >>> CN=CA Subsystem,O=XXXXXXX.NET ; issuer >>> CN=Certificate Authority,O=XXXXXXX.NET >>> [09/Feb/2016:12:55:41 -0600] conn=109598 op=-1 fd=287 closed - Peer's >>> Certificate has expired. >>> >> >> Ok, right. The subsystem cert expired on Feb 1 so you'd have to back >> at least that far in time to do the renewals. >> > >> There are a few entries in ou=People,o=ipaca that need to reflect the >> current state of certificates as well. > > Ah, right, just realized that that?s a base that can looked up > separately in LDAP..is there anything in particular to look for in there? Eventually you'll need to confirm that the IPA RA entry matches correctly but if your CA isn't coming up at all it is putting the cart before the horse. > >>> >>> >>> All of the host keytabs on all of the IPA servers are correct..are >>> there any other keytabs to check? >> >> No, just /etc/krb5.keytab. I think you should focus on getting the CA >> subsystem certs renewed and then we can look at the other things. So >> I'd go back in time to Jan 30 or so and just restart certmonger. > > After doing so, certmonger appears to run smoothly and goes from > SUBMITTING to MONITORING but the expiration date on all of the certs > stays the same. (It?s the same result if ipa-getcert resubmit is run > against all of the request IDs..quite perplexing) > > If we do a total shutdown/rewind/restart, getcert list produces the > following for these 3 certs during the time shift after the restart: > > Request ID '20160209194022': > status: CA_UNREACHABLE > ca-error: Internal error > stuck: no > key pair storage: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert > cert-pki-ca',token='NSS Certificate DB',pin set > certificate: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert > cert-pki-ca',token='NSS Certificate DB' > CA: dogtag-ipa-ca-renew-agent > issuer: CN=Certificate Authority,O=XXXXXXX.NET > subject: CN=CA Audit,O=XXXXXXX.NET > expires: 2016-02-01 19:46:48 UTC > key usage: digitalSignature,nonRepudiation > pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad > post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert > "auditSigningCert cert-pki-ca" > track: yes > auto-renew: yes > Request ID '20160209194023': > status: CA_UNREACHABLE > ca-error: Internal error > stuck: no > key pair storage: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS > Certificate DB',pin set > certificate: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS > Certificate DB' > CA: dogtag-ipa-ca-renew-agent > issuer: CN=Certificate Authority,O=XXXXXXX.NET > subject: CN=OCSP Subsystem,O=XXXXXXX.NET > expires: 2016-02-01 19:46:47 UTC > key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign > eku: id-kp-OCSPSigning > pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad > post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert > "ocspSigningCert cert-pki-ca" > track: yes > auto-renew: yes > Request ID '20160209194024': > status: CA_UNREACHABLE > ca-error: Internal error > stuck: no > key pair storage: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert > cert-pki-ca',token='NSS Certificate DB',pin set > certificate: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert > cert-pki-ca',token='NSS Certificate DB' > CA: dogtag-ipa-ca-renew-agent > issuer: CN=Certificate Authority,O=XXXXXXX.NET > subject: CN=CA Subsystem,O=XXXXXXX.NET > expires: 2016-02-01 19:46:47 UTC > key usage: > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > 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 > > The most puzzling thing (in my opinion) about this issue is that > timeshifting doesn?t seem to make any difference at all; pki-tomcatd > still doesn?t start cleanly (the log entries are very similar) even > though in theory those certs are no longer expired at that point..it > seems as if something else is also the issue. I think we need to see the debug log from a startup failure in the past. I'd also check the selftests log to see if it is not starting. Some have reported problems when there is more than one certificate stored for the subsystem certs in /var/lib/pki/pki-tomcat/alias/. Theoretically NSS should just ignore this but removing the older certs has tended to fix things. So you'd start with something like: - Save a copy of the 3 db files, just be sure to do so in a safe way considering it is your root CA - certutil -L -d /var/lib/pki/pki-tomcat/alias/ - for each nickname run certutil -L -d /var/lib/pki/pki-tomcat/alias/ -n '' -a This should make it fairly apparent if there is more than one. So far you haven't done anything destructive. We can tackle that if/when we need to. rob From filip at pytloun.cz Fri Feb 12 17:22:58 2016 From: filip at pytloun.cz (Filip Pytloun) Date: Fri, 12 Feb 2016 18:22:58 +0100 Subject: [Freeipa-users] Failed to setup replica, slapi_ldap_bind fails In-Reply-To: <56BE00E1.5080303@redhat.com> References: <20160208170505.GE4331@eru> <20160212140613.GC16168@eru> <56BDEA8F.2040506@redhat.com> <20160212143503.GD16168@eru> <56BE00E1.5080303@redhat.com> Message-ID: <20160212172258.GB5760@eru> Following is in /etc/ldap/ldap.conf on both servers (only URI differs): TLS_CACERT /etc/ipa/ca.crt TLS_REQCERT allow URI ldaps://idm02.tcpcloud.eu BASE dc=tcpcloud,dc=eu As ldapsearch is passing just fine on both nodes, I don't suppose ldap.conf is wrong. I also tried to set TLS_REQCERT to allow just to be sure (in case that bad cert is provided). On 2016/02/12 16:57, Ludwig Krispenz wrote: > > On 02/12/2016 03:35 PM, Filip Pytloun wrote: > >It's the same as for idm01: > > > >[12/Feb/2016:15:24:26 +0100] NSMMReplicationPlugin - agmt="cn=meToidm01.tcpcloud.eu" (idm01:389): Replication bind with SIMPLE auth failed: LDAP error -11 (Connect error) ((unknown error code)) > >[12/Feb/2016:15:24:27 +0100] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) > you can get this connect error if the client side cannot verify the cert the > server sends, could you check what you have in /etc/openldap/ldap.conf > > > > >In access logs I can't read much interesting, just that TLS connection happened from idm01: > > > >[12/Feb/2016:15:33:11 +0100] conn=14 fd=64 slot=64 connection from 185.22.97.19 to 172.10.10.192 > >[12/Feb/2016:15:33:11 +0100] conn=14 op=0 EXT oid="1.3.6.1.4.1.1466.20037" name="startTLS" > >[12/Feb/2016:15:33:11 +0100] conn=14 op=0 RESULT err=0 tag=120 nentries=0 etime=0 > >[12/Feb/2016:15:33:11 +0100] conn=14 TLS1.2 128-bit AES-GCM > >[12/Feb/2016:15:33:11 +0100] conn=14 op=-1 fd=64 closed - B1 > >[12/Feb/2016:15:33:59 +0100] conn=15 fd=64 slot=64 connection from 185.22.97.19 to 172.10.10.192 > >[12/Feb/2016:15:33:59 +0100] conn=15 op=0 EXT oid="1.3.6.1.4.1.1466.20037" name="startTLS" > >[12/Feb/2016:15:33:59 +0100] conn=15 op=0 RESULT err=0 tag=120 nentries=0 etime=0 > >[12/Feb/2016:15:34:00 +0100] conn=15 TLS1.2 128-bit AES-GCM > >[12/Feb/2016:15:34:00 +0100] conn=15 op=-1 fd=64 closed - B1 > > > >On 2016/02/12 15:22, Ludwig Krispenz wrote: > >>On 02/12/2016 03:06 PM, Filip Pytloun wrote: > >>>Hello, > >>> > >>>even when enabling replication logging, I get nothing useful in logs: > >>> > >>>[12/Feb/2016:14:57:00 +0100] NSMMReplicationPlugin - agmt="cn=meToidm02.tcpcloud.eu" (idm02:389): Trying secure startTLS slapi_ldap_init_ext > >>>[12/Feb/2016:14:57:00 +0100] NSMMReplicationPlugin - agmt="cn=meToidm02.tcpcloud.eu" (idm02:389): binddn = cn=replication manager,cn=config, passwd = {AES-some_encrypted_password > >>>[12/Feb/2016:14:57:01 +0100] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) > >>>[12/Feb/2016:14:57:01 +0100] NSMMReplicationPlugin - agmt="cn=meToidm02.tcpcloud.eu" (idm02:389): Replication bind with SIMPLE auth failed: LDAP error -11 (Connect error) ((unknown error code)) > >>>[12/Feb/2016:14:57:01 +0100] NSMMReplicationPlugin - agmt="cn=meToidm02.tcpcloud.eu" (idm02:389): Disconnected from the consumer > >>what is in the access and error logs of idm02 for this time ? > >>>But I can bind just fine manually: > >>> > >>>ldapsearch -D "cn=replication manager,cn=config" -w some_password -b cn=config -h idm02 -ZZ > >>> > >>>I am starting to be clueless, nobody has an idea what could be wrong? > >>> > >>>- DNS including PTR records are set up fine > >>>- /etc/hosts is setup fine > >>>- conncheck passes fine between nodes > >>>- I can bind manually just fine > >>> > >>>On 2016/02/08 18:05, Filip Pytloun wrote: > >>>>Hello, > >>>> > >>>>I have a weird issue setting up FreeIPA replica. Conncheck passes fine > >>>>but at the end of ipa-replica-install I always get following error: > >>>> > >>>>slapi_ldap_bind -Error: could not send startTLS request: error -11 > >>>>(Connect error) errno 0 (Success) > >>>> > >>>>on both master and replica without any further explanation in logs. > >>>> > >>>>/etc/ldap.conf is correctly setup before ipa-replica-install and IPA CA > >>>>certificate is installed in system CA bundle so TLS should work just > >>>>fine. > >>>> > >>>>Also I can manually connect just fine from replica to master and back so > >>>>it's not a network or LDAP client issue. > >>>> > >>>>Replica agreement looks like this: http://pastebin.com/FT3p3KUk > >>>> > >>>>freeipa-server 4.1.4 > >>>>389-ds 1.3.4.5 > >>>> > >>>>Has anyone idea where to look at? > >>>> > >>>>Filip > >>> > >>> > >>-- > >>Manage your subscription for the Freeipa-users mailing list: > >>https://www.redhat.com/mailman/listinfo/freeipa-users > >>Go to http://freeipa.org for more info on the project > > > > > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From jhrozek at redhat.com Fri Feb 12 18:12:21 2016 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 12 Feb 2016 19:12:21 +0100 Subject: [Freeipa-users] Active Directory Trust = filter users In-Reply-To: <20160212112947.GG28898@redhat.com> References: <56B9C666.9000302@dds.nl> <20160210084228.GY29883@hendrix.redhat.com> <56BB2B30.108@dds.nl> <20160210124646.GE28065@redhat.com> <6071ced0e74ac185b5819d96d898cd9d@dds.nl> <20160212112947.GG28898@redhat.com> Message-ID: <20160212181221.GU29883@hendrix.redhat.com> On Fri, Feb 12, 2016 at 01:29:47PM +0200, Alexander Bokovoy wrote: > On Fri, 12 Feb 2016, wdh at dds.nl wrote: > >Hi all, > > > >Yes, you can filter out certain SIDs--> I tried, but cannot get it to > >work. For example, I don't need "Domain Users": > > > >Found out the SID by: > > > >[root at suacri10103 ~]# getent group domain\ users at ad.example.org > >domain users at example.org:*:1012600513:someuser at ad.example.org > >[root at suacri10103 ~]# ldbsearch -H > >/var/lib/sss/db/cache_ipa.ad%s/example.org.ldb gidNumber=1012600513 | > >grep objectSIDString > >asq: Unable to register control with rootdse! > >objectSIDString: S-1-5-21-1447349426-2906170142-3196411423-513 > > > >and put the SID in the blacklist; yes it is blacklisted: > > > >admin01 at ipa ~]$ ipa trust-show ad.example.com --all | grep "SID blacklist > >incoming" > > SID blacklist incoming: S-1-5-20, > >S-1-5-21-1447349426-2906170142-3196411423-513, S-1-5-3, S-1-5-2, S-1-5-1, > >S-1-5-7, S-1-5-6, S-1-5-5, S-1-5-4, S-1-5-9, S-1-5-8, S-1-5-17, S-1-5-16, > >S-1-5-15, S-1-5-14, S-1-5-13, S-1-5-12, S-1-5-11, S-1-5-10, S-1-3, S-1-2, > >S-1-1, S-1-0, S-1-5-19, S-1-5-18 > > > >However, the group is still there if I do a n "id someuser at ad.example.com" > >(yep, whiped cache, restarted ipa etc.) > > > >Shouldn't the group be disappeared since the SID is blacklisted...? > Only from Kerberos tickets. I don't think SSSD in ipa_server_mode > consults this list. Instead, when AD users logins with Kerberos ticket, > the resulting ticket already has blacklisted SIDs filtered out by IPA > KDC and SSSD will see that these tickets' MS-PAC doesn't have additional > groups in it. Alexander, do you think this would make a reasonable RFE? From chris at etriptrader.com Fri Feb 12 19:49:31 2016 From: chris at etriptrader.com (Chris Lajoie) Date: Fri, 12 Feb 2016 12:49:31 -0700 Subject: [Freeipa-users] BIND apparently not loading ldap.so In-Reply-To: <56BD8F89.3060008@redhat.com> References: <77c8b66eb6614184b9d80045cae4d0c6@etriptrader.com> <56BC586F.4080902@redhat.com> <56BCD3D9.2050405@etriptrader.com> <56BD8F89.3060008@redhat.com> Message-ID: <56BE374B.4000700@etriptrader.com> On 02/12/2016 12:53 AM, Petr Spacek wrote: > On 11.2.2016 19:32, Chris Lajoie wrote: >> On 02/11/2016 02:46 AM, Petr Spacek wrote: >>> What version of BIND and bind-dyndb-ldap packages are you using? $ rpm >>> -q bind bind-dyndb-ldap >> bind-9.9.4-29.el7_2.2.x86_64 bind-dyndb-ldap-8.0-1.el7.x86_64 >>> I'm not sure how exactly the logging magic in BIND works so I would >>> recommend you to to run BIND using command: $ named -g -u named and >>> check output in the console to see if it contains line like >>> 'bind-dyndb-ldap version 8.0 compiled at 16:09:02 Jan 20 2016, >>> compiler 5.3.1 20151207 (Red Hat 5.3.1-2)' >> I get nothing like that. Here is the output I get from running named: >> https://gist.github.com/ctlajoie/0ed4e97e72aec3172a8d > Oh, wait, it seems that you are using views! > > Generally we do not test bind-dyndb-ldap with views so there be dragons. > > Could you share your named.conf with us? > > If you do not want to send it to mailing list feel free to send it to me > privately. My GPG key is attached just for the case you wish to encrypt it. Sure. I do not see anything in my named.conf besides the ldap password (which I changed) that should be kept private. https://gist.github.com/ctlajoie/827a2ec9cfa70e3a1ebd Not sure if it matters any more though.. I was able to get it working by commenting out the view parts and leaving only the zones. Unfortunately the plugin seems unable or unwilling to load if there are any views present at all. I also tried placing the dynamic-db section inside of one of the views. named will accept the configuration and start up, but again there are no ldap log messages. I would really like to use ldap as the backend for my DNS configuration... its heirarchical nature seems (to me) to be a good fit for storing that type of thing. It is surprising to me that almost nobody else does it this way (from what I can tell). I suppose if I want to do it then I will need to run seperate instances of bind, either on different servers or the same server using different ports for each instance, and doing some NATing with iptables. Either method complicates things more than I would like... Can you speculate on why there would be no log messages at all when the ldap plugin fails to load (if that is indeed what is happening)? If there was something in the log it would have saved me quite a bit of time investigating this. Thank you for helping me track down the problem. Chris From abokovoy at redhat.com Fri Feb 12 20:49:36 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 12 Feb 2016 22:49:36 +0200 Subject: [Freeipa-users] Active Directory Trust = filter users In-Reply-To: <20160212181221.GU29883@hendrix.redhat.com> References: <56B9C666.9000302@dds.nl> <20160210084228.GY29883@hendrix.redhat.com> <56BB2B30.108@dds.nl> <20160210124646.GE28065@redhat.com> <6071ced0e74ac185b5819d96d898cd9d@dds.nl> <20160212112947.GG28898@redhat.com> <20160212181221.GU29883@hendrix.redhat.com> Message-ID: <20160212204936.GK28898@redhat.com> On Fri, 12 Feb 2016, Jakub Hrozek wrote: >On Fri, Feb 12, 2016 at 01:29:47PM +0200, Alexander Bokovoy wrote: >> On Fri, 12 Feb 2016, wdh at dds.nl wrote: >> >Hi all, >> > >> >Yes, you can filter out certain SIDs--> I tried, but cannot get it to >> >work. For example, I don't need "Domain Users": >> > >> >Found out the SID by: >> > >> >[root at suacri10103 ~]# getent group domain\ users at ad.example.org >> >domain users at example.org:*:1012600513:someuser at ad.example.org >> >[root at suacri10103 ~]# ldbsearch -H >> >/var/lib/sss/db/cache_ipa.ad%s/example.org.ldb gidNumber=1012600513 | >> >grep objectSIDString >> >asq: Unable to register control with rootdse! >> >objectSIDString: S-1-5-21-1447349426-2906170142-3196411423-513 >> > >> >and put the SID in the blacklist; yes it is blacklisted: >> > >> >admin01 at ipa ~]$ ipa trust-show ad.example.com --all | grep "SID blacklist >> >incoming" >> > SID blacklist incoming: S-1-5-20, >> >S-1-5-21-1447349426-2906170142-3196411423-513, S-1-5-3, S-1-5-2, S-1-5-1, >> >S-1-5-7, S-1-5-6, S-1-5-5, S-1-5-4, S-1-5-9, S-1-5-8, S-1-5-17, S-1-5-16, >> >S-1-5-15, S-1-5-14, S-1-5-13, S-1-5-12, S-1-5-11, S-1-5-10, S-1-3, S-1-2, >> >S-1-1, S-1-0, S-1-5-19, S-1-5-18 >> > >> >However, the group is still there if I do a n "id someuser at ad.example.com" >> >(yep, whiped cache, restarted ipa etc.) >> > >> >Shouldn't the group be disappeared since the SID is blacklisted...? >> Only from Kerberos tickets. I don't think SSSD in ipa_server_mode >> consults this list. Instead, when AD users logins with Kerberos ticket, >> the resulting ticket already has blacklisted SIDs filtered out by IPA >> KDC and SSSD will see that these tickets' MS-PAC doesn't have additional >> groups in it. > >Alexander, do you think this would make a reasonable RFE? For non-logged-in case? Yes, it certainly makes sense as it would be consistent with KDC then. The only potential issue is that we'd lose 'true' group membership for IPA CLI/Web UI operations as removing 'Domain users at AD.TEST' would make it impossible to assign anything to 'Domain users at AD.TEST' in ID overrides and external group members, but given it is actually filtered out at the level of a trust boundary, may be this is exactly what a person would like to achieve? -- / Alexander Bokovoy From rakesh.rajasekharan at gmail.com Sat Feb 13 02:08:16 2016 From: rakesh.rajasekharan at gmail.com (Rakesh Rajasekharan) Date: Sat, 13 Feb 2016 07:38:16 +0530 Subject: [Freeipa-users] Connection closed by UNKNOWN Message-ID: I started up with freeipa and setup a server and a client Now when I add a user and try logging in, It successfully prompts for the password change and completes setting up the new password. However, when I gain try to login with the new password, it gives me the below error "Connection closed by UNKNOWN" In /var/log/secure , I see this fatal: Access denied for user t-temp by PAM account configuration. Any pointers, what I would have done wrong in the setup or if I would have missed something. Thanks. Rakesh -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Sat Feb 13 11:11:08 2016 From: jhrozek at redhat.com (Jakub Hrozek) Date: Sat, 13 Feb 2016 12:11:08 +0100 Subject: [Freeipa-users] Connection closed by UNKNOWN In-Reply-To: References: Message-ID: <20160213111108.GE29883@hendrix.redhat.com> On Sat, Feb 13, 2016 at 07:38:16AM +0530, Rakesh Rajasekharan wrote: > I started up with freeipa and setup a server and a client > > > Now when I add a user and try logging in, > It successfully prompts for the password change and completes setting up > the new password. > > However, when I gain try to login with the new password, it gives me the > below error > > "Connection closed by UNKNOWN" > > In /var/log/secure , I see this > > fatal: Access denied for user t-temp by PAM account configuration. > > Any pointers, what I would have done wrong in the setup or if I would have > missed something. I would guess HBAC if that message comes from pam_sss. From mkosek at redhat.com Sat Feb 13 13:13:56 2016 From: mkosek at redhat.com (Martin Kosek) Date: Sat, 13 Feb 2016 14:13:56 +0100 Subject: [Freeipa-users] sudo runs despite being denied by HBAC rules In-Reply-To: <20160209160631.GC13324@cs.ox.ac.uk> References: <20160209160631.GC13324@cs.ox.ac.uk> Message-ID: <56BF2C14.5070603@redhat.com> On 02/09/2016 05:06 PM, Ian Collier wrote: > Can anyone help me to understand these logs... is there maybe a bug here? > > The basic situation is that there is no HBAC rule that would allow > sudo. When people try it, sss accepts their password but then denies > them access to the sudo command. But despite this, our logs still > contain some entries indicating that sudo was actually run. Of course > the sudoers file then denied them access and sent the sysadmin an > email. > > Here's a journal extract: > > Feb 09 11:34:58 hostname sudo[24453]: pam_unix(sudo:auth): authentication failure; logname=xxxx uid=12113 euid=0 tty=/dev/pts/1 ruser=xxxx rhost= user=xxxx > Feb 09 11:34:58 hostname sudo[24453]: pam_sss(sudo:auth): authentication success; logname=xxxx uid=12113 euid=0 tty=/dev/pts/1 ruser=xxxx rhost= user=xxxx > Feb 09 11:34:58 hostname audit[24453]: pid=24453 uid=12113 auid=12113 ses=54 msg='op=PAM:authentication grantors=pam_succeed_if,pam_sss acct="xxxx" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=success' > Feb 09 11:34:58 hostname sudo[24453]: pam_sss(sudo:account): Access denied for user xxxx: 6 (Permission denied) > Feb 09 11:34:58 hostname audit[24453]: pid=24453 uid=12113 auid=12113 ses=54 msg='op=PAM:accounting grantors=? acct="xxxx" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=failed' > Feb 09 11:35:05 hostname sudo[24453]: pam_sss(sudo:auth): authentication success; logname=xxxx uid=12113 euid=0 tty=/dev/pts/1 ruser=xxxx rhost= user=xxxx > Feb 09 11:35:05 hostname audit[24453]: pid=24453 uid=12113 auid=12113 ses=54 msg='op=PAM:authentication grantors=pam_succeed_if,pam_sss acct="xxxx" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=success' > Feb 09 11:35:05 hostname sudo[24453]: pam_sss(sudo:account): Access denied for user xxxx: 6 (Permission denied) > Feb 09 11:35:05 hostname audit[24453]: pid=24453 uid=12113 auid=12113 ses=54 msg='op=PAM:accounting grantors=? acct="xxxx" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=failed' > Feb 09 11:35:08 hostname sudo[24453]: pam_unix(sudo:auth): auth could not identify password for [xxxx] > Feb 09 11:35:08 hostname sudo[24453]: pam_sss(sudo:auth): authentication failure; logname=xxxx uid=12113 euid=0 tty=/dev/pts/1 ruser=xxxx rhost= user=xxxx > Feb 09 11:35:08 hostname sudo[24453]: pam_sss(sudo:auth): received for user xxxx: 7 (Authentication failure) > Feb 09 11:35:08 hostname audit[24453]: pid=24453 uid=12113 auid=12113 ses=54 msg='op=PAM:authentication grantors=? acct="xxxx" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=failed' > Feb 09 11:35:08 hostname audit[24453]: pid=24453 uid=12113 auid=12113 ses=54 msg='cwd=2F6175xxx cmd=617074xxx terminal=pts/1 res=failed' > Feb 09 11:35:08 hostname audit[24453]: pid=24453 uid=12113 auid=12113 ses=54 msg='cwd=2F6175xxx cmd=617074xxx terminal=pts/1 res=failed' > Feb 09 11:35:08 hostname sudo[24453]: xxxx : user NOT in sudoers ; TTY=pts/1 ; PWD=/xxxxx ; USER=root ; COMMAND=xxxxx > Feb 09 11:35:09 hostname sSMTP[24463]: Sent mail for root at cs.ox.ac.uk (221 mail.cs.ox.ac.uk closing connection) uid=0 xxxx=root outbytes=607 > > What this seems to say: > > 1. pam_unix failed the password (expected because passwords are managed by IPA) > 2. pam_sss accepted the password > 3. pam_sss denied access to sudo:account > > Presumably sudo asked the user to try again and they re-typed the password > > 4. pam_sss accepted the password > 5. pam_sss denied access to sudo:account > > 6. Three seconds later pam_unix said it "could not identify password" (?) > 7. This time pam_sss failed the password and returned 7 (Authentication failure) > 8. sudo ran anyway! > > I can't duplicate this behaviour myself but looking through the logs in > our computer lab there are a few of these. See for instance the following > which appears to deny access three times and then just run it anyway: > > Feb 02 10:31:12 hostname2 sudo[24468]: pam_unix(sudo:auth): authentication failure; logname=xyyx uid=12106 euid=0 tty=/dev/pts/1 ruser=xyyx rhost= user=xyyx > Feb 02 10:31:14 hostname2 sudo[24468]: pam_sss(sudo:auth): authentication success; logname=xyyx uid=12106 euid=0 tty=/dev/pts/1 ruser=xyyx rhost= user=xyyx > Feb 02 10:31:14 hostname2 audit[24468]: pid=24468 uid=12106 auid=12106 ses=39 msg='op=PAM:authentication grantors=pam_succeed_if,pam_sss acct="xyyx" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=success' > Feb 02 10:31:15 hostname2 sudo[24468]: pam_sss(sudo:account): Access denied for user xyyx: 6 (Permission denied) > Feb 02 10:31:15 hostname2 audit[24468]: pid=24468 uid=12106 auid=12106 ses=39 msg='op=PAM:accounting grantors=? acct="xyyx" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=failed' > Feb 02 10:31:26 hostname2 sudo[24468]: pam_sss(sudo:auth): authentication success; logname=xyyx uid=12106 euid=0 tty=/dev/pts/1 ruser=xyyx rhost= user=xyyx > Feb 02 10:31:26 hostname2 audit[24468]: pid=24468 uid=12106 auid=12106 ses=39 msg='op=PAM:authentication grantors=pam_succeed_if,pam_sss acct="xyyx" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=success' > Feb 02 10:31:26 hostname2 sudo[24468]: pam_sss(sudo:account): Access denied for user xyyx: 6 (Permission denied) > Feb 02 10:31:26 hostname2 audit[24468]: pid=24468 uid=12106 auid=12106 ses=39 msg='op=PAM:accounting grantors=? acct="xyyx" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=failed' > Feb 02 10:31:46 hostname2 sudo[24468]: pam_sss(sudo:auth): authentication success; logname=xyyx uid=12106 euid=0 tty=/dev/pts/1 ruser=xyyx rhost= user=xyyx > Feb 02 10:31:46 hostname2 audit[24468]: pid=24468 uid=12106 auid=12106 ses=39 msg='op=PAM:authentication grantors=pam_succeed_if,pam_sss acct="xyyx" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=success' > Feb 02 10:31:46 hostname2 sudo[24468]: pam_sss(sudo:account): Access denied for user xyyx: 6 (Permission denied) > Feb 02 10:31:46 hostname2 audit[24468]: pid=24468 uid=12106 auid=12106 ses=39 msg='op=PAM:accounting grantors=? acct="xyyx" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=failed' > Feb 02 10:31:46 hostname2 audit[24468]: pid=24468 uid=12106 auid=12106 ses=39 msg='cwd="/xxxx" cmd=6E616Exxx terminal=pts/1 res=failed' > Feb 02 10:31:46 hostname2 audit[24468]: pid=24468 uid=12106 auid=12106 ses=39 msg='cwd="/xxxx" cmd=6E616Exxx terminal=pts/1 res=failed' > Feb 02 10:31:46 hostname2 sudo[24468]: xyyx : user NOT in sudoers ; TTY=pts/1 ; PWD=/xxxxxx ; USER=root ; COMMAND=xxxxxx > Feb 02 10:31:47 hostname2 sSMTP[24489]: Sent mail for root at cs.ox.ac.uk (221 mail.cs.ox.ac.uk closing connection) uid=0 username=root outbytes=589 > > Now since sudoers denies access, this isn't necessarily a security > problem for us. But it's rather puzzling and it does mean a trickle > of incoming emails to the sysadmin. > > The clients here are Fedora 22 with pam 1.1.8, sssd 1.13.3 and sudo 1.8.15. > The IPA servers are RHEL 6 with ipa-server 3.0.0. > > Ian Collier. > CCing Pavel, I am not sure on this one. From Ian.Collier at cs.ox.ac.uk Sat Feb 13 14:36:36 2016 From: Ian.Collier at cs.ox.ac.uk (Ian Collier) Date: Sat, 13 Feb 2016 14:36:36 +0000 Subject: [Freeipa-users] sudo runs despite being denied by HBAC rules In-Reply-To: <20160209160631.GC13324@cs.ox.ac.uk> References: <20160209160631.GC13324@cs.ox.ac.uk> Message-ID: <20160213143636.GK13393@cs.ox.ac.uk> I wrote... > Can anyone help me to understand these logs... is there maybe a bug here? > The basic situation is that there is no HBAC rule that would allow > sudo. When people try it, sss accepts their password but then denies > them access to the sudo command. But despite this, our logs still > contain some entries indicating that sudo was actually run. Of course > the sudoers file then denied them access and sent the sysadmin an > email. It turns out I am misinterpreting the logs. And because the sudoers file would normally allow me access, testing it with my own account didn't yield the same results. Essentially, if sudoers would deny access then it seems that sudo will log and email the sysadmin even if the user failed to supply a correct password. So there isn't a problem here after all. The user is being told their password was incorrect and sudo goes no further. But the email that the sysadmin receives is the same regardless of whether sudo accepted their password. If I try with my account, sudo tells me my password is incorrect but doesn't email the sysadmin, and it writes "3 incorrect password attempts" into the log instead of "user NOT in sudoers". Anyway, now I've added an HBAC rule that allows the system staff (but not general users) to run sudo, and this is working too. Sorry for the false alarm. Ian Collier. From prasun.gera at gmail.com Sat Feb 13 22:40:03 2016 From: prasun.gera at gmail.com (Prasun Gera) Date: Sat, 13 Feb 2016 17:40:03 -0500 Subject: [Freeipa-users] [freeipa-users] Configuring Automount on Ubuntu Clients In-Reply-To: <56B8BAB4.2080007@ubuntu.com> References: <56B8BAB4.2080007@ubuntu.com> Message-ID: Just replying to this thread to express interest in good client support in Ubuntu. As 16.04 draws close to a release, it would be great if the client side of things work well out of the box in 16.04 without any 3rd party ppas. 12.04 was pretty bad, 14.04 was mostly usable with some issues. I'm hoping that with 16.04, it reaches parity with Fedora based distros. I'll be happy to do some preliminary testing if needed. On Mon, Feb 8, 2016 at 10:56 AM, Timo Aaltonen wrote: > 04.02.2016, 19:28, Jon kirjoitti: > > Is Ubuntu not supported with FreeIPA? Is there an updated install > > script? I installed the freeipa-client from public repos. > > > >>> ii freeipa-client > > 3.3.4-0ubuntu3.1 amd64 > > FreeIPA centralized identity framework -- client > >>> ii python-freeipa > > 3.3.4-0ubuntu3.1 amd64 > > FreeIPA centralized identity framework -- python modules > > The stock packages in 14.04 are rather old, you'd probably be happier with > the 4.0.5-based client available on the PPA: > > https://launchpad.net/~freeipa/+archive/ubuntu/4.0 > > > > -- > t > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project > -------------- next part -------------- An HTML attachment was scrubbed... URL: From filip at pytloun.cz Sun Feb 14 07:14:17 2016 From: filip at pytloun.cz (Filip Pytloun) Date: Sun, 14 Feb 2016 08:14:17 +0100 Subject: [Freeipa-users] [freeipa-users] Configuring Automount on Ubuntu Clients In-Reply-To: References: <56B8BAB4.2080007@ubuntu.com> Message-ID: <20160214071417.GA6343@eru> Hello, we are using Ubuntu 14.04 on FreeIPA clients and Ubuntu 16.04 on FreeIPA server for 2 months with no critical issues. Using newer freeipa-client was not needed, only sssd update from here, because trusty version is buggy: https://launchpad.net/~sssd/+archive/ubuntu/updates?field.series_filter=trusty On server side, it was only needed to fix apparmor policy for bind to fix FreeIPA DNS zones: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814314 Maybe someone could be interested in Salt formula we are using to setup Freeipa server/client: https://github.com/tcpcloud/salt-formula-freeipa Filip On 2016/02/13 17:40, Prasun Gera wrote: > Just replying to this thread to express interest in good client support in > Ubuntu. As 16.04 draws close to a release, it would be great if the client > side of things work well out of the box in 16.04 without any 3rd party > ppas. 12.04 was pretty bad, 14.04 was mostly usable with some issues. I'm > hoping that with 16.04, it reaches parity with Fedora based distros. I'll > be happy to do some preliminary testing if needed. > > On Mon, Feb 8, 2016 at 10:56 AM, Timo Aaltonen wrote: > > > 04.02.2016, 19:28, Jon kirjoitti: > > > Is Ubuntu not supported with FreeIPA? Is there an updated install > > > script? I installed the freeipa-client from public repos. > > > > > >>> ii freeipa-client > > > 3.3.4-0ubuntu3.1 amd64 > > > FreeIPA centralized identity framework -- client > > >>> ii python-freeipa > > > 3.3.4-0ubuntu3.1 amd64 > > > FreeIPA centralized identity framework -- python modules > > > > The stock packages in 14.04 are rather old, you'd probably be happier with > > the 4.0.5-based client available on the PPA: > > > > https://launchpad.net/~freeipa/+archive/ubuntu/4.0 > > > > > > > > -- > > t > > > > -- > > Manage your subscription for the Freeipa-users mailing list: > > https://www.redhat.com/mailman/listinfo/freeipa-users > > Go to http://freeipa.org for more info on the project > > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From rakesh.rajasekharan at gmail.com Mon Feb 15 04:54:23 2016 From: rakesh.rajasekharan at gmail.com (Rakesh Rajasekharan) Date: Mon, 15 Feb 2016 10:24:23 +0530 Subject: [Freeipa-users] Connection closed by UNKNOWN In-Reply-To: <20160213111108.GE29883@hendrix.redhat.com> References: <20160213111108.GE29883@hendrix.redhat.com> Message-ID: hbac seems to be fine ipa hbactest --user=q-temp --host=x.x.x.x --service=sshd -------------------- Access granted: True -------------------- Matched rules: allow_all I see this in the sssd.log (Mon Feb 15 04:49:18 2016) [sssd[nss]] [sss_ncache_check_str] (0x2000): Checking negative cache for [NCE/USER/xyz.com/q-temp] (Mon Feb 15 04:49:18 2016) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [q-temp at xyz.com] (Mon Feb 15 04:49:18 2016) [sssd[nss]] [check_cache] (0x0400): Cached entry is valid, returning.. (Mon Feb 15 04:49:18 2016) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0400): Returning info for user [q-temp at xyz.com] (Mon Feb 15 04:49:18 2016) [sssd[nss]] [client_recv] (0x0200): Client disconnected! (Mon Feb 15 04:49:18 2016) [sssd[nss]] [client_destructor] (0x2000): Terminated client [0x23d2f80][20] (Mon Feb 15 04:49:27 2016) [sssd[nss]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit On Sat, Feb 13, 2016 at 4:41 PM, Jakub Hrozek wrote: > On Sat, Feb 13, 2016 at 07:38:16AM +0530, Rakesh Rajasekharan wrote: > > I started up with freeipa and setup a server and a client > > > > > > Now when I add a user and try logging in, > > It successfully prompts for the password change and completes setting up > > the new password. > > > > However, when I gain try to login with the new password, it gives me the > > below error > > > > "Connection closed by UNKNOWN" > > > > In /var/log/secure , I see this > > > > fatal: Access denied for user t-temp by PAM account configuration. > > > > Any pointers, what I would have done wrong in the setup or if I would > have > > missed something. > > I would guess HBAC if that message comes from pam_sss. > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbose at redhat.com Mon Feb 15 09:03:01 2016 From: sbose at redhat.com (Sumit Bose) Date: Mon, 15 Feb 2016 10:03:01 +0100 Subject: [Freeipa-users] Active Directory Trust = filter users In-Reply-To: <20160212204936.GK28898@redhat.com> References: <56B9C666.9000302@dds.nl> <20160210084228.GY29883@hendrix.redhat.com> <56BB2B30.108@dds.nl> <20160210124646.GE28065@redhat.com> <6071ced0e74ac185b5819d96d898cd9d@dds.nl> <20160212112947.GG28898@redhat.com> <20160212181221.GU29883@hendrix.redhat.com> <20160212204936.GK28898@redhat.com> Message-ID: <20160215090301.GS12933@p.redhat.com> On Fri, Feb 12, 2016 at 10:49:36PM +0200, Alexander Bokovoy wrote: > On Fri, 12 Feb 2016, Jakub Hrozek wrote: > >On Fri, Feb 12, 2016 at 01:29:47PM +0200, Alexander Bokovoy wrote: > >>On Fri, 12 Feb 2016, wdh at dds.nl wrote: > >>>Hi all, > >>> > >>>Yes, you can filter out certain SIDs--> I tried, but cannot get it to > >>>work. For example, I don't need "Domain Users": > >>> > >>>Found out the SID by: > >>> > >>>[root at suacri10103 ~]# getent group domain\ users at ad.example.org > >>>domain users at example.org:*:1012600513:someuser at ad.example.org > >>>[root at suacri10103 ~]# ldbsearch -H > >>>/var/lib/sss/db/cache_ipa.ad%s/example.org.ldb gidNumber=1012600513 | > >>>grep objectSIDString > >>>asq: Unable to register control with rootdse! > >>>objectSIDString: S-1-5-21-1447349426-2906170142-3196411423-513 > >>> > >>>and put the SID in the blacklist; yes it is blacklisted: > >>> > >>>admin01 at ipa ~]$ ipa trust-show ad.example.com --all | grep "SID blacklist > >>>incoming" > >>> SID blacklist incoming: S-1-5-20, > >>>S-1-5-21-1447349426-2906170142-3196411423-513, S-1-5-3, S-1-5-2, S-1-5-1, > >>>S-1-5-7, S-1-5-6, S-1-5-5, S-1-5-4, S-1-5-9, S-1-5-8, S-1-5-17, S-1-5-16, > >>>S-1-5-15, S-1-5-14, S-1-5-13, S-1-5-12, S-1-5-11, S-1-5-10, S-1-3, S-1-2, > >>>S-1-1, S-1-0, S-1-5-19, S-1-5-18 > >>> > >>>However, the group is still there if I do a n "id someuser at ad.example.com" > >>>(yep, whiped cache, restarted ipa etc.) > >>> > >>>Shouldn't the group be disappeared since the SID is blacklisted...? > >>Only from Kerberos tickets. I don't think SSSD in ipa_server_mode > >>consults this list. Instead, when AD users logins with Kerberos ticket, > >>the resulting ticket already has blacklisted SIDs filtered out by IPA > >>KDC and SSSD will see that these tickets' MS-PAC doesn't have additional > >>groups in it. > > > >Alexander, do you think this would make a reasonable RFE? > For non-logged-in case? Yes, it certainly makes sense as it would be > consistent with KDC then. The only potential issue is that we'd lose > 'true' group membership for IPA CLI/Web UI operations as removing > 'Domain users at AD.TEST' would make it impossible to assign anything to > 'Domain users at AD.TEST' in ID overrides and external group members, but > given it is actually filtered out at the level of a trust boundary, may > be this is exactly what a person would like to achieve? yes, I think we have to add support in SSSD for this to be consistent with the group memberships we get from the PAC. But since we in general cannot ignore the groups completely it might be sufficient to just label the filtered groups as non-POSIX groups in the cache (maybe we need an additional flag to indicate that the group is really filtered out to make sure that future lookup schemes which might include non-POSIX groups will ignore the filtered groups as well). Btw, the 'Domain Users' group is a bad example here, because it is in general the primary group of the AD users in AD and hence listed in the PAC as primary group. If you filter 'Domain Users' we have to reject all Kerberos request because the resulting PAC will not have a primary group. bye, Sumit > -- > / Alexander Bokovoy > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project From abokovoy at redhat.com Mon Feb 15 09:10:41 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 15 Feb 2016 11:10:41 +0200 Subject: [Freeipa-users] Active Directory Trust = filter users In-Reply-To: <20160215090301.GS12933@p.redhat.com> References: <56B9C666.9000302@dds.nl> <20160210084228.GY29883@hendrix.redhat.com> <56BB2B30.108@dds.nl> <20160210124646.GE28065@redhat.com> <6071ced0e74ac185b5819d96d898cd9d@dds.nl> <20160212112947.GG28898@redhat.com> <20160212181221.GU29883@hendrix.redhat.com> <20160212204936.GK28898@redhat.com> <20160215090301.GS12933@p.redhat.com> Message-ID: <20160215091041.GA4492@redhat.com> On Mon, 15 Feb 2016, Sumit Bose wrote: >On Fri, Feb 12, 2016 at 10:49:36PM +0200, Alexander Bokovoy wrote: >> On Fri, 12 Feb 2016, Jakub Hrozek wrote: >> >On Fri, Feb 12, 2016 at 01:29:47PM +0200, Alexander Bokovoy wrote: >> >>On Fri, 12 Feb 2016, wdh at dds.nl wrote: >> >>>Hi all, >> >>> >> >>>Yes, you can filter out certain SIDs--> I tried, but cannot get it to >> >>>work. For example, I don't need "Domain Users": >> >>> >> >>>Found out the SID by: >> >>> >> >>>[root at suacri10103 ~]# getent group domain\ users at ad.example.org >> >>>domain users at example.org:*:1012600513:someuser at ad.example.org >> >>>[root at suacri10103 ~]# ldbsearch -H >> >>>/var/lib/sss/db/cache_ipa.ad%s/example.org.ldb gidNumber=1012600513 | >> >>>grep objectSIDString >> >>>asq: Unable to register control with rootdse! >> >>>objectSIDString: S-1-5-21-1447349426-2906170142-3196411423-513 >> >>> >> >>>and put the SID in the blacklist; yes it is blacklisted: >> >>> >> >>>admin01 at ipa ~]$ ipa trust-show ad.example.com --all | grep "SID blacklist >> >>>incoming" >> >>> SID blacklist incoming: S-1-5-20, >> >>>S-1-5-21-1447349426-2906170142-3196411423-513, S-1-5-3, S-1-5-2, S-1-5-1, >> >>>S-1-5-7, S-1-5-6, S-1-5-5, S-1-5-4, S-1-5-9, S-1-5-8, S-1-5-17, S-1-5-16, >> >>>S-1-5-15, S-1-5-14, S-1-5-13, S-1-5-12, S-1-5-11, S-1-5-10, S-1-3, S-1-2, >> >>>S-1-1, S-1-0, S-1-5-19, S-1-5-18 >> >>> >> >>>However, the group is still there if I do a n "id someuser at ad.example.com" >> >>>(yep, whiped cache, restarted ipa etc.) >> >>> >> >>>Shouldn't the group be disappeared since the SID is blacklisted...? >> >>Only from Kerberos tickets. I don't think SSSD in ipa_server_mode >> >>consults this list. Instead, when AD users logins with Kerberos ticket, >> >>the resulting ticket already has blacklisted SIDs filtered out by IPA >> >>KDC and SSSD will see that these tickets' MS-PAC doesn't have additional >> >>groups in it. >> > >> >Alexander, do you think this would make a reasonable RFE? >> For non-logged-in case? Yes, it certainly makes sense as it would be >> consistent with KDC then. The only potential issue is that we'd lose >> 'true' group membership for IPA CLI/Web UI operations as removing >> 'Domain users at AD.TEST' would make it impossible to assign anything to >> 'Domain users at AD.TEST' in ID overrides and external group members, but >> given it is actually filtered out at the level of a trust boundary, may >> be this is exactly what a person would like to achieve? > >yes, I think we have to add support in SSSD for this to be consistent >with the group memberships we get from the PAC. But since we in general >cannot ignore the groups completely it might be sufficient to just label >the filtered groups as non-POSIX groups in the cache (maybe we need an >additional flag to indicate that the group is really filtered out to >make sure that future lookup schemes which might include non-POSIX >groups will ignore the filtered groups as well). Marking it non-POSIX wouldn't prevent nested group membership, though. This obviously needs more thought... >Btw, the 'Domain Users' group is a bad example here, because it is in >general the primary group of the AD users in AD and hence listed in the >PAC as primary group. If you filter 'Domain Users' we have to reject all >Kerberos request because the resulting PAC will not have a primary >group. Yep. Though I've seen some environments where people did actually change the primary group for AD users to something else. AD environments can be broken in a multitude of interesting ways. ;) -- / Alexander Bokovoy From Warren.Birnbaum at nike.com Mon Feb 15 09:34:33 2016 From: Warren.Birnbaum at nike.com (Birnbaum, Warren (ETW)) Date: Mon, 15 Feb 2016 09:34:33 +0000 Subject: [Freeipa-users] Question about ldap proxy/AD + sudo + HBAC Message-ID: Hello, I would like to get freeipa to work with a proxy solution ( I currently have this working with an active directory/no trust authentication and sudo but no HBAC) including HBAC. I can get sudo to work but not HBAC. I see there is a ticket for this as a new enhancement #4634 but wanted to confirm that there isn't another way to accomplish this. Here is my current configuration for proxy and this works OK: [domain/mikey.com] sudo_provider = ipa ipa_domain = va2.b2c.mikey.com id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = ip-10-12-177-28.va2.b2c.mikey.com chpass_provider = ipa ipa_server = _srv_, ip-10-12-177-24.va2.b2c.mikey.com ldap_tls_cacert = /etc/ipa/ca.crt id_provider = proxy proxy_lib_name = files auth_provider = ldap reconnection_retries = 3 ldap_uri = ldap://adldaplb.mikey.com ldap_search_base = dc=ad,dc=mikey,dc=com?subtree? ldap_schema = AD ldap_default_authtok_type = password ldap_network_timeout = 120 ldap_opt_timeout = 120 ldap_search_timeout = 120 ldap_id_use_start_tls = false ldap_user_object_class = user ldap_group_object_class = group ldap_user_name = sAMAccountName enumerate = true ldap_referrals = true ldap_tls_reqcert = allow ldap_tls_cacertdir = /etc/openldap/cacerts ldap_access_filter = * case_sensitive = false lookup_family_order = ipv4_only dns_resolver_timeout = 30 cache_credentials = false Thanks for your help, Warren Birnbaum -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbose at redhat.com Mon Feb 15 09:54:26 2016 From: sbose at redhat.com (Sumit Bose) Date: Mon, 15 Feb 2016 10:54:26 +0100 Subject: [Freeipa-users] Active Directory Trust = filter users In-Reply-To: <20160215091041.GA4492@redhat.com> References: <56B9C666.9000302@dds.nl> <20160210084228.GY29883@hendrix.redhat.com> <56BB2B30.108@dds.nl> <20160210124646.GE28065@redhat.com> <6071ced0e74ac185b5819d96d898cd9d@dds.nl> <20160212112947.GG28898@redhat.com> <20160212181221.GU29883@hendrix.redhat.com> <20160212204936.GK28898@redhat.com> <20160215090301.GS12933@p.redhat.com> <20160215091041.GA4492@redhat.com> Message-ID: <20160215095426.GT12933@p.redhat.com> On Mon, Feb 15, 2016 at 11:10:41AM +0200, Alexander Bokovoy wrote: > On Mon, 15 Feb 2016, Sumit Bose wrote: > >On Fri, Feb 12, 2016 at 10:49:36PM +0200, Alexander Bokovoy wrote: > >>On Fri, 12 Feb 2016, Jakub Hrozek wrote: > >>>On Fri, Feb 12, 2016 at 01:29:47PM +0200, Alexander Bokovoy wrote: > >>>>On Fri, 12 Feb 2016, wdh at dds.nl wrote: > >>>>>Hi all, > >>>>> > >>>>>Yes, you can filter out certain SIDs--> I tried, but cannot get it to > >>>>>work. For example, I don't need "Domain Users": > >>>>> > >>>>>Found out the SID by: > >>>>> > >>>>>[root at suacri10103 ~]# getent group domain\ users at ad.example.org > >>>>>domain users at example.org:*:1012600513:someuser at ad.example.org > >>>>>[root at suacri10103 ~]# ldbsearch -H > >>>>>/var/lib/sss/db/cache_ipa.ad%s/example.org.ldb gidNumber=1012600513 | > >>>>>grep objectSIDString > >>>>>asq: Unable to register control with rootdse! > >>>>>objectSIDString: S-1-5-21-1447349426-2906170142-3196411423-513 > >>>>> > >>>>>and put the SID in the blacklist; yes it is blacklisted: > >>>>> > >>>>>admin01 at ipa ~]$ ipa trust-show ad.example.com --all | grep "SID blacklist > >>>>>incoming" > >>>>> SID blacklist incoming: S-1-5-20, > >>>>>S-1-5-21-1447349426-2906170142-3196411423-513, S-1-5-3, S-1-5-2, S-1-5-1, > >>>>>S-1-5-7, S-1-5-6, S-1-5-5, S-1-5-4, S-1-5-9, S-1-5-8, S-1-5-17, S-1-5-16, > >>>>>S-1-5-15, S-1-5-14, S-1-5-13, S-1-5-12, S-1-5-11, S-1-5-10, S-1-3, S-1-2, > >>>>>S-1-1, S-1-0, S-1-5-19, S-1-5-18 > >>>>> > >>>>>However, the group is still there if I do a n "id someuser at ad.example.com" > >>>>>(yep, whiped cache, restarted ipa etc.) > >>>>> > >>>>>Shouldn't the group be disappeared since the SID is blacklisted...? > >>>>Only from Kerberos tickets. I don't think SSSD in ipa_server_mode > >>>>consults this list. Instead, when AD users logins with Kerberos ticket, > >>>>the resulting ticket already has blacklisted SIDs filtered out by IPA > >>>>KDC and SSSD will see that these tickets' MS-PAC doesn't have additional > >>>>groups in it. > >>> > >>>Alexander, do you think this would make a reasonable RFE? > >>For non-logged-in case? Yes, it certainly makes sense as it would be > >>consistent with KDC then. The only potential issue is that we'd lose > >>'true' group membership for IPA CLI/Web UI operations as removing > >>'Domain users at AD.TEST' would make it impossible to assign anything to > >>'Domain users at AD.TEST' in ID overrides and external group members, but > >>given it is actually filtered out at the level of a trust boundary, may > >>be this is exactly what a person would like to achieve? > > > >yes, I think we have to add support in SSSD for this to be consistent > >with the group memberships we get from the PAC. But since we in general > >cannot ignore the groups completely it might be sufficient to just label > >the filtered groups as non-POSIX groups in the cache (maybe we need an > >additional flag to indicate that the group is really filtered out to > >make sure that future lookup schemes which might include non-POSIX > >groups will ignore the filtered groups as well). > Marking it non-POSIX wouldn't prevent nested group membership, though. > This obviously needs more thought... yes, but I think this would be in agreement to the filtering in the PAC because here we filter only the SID from this blacklist and not the SIDs of groups nested in the related group. bye, Sumit > > >Btw, the 'Domain Users' group is a bad example here, because it is in > >general the primary group of the AD users in AD and hence listed in the > >PAC as primary group. If you filter 'Domain Users' we have to reject all > >Kerberos request because the resulting PAC will not have a primary > >group. > Yep. Though I've seen some environments where people did actually change > the primary group for AD users to something else. AD environments can be > broken in a multitude of interesting ways. ;) > > -- > / Alexander Bokovoy From lkrispen at redhat.com Mon Feb 15 10:06:39 2016 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Mon, 15 Feb 2016 11:06:39 +0100 Subject: [Freeipa-users] Failed to setup replica, slapi_ldap_bind fails In-Reply-To: <20160212172258.GB5760@eru> References: <20160208170505.GE4331@eru> <20160212140613.GC16168@eru> <56BDEA8F.2040506@redhat.com> <20160212143503.GD16168@eru> <56BE00E1.5080303@redhat.com> <20160212172258.GB5760@eru> Message-ID: <56C1A32F.4010107@redhat.com> On 02/12/2016 06:22 PM, Filip Pytloun wrote: > Following is in /etc/ldap/ldap.conf on both servers (only URI differs): what is your OS, do you also have a /etc/openldap/ldap.conf ldapsearch and the replication connection shoudl use the same openldap libraries and so it is strange that -ZZ works and indside ds doesn't. At what point did your replica install fail, is there any hint in the replica install log ? > > TLS_CACERT /etc/ipa/ca.crt > TLS_REQCERT allow > URI ldaps://idm02.tcpcloud.eu > BASE dc=tcpcloud,dc=eu > > As ldapsearch is passing just fine on both nodes, I don't suppose > ldap.conf is wrong. > I also tried to set TLS_REQCERT to allow just to be sure (in case that > bad cert is provided). > > On 2016/02/12 16:57, Ludwig Krispenz wrote: >> On 02/12/2016 03:35 PM, Filip Pytloun wrote: >>> It's the same as for idm01: >>> >>> [12/Feb/2016:15:24:26 +0100] NSMMReplicationPlugin - agmt="cn=meToidm01.tcpcloud.eu" (idm01:389): Replication bind with SIMPLE auth failed: LDAP error -11 (Connect error) ((unknown error code)) >>> [12/Feb/2016:15:24:27 +0100] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) >> you can get this connect error if the client side cannot verify the cert the >> server sends, could you check what you have in f >> >>> In access logs I can't read much interesting, just that TLS connection happened from idm01: >>> >>> [12/Feb/2016:15:33:11 +0100] conn=14 fd=64 slot=64 connection from 185.22.97.19 to 172.10.10.192 >>> [12/Feb/2016:15:33:11 +0100] conn=14 op=0 EXT oid="1.3.6.1.4.1.1466.20037" name="startTLS" >>> [12/Feb/2016:15:33:11 +0100] conn=14 op=0 RESULT err=0 tag=120 nentries=0 etime=0 >>> [12/Feb/2016:15:33:11 +0100] conn=14 TLS1.2 128-bit AES-GCM >>> [12/Feb/2016:15:33:11 +0100] conn=14 op=-1 fd=64 closed - B1 >>> [12/Feb/2016:15:33:59 +0100] conn=15 fd=64 slot=64 connection from 185.22.97.19 to 172.10.10.192 >>> [12/Feb/2016:15:33:59 +0100] conn=15 op=0 EXT oid="1.3.6.1.4.1.1466.20037" name="startTLS" >>> [12/Feb/2016:15:33:59 +0100] conn=15 op=0 RESULT err=0 tag=120 nentries=0 etime=0 >>> [12/Feb/2016:15:34:00 +0100] conn=15 TLS1.2 128-bit AES-GCM >>> [12/Feb/2016:15:34:00 +0100] conn=15 op=-1 fd=64 closed - B1 >>> >>> On 2016/02/12 15:22, Ludwig Krispenz wrote: >>>> On 02/12/2016 03:06 PM, Filip Pytloun wrote: >>>>> Hello, >>>>> >>>>> even when enabling replication logging, I get nothing useful in logs: >>>>> >>>>> [12/Feb/2016:14:57:00 +0100] NSMMReplicationPlugin - agmt="cn=meToidm02.tcpcloud.eu" (idm02:389): Trying secure startTLS slapi_ldap_init_ext >>>>> [12/Feb/2016:14:57:00 +0100] NSMMReplicationPlugin - agmt="cn=meToidm02.tcpcloud.eu" (idm02:389): binddn = cn=replication manager,cn=config, passwd = {AES-some_encrypted_password >>>>> [12/Feb/2016:14:57:01 +0100] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) >>>>> [12/Feb/2016:14:57:01 +0100] NSMMReplicationPlugin - agmt="cn=meToidm02.tcpcloud.eu" (idm02:389): Replication bind with SIMPLE auth failed: LDAP error -11 (Connect error) ((unknown error code)) >>>>> [12/Feb/2016:14:57:01 +0100] NSMMReplicationPlugin - agmt="cn=meToidm02.tcpcloud.eu" (idm02:389): Disconnected from the consumer >>>> what is in the access and error logs of idm02 for this time ? >>>>> But I can bind just fine manually: >>>>> >>>>> ldapsearch -D "cn=replication manager,cn=config" -w some_password -b cn=config -h idm02 -ZZ >>>>> >>>>> I am starting to be clueless, nobody has an idea what could be wrong? >>>>> >>>>> - DNS including PTR records are set up fine >>>>> - /etc/hosts is setup fine >>>>> - conncheck passes fine between nodes >>>>> - I can bind manually just fine >>>>> >>>>> On 2016/02/08 18:05, Filip Pytloun wrote: >>>>>> Hello, >>>>>> >>>>>> I have a weird issue setting up FreeIPA replica. Conncheck passes fine >>>>>> but at the end of ipa-replica-install I always get following error: >>>>>> >>>>>> slapi_ldap_bind -Error: could not send startTLS request: error -11 >>>>>> (Connect error) errno 0 (Success) >>>>>> >>>>>> on both master and replica without any further explanation in logs. >>>>>> >>>>>> /etc/ldap.conf is correctly setup before ipa-replica-install and IPA CA >>>>>> certificate is installed in system CA bundle so TLS should work just >>>>>> fine. >>>>>> >>>>>> Also I can manually connect just fine from replica to master and back so >>>>>> it's not a network or LDAP client issue. >>>>>> >>>>>> Replica agreement looks like this: http://pastebin.com/FT3p3KUk >>>>>> >>>>>> freeipa-server 4.1.4 >>>>>> 389-ds 1.3.4.5 >>>>>> >>>>>> Has anyone idea where to look at? >>>>>> >>>>>> Filip >>>>> >>>> -- >>>> Manage your subscription for the Freeipa-users mailing list: >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>> Go to http://freeipa.org for more info on the project >>> >> -- >> Manage your subscription for the Freeipa-users mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-users >> Go to http://freeipa.org for more info on the project From filip at pytloun.cz Mon Feb 15 10:14:08 2016 From: filip at pytloun.cz (Filip Pytloun) Date: Mon, 15 Feb 2016 11:14:08 +0100 Subject: [Freeipa-users] Failed to setup replica, slapi_ldap_bind fails In-Reply-To: <56C1A32F.4010107@redhat.com> References: <20160208170505.GE4331@eru> <20160212140613.GC16168@eru> <56BDEA8F.2040506@redhat.com> <20160212143503.GD16168@eru> <56BE00E1.5080303@redhat.com> <20160212172258.GB5760@eru> <56C1A32F.4010107@redhat.com> Message-ID: <20160215101408.GC30322@eru> I am using Ubuntu 16.04 (Xenial), there's no /etc/openldap Here's complete debug log of replica install: http://pastebin.com/38zi5MWd Now I noticed following, don't know if it can directly relate to this issue: ipa : DEBUG stderr=ldap_initialize( ldap://idm02.tcpcloud.eu:389/??base ) ldap_modify: Server is unwilling to perform (53) ipa : CRITICAL Failed to load indices.ldif: Command ''/usr/bin/ldapmodify' '-v' '-f' '/usr/share/ipa/indices.ldif' '-H' 'ldap://idm02.tcpcloud.eu:389' '-x' '-D' 'cn=Directory Manager' '-y' '/tmp/tmpIV39iM'' returned non-zero exit status 53 On 2016/02/15 11:06, Ludwig Krispenz wrote: > > On 02/12/2016 06:22 PM, Filip Pytloun wrote: > >Following is in /etc/ldap/ldap.conf on both servers (only URI differs): > what is your OS, do you also have a /etc/openldap/ldap.conf > > ldapsearch and the replication connection shoudl use the same openldap > libraries and so it is strange that -ZZ works and indside ds doesn't. > > At what point did your replica install fail, is there any hint in the > replica install log ? > > > >TLS_CACERT /etc/ipa/ca.crt > >TLS_REQCERT allow > >URI ldaps://idm02.tcpcloud.eu > >BASE dc=tcpcloud,dc=eu > > > >As ldapsearch is passing just fine on both nodes, I don't suppose > >ldap.conf is wrong. > >I also tried to set TLS_REQCERT to allow just to be sure (in case that > >bad cert is provided). > > > >On 2016/02/12 16:57, Ludwig Krispenz wrote: > >>On 02/12/2016 03:35 PM, Filip Pytloun wrote: > >>>It's the same as for idm01: > >>> > >>>[12/Feb/2016:15:24:26 +0100] NSMMReplicationPlugin - agmt="cn=meToidm01.tcpcloud.eu" (idm01:389): Replication bind with SIMPLE auth failed: LDAP error -11 (Connect error) ((unknown error code)) > >>>[12/Feb/2016:15:24:27 +0100] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) > >>you can get this connect error if the client side cannot verify the cert the > >>server sends, could you check what you have in f > >> > >>>In access logs I can't read much interesting, just that TLS connection happened from idm01: > >>> > >>>[12/Feb/2016:15:33:11 +0100] conn=14 fd=64 slot=64 connection from 185.22.97.19 to 172.10.10.192 > >>>[12/Feb/2016:15:33:11 +0100] conn=14 op=0 EXT oid="1.3.6.1.4.1.1466.20037" name="startTLS" > >>>[12/Feb/2016:15:33:11 +0100] conn=14 op=0 RESULT err=0 tag=120 nentries=0 etime=0 > >>>[12/Feb/2016:15:33:11 +0100] conn=14 TLS1.2 128-bit AES-GCM > >>>[12/Feb/2016:15:33:11 +0100] conn=14 op=-1 fd=64 closed - B1 > >>>[12/Feb/2016:15:33:59 +0100] conn=15 fd=64 slot=64 connection from 185.22.97.19 to 172.10.10.192 > >>>[12/Feb/2016:15:33:59 +0100] conn=15 op=0 EXT oid="1.3.6.1.4.1.1466.20037" name="startTLS" > >>>[12/Feb/2016:15:33:59 +0100] conn=15 op=0 RESULT err=0 tag=120 nentries=0 etime=0 > >>>[12/Feb/2016:15:34:00 +0100] conn=15 TLS1.2 128-bit AES-GCM > >>>[12/Feb/2016:15:34:00 +0100] conn=15 op=-1 fd=64 closed - B1 > >>> > >>>On 2016/02/12 15:22, Ludwig Krispenz wrote: > >>>>On 02/12/2016 03:06 PM, Filip Pytloun wrote: > >>>>>Hello, > >>>>> > >>>>>even when enabling replication logging, I get nothing useful in logs: > >>>>> > >>>>>[12/Feb/2016:14:57:00 +0100] NSMMReplicationPlugin - agmt="cn=meToidm02.tcpcloud.eu" (idm02:389): Trying secure startTLS slapi_ldap_init_ext > >>>>>[12/Feb/2016:14:57:00 +0100] NSMMReplicationPlugin - agmt="cn=meToidm02.tcpcloud.eu" (idm02:389): binddn = cn=replication manager,cn=config, passwd = {AES-some_encrypted_password > >>>>>[12/Feb/2016:14:57:01 +0100] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) > >>>>>[12/Feb/2016:14:57:01 +0100] NSMMReplicationPlugin - agmt="cn=meToidm02.tcpcloud.eu" (idm02:389): Replication bind with SIMPLE auth failed: LDAP error -11 (Connect error) ((unknown error code)) > >>>>>[12/Feb/2016:14:57:01 +0100] NSMMReplicationPlugin - agmt="cn=meToidm02.tcpcloud.eu" (idm02:389): Disconnected from the consumer > >>>>what is in the access and error logs of idm02 for this time ? > >>>>>But I can bind just fine manually: > >>>>> > >>>>>ldapsearch -D "cn=replication manager,cn=config" -w some_password -b cn=config -h idm02 -ZZ > >>>>> > >>>>>I am starting to be clueless, nobody has an idea what could be wrong? > >>>>> > >>>>>- DNS including PTR records are set up fine > >>>>>- /etc/hosts is setup fine > >>>>>- conncheck passes fine between nodes > >>>>>- I can bind manually just fine > >>>>> > >>>>>On 2016/02/08 18:05, Filip Pytloun wrote: > >>>>>>Hello, > >>>>>> > >>>>>>I have a weird issue setting up FreeIPA replica. Conncheck passes fine > >>>>>>but at the end of ipa-replica-install I always get following error: > >>>>>> > >>>>>>slapi_ldap_bind -Error: could not send startTLS request: error -11 > >>>>>>(Connect error) errno 0 (Success) > >>>>>> > >>>>>>on both master and replica without any further explanation in logs. > >>>>>> > >>>>>>/etc/ldap.conf is correctly setup before ipa-replica-install and IPA CA > >>>>>>certificate is installed in system CA bundle so TLS should work just > >>>>>>fine. > >>>>>> > >>>>>>Also I can manually connect just fine from replica to master and back so > >>>>>>it's not a network or LDAP client issue. > >>>>>> > >>>>>>Replica agreement looks like this: http://pastebin.com/FT3p3KUk > >>>>>> > >>>>>>freeipa-server 4.1.4 > >>>>>>389-ds 1.3.4.5 > >>>>>> > >>>>>>Has anyone idea where to look at? > >>>>>> > >>>>>>Filip > >>>>> > >>>>-- > >>>>Manage your subscription for the Freeipa-users mailing list: > >>>>https://www.redhat.com/mailman/listinfo/freeipa-users > >>>>Go to http://freeipa.org for more info on the project > >>> > >>-- > >>Manage your subscription for the Freeipa-users mailing list: > >>https://www.redhat.com/mailman/listinfo/freeipa-users > >>Go to http://freeipa.org for more info on the project > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From jhrozek at redhat.com Mon Feb 15 10:15:07 2016 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 15 Feb 2016 11:15:07 +0100 Subject: [Freeipa-users] Connection closed by UNKNOWN In-Reply-To: References: <20160213111108.GE29883@hendrix.redhat.com> Message-ID: <20160215101507.GE7612@hendrix.lan> On Mon, Feb 15, 2016 at 10:24:23AM +0530, Rakesh Rajasekharan wrote: > hbac seems to be fine > > > ipa hbactest --user=q-temp --host=x.x.x.x --service=sshd > -------------------- > Access granted: True > -------------------- > Matched rules: allow_all > > > I see this in the sssd.log > > (Mon Feb 15 04:49:18 2016) [sssd[nss]] [sss_ncache_check_str] (0x2000): > Checking negative cache for [NCE/USER/xyz.com/q-temp] > (Mon Feb 15 04:49:18 2016) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): > Requesting info for [q-temp at xyz.com] > (Mon Feb 15 04:49:18 2016) [sssd[nss]] [check_cache] (0x0400): Cached entry > is valid, returning.. > (Mon Feb 15 04:49:18 2016) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0400): > Returning info for user [q-temp at xyz.com] > (Mon Feb 15 04:49:18 2016) [sssd[nss]] [client_recv] (0x0200): Client > disconnected! > (Mon Feb 15 04:49:18 2016) [sssd[nss]] [client_destructor] (0x2000): > Terminated client [0x23d2f80][20] > (Mon Feb 15 04:49:27 2016) [sssd[nss]] [sbus_get_sender_id_send] (0x2000): > Not a sysbus message, quit What does /var/log/secure say? Also you pasted the NSS log, the domain log would be more useful here. From jhrozek at redhat.com Mon Feb 15 10:31:13 2016 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 15 Feb 2016 11:31:13 +0100 Subject: [Freeipa-users] Question about ldap proxy/AD + sudo + HBAC In-Reply-To: References: Message-ID: <20160215103113.GI7612@hendrix.lan> On Mon, Feb 15, 2016 at 09:34:33AM +0000, Birnbaum, Warren (ETW) wrote: > Hello, > > I would like to get freeipa to work with a proxy solution ( I currently have this working with an active directory/no trust authentication and sudo but no HBAC) including HBAC. I can get sudo to work but not HBAC. I see there is a ticket for this as a new enhancement #4634 but wanted to confirm that there isn't another way to accomplish this. > > Here is my current configuration for proxy and this works OK: I've used the proxy hack to enable sudo for local (=/etc/passwd) users with LDAP sudoers and it just worked. Can you try following: https://fedorahosted.org/sssd/wiki/HOWTO_Troubleshoot_SUDO and see which part does not work? From Warren.Birnbaum at nike.com Mon Feb 15 11:24:08 2016 From: Warren.Birnbaum at nike.com (Birnbaum, Warren (ETW)) Date: Mon, 15 Feb 2016 11:24:08 +0000 Subject: [Freeipa-users] Question about ldap proxy/AD + sudo + HBAC In-Reply-To: <20160215103113.GI7612@hendrix.lan> References: <20160215103113.GI7612@hendrix.lan> Message-ID: Hi Jakub, Thanks but I have sudo working OK. What I am trying make work is HBAC. That I can?t get to work with the proxy hack. Is there a way to do that? Thanks, Warren ___________________ Warren Birnbaum : Infrastructure Services Digital Linux Infrastructure Services Europe CDT Techn. Operations Nike Inc. : Mobile +31 6 23902697 On 2/15/16, 11:31 AM, "freeipa-users-bounces at redhat.com on behalf of Jakub Hrozek" wrote: >On Mon, Feb 15, 2016 at 09:34:33AM +0000, Birnbaum, Warren (ETW) wrote: >> Hello, >> >> I would like to get freeipa to work with a proxy solution ( I currently >>have this working with an active directory/no trust authentication and >>sudo but no HBAC) including HBAC. I can get sudo to work but not HBAC. >>I see there is a ticket for this as a new enhancement #4634 but wanted >>to confirm that there isn't another way to accomplish this. >> >> Here is my current configuration for proxy and this works OK: > >I've used the proxy hack to enable sudo for local (=/etc/passwd) users >with LDAP sudoers and it just worked. Can you try following: > https://fedorahosted.org/sssd/wiki/HOWTO_Troubleshoot_SUDO >and see which part does not work? > >-- >Manage your subscription for the Freeipa-users mailing list: >https://www.redhat.com/mailman/listinfo/freeipa-users >Go to http://freeipa.org for more info on the project From lslebodn at redhat.com Mon Feb 15 11:36:18 2016 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Mon, 15 Feb 2016 12:36:18 +0100 Subject: [Freeipa-users] Question about ldap proxy/AD + sudo + HBAC In-Reply-To: References: Message-ID: <20160215113617.GF25417@mail.corp.redhat.com> On (15/02/16 09:34), Birnbaum, Warren (ETW) wrote: >Hello, > >I would like to get freeipa to work with a proxy solution ( I currently have this working with an active directory/no trust authentication and sudo but no HBAC) including HBAC. I can get sudo to work but not HBAC. I see there is a ticket for this as a new enhancement #4634 but wanted to confirm that there isn't another way to accomplish this. > >Here is my current configuration for proxy and this works OK: > >[domain/mikey.com] >sudo_provider = ipa >ipa_domain = va2.b2c.mikey.com >id_provider = ipa >auth_provider = ipa >access_provider = ipa >ipa_hostname = ip-10-12-177-28.va2.b2c.mikey.com >chpass_provider = ipa >ipa_server = _srv_, ip-10-12-177-24.va2.b2c.mikey.com >ldap_tls_cacert = /etc/ipa/ca.crt > >id_provider = proxy >proxy_lib_name = files >auth_provider = ldap >reconnection_retries = 3 >ldap_uri = ldap://adldaplb.mikey.com >ldap_search_base = dc=ad,dc=mikey,dc=com?subtree? >ldap_schema = AD >ldap_default_authtok_type = password >ldap_network_timeout = 120 >ldap_opt_timeout = 120 >ldap_search_timeout = 120 >ldap_id_use_start_tls = false >ldap_user_object_class = user >ldap_group_object_class = group >ldap_user_name = sAMAccountName >enumerate = true >ldap_referrals = true >ldap_tls_reqcert = allow >ldap_tls_cacertdir = /etc/openldap/cacerts >ldap_access_filter = * >case_sensitive = false >lookup_family_order = ipv4_only >dns_resolver_timeout = 30 >cache_credentials = false > This configuration file is a little bit suspicious to me. There is mixed/overriden id_provider ipa and proxy + some parts from AD. HBAC can work only with IPA users or trusted AD users (IPA AD trust) HBAC cannot work with id_provider ldap, proxy or AD. You can achieve something similar with GPO and ad provider. LS From pspacek at redhat.com Mon Feb 15 11:36:29 2016 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 15 Feb 2016 12:36:29 +0100 Subject: [Freeipa-users] BIND apparently not loading ldap.so In-Reply-To: <56BE374B.4000700@etriptrader.com> References: <77c8b66eb6614184b9d80045cae4d0c6@etriptrader.com> <56BC586F.4080902@redhat.com> <56BCD3D9.2050405@etriptrader.com> <56BD8F89.3060008@redhat.com> <56BE374B.4000700@etriptrader.com> Message-ID: <56C1B83D.7090805@redhat.com> On 12.2.2016 20:49, Chris Lajoie wrote: > On 02/12/2016 12:53 AM, Petr Spacek wrote: >> On 11.2.2016 19:32, Chris Lajoie wrote: >>> On 02/11/2016 02:46 AM, Petr Spacek wrote: >>>> What version of BIND and bind-dyndb-ldap packages are you using? $ rpm >>>> -q bind bind-dyndb-ldap >>> bind-9.9.4-29.el7_2.2.x86_64 bind-dyndb-ldap-8.0-1.el7.x86_64 >>>> I'm not sure how exactly the logging magic in BIND works so I would >>>> recommend you to to run BIND using command: $ named -g -u named and >>>> check output in the console to see if it contains line like >>>> 'bind-dyndb-ldap version 8.0 compiled at 16:09:02 Jan 20 2016, >>>> compiler 5.3.1 20151207 (Red Hat 5.3.1-2)' >>> I get nothing like that. Here is the output I get from running named: >>> https://gist.github.com/ctlajoie/0ed4e97e72aec3172a8d >> Oh, wait, it seems that you are using views! >> >> Generally we do not test bind-dyndb-ldap with views so there be dragons. >> >> Could you share your named.conf with us? >> >> If you do not want to send it to mailing list feel free to send it to me >> privately. My GPG key is attached just for the case you wish to encrypt it. > > Sure. I do not see anything in my named.conf besides the ldap password (which > I changed) that should be kept private. > https://gist.github.com/ctlajoie/827a2ec9cfa70e3a1ebd > > Not sure if it matters any more though.. I was able to get it working by > commenting out the view parts and leaving only the zones. Unfortunately the > plugin seems unable or unwilling to load if there are any views present at > all. I also tried placing the dynamic-db section inside of one of the views. > named will accept the configuration and start up, but again there are no ldap > log messages. > > I would really like to use ldap as the backend for my DNS configuration... its > heirarchical nature seems (to me) to be a good fit for storing that type of > thing. It is surprising to me that almost nobody else does it this way (from > what I can tell). I suppose if I want to do it then I will need to run > seperate instances of bind, either on different servers or the same server > using different ports for each instance, and doing some NATing with iptables. > Either method complicates things more than I would like... > > Can you speculate on why there would be no log messages at all when the ldap > plugin fails to load (if that is indeed what is happening)? > If there was something in the log it would have saved me quite a bit of time > investigating this. Thank you for helping me track down the problem. Interesting, this is a bug in integration with BIND. It works just fine if dynamic-db part is inside a view {};. If there is no view explicitly defined then BIND is using implicit view "_default". It does not work if you have some views explicitly defined and dynamic-db section is defined outside of any view. It means that dynamic-db section does not belong to any view and init() is not called for it. So, workaround is to put dynamic-db section to a view. I hope it helps. -- Petr^2 Spacek From Warren.Birnbaum at nike.com Mon Feb 15 11:45:58 2016 From: Warren.Birnbaum at nike.com (Birnbaum, Warren (ETW)) Date: Mon, 15 Feb 2016 11:45:58 +0000 Subject: [Freeipa-users] Question about ldap proxy/AD + sudo + HBAC In-Reply-To: <20160215113617.GF25417@mail.corp.redhat.com> References: <20160215113617.GF25417@mail.corp.redhat.com> Message-ID: Thanks Lukas. Unfortunately setting up a IPA Ad Trust is something not possible within our organization. Is it then fair to say that waiting for Ticket #4623 is our only option? https://fedorahosted.org/freeipa/ticket/4634 Thanks, Warren ___________________ Warren Birnbaum : Infrastructure Services Digital Linux Infrastructure Services Europe CDT Techn. Operations Nike Inc. : Mobile +31 6 23902697 On 2/15/16, 12:36 PM, "Lukas Slebodnik" wrote: >On (15/02/16 09:34), Birnbaum, Warren (ETW) wrote: >>Hello, >> >>I would like to get freeipa to work with a proxy solution ( I currently >>have this working with an active directory/no trust authentication and >>sudo but no HBAC) including HBAC. I can get sudo to work but not HBAC. >>I see there is a ticket for this as a new enhancement #4634 but wanted >>to confirm that there isn't another way to accomplish this. >> >>Here is my current configuration for proxy and this works OK: >> >>[domain/mikey.com] >>sudo_provider = ipa >>ipa_domain = va2.b2c.mikey.com >>id_provider = ipa >>auth_provider = ipa >>access_provider = ipa >>ipa_hostname = ip-10-12-177-28.va2.b2c.mikey.com >>chpass_provider = ipa >>ipa_server = _srv_, ip-10-12-177-24.va2.b2c.mikey.com >>ldap_tls_cacert = /etc/ipa/ca.crt >> >>id_provider = proxy >>proxy_lib_name = files >>auth_provider = ldap >>reconnection_retries = 3 >>ldap_uri = ldap://adldaplb.mikey.com >>ldap_search_base = dc=ad,dc=mikey,dc=com?subtree? >>ldap_schema = AD >>ldap_default_authtok_type = password >>ldap_network_timeout = 120 >>ldap_opt_timeout = 120 >>ldap_search_timeout = 120 >>ldap_id_use_start_tls = false >>ldap_user_object_class = user >>ldap_group_object_class = group >>ldap_user_name = sAMAccountName >>enumerate = true >>ldap_referrals = true >>ldap_tls_reqcert = allow >>ldap_tls_cacertdir = /etc/openldap/cacerts >>ldap_access_filter = * >>case_sensitive = false >>lookup_family_order = ipv4_only >>dns_resolver_timeout = 30 >>cache_credentials = false >> >This configuration file is a little bit suspicious to me. >There is mixed/overriden id_provider ipa and proxy + some parts from AD. > >HBAC can work only with IPA users or trusted AD users (IPA AD trust) >HBAC cannot work with id_provider ldap, proxy or AD. >You can achieve something similar with GPO and ad provider. > >LS From abokovoy at redhat.com Mon Feb 15 11:52:42 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 15 Feb 2016 13:52:42 +0200 Subject: [Freeipa-users] Question about ldap proxy/AD + sudo + HBAC In-Reply-To: References: <20160215113617.GF25417@mail.corp.redhat.com> Message-ID: <20160215115242.GD4492@redhat.com> On Mon, 15 Feb 2016, Birnbaum, Warren (ETW) wrote: >Thanks Lukas. > >Unfortunately setting up a IPA Ad Trust is something not possible within >our organization. Is it then fair to say that waiting for Ticket #4623 is >our only option? https://fedorahosted.org/freeipa/ticket/4634 This ticket is not going to be implemented in a near future. It has huge development cost while very little benefits. I don't think it is going to be something you can rely on. -- / Alexander Bokovoy From Warren.Birnbaum at nike.com Mon Feb 15 11:58:24 2016 From: Warren.Birnbaum at nike.com (Birnbaum, Warren (ETW)) Date: Mon, 15 Feb 2016 11:58:24 +0000 Subject: [Freeipa-users] Question about ldap proxy/AD + sudo + HBAC In-Reply-To: <20160215115242.GD4492@redhat.com> References: <20160215113617.GF25417@mail.corp.redhat.com> <20160215115242.GD4492@redhat.com> Message-ID: Alexander, Thanks for letting me know this. Is it true then that my only option is to have the IPA AD trust to achieve AD authentication (proxy style), HBAC and sudo? Thanks ___________________ Warren Birnbaum : Infrastructure Services Digital Linux Infrastructure Services Europe CDT Techn. Operations Nike Inc. : Mobile +31 6 23902697 On 2/15/16, 12:52 PM, "Alexander Bokovoy" wrote: >On Mon, 15 Feb 2016, Birnbaum, Warren (ETW) wrote: >>Thanks Lukas. >> >>Unfortunately setting up a IPA Ad Trust is something not possible within >>our organization. Is it then fair to say that waiting for Ticket #4623 >>is >>our only option? https://fedorahosted.org/freeipa/ticket/4634 >This ticket is not going to be implemented in a near future. It has >huge development cost while very little benefits. I don't think it is >going to be something you can rely on. > >-- >/ Alexander Bokovoy From lslebodn at redhat.com Mon Feb 15 12:01:17 2016 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Mon, 15 Feb 2016 13:01:17 +0100 Subject: [Freeipa-users] Question about ldap proxy/AD + sudo + HBAC In-Reply-To: References: <20160215113617.GF25417@mail.corp.redhat.com> Message-ID: <20160215120116.GG25417@mail.corp.redhat.com> On (15/02/16 11:45), Birnbaum, Warren (ETW) wrote: >Thanks Lukas. > >Unfortunately setting up a IPA Ad Trust is something not possible within >our organization. Is it then fair to say that waiting for Ticket #4623 is >our only option? https://fedorahosted.org/freeipa/ticket/4634 > As I wrote in previous mail HBAC can work only with id_provider = ipa. and GPO works only with id_provider = ad. Your configuration is little bit non-standard id_provider = proxy (to files) and auth provider LDAP (AD). I can only recommend to look into pam_access.so. LS From abokovoy at redhat.com Mon Feb 15 12:09:02 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 15 Feb 2016 14:09:02 +0200 Subject: [Freeipa-users] Question about ldap proxy/AD + sudo + HBAC In-Reply-To: References: <20160215113617.GF25417@mail.corp.redhat.com> <20160215115242.GD4492@redhat.com> Message-ID: <20160215120902.GF4492@redhat.com> On Mon, 15 Feb 2016, Birnbaum, Warren (ETW) wrote: >Alexander, > >Thanks for letting me know this. Is it true then that my only option is >to have the IPA AD trust to achieve AD authentication (proxy style), HBAC >and sudo? I'm not sure using 'proxy' term is actually helpful here. IPA does not work as a proxy authentication when it trusts AD forest. All authentication happens directly against AD domain controllers, and IPA is only used to host resources specific to Linux deployments. Given that HBAC is a feature of IPA, not AD, you cannot have HBAC working in other configurations. -- / Alexander Bokovoy From pspacek at redhat.com Mon Feb 15 12:26:29 2016 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 15 Feb 2016 13:26:29 +0100 Subject: [Freeipa-users] How to reference to IPA Server in Multi-Master Setup ? In-Reply-To: References: <56A60141.6090606@redhat.com> <56A60B1C.6070503@redhat.com> Message-ID: <56C1C3F5.4040707@redhat.com> On 26.1.2016 13:18, Zeal Vora wrote: > Thanks David. > > Generally for Operating systems like Amazon Linux etc which does not have a > IPA-Client, we generally use SSSD to get things working. > > In such cases, what would be optimal way to configure the SRV records as > --domain parameter won't be present. Hi, ipa-client just configures SSSD, so SRV records will work just fine if you configure it by hand. Anyway, I would recommend you either to push Amazon to include IPA support in their distro or to use RHEL/CentOS in AWS. Petr^2 Spacek > On Mon, Jan 25, 2016 at 5:16 PM, David Kupka wrote: > >> On 25/01/16 12:08, Zeal Vora wrote: >> >>> Thanks Petr. >>> >>> So if the domain is example.com, in DNS, what would be the IP associated >>> with it ? >>> >>> As there are 2 master servers, each of them will have different IP >>> address. >>> >>> On Mon, Jan 25, 2016 at 4:34 PM, Petr Spacek wrote: >>> >>> On 25.1.2016 10:47, Zeal Vora wrote: >>>> >>>>> Hi >>>>> >>>>> I have setup a multi-master IPA and it seems to be working fine. >>>>> >>>>> The clients ( laptops and servers ) are not using the DNS of IPA. >>>>> >>>>> I was wondering, while configuring ipa-client, which server do I >>>>> >>>> reference >>>> >>>>> to when it asks the ipa-server hostname ? >>>>> >>>>> Both the master server has different hostnames. >>>>> >>>>> master1.example.com ( Master 1 ) >>>>> master2.example.com ( Master 2 ) >>>>> >>>> >>>> Specify only --domain option and do not use --server option at all. In >>>> will >>>> enable server auto-detection using DNS SRV records and you will not need >>>> to >>>> worry about adding/removing servers because all clients will >>>> automatically >>>> pick the new list up. >>>> >>>> -- >>>> Petr^2 Spacek >>>> >>>> -- >>>> Manage your subscription for the Freeipa-users mailing list: >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>> Go to http://freeipa.org for more info on the project >>>> >>>> >>> >>> >>> >> The '--domain' parameter is for client installer to form DNS request. >> Request that is sent is the same as one sent by this command: >> dig -t SRV _ldap._tcp. >> >> It then receiver list of records similar to this one: >> 100 0 389 >> 100 0 389 >> >> Installer then goes through the list and checks if it's really FreeIPA >> server and first one that passes is used. When IP address is needed it can >> be resolved from the name included in SRV response. >> >> HTH, >> -- >> David Kupka >> > -- Petr^2 Spacek From wanderley.mayhe at ibp.org.br Mon Feb 15 13:12:16 2016 From: wanderley.mayhe at ibp.org.br (=?iso-8859-1?Q?Wanderley_Mayh=E9?=) Date: Mon, 15 Feb 2016 11:12:16 -0200 (BRST) Subject: [Freeipa-users] Disable IPA Web UI auto-login Message-ID: <000001d167f3$b3a56590$1af030b0$@ibp.org.br> Hello Rob Regarding the thread https://www.redhat.com/archives/freeipa-users/2010-July/msg00022.html I have tested to set KrbMethodK5Passwd to ?on? and restarted httpd but IPA Web UI was still trying to auto-login user through a browser dialog. In order to effectively disable this browser dialog, I had to edit /etc/httpd/conf.d/ipa.conf and add this line set KrbMethodNegotiate to off as follows (and restarted httpd): # Protect /ipa and everything below it in webspace with Apache Kerberos auth AuthType Kerberos AuthName "Kerberos Login" ## KrbMethodNegotiate on KrbMethodNegotiate off KrbMethodK5Passwd off KrbServiceName HTTP KrbAuthRealms IBP.ORG.BR Krb5KeyTab /etc/httpd/conf/ipa.keytab KrbSaveCredentials on KrbConstrainedDelegation on Require valid-user ErrorDocument 401 /ipa/errors/unauthorized.html Am I correct to assume that that JSON API will not be affected by this change? Is there any major problems this setting could cause? Att Wanderley -------------- next part -------------- An HTML attachment was scrubbed... URL: From rakesh.rajasekharan at gmail.com Mon Feb 15 13:29:57 2016 From: rakesh.rajasekharan at gmail.com (Rakesh Rajasekharan) Date: Mon, 15 Feb 2016 18:59:57 +0530 Subject: [Freeipa-users] Connection closed by UNKNOWN In-Reply-To: <20160215101507.GE7612@hendrix.lan> References: <20160213111108.GE29883@hendrix.redhat.com> <20160215101507.GE7612@hendrix.lan> Message-ID: this is what I have in /var/log/secure Feb 15 12:22:33 ipa-xyz sshd[13499]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=x.x.x.x user=tempuser Feb 15 12:22:33 ipa-xyz sshd[13499]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=x.x.x.x user=tempuser Feb 15 12:22:33 ipa-xyz sshd[13499]: pam_sss(sshd:auth): received for user tempuser: 7 (Authentication failure) Feb 15 12:22:33 ipa-xyz sshd[13499]: pam_ldap: ldap_simple_bind Can't contact LDAP server Feb 15 12:22:33 ipa-xyz sshd[13499]: pam_ldap: reconnecting to LDAP server... Feb 15 12:22:33 ipa-xyz sshd[13499]: pam_ldap: ldap_simple_bind Can't contact LDAP server Feb 15 12:22:35 ipa-xyz sshd[13499]: Failed password for tempuser from x.x.x.x port 34318 ssh2 Feb 15 12:22:37 ipa-xyz sshd[13500]: Connection closed by x.x.x.x Feb 15 12:31:32 ipa-xyz sshd[13859]: Accepted publickey for root from x.x.x.x port 56275 ssh2 Feb 15 12:31:32 ipa-xyz sshd[13859]: pam_unix(sshd:session): session opened for user root by (uid=0) Feb 15 13:01:32 ipa-xyz sshd[13859]: Received disconnect from x.x.x.x: 11: disconnected by user but both 389 and 636 ports are listening # ] netstat -tunlp |grep 636 tcp 0 0 :::636 :::* LISTEN 9564/ns-slapd #] netstat -tunlp |grep 389 tcp 0 0 :::7389 :::* LISTEN 9495/ns-slapd tcp 0 0 :::389 :::* LISTEN 9564/ns-slapd And from /var/log/sssd/sssd_xyz.com.log (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [pam_print_data] (0x0100): command: PAM_AUTHENTICATE (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [pam_print_data] (0x0100): domain: xyz.com (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [pam_print_data] (0x0100): user: tempuser (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [pam_print_data] (0x0100): service: sshd (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [pam_print_data] (0x0100): tty: ssh (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [pam_print_data] (0x0100): ruser: (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [pam_print_data] (0x0100): rhost: x.x.x.x (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [pam_print_data] (0x0100): authtok type: 1 (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [pam_print_data] (0x0100): newauthtok type: 0 (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [pam_print_data] (0x0100): priv: 1 (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [pam_print_data] (0x0100): cli_pid: 13499 (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [pam_print_data] (0x0100): logon name: not set (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [krb5_auth_prepare_ccache_name] (0x1000): No ccache file for user [tempuser] found. (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [get_server_status] (0x1000): Status of server 'ipa.xyz.com' is 'working' (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [get_port_status] (0x1000): Port status of port 0 for server 'ipa.xyz.com' is 'working' (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [get_server_status] (0x1000): Status of server 'ipa.xyz.com' is 'working' (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [be_resolve_server_process] (0x1000): Saving the first resolved server (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [be_resolve_server_process] (0x0200): Found address for server ipa.xyz.com: [x.x.x.x] TTL 7200 (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [write_pipe_handler] (0x0400): All data has been sent! (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [child_sig_handler] (0x1000): Waiting for child [13501]. (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [child_sig_handler] (0x0100): child [13501] finished successfully. (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [read_pipe_handler] (0x0400): EOF received, client finished (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 7, ) [Success] (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [be_pam_handler_callback] (0x0100): Sending result [7][xyz.com] (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [be_pam_handler_callback] (0x0100): Sent result [7][xyz.com] Thanks, Rakesh On Mon, Feb 15, 2016 at 3:45 PM, Jakub Hrozek wrote: > On Mon, Feb 15, 2016 at 10:24:23AM +0530, Rakesh Rajasekharan wrote: > > hbac seems to be fine > > > > > > ipa hbactest --user=q-temp --host=x.x.x.x --service=sshd > > -------------------- > > Access granted: True > > -------------------- > > Matched rules: allow_all > > > > > > I see this in the sssd.log > > > > (Mon Feb 15 04:49:18 2016) [sssd[nss]] [sss_ncache_check_str] (0x2000): > > Checking negative cache for [NCE/USER/xyz.com/q-temp] > > (Mon Feb 15 04:49:18 2016) [sssd[nss]] [nss_cmd_getpwnam_search] > (0x0100): > > Requesting info for [q-temp at xyz.com] > > (Mon Feb 15 04:49:18 2016) [sssd[nss]] [check_cache] (0x0400): Cached > entry > > is valid, returning.. > > (Mon Feb 15 04:49:18 2016) [sssd[nss]] [nss_cmd_getpwnam_search] > (0x0400): > > Returning info for user [q-temp at xyz.com] > > (Mon Feb 15 04:49:18 2016) [sssd[nss]] [client_recv] (0x0200): Client > > disconnected! > > (Mon Feb 15 04:49:18 2016) [sssd[nss]] [client_destructor] (0x2000): > > Terminated client [0x23d2f80][20] > > (Mon Feb 15 04:49:27 2016) [sssd[nss]] [sbus_get_sender_id_send] > (0x2000): > > Not a sysbus message, quit > > What does /var/log/secure say? > > Also you pasted the NSS log, the domain log would be more useful here. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpazdziora at redhat.com Mon Feb 15 13:39:32 2016 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Mon, 15 Feb 2016 14:39:32 +0100 Subject: [Freeipa-users] client/authentication inside a docker container In-Reply-To: References: <20160204155640.GF16558@redhat.com> Message-ID: <20160215133932.GA23829@redhat.com> On Thu, Feb 04, 2016 at 12:37:07PM -0500, Prasun Gera wrote: > On Thu, Feb 4, 2016 at 10:56 AM, Jan Pazdziora > wrote: > > > > The goal is to run the > > > docker container such that when the user calls docker run, > > > > Is any user allowed to run docker run? That seems like a security > > issue. > > Well any user that can do sudo should be able to run docker. Is there a > security issue with that ? You need to limit those sudo calls to very specific list of parameters that can be passed to the docker client, otherwise it has the potential of running any command. > > > it just drops > > > into a shell with the container's environment, but everything else looks > > > largely the same. i.e. The user gets the same uid:gid and sees the same > > > directories and permissions as the host. > > > > So you want bash started in the container, with the uid:gid of the > > person invoking the command? If the users are trusted to do docker > > run, they can do > > > > docker run -u $UID container bash > > > > themselves. > > Yes, this is similar to the 3rd point I mentioned. The problem though is > that directory listings will not show names inside the container. They'll In that case, having sssd-client package installed in the container and /var/lib/sss mounted to the container could help. > only show uids and gids. NIS solves this as a quick hack, but is there > something better ? Permissions would still work since NFS is not > kerberized. Another issue I haven't figured out is how the user can get > sudo inside the container. If you start docker with the user's uid, I don't > know if there is a safe way for that user to get sudo inside. If you start > docker in the root shell, you can create the user with the uid:gid, add it > to sudoers, and then change to the user's shell ? Yes. If you have /var/lib/sss mounted and sssd-common (or libsss_sudo in new versions) installed in the container, you can even use the sudo rules from IPA. > > But you likely do not want to give every user a way to run any command, > > why not just use sudo, and > > > > docker run -u $SUDO_UID container bash > > > > in the script invoked with the sudo (untested)? > > I didn't follow this. Can you explain a bit more ? In the default setup, > you anyway need sudo to run docker. Not really -- access to docker's Unix socket is all that the docker client needs. > What is the -u string here ? Setting the uid under which the container processes are run back to the invoking user. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat From aaron.d.estrada at gmail.com Sun Feb 14 08:36:37 2016 From: aaron.d.estrada at gmail.com (Aaron Estrada) Date: Sun, 14 Feb 2016 01:36:37 -0700 Subject: [Freeipa-users] SOLUTION to Failed replica install with /32 netmask Message-ID: I tried creating a FreeIPA replica in GCE. GCE is a little weird in that it's DHCP assigns a /32 netmask to VMs. There does not seem to be any way to disable that specific behavior in GCE since as a user you have no control of the DHCP server. As a user you can create your own networks but it seems that under the hood Google wants to always route everything themselves, so even though they allow you to create say a /16 network, the machines all get a /32 netmask and use the gateway for routing, even within their own network. It's actually a little confusing because from the view of the the machine, you actually have no way of determining the size of the network (you have to actually learn the netmask/size of the virtual network via other means, like the glcoud command or web console) But with the /32 netmask routing does work, and machines can find other machines. Unfortunately, the FreeIPA server install scripts seem to have some error checking that gets confused by the /32 netmask scheme GCE uses and causes the scripts to crap out. I managed to trick ipa-server-install into installing by temporarily manually opening up the netmask. It only kind of works, since in some cases it breaks networking and the connection to the machine is lost. However, once IPA server is set up, it keeps working and I can enroll client machines. It seems like too much of a hack and I couldn't get he same trick to work for replicas in any case. This is the error I get: File "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", line 877, in main install_check(self) File "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", line 295, in decorated func(installer) File "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", line 514, in install_check options.ip_addresses) File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 516, in get_server_ip_address sys.exit(1)ipa.ipapython.install.cli.install_tool(Replica): DEBUG The ipa-replica-install command failed, exception: SystemExit: 1 I went into installutils.py and commented out the error test at line 516: # if not ips: # print >> sys.stderr, "No usable IP address provided nor resolved." # sys.exit(1) It's an ugly hack but you can at least get past the error check and install the replica. Would it be possible to make the installer scripts a less sensitive to the /32 netmask? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Mon Feb 15 14:23:54 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 15 Feb 2016 09:23:54 -0500 Subject: [Freeipa-users] Failed to setup replica, slapi_ldap_bind fails In-Reply-To: <20160215101408.GC30322@eru> References: <20160208170505.GE4331@eru> <20160212140613.GC16168@eru> <56BDEA8F.2040506@redhat.com> <20160212143503.GD16168@eru> <56BE00E1.5080303@redhat.com> <20160212172258.GB5760@eru> <56C1A32F.4010107@redhat.com> <20160215101408.GC30322@eru> Message-ID: <56C1DF7A.3030208@redhat.com> Filip Pytloun wrote: > I am using Ubuntu 16.04 (Xenial), there's no /etc/openldap That's the problem right there. I don't believe Ubuntu supports setting up replication agreements yet due to gnutls vs NSS issues. An effort is being made upstream to eliminate the need for TLS during agreement setup but I don't believe the Ubuntu maintainer has had complete success in getting it working yet. rob > > Here's complete debug log of replica install: > http://pastebin.com/38zi5MWd > > Now I noticed following, don't know if it can directly relate to this issue: > > ipa : DEBUG stderr=ldap_initialize( ldap://idm02.tcpcloud.eu:389/??base ) > ldap_modify: Server is unwilling to perform (53) > > ipa : CRITICAL Failed to load indices.ldif: Command ''/usr/bin/ldapmodify' '-v' '-f' '/usr/share/ipa/indices.ldif' '-H' 'ldap://idm02.tcpcloud.eu:389' '-x' '-D' 'cn=Directory Manager' '-y' '/tmp/tmpIV39iM'' returned non-zero exit status 53 > > On 2016/02/15 11:06, Ludwig Krispenz wrote: >> >> On 02/12/2016 06:22 PM, Filip Pytloun wrote: >>> Following is in /etc/ldap/ldap.conf on both servers (only URI differs): >> what is your OS, do you also have a /etc/openldap/ldap.conf >> >> ldapsearch and the replication connection shoudl use the same openldap >> libraries and so it is strange that -ZZ works and indside ds doesn't. >> >> At what point did your replica install fail, is there any hint in the >> replica install log ? >>> >>> TLS_CACERT /etc/ipa/ca.crt >>> TLS_REQCERT allow >>> URI ldaps://idm02.tcpcloud.eu >>> BASE dc=tcpcloud,dc=eu >>> >>> As ldapsearch is passing just fine on both nodes, I don't suppose >>> ldap.conf is wrong. >>> I also tried to set TLS_REQCERT to allow just to be sure (in case that >>> bad cert is provided). >>> >>> On 2016/02/12 16:57, Ludwig Krispenz wrote: >>>> On 02/12/2016 03:35 PM, Filip Pytloun wrote: >>>>> It's the same as for idm01: >>>>> >>>>> [12/Feb/2016:15:24:26 +0100] NSMMReplicationPlugin - agmt="cn=meToidm01.tcpcloud.eu" (idm01:389): Replication bind with SIMPLE auth failed: LDAP error -11 (Connect error) ((unknown error code)) >>>>> [12/Feb/2016:15:24:27 +0100] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) >>>> you can get this connect error if the client side cannot verify the cert the >>>> server sends, could you check what you have in f >>>> >>>>> In access logs I can't read much interesting, just that TLS connection happened from idm01: >>>>> >>>>> [12/Feb/2016:15:33:11 +0100] conn=14 fd=64 slot=64 connection from 185.22.97.19 to 172.10.10.192 >>>>> [12/Feb/2016:15:33:11 +0100] conn=14 op=0 EXT oid="1.3.6.1.4.1.1466.20037" name="startTLS" >>>>> [12/Feb/2016:15:33:11 +0100] conn=14 op=0 RESULT err=0 tag=120 nentries=0 etime=0 >>>>> [12/Feb/2016:15:33:11 +0100] conn=14 TLS1.2 128-bit AES-GCM >>>>> [12/Feb/2016:15:33:11 +0100] conn=14 op=-1 fd=64 closed - B1 >>>>> [12/Feb/2016:15:33:59 +0100] conn=15 fd=64 slot=64 connection from 185.22.97.19 to 172.10.10.192 >>>>> [12/Feb/2016:15:33:59 +0100] conn=15 op=0 EXT oid="1.3.6.1.4.1.1466.20037" name="startTLS" >>>>> [12/Feb/2016:15:33:59 +0100] conn=15 op=0 RESULT err=0 tag=120 nentries=0 etime=0 >>>>> [12/Feb/2016:15:34:00 +0100] conn=15 TLS1.2 128-bit AES-GCM >>>>> [12/Feb/2016:15:34:00 +0100] conn=15 op=-1 fd=64 closed - B1 >>>>> >>>>> On 2016/02/12 15:22, Ludwig Krispenz wrote: >>>>>> On 02/12/2016 03:06 PM, Filip Pytloun wrote: >>>>>>> Hello, >>>>>>> >>>>>>> even when enabling replication logging, I get nothing useful in logs: >>>>>>> >>>>>>> [12/Feb/2016:14:57:00 +0100] NSMMReplicationPlugin - agmt="cn=meToidm02.tcpcloud.eu" (idm02:389): Trying secure startTLS slapi_ldap_init_ext >>>>>>> [12/Feb/2016:14:57:00 +0100] NSMMReplicationPlugin - agmt="cn=meToidm02.tcpcloud.eu" (idm02:389): binddn = cn=replication manager,cn=config, passwd = {AES-some_encrypted_password >>>>>>> [12/Feb/2016:14:57:01 +0100] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) >>>>>>> [12/Feb/2016:14:57:01 +0100] NSMMReplicationPlugin - agmt="cn=meToidm02.tcpcloud.eu" (idm02:389): Replication bind with SIMPLE auth failed: LDAP error -11 (Connect error) ((unknown error code)) >>>>>>> [12/Feb/2016:14:57:01 +0100] NSMMReplicationPlugin - agmt="cn=meToidm02.tcpcloud.eu" (idm02:389): Disconnected from the consumer >>>>>> what is in the access and error logs of idm02 for this time ? >>>>>>> But I can bind just fine manually: >>>>>>> >>>>>>> ldapsearch -D "cn=replication manager,cn=config" -w some_password -b cn=config -h idm02 -ZZ >>>>>>> >>>>>>> I am starting to be clueless, nobody has an idea what could be wrong? >>>>>>> >>>>>>> - DNS including PTR records are set up fine >>>>>>> - /etc/hosts is setup fine >>>>>>> - conncheck passes fine between nodes >>>>>>> - I can bind manually just fine >>>>>>> >>>>>>> On 2016/02/08 18:05, Filip Pytloun wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> I have a weird issue setting up FreeIPA replica. Conncheck passes fine >>>>>>>> but at the end of ipa-replica-install I always get following error: >>>>>>>> >>>>>>>> slapi_ldap_bind -Error: could not send startTLS request: error -11 >>>>>>>> (Connect error) errno 0 (Success) >>>>>>>> >>>>>>>> on both master and replica without any further explanation in logs. >>>>>>>> >>>>>>>> /etc/ldap.conf is correctly setup before ipa-replica-install and IPA CA >>>>>>>> certificate is installed in system CA bundle so TLS should work just >>>>>>>> fine. >>>>>>>> >>>>>>>> Also I can manually connect just fine from replica to master and back so >>>>>>>> it's not a network or LDAP client issue. >>>>>>>> >>>>>>>> Replica agreement looks like this: http://pastebin.com/FT3p3KUk >>>>>>>> >>>>>>>> freeipa-server 4.1.4 >>>>>>>> 389-ds 1.3.4.5 >>>>>>>> >>>>>>>> Has anyone idea where to look at? >>>>>>>> >>>>>>>> Filip >>>>>>> >>>>>> -- >>>>>> Manage your subscription for the Freeipa-users mailing list: >>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>>> Go to http://freeipa.org for more info on the project >>>>> >>>> -- >>>> Manage your subscription for the Freeipa-users mailing list: >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>> Go to http://freeipa.org for more info on the project >> >> >> From jhrozek at redhat.com Mon Feb 15 15:08:40 2016 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 15 Feb 2016 16:08:40 +0100 Subject: [Freeipa-users] Question about ldap proxy/AD + sudo + HBAC In-Reply-To: References: <20160215103113.GI7612@hendrix.lan> Message-ID: <20160215150840.GJ7612@hendrix.lan> On Mon, Feb 15, 2016 at 11:24:08AM +0000, Birnbaum, Warren (ETW) wrote: > Hi Jakub, > > Thanks but I have sudo working OK. I'm sorry, my fault.. > What I am trying make work is HBAC. > That I can?t get to work with the proxy hack. Is there a way to do that? I haven't tested that use-case, but from the code it looks like it wouldn't work, because the HBAC code tries to match the originalDN of the user as stored on the IPA server. I'm finishing a standalone HBAC PAM module that could help in setups like this, but more importantly -- why do you have the user proxied from files? Isn't it better to just rely on sssd's caching and fetch the user from IPA? From mj at casalogic.dk Mon Feb 15 15:27:15 2016 From: mj at casalogic.dk (Martin Juhl) Date: Mon, 15 Feb 2016 16:27:15 +0100 (CET) Subject: [Freeipa-users] IPA inaccessable after adding service principle Message-ID: <855335456.1449820.1455550035794.JavaMail.zimbra@casalogic.dk> Hi guys I've just installed a RHEL7 server with ipa-server 4.2.0... Everything seems to work fine, until I add a service principle: (Running on a client, after a kinit) [root at dantooine ~]# ipa-getkeytab -s naboo.outerrim.lan -p HTTP/naboo.outerrim.lan at OUTERRIM.LAN -k /etc/krb5.keytab Keytab successfully retrieved and stored in: /etc/krb5.keytab After running the command, the web-interface returns: The password or username you entered is incorrect. when I try to login, and the "ipa" command has stopped working as well (both on the server and client): [root at dantooine ~]# ipa user-show admin ipa: ERROR: Insufficient access: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (KDC returned error string: 2ND_TKT_SERVER) [root at dantooine ~]# [root at dantooine ~]# kdestroy [root at dantooine ~]# kinit admin Password for admin at OUTERRIM.LAN: [root at dantooine ~]# ipa user-show admin ipa: ERROR: cannot connect to 'https://naboo.outerrim.lan/ipa/json': Unauthorized /var/log/httpd/error_log on the server gives me: ValueError: non-generic 'CCacheError' needs format=None; got format="(-1765328353, 'Decrypt integrity check failed')" What did I do wrong here??? Regards Martin Juhl From sbose at redhat.com Mon Feb 15 15:41:46 2016 From: sbose at redhat.com (Sumit Bose) Date: Mon, 15 Feb 2016 16:41:46 +0100 Subject: [Freeipa-users] IPA inaccessable after adding service principle In-Reply-To: <855335456.1449820.1455550035794.JavaMail.zimbra@casalogic.dk> References: <855335456.1449820.1455550035794.JavaMail.zimbra@casalogic.dk> Message-ID: <20160215154146.GF20563@p.redhat.com> On Mon, Feb 15, 2016 at 04:27:15PM +0100, Martin Juhl wrote: > Hi guys > > I've just installed a RHEL7 server with ipa-server 4.2.0... > > Everything seems to work fine, until I add a service principle: > > (Running on a client, after a kinit) > > [root at dantooine ~]# ipa-getkeytab -s naboo.outerrim.lan -p HTTP/naboo.outerrim.lan at OUTERRIM.LAN -k /etc/krb5.keytab > Keytab successfully retrieved and stored in: /etc/krb5.keytab ipa-getkeytab will always create a new key unless you use the --retrieve option. It looks like you call ipa-getkeytab on the host dantooine, so it will create a new key for naboo but save it on dantooine. So the keytab on naboo will still have the old key but the KDC will hand out service tickets with the new key which naboo does not know about. Please try to call ipa-getkeytab with the --retrieve option on naboo so that the new key is available on naboo as well. HTH bye, Sumit > > > After running the command, the web-interface returns: > > The password or username you entered is incorrect. > > when I try to login, and the "ipa" command has stopped working as well (both on the server and client): > > > [root at dantooine ~]# ipa user-show admin > ipa: ERROR: Insufficient access: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (KDC returned error string: 2ND_TKT_SERVER) > [root at dantooine ~]# > [root at dantooine ~]# kdestroy > [root at dantooine ~]# kinit admin > Password for admin at OUTERRIM.LAN: > [root at dantooine ~]# ipa user-show admin > ipa: ERROR: cannot connect to 'https://naboo.outerrim.lan/ipa/json': Unauthorized > > > /var/log/httpd/error_log on the server gives me: > > ValueError: non-generic 'CCacheError' needs format=None; got format="(-1765328353, 'Decrypt integrity check failed')" > > > What did I do wrong here??? > > Regards > > Martin Juhl > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project From jhrozek at redhat.com Mon Feb 15 15:46:38 2016 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 15 Feb 2016 16:46:38 +0100 Subject: [Freeipa-users] Connection closed by UNKNOWN In-Reply-To: References: <20160213111108.GE29883@hendrix.redhat.com> <20160215101507.GE7612@hendrix.lan> Message-ID: <20160215154638.GM7612@hendrix.lan> On Mon, Feb 15, 2016 at 06:59:57PM +0530, Rakesh Rajasekharan wrote: > this is what I have in /var/log/secure > > Feb 15 12:22:33 ipa-xyz sshd[13499]: pam_unix(sshd:auth): authentication > failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=x.x.x.x user=tempuser > Feb 15 12:22:33 ipa-xyz sshd[13499]: pam_sss(sshd:auth): authentication > failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=x.x.x.x user=tempuser > Feb 15 12:22:33 ipa-xyz sshd[13499]: pam_sss(sshd:auth): received for user > tempuser: 7 (Authentication failure) > Feb 15 12:22:33 ipa-xyz sshd[13499]: pam_ldap: ldap_simple_bind Can't > contact LDAP server > Feb 15 12:22:33 ipa-xyz sshd[13499]: pam_ldap: reconnecting to LDAP > server... > Feb 15 12:22:33 ipa-xyz sshd[13499]: pam_ldap: ldap_simple_bind Can't > contact LDAP server Why is both pam_ldap and pam_sss in the PAM stack? This seems a bit wrong.. > Feb 15 12:22:35 ipa-xyz sshd[13499]: Failed password for tempuser from > x.x.x.x port 34318 ssh2 > Feb 15 12:22:37 ipa-xyz sshd[13500]: Connection closed by x.x.x.x > Feb 15 12:31:32 ipa-xyz sshd[13859]: Accepted publickey for root from > x.x.x.x port 56275 ssh2 > Feb 15 12:31:32 ipa-xyz sshd[13859]: pam_unix(sshd:session): session opened > for user root by (uid=0) > Feb 15 13:01:32 ipa-xyz sshd[13859]: Received disconnect from x.x.x.x: 11: > disconnected by user > > but both 389 and 636 ports are listening > # ] netstat -tunlp |grep 636 > tcp 0 0 :::636 :::* > LISTEN 9564/ns-slapd > > #] netstat -tunlp |grep 389 > tcp 0 0 :::7389 :::* > LISTEN 9495/ns-slapd > tcp 0 0 :::389 :::* > LISTEN 9564/ns-slapd > > > And from /var/log/sssd/sssd_xyz.com.log > > (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [pam_print_data] (0x0100): > command: PAM_AUTHENTICATE > (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [pam_print_data] (0x0100): > domain: xyz.com > (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [pam_print_data] (0x0100): > user: tempuser > (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [pam_print_data] (0x0100): > service: sshd > (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [pam_print_data] (0x0100): > tty: ssh > (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [pam_print_data] (0x0100): > ruser: > (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [pam_print_data] (0x0100): > rhost: x.x.x.x > (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [pam_print_data] (0x0100): > authtok type: 1 > (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [pam_print_data] (0x0100): > newauthtok type: 0 > (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [pam_print_data] (0x0100): > priv: 1 > (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [pam_print_data] (0x0100): > cli_pid: 13499 > (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [pam_print_data] (0x0100): > logon name: not set > (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] > [krb5_auth_prepare_ccache_name] (0x1000): No ccache file for user > [tempuser] found. > (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [fo_resolve_service_send] > (0x0100): Trying to resolve service 'IPA' > (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [get_server_status] > (0x1000): Status of server 'ipa.xyz.com' is 'working' > (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [get_port_status] (0x1000): > Port status of port 0 for server 'ipa.xyz.com' is 'working' > (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [get_server_status] > (0x1000): Status of server 'ipa.xyz.com' is 'working' > (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [be_resolve_server_process] > (0x1000): Saving the first resolved server > (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [be_resolve_server_process] > (0x0200): Found address for server ipa.xyz.com: [x.x.x.x] TTL 7200 > (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [write_pipe_handler] > (0x0400): All data has been sent! > (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [child_sig_handler] > (0x1000): Waiting for child [13501]. > (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [child_sig_handler] > (0x0100): child [13501] finished successfully. > (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [read_pipe_handler] > (0x0400): EOF received, client finished > (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [be_pam_handler_callback] > (0x0100): Backend returned: (0, 7, ) [Success] I think you need to look into krb5_child.log with a high debug_level. > (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [be_pam_handler_callback] > (0x0100): Sending result [7][xyz.com] > (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [be_pam_handler_callback] > (0x0100): Sent result [7][xyz.com] > > > > Thanks, > Rakesh > > > On Mon, Feb 15, 2016 at 3:45 PM, Jakub Hrozek wrote: > > > On Mon, Feb 15, 2016 at 10:24:23AM +0530, Rakesh Rajasekharan wrote: > > > hbac seems to be fine > > > > > > > > > ipa hbactest --user=q-temp --host=x.x.x.x --service=sshd > > > -------------------- > > > Access granted: True > > > -------------------- > > > Matched rules: allow_all > > > > > > > > > I see this in the sssd.log > > > > > > (Mon Feb 15 04:49:18 2016) [sssd[nss]] [sss_ncache_check_str] (0x2000): > > > Checking negative cache for [NCE/USER/xyz.com/q-temp] > > > (Mon Feb 15 04:49:18 2016) [sssd[nss]] [nss_cmd_getpwnam_search] > > (0x0100): > > > Requesting info for [q-temp at xyz.com] > > > (Mon Feb 15 04:49:18 2016) [sssd[nss]] [check_cache] (0x0400): Cached > > entry > > > is valid, returning.. > > > (Mon Feb 15 04:49:18 2016) [sssd[nss]] [nss_cmd_getpwnam_search] > > (0x0400): > > > Returning info for user [q-temp at xyz.com] > > > (Mon Feb 15 04:49:18 2016) [sssd[nss]] [client_recv] (0x0200): Client > > > disconnected! > > > (Mon Feb 15 04:49:18 2016) [sssd[nss]] [client_destructor] (0x2000): > > > Terminated client [0x23d2f80][20] > > > (Mon Feb 15 04:49:27 2016) [sssd[nss]] [sbus_get_sender_id_send] > > (0x2000): > > > Not a sysbus message, quit > > > > What does /var/log/secure say? > > > > Also you pasted the NSS log, the domain log would be more useful here. > > From pvoborni at redhat.com Mon Feb 15 15:53:29 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 15 Feb 2016 16:53:29 +0100 Subject: [Freeipa-users] Disable IPA Web UI auto-login In-Reply-To: <000001d167f3$b3a56590$1af030b0$@ibp.org.br> References: <000001d167f3$b3a56590$1af030b0$@ibp.org.br> Message-ID: <56C1F479.6050807@redhat.com> Hello, On 02/15/2016 02:12 PM, Wanderley Mayh? wrote: > > > Hello Rob > > > > Regarding the thread > https://www.redhat.com/archives/freeipa-users/2010-July/msg00022.html I > have tested to set KrbMethodK5Passwd to ?on? and restarted httpd but IPA > Web UI was still trying to auto-login user through a browser dialog. > > > > In order to effectively disable this browser dialog, I had to edit > /etc/httpd/conf.d/ipa.conf > > and add this line set KrbMethodNegotiate to off as follows (and restarted > httpd): > > > > > > # Protect /ipa and everything below it in webspace with Apache Kerberos > auth > > > > AuthType Kerberos > > AuthName "Kerberos Login" > > ## KrbMethodNegotiate on > > KrbMethodNegotiate off > > KrbMethodK5Passwd off > > KrbServiceName HTTP > > KrbAuthRealms IBP.ORG.BR > > Krb5KeyTab /etc/httpd/conf/ipa.keytab > > KrbSaveCredentials on > > KrbConstrainedDelegation on > > Require valid-user > > ErrorDocument 401 /ipa/errors/unauthorized.html > > > > > > Am I correct to assume that that JSON API will not be affected by this > change? No > > Is there any major problems this setting could cause? > Yes, it would affect the API :) Better option would be to modify Web UI with UI plugin to skip Kerberous auth - harder to explain. Or easier thing might be to modify ipa.conf in a way that /ipa/session/login_kerberos would not return negotiate headers but would fail immediately with 401. -- Petr Vobornik From jhrozek at redhat.com Mon Feb 15 16:16:58 2016 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 15 Feb 2016 17:16:58 +0100 Subject: [Freeipa-users] Question about ldap proxy/AD + sudo + HBAC In-Reply-To: References: <20160215103113.GI7612@hendrix.lan> <20160215150840.GJ7612@hendrix.lan> Message-ID: <20160215161658.GT7612@hendrix.lan> On Mon, Feb 15, 2016 at 03:58:15PM +0000, Birnbaum, Warren (ETW) wrote: > Jakub, > > We want to use password stored in AD and get a yes/no from the AD side. OK, I see. Yes, with IPA provider you would authenticate the IPA user against the IPA KDC. > My understanding (which is very limited) is that if we use the IPA > authentication then it resides in the local kerberos database. Is that > not correct? If I am completely off, how would I setup type of > authentication from IPA up? Normally with trusts. > > Thanks again, > > Warren > ___________________ > Warren Birnbaum : Infrastructure Services > Digital Linux Infrastructure Services > Europe CDT Techn. Operations > Nike Inc. : Mobile +31 6 23902697 > > > > > > > On 2/15/16, 4:08 PM, "Jakub Hrozek" wrote: > > >On Mon, Feb 15, 2016 at 11:24:08AM +0000, Birnbaum, Warren (ETW) wrote: > >> Hi Jakub, > >> > >> Thanks but I have sudo working OK. > > > >I'm sorry, my fault.. > > > >> What I am trying make work is HBAC. > >> That I can?t get to work with the proxy hack. Is there a way to do > >>that? > > > >I haven't tested that use-case, but from the code it looks like it > >wouldn't work, because the HBAC code tries to match the originalDN of > >the user as stored on the IPA server. > > > >I'm finishing a standalone HBAC PAM module that could help in setups > >like this, but more importantly -- why do you have the user proxied from > >files? Isn't it better to just rely on sssd's caching and fetch the user > >from IPA? > From mbabinsk at redhat.com Mon Feb 15 16:51:02 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 15 Feb 2016 17:51:02 +0100 Subject: [Freeipa-users] IPA inaccessable after adding service principle In-Reply-To: <20160215154146.GF20563@p.redhat.com> References: <855335456.1449820.1455550035794.JavaMail.zimbra@casalogic.dk> <20160215154146.GF20563@p.redhat.com> Message-ID: <56C201F6.60309@redhat.com> On 02/15/2016 04:41 PM, Sumit Bose wrote: > On Mon, Feb 15, 2016 at 04:27:15PM +0100, Martin Juhl wrote: >> Hi guys >> >> I've just installed a RHEL7 server with ipa-server 4.2.0... >> >> Everything seems to work fine, until I add a service principle: >> >> (Running on a client, after a kinit) >> >> [root at dantooine ~]# ipa-getkeytab -s naboo.outerrim.lan -p HTTP/naboo.outerrim.lan at OUTERRIM.LAN -k /etc/krb5.keytab >> Keytab successfully retrieved and stored in: /etc/krb5.keytab > > ipa-getkeytab will always create a new key unless you use the --retrieve > option. > > It looks like you call ipa-getkeytab on the host dantooine, so it will > create a new key for naboo but save it on dantooine. So the keytab on > naboo will still have the old key but the KDC will hand out service > tickets with the new key which naboo does not know about. > > Please try to call ipa-getkeytab with the --retrieve option on naboo so > that the new key is available on naboo as well. > > HTH > > bye, > Sumit > > You will also need to regenerate apache keytab since by using the command you regenerate kerberos keys of HTTP service while leaving old keys in IPA HTTP service keytab, hence the decrypt integrity check error when using cli/webui. on naboo.outerrim.lan, run: """ ipa-getkeytab -s naboo.outerrim.lan -p HTTP/naboo.outerrim.lan at OUTERRIM.LAN -k /etc/httpd/conf/ipa.keytab """ and then either restart httpd service or run: """ kdestroy -c /var/run/httpd/ipa/krbcache/krb5ccache """ That should make webui and cli work again. >> >> >> After running the command, the web-interface returns: >> >> The password or username you entered is incorrect. >> >> when I try to login, and the "ipa" command has stopped working as well (both on the server and client): >> >> >> [root at dantooine ~]# ipa user-show admin >> ipa: ERROR: Insufficient access: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (KDC returned error string: 2ND_TKT_SERVER) >> [root at dantooine ~]# >> [root at dantooine ~]# kdestroy >> [root at dantooine ~]# kinit admin >> Password for admin at OUTERRIM.LAN: >> [root at dantooine ~]# ipa user-show admin >> ipa: ERROR: cannot connect to 'https://naboo.outerrim.lan/ipa/json': Unauthorized >> >> >> /var/log/httpd/error_log on the server gives me: >> >> ValueError: non-generic 'CCacheError' needs format=None; got format="(-1765328353, 'Decrypt integrity check failed')" >> >> >> What did I do wrong here??? >> >> Regards >> >> Martin Juhl >> >> -- >> Manage your subscription for the Freeipa-users mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-users >> Go to http://freeipa.org for more info on the project > -- Martin^3 Babinsky From Warren.Birnbaum at nike.com Mon Feb 15 15:58:15 2016 From: Warren.Birnbaum at nike.com (Birnbaum, Warren (ETW)) Date: Mon, 15 Feb 2016 15:58:15 +0000 Subject: [Freeipa-users] Question about ldap proxy/AD + sudo + HBAC In-Reply-To: <20160215150840.GJ7612@hendrix.lan> References: <20160215103113.GI7612@hendrix.lan> <20160215150840.GJ7612@hendrix.lan> Message-ID: Jakub, We want to use password stored in AD and get a yes/no from the AD side. My understanding (which is very limited) is that if we use the IPA authentication then it resides in the local kerberos database. Is that not correct? If I am completely off, how would I setup type of authentication from IPA up? Thanks again, Warren ___________________ Warren Birnbaum : Infrastructure Services Digital Linux Infrastructure Services Europe CDT Techn. Operations Nike Inc. : Mobile +31 6 23902697 On 2/15/16, 4:08 PM, "Jakub Hrozek" wrote: >On Mon, Feb 15, 2016 at 11:24:08AM +0000, Birnbaum, Warren (ETW) wrote: >> Hi Jakub, >> >> Thanks but I have sudo working OK. > >I'm sorry, my fault.. > >> What I am trying make work is HBAC. >> That I can?t get to work with the proxy hack. Is there a way to do >>that? > >I haven't tested that use-case, but from the code it looks like it >wouldn't work, because the HBAC code tries to match the originalDN of >the user as stored on the IPA server. > >I'm finishing a standalone HBAC PAM module that could help in setups >like this, but more importantly -- why do you have the user proxied from >files? Isn't it better to just rely on sssd's caching and fetch the user >from IPA? From Warren.Birnbaum at nike.com Mon Feb 15 18:57:13 2016 From: Warren.Birnbaum at nike.com (Birnbaum, Warren (ETW)) Date: Mon, 15 Feb 2016 18:57:13 +0000 Subject: [Freeipa-users] Question about ldap proxy/AD + sudo + HBAC In-Reply-To: <20160215161658.GT7612@hendrix.lan> References: <20160215103113.GI7612@hendrix.lan> <20160215150840.GJ7612@hendrix.lan> <20160215161658.GT7612@hendrix.lan> Message-ID: Jakub, I am very interested in your standalone HBAC PAM module if you think it would apply in this situation. I would be happy to test it out if helpful. Thanks again for you help, Warren Birnbaum ___________________ Warren Birnbaum : Infrastructure Services Digital Linux Infrastructure Services Europe CDT Techn. Operations Nike Inc. : Mobile +31 6 23902697 On 2/15/16, 5:16 PM, "Jakub Hrozek" wrote: >On Mon, Feb 15, 2016 at 03:58:15PM +0000, Birnbaum, Warren (ETW) wrote: >> Jakub, >> >> We want to use password stored in AD and get a yes/no from the AD side. > >OK, I see. Yes, with IPA provider you would authenticate the IPA user >against the IPA KDC. > >> My understanding (which is very limited) is that if we use the IPA >> authentication then it resides in the local kerberos database. Is that >> not correct? If I am completely off, how would I setup type of >> authentication from IPA up? > >Normally with trusts. > >> >> Thanks again, >> >> Warren >> ___________________ >> Warren Birnbaum : Infrastructure Services >> Digital Linux Infrastructure Services >> Europe CDT Techn. Operations >> Nike Inc. : Mobile +31 6 23902697 >> >> >> >> >> >> >> On 2/15/16, 4:08 PM, "Jakub Hrozek" wrote: >> >> >On Mon, Feb 15, 2016 at 11:24:08AM +0000, Birnbaum, Warren (ETW) wrote: >> >> Hi Jakub, >> >> >> >> Thanks but I have sudo working OK. >> > >> >I'm sorry, my fault.. >> > >> >> What I am trying make work is HBAC. >> >> That I can?t get to work with the proxy hack. Is there a way to do >> >>that? >> > >> >I haven't tested that use-case, but from the code it looks like it >> >wouldn't work, because the HBAC code tries to match the originalDN of >> >the user as stored on the IPA server. >> > >> >I'm finishing a standalone HBAC PAM module that could help in setups >> >like this, but more importantly -- why do you have the user proxied >>from >> >files? Isn't it better to just rely on sssd's caching and fetch the >>user >> >from IPA? >> From filip at pytloun.cz Mon Feb 15 19:58:59 2016 From: filip at pytloun.cz (Filip Pytloun) Date: Mon, 15 Feb 2016 20:58:59 +0100 Subject: [Freeipa-users] Failed to setup replica, slapi_ldap_bind fails In-Reply-To: <56C1DF7A.3030208@redhat.com> References: <20160208170505.GE4331@eru> <20160212140613.GC16168@eru> <56BDEA8F.2040506@redhat.com> <20160212143503.GD16168@eru> <56BE00E1.5080303@redhat.com> <20160212172258.GB5760@eru> <56C1A32F.4010107@redhat.com> <20160215101408.GC30322@eru> <56C1DF7A.3030208@redhat.com> Message-ID: <20160215195859.GA24845@eru> Thank you, this information helped. I have found related bugs: FreeIPA: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786411 OpenLDAP switch to NSS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725153 389ds ticket: https://fedorahosted.org/389/ticket/47536 It doesn't seem there's some functional workaround? :-/ On 2016/02/15 09:23, Rob Crittenden wrote: > Filip Pytloun wrote: > > I am using Ubuntu 16.04 (Xenial), there's no /etc/openldap > > That's the problem right there. I don't believe Ubuntu supports setting > up replication agreements yet due to gnutls vs NSS issues. An effort is > being made upstream to eliminate the need for TLS during agreement setup > but I don't believe the Ubuntu maintainer has had complete success in > getting it working yet. > > rob > > > > > Here's complete debug log of replica install: > > http://pastebin.com/38zi5MWd > > > > Now I noticed following, don't know if it can directly relate to this issue: > > > > ipa : DEBUG stderr=ldap_initialize( ldap://idm02.tcpcloud.eu:389/??base ) > > ldap_modify: Server is unwilling to perform (53) > > > > ipa : CRITICAL Failed to load indices.ldif: Command ''/usr/bin/ldapmodify' '-v' '-f' '/usr/share/ipa/indices.ldif' '-H' 'ldap://idm02.tcpcloud.eu:389' '-x' '-D' 'cn=Directory Manager' '-y' '/tmp/tmpIV39iM'' returned non-zero exit status 53 > > > > On 2016/02/15 11:06, Ludwig Krispenz wrote: > >> > >> On 02/12/2016 06:22 PM, Filip Pytloun wrote: > >>> Following is in /etc/ldap/ldap.conf on both servers (only URI differs): > >> what is your OS, do you also have a /etc/openldap/ldap.conf > >> > >> ldapsearch and the replication connection shoudl use the same openldap > >> libraries and so it is strange that -ZZ works and indside ds doesn't. > >> > >> At what point did your replica install fail, is there any hint in the > >> replica install log ? > >>> > >>> TLS_CACERT /etc/ipa/ca.crt > >>> TLS_REQCERT allow > >>> URI ldaps://idm02.tcpcloud.eu > >>> BASE dc=tcpcloud,dc=eu > >>> > >>> As ldapsearch is passing just fine on both nodes, I don't suppose > >>> ldap.conf is wrong. > >>> I also tried to set TLS_REQCERT to allow just to be sure (in case that > >>> bad cert is provided). > >>> > >>> On 2016/02/12 16:57, Ludwig Krispenz wrote: > >>>> On 02/12/2016 03:35 PM, Filip Pytloun wrote: > >>>>> It's the same as for idm01: > >>>>> > >>>>> [12/Feb/2016:15:24:26 +0100] NSMMReplicationPlugin - agmt="cn=meToidm01.tcpcloud.eu" (idm01:389): Replication bind with SIMPLE auth failed: LDAP error -11 (Connect error) ((unknown error code)) > >>>>> [12/Feb/2016:15:24:27 +0100] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) > >>>> you can get this connect error if the client side cannot verify the cert the > >>>> server sends, could you check what you have in f > >>>> > >>>>> In access logs I can't read much interesting, just that TLS connection happened from idm01: > >>>>> > >>>>> [12/Feb/2016:15:33:11 +0100] conn=14 fd=64 slot=64 connection from 185.22.97.19 to 172.10.10.192 > >>>>> [12/Feb/2016:15:33:11 +0100] conn=14 op=0 EXT oid="1.3.6.1.4.1.1466.20037" name="startTLS" > >>>>> [12/Feb/2016:15:33:11 +0100] conn=14 op=0 RESULT err=0 tag=120 nentries=0 etime=0 > >>>>> [12/Feb/2016:15:33:11 +0100] conn=14 TLS1.2 128-bit AES-GCM > >>>>> [12/Feb/2016:15:33:11 +0100] conn=14 op=-1 fd=64 closed - B1 > >>>>> [12/Feb/2016:15:33:59 +0100] conn=15 fd=64 slot=64 connection from 185.22.97.19 to 172.10.10.192 > >>>>> [12/Feb/2016:15:33:59 +0100] conn=15 op=0 EXT oid="1.3.6.1.4.1.1466.20037" name="startTLS" > >>>>> [12/Feb/2016:15:33:59 +0100] conn=15 op=0 RESULT err=0 tag=120 nentries=0 etime=0 > >>>>> [12/Feb/2016:15:34:00 +0100] conn=15 TLS1.2 128-bit AES-GCM > >>>>> [12/Feb/2016:15:34:00 +0100] conn=15 op=-1 fd=64 closed - B1 > >>>>> > >>>>> On 2016/02/12 15:22, Ludwig Krispenz wrote: > >>>>>> On 02/12/2016 03:06 PM, Filip Pytloun wrote: > >>>>>>> Hello, > >>>>>>> > >>>>>>> even when enabling replication logging, I get nothing useful in logs: > >>>>>>> > >>>>>>> [12/Feb/2016:14:57:00 +0100] NSMMReplicationPlugin - agmt="cn=meToidm02.tcpcloud.eu" (idm02:389): Trying secure startTLS slapi_ldap_init_ext > >>>>>>> [12/Feb/2016:14:57:00 +0100] NSMMReplicationPlugin - agmt="cn=meToidm02.tcpcloud.eu" (idm02:389): binddn = cn=replication manager,cn=config, passwd = {AES-some_encrypted_password > >>>>>>> [12/Feb/2016:14:57:01 +0100] slapi_ldap_bind - Error: could not send startTLS request: error -11 (Connect error) errno 0 (Success) > >>>>>>> [12/Feb/2016:14:57:01 +0100] NSMMReplicationPlugin - agmt="cn=meToidm02.tcpcloud.eu" (idm02:389): Replication bind with SIMPLE auth failed: LDAP error -11 (Connect error) ((unknown error code)) > >>>>>>> [12/Feb/2016:14:57:01 +0100] NSMMReplicationPlugin - agmt="cn=meToidm02.tcpcloud.eu" (idm02:389): Disconnected from the consumer > >>>>>> what is in the access and error logs of idm02 for this time ? > >>>>>>> But I can bind just fine manually: > >>>>>>> > >>>>>>> ldapsearch -D "cn=replication manager,cn=config" -w some_password -b cn=config -h idm02 -ZZ > >>>>>>> > >>>>>>> I am starting to be clueless, nobody has an idea what could be wrong? > >>>>>>> > >>>>>>> - DNS including PTR records are set up fine > >>>>>>> - /etc/hosts is setup fine > >>>>>>> - conncheck passes fine between nodes > >>>>>>> - I can bind manually just fine > >>>>>>> > >>>>>>> On 2016/02/08 18:05, Filip Pytloun wrote: > >>>>>>>> Hello, > >>>>>>>> > >>>>>>>> I have a weird issue setting up FreeIPA replica. Conncheck passes fine > >>>>>>>> but at the end of ipa-replica-install I always get following error: > >>>>>>>> > >>>>>>>> slapi_ldap_bind -Error: could not send startTLS request: error -11 > >>>>>>>> (Connect error) errno 0 (Success) > >>>>>>>> > >>>>>>>> on both master and replica without any further explanation in logs. > >>>>>>>> > >>>>>>>> /etc/ldap.conf is correctly setup before ipa-replica-install and IPA CA > >>>>>>>> certificate is installed in system CA bundle so TLS should work just > >>>>>>>> fine. > >>>>>>>> > >>>>>>>> Also I can manually connect just fine from replica to master and back so > >>>>>>>> it's not a network or LDAP client issue. > >>>>>>>> > >>>>>>>> Replica agreement looks like this: http://pastebin.com/FT3p3KUk > >>>>>>>> > >>>>>>>> freeipa-server 4.1.4 > >>>>>>>> 389-ds 1.3.4.5 > >>>>>>>> > >>>>>>>> Has anyone idea where to look at? > >>>>>>>> > >>>>>>>> Filip > >>>>>>> > >>>>>> -- > >>>>>> Manage your subscription for the Freeipa-users mailing list: > >>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users > >>>>>> Go to http://freeipa.org for more info on the project > >>>>> > >>>> -- > >>>> Manage your subscription for the Freeipa-users mailing list: > >>>> https://www.redhat.com/mailman/listinfo/freeipa-users > >>>> Go to http://freeipa.org for more info on the project > >> > >> > >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From mitra.dehghan at gmail.com Tue Feb 16 08:18:53 2016 From: mitra.dehghan at gmail.com (Mitra Dehghan) Date: Tue, 16 Feb 2016 11:48:53 +0330 Subject: [Freeipa-users] Problem with Sync. IPA and Active directory using an external CA server with key size of 4096 Message-ID: Hello, I want to Sync IPA and Active directory servers: 1- I'm using an external root CA server which uses key size of 4096 2- Both IPA and Active directory, use the same CA server as external root CA. 3- Using default configuration,the handshake process for establishing SSL connection between servers(IPA and active directory) is failed during certificate-base authentication. As a result password Sync. fails after user synchronization is done. I guess the problem is key size and I was wondering if any special changes are required in the CA instance configured by IPA or if the job is possible at all. Note: Things goes well when I use internal CA servers both for active directory and IPA server. -- m-dehghan -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Tue Feb 16 08:36:49 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 16 Feb 2016 10:36:49 +0200 Subject: [Freeipa-users] Problem with Sync. IPA and Active directory using an external CA server with key size of 4096 In-Reply-To: References: Message-ID: <20160216083649.GO4492@redhat.com> On Tue, 16 Feb 2016, Mitra Dehghan wrote: >Hello, >I want to Sync IPA and Active directory servers: >1- I'm using an external root CA server which uses key size of 4096 >2- Both IPA and Active directory, use the same CA server as external root >CA. >3- Using default configuration,the handshake process for establishing SSL >connection between servers(IPA and active directory) is failed during >certificate-base authentication. As a result password Sync. fails after >user synchronization is done. > >I guess the problem is key size and I was wondering if any special changes >are required in the CA instance configured by IPA or if the job is possible >at all. > >Note: Things goes well when I use internal CA servers both for active >directory and IPA server. Can you give a bit more details about your environment? We fixed a bug in NSS some time ago related to this issue. https://rhn.redhat.com/errata/RHBA-2015-2121.html What is your distribution? nss package version? IPA version? 389-ds-base version? -- / Alexander Bokovoy From mitra.dehghan at gmail.com Tue Feb 16 10:28:03 2016 From: mitra.dehghan at gmail.com (Mitra Dehghan) Date: Tue, 16 Feb 2016 13:58:03 +0330 Subject: [Freeipa-users] Problem with Sync. IPA and Active directory using an external CA server with key size of 4096 In-Reply-To: <20160216083649.GO4492@redhat.com> References: <20160216083649.GO4492@redhat.com> Message-ID: Thanks for your response. My environment is: OS: Centos 6.7 - kernel 2.6.32-537.3.1 NSS package: nss-3.19.1-3 IPA version: 3.0.0-47 389-ds-base version: 1.2.11.15-60 On Tue, Feb 16, 2016 at 12:06 PM, Alexander Bokovoy wrote: > On Tue, 16 Feb 2016, Mitra Dehghan wrote: > >> Hello, >> I want to Sync IPA and Active directory servers: >> 1- I'm using an external root CA server which uses key size of 4096 >> 2- Both IPA and Active directory, use the same CA server as external root >> CA. >> 3- Using default configuration,the handshake process for establishing SSL >> connection between servers(IPA and active directory) is failed during >> certificate-base authentication. As a result password Sync. fails after >> user synchronization is done. >> >> I guess the problem is key size and I was wondering if any special changes >> are required in the CA instance configured by IPA or if the job is >> possible >> at all. >> >> Note: Things goes well when I use internal CA servers both for active >> directory and IPA server. >> > Can you give a bit more details about your environment? We fixed a bug > in NSS some time ago related to this issue. > https://rhn.redhat.com/errata/RHBA-2015-2121.html > > What is your distribution? nss package version? IPA version? 389-ds-base > version? > > -- > / Alexander Bokovoy > -- m-dehghan -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Tue Feb 16 11:18:50 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 16 Feb 2016 13:18:50 +0200 Subject: [Freeipa-users] Problem with Sync. IPA and Active directory using an external CA server with key size of 4096 In-Reply-To: References: <20160216083649.GO4492@redhat.com> Message-ID: <20160216111850.GP4492@redhat.com> On Tue, 16 Feb 2016, Mitra Dehghan wrote: >Thanks for your response. > >My environment is: >OS: Centos 6.7 - kernel 2.6.32-537.3.1 >NSS package: nss-3.19.1-3 >IPA version: 3.0.0-47 >389-ds-base version: 1.2.11.15-60 Ok, NSS fix is there as part of 3.19.1 rebase, https://rhn.redhat.com/errata/RHSA-2015-1185.html However, you need to work out ciphers in 389-ds-base configuration. To see what could be done, install FreeIPA 4.x in CentOS 7 and compare settings there in cn=config. -- / Alexander Bokovoy From rakesh.rajasekharan at gmail.com Tue Feb 16 14:52:23 2016 From: rakesh.rajasekharan at gmail.com (Rakesh Rajasekharan) Date: Tue, 16 Feb 2016 20:22:23 +0530 Subject: [Freeipa-users] Connection closed by UNKNOWN In-Reply-To: <20160215154638.GM7612@hendrix.lan> References: <20160213111108.GE29883@hendrix.redhat.com> <20160215101507.GE7612@hendrix.lan> <20160215154638.GM7612@hendrix.lan> Message-ID: >Why is both pam_ldap and pam_sss in the PAM stack? This seems a bit >wrong.. This was the pointer... there was a prior installation of openldap and the entries for ldap were still there .. auth sufficient pam_ldap.so use_first_pass account [default=bad success=ok user_unknown=ignore] pam_ldap.so password sufficient pam_ldap.so use_authtok session optional pam_ldap.so I removed it and everything works perfectly... Thanks!! On Mon, Feb 15, 2016 at 9:16 PM, Jakub Hrozek wrote: > On Mon, Feb 15, 2016 at 06:59:57PM +0530, Rakesh Rajasekharan wrote: > > this is what I have in /var/log/secure > > > > Feb 15 12:22:33 ipa-xyz sshd[13499]: pam_unix(sshd:auth): authentication > > failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=x.x.x.x > user=tempuser > > Feb 15 12:22:33 ipa-xyz sshd[13499]: pam_sss(sshd:auth): authentication > > failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=x.x.x.x user=tempuser > > Feb 15 12:22:33 ipa-xyz sshd[13499]: pam_sss(sshd:auth): received for > user > > tempuser: 7 (Authentication failure) > > Feb 15 12:22:33 ipa-xyz sshd[13499]: pam_ldap: ldap_simple_bind Can't > > contact LDAP server > > Feb 15 12:22:33 ipa-xyz sshd[13499]: pam_ldap: reconnecting to LDAP > > server... > > Feb 15 12:22:33 ipa-xyz sshd[13499]: pam_ldap: ldap_simple_bind Can't > > contact LDAP server > > Why is both pam_ldap and pam_sss in the PAM stack? This seems a bit > wrong.. > > > Feb 15 12:22:35 ipa-xyz sshd[13499]: Failed password for tempuser from > > x.x.x.x port 34318 ssh2 > > Feb 15 12:22:37 ipa-xyz sshd[13500]: Connection closed by x.x.x.x > > Feb 15 12:31:32 ipa-xyz sshd[13859]: Accepted publickey for root from > > x.x.x.x port 56275 ssh2 > > Feb 15 12:31:32 ipa-xyz sshd[13859]: pam_unix(sshd:session): session > opened > > for user root by (uid=0) > > Feb 15 13:01:32 ipa-xyz sshd[13859]: Received disconnect from x.x.x.x: > 11: > > disconnected by user > > > > but both 389 and 636 ports are listening > > # ] netstat -tunlp |grep 636 > > tcp 0 0 :::636 :::* > > LISTEN 9564/ns-slapd > > > > #] netstat -tunlp |grep 389 > > tcp 0 0 :::7389 :::* > > LISTEN 9495/ns-slapd > > tcp 0 0 :::389 :::* > > LISTEN 9564/ns-slapd > > > > > > And from /var/log/sssd/sssd_xyz.com.log > > > > (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [pam_print_data] > (0x0100): > > command: PAM_AUTHENTICATE > > (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [pam_print_data] > (0x0100): > > domain: xyz.com > > (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [pam_print_data] > (0x0100): > > user: tempuser > > (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [pam_print_data] > (0x0100): > > service: sshd > > (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [pam_print_data] > (0x0100): > > tty: ssh > > (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [pam_print_data] > (0x0100): > > ruser: > > (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [pam_print_data] > (0x0100): > > rhost: x.x.x.x > > (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [pam_print_data] > (0x0100): > > authtok type: 1 > > (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [pam_print_data] > (0x0100): > > newauthtok type: 0 > > (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [pam_print_data] > (0x0100): > > priv: 1 > > (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [pam_print_data] > (0x0100): > > cli_pid: 13499 > > (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [pam_print_data] > (0x0100): > > logon name: not set > > (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] > > [krb5_auth_prepare_ccache_name] (0x1000): No ccache file for user > > [tempuser] found. > > (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [fo_resolve_service_send] > > (0x0100): Trying to resolve service 'IPA' > > (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [get_server_status] > > (0x1000): Status of server 'ipa.xyz.com' is 'working' > > (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [get_port_status] > (0x1000): > > Port status of port 0 for server 'ipa.xyz.com' is 'working' > > (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [get_server_status] > > (0x1000): Status of server 'ipa.xyz.com' is 'working' > > (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] > [be_resolve_server_process] > > (0x1000): Saving the first resolved server > > (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] > [be_resolve_server_process] > > (0x0200): Found address for server ipa.xyz.com: [x.x.x.x] TTL 7200 > > (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [write_pipe_handler] > > (0x0400): All data has been sent! > > (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [child_sig_handler] > > (0x1000): Waiting for child [13501]. > > (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [child_sig_handler] > > (0x0100): child [13501] finished successfully. > > (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [read_pipe_handler] > > (0x0400): EOF received, client finished > > (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [be_pam_handler_callback] > > (0x0100): Backend returned: (0, 7, ) [Success] > > I think you need to look into krb5_child.log with a high debug_level. > > > (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [be_pam_handler_callback] > > (0x0100): Sending result [7][xyz.com] > > (Mon Feb 15 12:22:33 2016) [sssd[be[xyz.com]]] [be_pam_handler_callback] > > (0x0100): Sent result [7][xyz.com] > > > > > > > > Thanks, > > Rakesh > > > > > > On Mon, Feb 15, 2016 at 3:45 PM, Jakub Hrozek > wrote: > > > > > On Mon, Feb 15, 2016 at 10:24:23AM +0530, Rakesh Rajasekharan wrote: > > > > hbac seems to be fine > > > > > > > > > > > > ipa hbactest --user=q-temp --host=x.x.x.x --service=sshd > > > > -------------------- > > > > Access granted: True > > > > -------------------- > > > > Matched rules: allow_all > > > > > > > > > > > > I see this in the sssd.log > > > > > > > > (Mon Feb 15 04:49:18 2016) [sssd[nss]] [sss_ncache_check_str] > (0x2000): > > > > Checking negative cache for [NCE/USER/xyz.com/q-temp] > > > > (Mon Feb 15 04:49:18 2016) [sssd[nss]] [nss_cmd_getpwnam_search] > > > (0x0100): > > > > Requesting info for [q-temp at xyz.com] > > > > (Mon Feb 15 04:49:18 2016) [sssd[nss]] [check_cache] (0x0400): Cached > > > entry > > > > is valid, returning.. > > > > (Mon Feb 15 04:49:18 2016) [sssd[nss]] [nss_cmd_getpwnam_search] > > > (0x0400): > > > > Returning info for user [q-temp at xyz.com] > > > > (Mon Feb 15 04:49:18 2016) [sssd[nss]] [client_recv] (0x0200): Client > > > > disconnected! > > > > (Mon Feb 15 04:49:18 2016) [sssd[nss]] [client_destructor] (0x2000): > > > > Terminated client [0x23d2f80][20] > > > > (Mon Feb 15 04:49:27 2016) [sssd[nss]] [sbus_get_sender_id_send] > > > (0x2000): > > > > Not a sysbus message, quit > > > > > > What does /var/log/secure say? > > > > > > Also you pasted the NSS log, the domain log would be more useful here. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yamakasi.014 at gmail.com Tue Feb 16 19:26:33 2016 From: yamakasi.014 at gmail.com (Matt .) Date: Tue, 16 Feb 2016 20:26:33 +0100 Subject: [Freeipa-users] Split backup actions in stop - backup - start commands Message-ID: Hi, I'm fugiring out if it's possible to strip the ipa start and stop from the backup method and actually do a fullbackup manually started. Any idea ? Thanks! Matt From Nathan.Peters at globalrelay.net Tue Feb 16 22:23:30 2016 From: Nathan.Peters at globalrelay.net (Nathan Peters) Date: Tue, 16 Feb 2016 22:23:30 +0000 Subject: [Freeipa-users] FreeIPA 4.3.0 Kerberos client referrals not working? Message-ID: I have created a trust between my FreeIPA domain and an active directory domain. I can get a kerberos ticket properly from the other domain at the command line on the IPA server. I have also created sudo and HBAC rules to allow my AD users to logon to the IPA domain controller using the recommended nested external group setup. However, I can not actually login to the machines. I should note that our AD domain is office.mydomain.net, but we use alternative UPN suffixes so the usernames are user at mydomain.net. I read the patch notes and apparently support for client referrals that will allow alternate UPN suffixes in trusted domains was added in FreeIPA 4.2.1. Is there anything special I need to do to configure it beyond the creation of the original trust? Do I need to set special options in krb5.conf or sssd.conf to get it to work? ==============Kinit works========================== [root at dc1-ipa-dev-nvan log]# kinit nathan.peters at OFFICE.MYDOMAIN.NET Password for nathan.peters at OFFICE.MYDOMAIN.NET: [root at dc1-ipa-dev-nvan log]# klist Ticket cache: KEYRING:persistent:0:krb_ccache_V7hjacL Default principal: nathan.peters at OFFICE.MYDOMAIN.NET Valid starting Expires Service principal 16/02/16 14:05:33 17/02/16 14:05:30 krbtgt/OFFICE.MYDOMAIN.NET at OFFICE.MYDOMAIN.NET ============/var/log/messages during login failure=============== Feb 16 14:10:14 dc1-ipa-dev-nvan audit: CRYPTO_SESSION pid=2019 uid=0 auid=4294967295 ses=4294967295 msg='op=start direction=from-client cipher=aes256-ctr ksize=256 mac=hmac-sha2-256 pfs=diffie-hellman-group14-sha1 spid=2020 suid=74 rport=9577 laddr=10.178.0.99 lport=22 exe="/usr/sbin/sshd" hostname=? addr=10.8.134.154 terminal=? res=success' Feb 16 14:10:20 dc1-ipa-dev-nvan audit: USER_AUTH pid=2019 uid=0 auid=4294967295 ses=4294967295 msg='op=gssapi acct="nathan.peters at mydomain.net" exe="/usr/sbin/sshd" hostname=? addr=10.8.134.154 terminal=ssh res=failed' Feb 16 14:10:23 dc1-ipa-dev-nvan audit: USER_AUTH pid=2019 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:authentication grantors=? acct="nathan.peters at mydomain.net" exe="/usr/sbin/sshd" hostname=10.8.134.154 addr=10.8.134.154 terminal=ssh res=failed' Feb 16 14:10:23 dc1-ipa-dev-nvan audit: USER_AUTH pid=2019 uid=0 auid=4294967295 ses=4294967295 msg='op=password acct="nathan.peters at mydomain.net" exe="/usr/sbin/sshd" hostname=? addr=10.8.134.154 terminal=ssh res=failed' Feb 16 14:10:25 dc1-ipa-dev-nvan audit: CRYPTO_KEY_USER pid=2019 uid=0 auid=4294967295 ses=4294967295 msg='op=destroy kind=server fp=SHA256:28:cf:eb:e1:3f:61:00:c5:ff:62:da:54:cc:bb:62:7c:e5:07:d1:3a:62:9e:7c:c0:3b:bc:8e:08:90:9a:9b:83 direction=? spid=2020 suid=74 exe="/usr/sbin/sshd" hostname=? addr=10.8.134.154 terminal=? res=success' Feb 16 14:10:25 dc1-ipa-dev-nvan audit: CRYPTO_KEY_USER pid=2019 uid=0 auid=4294967295 ses=4294967295 msg='op=destroy kind=session fp=? direction=both spid=2020 suid=74 rport=9577 laddr=10.178.0.99 lport=22 exe="/usr/sbin/sshd" hostname=? addr=10.8.134.154 terminal=? res=success' Feb 16 14:10:25 dc1-ipa-dev-nvan audit: CRYPTO_KEY_USER pid=2019 uid=0 auid=4294967295 ses=4294967295 msg='op=destroy kind=server fp=SHA256:f2:5c:54:6f:2a:0e:38:19:8c:e4:94:ef:53:2e:9b:ce:07:7f:bb:af:e0:65:7d:11:82:30:cf:03:0d:35:1b:ca direction=? spid=2019 suid=0 exe="/usr/sbin/sshd" hostname=? addr=10.8.134.154 terminal=? res=success' Feb 16 14:10:25 dc1-ipa-dev-nvan audit: CRYPTO_KEY_USER pid=2019 uid=0 auid=4294967295 ses=4294967295 msg='op=destroy kind=server fp=SHA256:4b:0e:be:22:b5:28:65:28:72:90:5b:81:70:99:ff:47:5d:3c:90:a8:81:12:d1:1f:a0:e7:a3:d0:29:d1:25:1e direction=? spid=2019 suid=0 exe="/usr/sbin/sshd" hostname=? addr=10.8.134.154 terminal=? res=success' Feb 16 14:10:25 dc1-ipa-dev-nvan audit: CRYPTO_KEY_USER pid=2019 uid=0 auid=4294967295 ses=4294967295 msg='op=destroy kind=server fp=SHA256:28:cf:eb:e1:3f:61:00:c5:ff:62:da:54:cc:bb:62:7c:e5:07:d1:3a:62:9e:7c:c0:3b:bc:8e:08:90:9a:9b:83 direction=? spid=2019 suid=0 exe="/usr/sbin/sshd" hostname=? addr=10.8.134.154 terminal=? res=success' Feb 16 14:10:25 dc1-ipa-dev-nvan audit: USER_LOGIN pid=2019 uid=0 auid=4294967295 ses=4294967295 msg='op=login acct="nathan.peters at mydomain.net" exe="/usr/sbin/sshd" hostname=? addr=10.8.134.154 terminal=ssh res=failed' ===================/var/log/secure during login failure======================= Feb 16 14:09:56 dc1-ipa-dev-nvan polkitd[604]: Registered Authentication Agent for unix-process:1968:182654681 (system bus name :1.222 [/usr/bin/pkttyagent --notify-fd 5 --fallback], object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_CA.UTF-8) Feb 16 14:09:56 dc1-ipa-dev-nvan polkitd[604]: Unregistered Authentication Agent for unix-process:1968:182654681 (system bus name :1.222, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_CA.UTF-8) (disconnected from bus) Feb 16 14:09:56 dc1-ipa-dev-nvan polkitd[604]: Registered Authentication Agent for unix-process:1979:182654684 (system bus name :1.223 [/usr/bin/pkttyagent --notify-fd 5 --fallback], object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_CA.UTF-8) Feb 16 14:09:56 dc1-ipa-dev-nvan polkitd[604]: Unregistered Authentication Agent for unix-process:1979:182654684 (system bus name :1.223, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_CA.UTF-8) (disconnected from bus) Feb 16 14:10:02 dc1-ipa-dev-nvan sshd[2006]: Connection closed by 10.21.2.100 [preauth] Feb 16 14:10:23 dc1-ipa-dev-nvan sshd[2019]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.8.134.154 user=nathan.peters at mydomain.net Feb 16 14:10:23 dc1-ipa-dev-nvan sshd[2019]: pam_sss(sshd:auth): received for user nathan.peters at mydomain.net: 4 (System error) Feb 16 14:10:23 dc1-ipa-dev-nvan sshd[2019]: Failed password for nathan.peters at mydomain.net from 10.8.134.154 port 9577 ssh2 Feb 16 14:10:25 dc1-ipa-dev-nvan sshd[2019]: error: Received disconnect from 10.8.134.154: 13: Unable to authenticate [preauth] Feb 16 14:10:25 dc1-ipa-dev-nvan sshd[2019]: Disconnected from 10.8.134.154 [preauth] -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkupka at redhat.com Wed Feb 17 07:00:30 2016 From: dkupka at redhat.com (David Kupka) Date: Wed, 17 Feb 2016 08:00:30 +0100 Subject: [Freeipa-users] Split backup actions in stop - backup - start commands In-Reply-To: References: Message-ID: <56C41A8E.7040705@redhat.com> On 16/02/16 20:26, Matt . wrote: > Hi, > > I'm fugiring out if it's possible to strip the ipa start and stop from > the backup method and actually do a fullbackup manually started. > > Any idea ? > > Thanks! > > Matt > Hello Matt, you can perform data only backup where freeipa server is still running (ipa-backup --data --online). But IIUC you want full backup with stopped freeipa sever only want to manually run sequence ipactl stop ; ipa-backup ; ipactl start Could you please explain why do you need such behavior? Honestly, I'm unable to find use for this. There's no way how to do it without touching the code. If you don't mind editing code just remove two else branches starting on lines 293[0] and 316[1] in ipaserver/install/ipa_backup.py (on recent Fedoras located in /usr/lib/python2.7/site-packages/). With this change full backup will be performed on running server unless you stopped it before. It can result in inconsistent data in backup archive. [0] https://git.fedorahosted.org/cgit/freeipa.git/tree/ipaserver/install/ipa_backup.py#n293 [1] https://git.fedorahosted.org/cgit/freeipa.git/tree/ipaserver/install/ipa_backup.py#n316 -- David Kupka From abokovoy at redhat.com Wed Feb 17 07:07:38 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 17 Feb 2016 09:07:38 +0200 Subject: [Freeipa-users] FreeIPA 4.3.0 Kerberos client referrals not working? In-Reply-To: References: Message-ID: <20160217070738.GS4492@redhat.com> On Tue, 16 Feb 2016, Nathan Peters wrote: >I have created a trust between my FreeIPA domain and an active >directory domain. I can get a kerberos ticket properly from the other >domain at the command line on the IPA server. I have also created sudo >and HBAC rules to allow my AD users to logon to the IPA domain >controller using the recommended nested external group setup. >However, I can not actually login to the machines. > >I should note that our AD domain is office.mydomain.net, but we use >alternative UPN suffixes so the usernames are user at mydomain.net. > >I read the patch notes and apparently support for client referrals that >will allow alternate UPN suffixes in trusted domains was added in >FreeIPA 4.2.1. > >Is there anything special I need to do to configure it beyond the >creation of the original trust? Do I need to set special options in >krb5.conf or sssd.conf to get it to work? Not sure what are you trying to achieve. In the output of your 'kinit' call you are not talking to IPA KDC. Instead, you are talking directly to your AD DCs. You can verify it by setting KRB5_TRACE=/dev/stderr in the environment where you would run 'kinit user at AD'. How is IPA KDC involved? >Feb 16 14:10:23 dc1-ipa-dev-nvan sshd[2019]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.8.134.154 user=nathan.peters at mydomain.net >Feb 16 14:10:23 dc1-ipa-dev-nvan sshd[2019]: pam_sss(sshd:auth): received for user nathan.peters at mydomain.net: 4 (System error) >Feb 16 14:10:23 dc1-ipa-dev-nvan sshd[2019]: Failed password for nathan.peters at mydomain.net from 10.8.134.154 port 9577 ssh2 >Feb 16 14:10:25 dc1-ipa-dev-nvan sshd[2019]: error: Received disconnect from 10.8.134.154: 13: Unable to authenticate [preauth] >Feb 16 14:10:25 dc1-ipa-dev-nvan sshd[2019]: Disconnected from 10.8.134.154 [preauth] Use https://fedorahosted.org/sssd/wiki/Troubleshooting to produce sssd logs that can be analyzed. The logs above are mostly useless, they don't tell anything. -- / Alexander Bokovoy From sbose at redhat.com Wed Feb 17 08:13:00 2016 From: sbose at redhat.com (Sumit Bose) Date: Wed, 17 Feb 2016 09:13:00 +0100 Subject: [Freeipa-users] FreeIPA 4.3.0 Kerberos client referrals not working? In-Reply-To: References: Message-ID: <20160217081300.GP20563@p.redhat.com> On Tue, Feb 16, 2016 at 10:23:30PM +0000, Nathan Peters wrote: > I have created a trust between my FreeIPA domain and an active directory domain. I can get a kerberos ticket properly from the other domain at the command line on the IPA server. > I have also created sudo and HBAC rules to allow my AD users to logon to the IPA domain controller using the recommended nested external group setup. > However, I can not actually login to the machines. > > I should note that our AD domain is office.mydomain.net, but we use alternative UPN suffixes so the usernames are user at mydomain.net. > > I read the patch notes and apparently support for client referrals that will allow alternate UPN suffixes in trusted domains was added in FreeIPA 4.2.1. While client referrals with the realm derived from the domain name already work the UPN support is currently WIP (https://fedorahosted.org/freeipa/ticket/5354). HTH bye, Sumit > > Is there anything special I need to do to configure it beyond the creation of the original trust? Do I need to set special options in krb5.conf or sssd.conf to get it to work? > > ==============Kinit works========================== > [root at dc1-ipa-dev-nvan log]# kinit nathan.peters at OFFICE.MYDOMAIN.NET > Password for nathan.peters at OFFICE.MYDOMAIN.NET: > [root at dc1-ipa-dev-nvan log]# klist > Ticket cache: KEYRING:persistent:0:krb_ccache_V7hjacL > Default principal: nathan.peters at OFFICE.MYDOMAIN.NET > > Valid starting Expires Service principal > 16/02/16 14:05:33 17/02/16 14:05:30 krbtgt/OFFICE.MYDOMAIN.NET at OFFICE.MYDOMAIN.NET > > ============/var/log/messages during login failure=============== > Feb 16 14:10:14 dc1-ipa-dev-nvan audit: CRYPTO_SESSION pid=2019 uid=0 auid=4294967295 ses=4294967295 msg='op=start direction=from-client cipher=aes256-ctr ksize=256 mac=hmac-sha2-256 pfs=diffie-hellman-group14-sha1 spid=2020 suid=74 rport=9577 laddr=10.178.0.99 lport=22 exe="/usr/sbin/sshd" hostname=? addr=10.8.134.154 terminal=? res=success' > Feb 16 14:10:20 dc1-ipa-dev-nvan audit: USER_AUTH pid=2019 uid=0 auid=4294967295 ses=4294967295 msg='op=gssapi acct="nathan.peters at mydomain.net" exe="/usr/sbin/sshd" hostname=? addr=10.8.134.154 terminal=ssh res=failed' > Feb 16 14:10:23 dc1-ipa-dev-nvan audit: USER_AUTH pid=2019 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:authentication grantors=? acct="nathan.peters at mydomain.net" exe="/usr/sbin/sshd" hostname=10.8.134.154 addr=10.8.134.154 terminal=ssh res=failed' > Feb 16 14:10:23 dc1-ipa-dev-nvan audit: USER_AUTH pid=2019 uid=0 auid=4294967295 ses=4294967295 msg='op=password acct="nathan.peters at mydomain.net" exe="/usr/sbin/sshd" hostname=? addr=10.8.134.154 terminal=ssh res=failed' > Feb 16 14:10:25 dc1-ipa-dev-nvan audit: CRYPTO_KEY_USER pid=2019 uid=0 auid=4294967295 ses=4294967295 msg='op=destroy kind=server fp=SHA256:28:cf:eb:e1:3f:61:00:c5:ff:62:da:54:cc:bb:62:7c:e5:07:d1:3a:62:9e:7c:c0:3b:bc:8e:08:90:9a:9b:83 direction=? spid=2020 suid=74 exe="/usr/sbin/sshd" hostname=? addr=10.8.134.154 terminal=? res=success' > Feb 16 14:10:25 dc1-ipa-dev-nvan audit: CRYPTO_KEY_USER pid=2019 uid=0 auid=4294967295 ses=4294967295 msg='op=destroy kind=session fp=? direction=both spid=2020 suid=74 rport=9577 laddr=10.178.0.99 lport=22 exe="/usr/sbin/sshd" hostname=? addr=10.8.134.154 terminal=? res=success' > Feb 16 14:10:25 dc1-ipa-dev-nvan audit: CRYPTO_KEY_USER pid=2019 uid=0 auid=4294967295 ses=4294967295 msg='op=destroy kind=server fp=SHA256:f2:5c:54:6f:2a:0e:38:19:8c:e4:94:ef:53:2e:9b:ce:07:7f:bb:af:e0:65:7d:11:82:30:cf:03:0d:35:1b:ca direction=? spid=2019 suid=0 exe="/usr/sbin/sshd" hostname=? addr=10.8.134.154 terminal=? res=success' > Feb 16 14:10:25 dc1-ipa-dev-nvan audit: CRYPTO_KEY_USER pid=2019 uid=0 auid=4294967295 ses=4294967295 msg='op=destroy kind=server fp=SHA256:4b:0e:be:22:b5:28:65:28:72:90:5b:81:70:99:ff:47:5d:3c:90:a8:81:12:d1:1f:a0:e7:a3:d0:29:d1:25:1e direction=? spid=2019 suid=0 exe="/usr/sbin/sshd" hostname=? addr=10.8.134.154 terminal=? res=success' > Feb 16 14:10:25 dc1-ipa-dev-nvan audit: CRYPTO_KEY_USER pid=2019 uid=0 auid=4294967295 ses=4294967295 msg='op=destroy kind=server fp=SHA256:28:cf:eb:e1:3f:61:00:c5:ff:62:da:54:cc:bb:62:7c:e5:07:d1:3a:62:9e:7c:c0:3b:bc:8e:08:90:9a:9b:83 direction=? spid=2019 suid=0 exe="/usr/sbin/sshd" hostname=? addr=10.8.134.154 terminal=? res=success' > Feb 16 14:10:25 dc1-ipa-dev-nvan audit: USER_LOGIN pid=2019 uid=0 auid=4294967295 ses=4294967295 msg='op=login acct="nathan.peters at mydomain.net" exe="/usr/sbin/sshd" hostname=? addr=10.8.134.154 terminal=ssh res=failed' > > ===================/var/log/secure during login failure======================= > Feb 16 14:09:56 dc1-ipa-dev-nvan polkitd[604]: Registered Authentication Agent for unix-process:1968:182654681 (system bus name :1.222 [/usr/bin/pkttyagent --notify-fd 5 --fallback], object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_CA.UTF-8) > Feb 16 14:09:56 dc1-ipa-dev-nvan polkitd[604]: Unregistered Authentication Agent for unix-process:1968:182654681 (system bus name :1.222, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_CA.UTF-8) (disconnected from bus) > Feb 16 14:09:56 dc1-ipa-dev-nvan polkitd[604]: Registered Authentication Agent for unix-process:1979:182654684 (system bus name :1.223 [/usr/bin/pkttyagent --notify-fd 5 --fallback], object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_CA.UTF-8) > Feb 16 14:09:56 dc1-ipa-dev-nvan polkitd[604]: Unregistered Authentication Agent for unix-process:1979:182654684 (system bus name :1.223, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_CA.UTF-8) (disconnected from bus) > Feb 16 14:10:02 dc1-ipa-dev-nvan sshd[2006]: Connection closed by 10.21.2.100 [preauth] > Feb 16 14:10:23 dc1-ipa-dev-nvan sshd[2019]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.8.134.154 user=nathan.peters at mydomain.net > Feb 16 14:10:23 dc1-ipa-dev-nvan sshd[2019]: pam_sss(sshd:auth): received for user nathan.peters at mydomain.net: 4 (System error) > Feb 16 14:10:23 dc1-ipa-dev-nvan sshd[2019]: Failed password for nathan.peters at mydomain.net from 10.8.134.154 port 9577 ssh2 > Feb 16 14:10:25 dc1-ipa-dev-nvan sshd[2019]: error: Received disconnect from 10.8.134.154: 13: Unable to authenticate [preauth] > Feb 16 14:10:25 dc1-ipa-dev-nvan sshd[2019]: Disconnected from 10.8.134.154 [preauth] > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project From pioto at pioto.org Tue Feb 16 16:23:10 2016 From: pioto at pioto.org (Mike Kelly) Date: Tue, 16 Feb 2016 16:23:10 +0000 Subject: [Freeipa-users] ID Views without AD In-Reply-To: References: <20160210081945.GR12787@redhat.com> <20160211082137.GA28898@redhat.com> Message-ID: >> Thanks. Here's what is hopefully the relevant lines: > > I'm sorry, but these logs only capture how the original entry was searched, not the overrides. Can you capture the full logs since the sssd startup? Also please make sure the cache was invalidated prior to the request with sss_cache -E. Attached are the full logs since a restart of sssd. I ran these commands: systemctl stop sssd echo '----MARK----' >> /var/log/sssd/sssd_home.pioto.org.log # so I could mark were the restart happened sss_cache -E systemctl start sssd sss_cache -E id pioto ---- I still don't see the override being applied. Possibly because of this line? (Tue Feb 16 11:12:27 2016) [sssd[be[home.pioto.org]]] [ipa_get_ad_override_send] (0x4000): View not defined, nothing to do. So, I get the feeling that, for whatever reason, sssd isn't correctly deciding that my id view applies to this host, or just isn't looking it up? Is there possibly some sort of extra configuration that I've missed to tell SSSD to apply these views? From what I can tell, it should just pick these up out of the box, from the configuration built by ipa-client-install...? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: sssd_home.pioto.org.log Type: application/octet-stream Size: 588863 bytes Desc: not available URL: From jhrozek at redhat.com Wed Feb 17 08:31:32 2016 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 17 Feb 2016 09:31:32 +0100 Subject: [Freeipa-users] FreeIPA 4.3.0 Kerberos client referrals not working? In-Reply-To: <20160217081300.GP20563@p.redhat.com> References: <20160217081300.GP20563@p.redhat.com> Message-ID: <20160217083132.GX12060@hendrix.arn.redhat.com> On Wed, Feb 17, 2016 at 09:13:00AM +0100, Sumit Bose wrote: > On Tue, Feb 16, 2016 at 10:23:30PM +0000, Nathan Peters wrote: > > I have created a trust between my FreeIPA domain and an active directory domain. I can get a kerberos ticket properly from the other domain at the command line on the IPA server. > > I have also created sudo and HBAC rules to allow my AD users to logon to the IPA domain controller using the recommended nested external group setup. > > However, I can not actually login to the machines. > > > > I should note that our AD domain is office.mydomain.net, but we use alternative UPN suffixes so the usernames are user at mydomain.net. > > > > I read the patch notes and apparently support for client referrals that will allow alternate UPN suffixes in trusted domains was added in FreeIPA 4.2.1. > > While client referrals with the realm derived from the domain name > already work the UPN support is currently WIP > (https://fedorahosted.org/freeipa/ticket/5354). Several users have reported that a workaround of: subdomain_inherit = ldap_user_principal ldap_user_principal = phonyattr solves their issue, but it's just a workaround, not a real solution.. From bahanw042014 at gmail.com Wed Feb 17 08:36:21 2016 From: bahanw042014 at gmail.com (bahan w) Date: Wed, 17 Feb 2016 09:36:21 +0100 Subject: [Freeipa-users] Logging configuration for ipa server In-Reply-To: References: Message-ID: Hello ! I send you this mail for a question about the kerberos logs on the ipa server. On the server, there are two configuration files : - kdc.conf : for the server - krb5.conf : for the client In both of these files, we can put a logging section. In this section, there is 3 parameters : - default - kdc - admin May I put the same values for both client and server or is it better to put different values for the server part ? BR. Bahan -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkupka at redhat.com Wed Feb 17 09:14:32 2016 From: dkupka at redhat.com (David Kupka) Date: Wed, 17 Feb 2016 10:14:32 +0100 Subject: [Freeipa-users] Logging configuration for ipa server In-Reply-To: References: Message-ID: <56C439F8.4090402@redhat.com> On 17/02/16 09:36, bahan w wrote: > Hello ! > > I send you this mail for a question about the kerberos logs on the ipa > server. > > On the server, there are two configuration files : > - kdc.conf : for the server > - krb5.conf : for the client > > In both of these files, we can put a logging section. > In this section, there is 3 parameters : > - default > - kdc > - admin > > May I put the same values for both client and server or is it better to put > different values for the server part ? > > BR. > > Bahan > > > Hello Bahan, looking into krb5.conf man page I don't see any logging section. I think it should be enough to configure logging on the server (in kdc.conf). Example: User tries to perform kinit with nonexistent principal and receives error $ kinit nonexistent kinit: Client 'nonexistent at EXAMPLE.TEST' not found in Kerberos database while getting initial credentials Then admin can see this event in the kdc log on server: Feb 17 10:10:35 vm-248.example.test krb5kdc[11350](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 192.0.2.248: CLIENT_NOT_FOUND: nonexistent at EXAMPLE.TEST for krbtgt/EXAMPLE.TEST at EXAMPLE.TEST, Client not found in Kerberos database -- David Kupka From yamakasi.014 at gmail.com Wed Feb 17 09:47:46 2016 From: yamakasi.014 at gmail.com (Matt .) Date: Wed, 17 Feb 2016 10:47:46 +0100 Subject: [Freeipa-users] Split backup actions in stop - backup - start commands In-Reply-To: <56C41A8E.7040705@redhat.com> References: <56C41A8E.7040705@redhat.com> Message-ID: Hi David, I have tested your way out and it seems to be OK. The reason why I need this was is so I can perform a stop and ipa-backup before I start my backup to my backupserver. (pre-command). If I use ipa-backup directly it errors between the stop of ipa and the actual ipa backup. I need to check that out further. An ipactl start is not needed it seems as the ipa-backup command seems to start ipa at any time again. Do you understand/agree here ? 2016-02-17 8:00 GMT+01:00 David Kupka : > On 16/02/16 20:26, Matt . wrote: >> >> Hi, >> >> I'm fugiring out if it's possible to strip the ipa start and stop from >> the backup method and actually do a fullbackup manually started. >> >> Any idea ? >> >> Thanks! >> >> Matt >> > > Hello Matt, > you can perform data only backup where freeipa server is still running > (ipa-backup --data --online). > But IIUC you want full backup with stopped freeipa sever only want to > manually run sequence ipactl stop ; ipa-backup ; ipactl start > > Could you please explain why do you need such behavior? Honestly, I'm unable > to find use for this. > > There's no way how to do it without touching the code. If you don't mind > editing code just remove two else branches starting on lines 293[0] and > 316[1] in ipaserver/install/ipa_backup.py (on recent Fedoras located in > /usr/lib/python2.7/site-packages/). > > With this change full backup will be performed on running server unless you > stopped it before. It can result in inconsistent data in backup archive. > > [0] > https://git.fedorahosted.org/cgit/freeipa.git/tree/ipaserver/install/ipa_backup.py#n293 > [1] > https://git.fedorahosted.org/cgit/freeipa.git/tree/ipaserver/install/ipa_backup.py#n316 > > -- > David Kupka From jhrozek at redhat.com Wed Feb 17 09:20:15 2016 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 17 Feb 2016 10:20:15 +0100 Subject: [Freeipa-users] Announcing SSSD 1.11.8 Message-ID: <20160217092015.GA3765@hendrix.arn.redhat.com> === SSSD 1.11.8 === The SSSD team is proud to announce the release of version 1.11.8 of the System Security Services Daemon. As always, the source is available from https://fedorahosted.org/sssd == Feedback == Please provide comments, bugs and other feedback via the sssd-devel or sssd-users mailing lists: https://lists.fedorahosted.org/mailman/listinfo/sssd-devel https://lists.fedorahosted.org/mailman/listinfo/sssd-users == Highlights == * This release focuses on backporting bug fixes from the 1.12 and 1.13 releases. At the moment, the SSSD upstream does not plan on releasing 1.11.9, barring security issues or regressions in this release. We recommend that all users of 1.11 upgrade to 1.12 or 1.13. * Several bugs related to using id_provider=ldap together with ID mapping enabled were fixed * Fixed a potential use-after-free error in the nested groups resolution code * The service restart code in the main "sssd" process was improved * The PAC responder can be built with MIT Kerberos versions 1.13 and 1.14 * A potential segfault in the memberof ldb plugin was fixed * The LDAP child no longer leaves a stray temporary file behind in case acquiring the credentials fails * The sudo responder works correctly even for users or groups whose name contains an LDAP special character such as ) * The autofs responder now works even with setups that enable the default_domain_suffix option * A memory leak in the NSS responder when a non-existing netgroup was requested is fixed in this release * The SSSD no longer leaks a file descriptor if service discovery times out when discovering an LDAP server * The sudo responder fixed the logic to sort entries with the sudoOrder attribute to match the sudo's native LDAP code == Documentation Changes == * The ldap_use_tokengroups option defaults to false in the generic LDAP provider. Previously, both the AD and LDAP provider (with ldap_schema set to ad) attempted to use the tokenGroups, resulting in numerous bugs. == Tickets Fixed == * https://fedorahosted.org/sssd/ticket/2412 Error processing universal groups with cross-domain membership in SSSD server mode * https://fedorahosted.org/sssd/ticket/2471 RHEL6.6 sssd (1.11) fails if IPA permissions and roles have the same name * https://fedorahosted.org/sssd/ticket/2484 Password change over ssh doesn't work with OTP and FreeIPA * https://fedorahosted.org/sssd/ticket/2448 MAN: If ldap_group_base is set, tokengroups might not be able to convert all GIDs to names * https://fedorahosted.org/sssd/ticket/2445 Race condition while invalidating memory cache in client code * https://fedorahosted.org/sssd/ticket/2492 Group membership gets lost in IPA server mode * https://fedorahosted.org/sssd/ticket/2573 Use after free in proxy provider. * https://fedorahosted.org/sssd/ticket/2611 sssd_be dumping core if enumeration times out * https://fedorahosted.org/sssd/ticket/2525 Monitor SIGKILL timer issue and service restart failure * https://fedorahosted.org/sssd/ticket/2572 [abrt] sssd-common: talloc_abort(): sssd killed by SIGABRT * https://fedorahosted.org/sssd/ticket/2430 sssd segfaults repeatedly with error 4 in memberof.so * https://fedorahosted.org/sssd/ticket/1096 Clock skew in krb5 auth should result in offline operation, not failure * https://fedorahosted.org/sssd/ticket/2592 ccname_file_dummy is not unlinked on error * https://fedorahosted.org/sssd/ticket/2613 sysdb sudo search doesn't escape special characters * https://fedorahosted.org/sssd/ticket/2625 Sudo responder does not respect filter_users and filter_groups * https://fedorahosted.org/sssd/ticket/2643 autofs provider fails when default_domain_suffix and use_fully_qualified_names set * https://fedorahosted.org/sssd/ticket/2634 sssd nss responder gets wrong number of secondary groups * https://fedorahosted.org/sssd/ticket/2644 ignore_group_members doesn't work for subdomains * https://fedorahosted.org/sssd/ticket/2659 IPA enumeration provider crashes * https://fedorahosted.org/sssd/ticket/2663 id lookup for non-root domain users doesn't return all groups on first attempt * https://fedorahosted.org/sssd/ticket/2681 SSSD cache is not updated after user is deleted from ldap server * https://fedorahosted.org/sssd/ticket/2744 cleanup_groups should sanitize dn of groups * https://fedorahosted.org/sssd/ticket/2800 Relax POSIX check * https://fedorahosted.org/sssd/ticket/2803 Memory leak / possible DoS with krb auth. * https://fedorahosted.org/sssd/ticket/2792 SSSD is not closing sockets properly * https://fedorahosted.org/sssd/ticket/2888 SRV lookups with id_provider=proxy and auth_provider=krb5 * https://fedorahosted.org/sssd/ticket/2865 sssd_nss memory usage keeps growing on sssd-1.12.4-47.el6.x86_64 (RHEL6.7) when trying to retrieve non-existing netgroups * https://fedorahosted.org/sssd/ticket/2682 sudoOrder not honored as expected == Detailed Changelog == Adam Tkac (1): * Option filter_users had no effect for retrieving sudo rules Aron Parsons (1): * autofs: fix 'Cannot allocate memory' with FQDNs Dan Lavu (1): * MAN: page edit for ldap_use_tokengroups Daniel Hjorth (1): * LDAP: unlink ccname_file_dummy if there is an error Jakub Hrozek (8): * Updating the version for the 1.11.8 development * IPA: Use GC for group lookups in server mode * LDAP: Do not clobber return value when multiple controls are returned * PAC: krb5_pac_verify failures should not be fatal * LDAP: return after tevent_req_error * KRB5: Go offline in case of clock skew * Download complete groups if ignore_group_members is set with tokengroups * DP: Set extra_value to NULL for enum requests Jan Engelhardt (1): * build: call AC_BUILD_AUX_DIR before anything else Lukas Slebodnik (16): * Revert "LDAP: Change defaults for ldap_user/group_objectsid" * LDAP: Disable token groups by default * sss_client: Extract destroying of mmap cache to function * sss_client: Fix race condition in memory cache * PROXY: Fix use after free * pysss_nss_idmap: Use wrapper for older python * MONITOR: Fix double free * TEST: Test empty results from functions sysdb_search_* * SDAP: Do not set gid 0 twice * nss: Do not ignore default vaue of SYSDB_INITGR_EXPIRE * SDAP: Set initgroups expire attribute at the end * SDAP: Remove user from cache for missing user in LDAP * LDAP: Sanitize group dn before using in filter * LDAP: Fix leak of file descriptors * BUILD: Accept krb5 1.14 for building the PAC plugin * BUILD: Fix linking issues on debian Michal Zidek (1): * LDAP: Change defaults for ldap_user/group_objectsid Nalin Dahyabhai (1): * Accept krb5 1.13 for building the PAC plugin Nikolai Kondrashov (1): * build: Don't install ad and ipa man pages unnecessarily Pavel B?ezina (4): * IPA: use ipaUserGroup object class for groups * enumeration: fix talloc context * sudo: sanitize filter values * sudo: use "higher value wins" when ordering rules Pavel Reichl (14): * LDAP: retain external members * SDAP: return after tevent_req_error * sudo: return after tevent_req_error * monitor: use-after-free bugfix * monitor: monitor_kill_service - refactor * monitor: memory-leak bug * SYSDB: sysdb_search_entry fix memory leak * SYSDB: sysdb_search_custom fix memory leak * TESTS: sysdb_search_return_ENOENT - check mem leaks * SDAP: Relax POSIX check * NSS: sysdb_getnetgr check return value first * NSS: sysdb_getnetgr refactor * NSS: fix memory leak in sysdb_getnetgr * NSS: Fix memory leak netgroup Petr Cech (1): * KRB5: Adding DNS SRV lookup for krb5 provider Simo Sorce (1): * Signals: Remove unused functions Stephen Gallagher (2): * monitor: Service restart fixes * UTIL: Do not change SSSD domains in get_domains_head Sumit Bose (2): * memberof: check for empty arrays to avoid segfaults * ldap: use proper sysdb name in groups_by_user_done() Thomas Oulevey (1): * Fix memory leak in sssdpac_verify() From pdomineaux at gmail.com Wed Feb 17 13:01:12 2016 From: pdomineaux at gmail.com (Philippe Domineaux) Date: Wed, 17 Feb 2016 14:01:12 +0100 Subject: [Freeipa-users] Fwd: [freeipa-users] Configuring Automount on Ubuntu Clients In-Reply-To: References: <56B8BAB4.2080007@ubuntu.com> <20160214071417.GA6343@eru> Message-ID: Hello, and don?t you have any issues with the display of files owners. I can only see nobody as the owner/group for files? Le 17 f?vrier 2016 ? 02:08:51, Domineaux Philippe (pdomineaux at gmail.com) a ?crit: ---------- Forwarded message ---------- From: Filip Pytloun Date: 2016-02-14 8:14 GMT+01:00 Subject: Re: [Freeipa-users] [freeipa-users] Configuring Automount on Ubuntu Clients To: freeipa-users at redhat.com Hello, we are using Ubuntu 14.04 on FreeIPA clients and Ubuntu 16.04 on FreeIPA server for 2 months with no critical issues. Using newer freeipa-client was not needed, only sssd update from here, because trusty version is buggy: https://launchpad.net/~sssd/+archive/ubuntu/updates?field.series_filter=trusty On server side, it was only needed to fix apparmor policy for bind to fix FreeIPA DNS zones: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814314 Maybe someone could be interested in Salt formula we are using to setup Freeipa server/client: https://github.com/tcpcloud/salt-formula-freeipa Filip On 2016/02/13 17:40, Prasun Gera wrote: > Just replying to this thread to express interest in good client support in > Ubuntu. As 16.04 draws close to a release, it would be great if the client > side of things work well out of the box in 16.04 without any 3rd party > ppas. 12.04 was pretty bad, 14.04 was mostly usable with some issues. I'm > hoping that with 16.04, it reaches parity with Fedora based distros. I'll >? be happy to do some preliminary testing if needed. > > On Mon, Feb 8, 2016 at 10:56 AM, Timo Aaltonen wrote: > > > 04.02.2016, 19:28, Jon kirjoitti: > > > Is Ubuntu not supported with FreeIPA?? Is there an updated install > > > script?? I installed the freeipa-client from public repos. > > > > > >>> ii? freeipa-client > > >? 3.3.4-0ubuntu3.1? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? amd64 > > >? FreeIPA centralized identity framework -- client > > >>> ii? python-freeipa > > >? 3.3.4-0ubuntu3.1? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? amd64 > > >? FreeIPA centralized identity framework -- python modules > > > > The stock packages in 14.04 are rather old, you'd probably be happier with > > the 4.0.5-based client available on the PPA: > > > > https://launchpad.net/~freeipa/+archive/ubuntu/4.0 > > > > > > > > -- > > t > > > > -- > > Manage your subscription for the Freeipa-users mailing list: > > https://www.redhat.com/mailman/listinfo/freeipa-users > > Go to http://freeipa.org for more info on the project > > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasun.gera at gmail.com Wed Feb 17 15:06:28 2016 From: prasun.gera at gmail.com (Prasun Gera) Date: Wed, 17 Feb 2016 10:06:28 -0500 Subject: [Freeipa-users] Fwd: [freeipa-users] Configuring Automount on Ubuntu Clients In-Reply-To: References: <56B8BAB4.2080007@ubuntu.com> <20160214071417.GA6343@eru> Message-ID: That could be an nfs v3 v/s v4 issue. I had a similar issue, which I resolved by setting nfs to v3 at mount time. On Wed, Feb 17, 2016 at 8:01 AM, Philippe Domineaux wrote: > Hello, > > and don?t you have any issues with the display of files owners. > I can only see nobody as the owner/group for files? > > > Le 17 f?vrier 2016 ? 02:08:51, Domineaux Philippe (pdomineaux at gmail.com) > a ?crit: > > > ---------- Forwarded message ---------- > From: Filip Pytloun > Date: 2016-02-14 8:14 GMT+01:00 > Subject: Re: [Freeipa-users] [freeipa-users] Configuring Automount on > Ubuntu Clients > To: freeipa-users at redhat.com > > > Hello, > > we are using Ubuntu 14.04 on FreeIPA clients and Ubuntu 16.04 on FreeIPA > server for 2 months with no critical issues. > > Using newer freeipa-client was not needed, only sssd update from here, > because trusty version is buggy: > > https://launchpad.net/~sssd/+archive/ubuntu/updates?field.series_filter=trusty > > On server side, it was only needed to fix apparmor policy for bind to > fix FreeIPA DNS zones: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814314 > > Maybe someone could be interested in Salt formula we are using to setup > Freeipa server/client: https://github.com/tcpcloud/salt-formula-freeipa > > Filip > > On 2016/02/13 17:40, Prasun Gera wrote: > > Just replying to this thread to express interest in good client support > in > > Ubuntu. As 16.04 draws close to a release, it would be great if the > client > > side of things work well out of the box in 16.04 without any 3rd party > > ppas. 12.04 was pretty bad, 14.04 was mostly usable with some issues. I'm > > hoping that with 16.04, it reaches parity with Fedora based distros. I'll > > be happy to do some preliminary testing if needed. > > > > On Mon, Feb 8, 2016 at 10:56 AM, Timo Aaltonen > wrote: > > > > > 04.02.2016, 19:28, Jon kirjoitti: > > > > Is Ubuntu not supported with FreeIPA? Is there an updated install > > > > script? I installed the freeipa-client from public repos. > > > > > > > >>> ii freeipa-client > > > > 3.3.4-0ubuntu3.1 amd64 > > > > FreeIPA centralized identity framework -- client > > > >>> ii python-freeipa > > > > 3.3.4-0ubuntu3.1 amd64 > > > > FreeIPA centralized identity framework -- python modules > > > > > > The stock packages in 14.04 are rather old, you'd probably be happier > with > > > the 4.0.5-based client available on the PPA: > > > > > > https://launchpad.net/~freeipa/+archive/ubuntu/4.0 > > > > > > > > > > > > -- > > > t > > > > > > -- > > > Manage your subscription for the Freeipa-users mailing list: > > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > Go to http://freeipa.org for more info on the project > > > > > > -- > > Manage your subscription for the Freeipa-users mailing list: > > https://www.redhat.com/mailman/listinfo/freeipa-users > > Go to http://freeipa.org for more info on the project > > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project > > ------------------------------ > > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project > -------------- next part -------------- An HTML attachment was scrubbed... URL: From svm2k20 at gmail.com Wed Feb 17 15:35:53 2016 From: svm2k20 at gmail.com (Shashi M) Date: Wed, 17 Feb 2016 15:35:53 +0000 Subject: [Freeipa-users] Freeipa-users Digest, Vol 84, Issue 87 In-Reply-To: References: Message-ID: > > > Message: 2 > Date: Mon, 27 Jul 2015 17:30:09 +0300 > From: Alexander Bokovoy > To: John Stein > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] AD trust deployment without IPA authority > over reverse lookup zone > Message-ID: <20150727143009.GC21928 at redhat.com> > Content-Type: text/plain; charset=us-ascii; format=flowed > > On Mon, 27 Jul 2015, John Stein wrote: > >Hi, > > > >I consider deploying IPA in my organization.The environment is > disconnected > >from the internet.I have some concerns I'm not sure how to resolve. > > > >The environment consists mostly of windows servers (thousands) and > >workstations (ten thousand) managed by AD (CORP.COM). There is also a > small > >linux environment (up to a thousand servers) that are currently not > >centerally managed (user-wise). > > > >I want to utilize IPA and the AD trust feature to implement SSO. > > > >I'd like to have a sub-domain ran by IPA (LINUX.CORP.COM). > > > >Because the environment is windows dominated, the AD is used as the > >authoritative DNS server for all forward and reverse lookup zones. > > > >The AD trust requires that both the IPA and AD will be authoritative over > >their respective forward and reverse lookup zones. However, the linux and > No. We require that *some entity* is responsible for the zones. If you > put everything in AD DNS, fine, but then you are responsible for manual > update of the zone records and that all specific records are there. > > >windows servers are spread across multiple subnets without any big-scale > >logic, therefore it is not practical to create a reverse lookup zone for > >each subnet in the IPA server as those subnets contain both linux and > >windows machines. > You cannot have machines from IPA and AD domains in the same DNS zone at > the same time. A/AAAA records of those IPA and AD machines must belong > to different DNS zones. > > This is basic requirement of Active Directory deployment -- each AD > domain is responsible for at least one DNS zone and you cannot have > machines from two different AD domains in the same DNS zone. > > >I came up with some solutions: > > > >1) Have only the AD as a DNS server and give up on ipa-client-install and > >automatic client registration. > Totally unrelated to how you handle DNS zones. ipa-client-install does > not require you to allow creation of DNS records. It can sufficiently > work with a configuration where a DNS record for the host is > pre-created. > > >2) DNS synchronization between IPA and AD. > Unrelated and is not recommended. In DNS lexicon only a single entity is > responsible for the single DNS zone. IPA cannot be authoritative at the > same time as AD. (Neither we support IPA being a slave for other DNS > server). > > >3) Have the IPA manage the forward zone (linux.corp.com), and have the > >clients update its own A record automatically upon ipa-client-install, > >while having the AD manage the reverse zones (A or B class subnets) with > me > >creating the PTR records manually. The IPA will be configured as a > >conditional forwarder for linux.corp.com, while the AD will be configured > >as a global forwarder in the IPA server. > That would work. There is a bug in nsupdate tool that prevents you from > GSSAPI-updating PTR records (over AD trust) so going with manual PTR > records would work. > > You need to make sure AD has no policy to periodically remove PTR > records for Linux machines. > > -- > / Alexander Bokovoy > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pioto at pioto.org Thu Feb 18 02:25:25 2016 From: pioto at pioto.org (Mike Kelly) Date: Thu, 18 Feb 2016 02:25:25 +0000 Subject: [Freeipa-users] ID Views without AD In-Reply-To: References: <20160210081945.GR12787@redhat.com> <20160211082137.GA28898@redhat.com> Message-ID: Digging into the code more, I wonder if this is a bug in sssd? https://github.com/SSSD/sssd/blob/sssd-1_13_0/src/db/sysdb.h#L465-L474 -- NULL is treated as the "default" view, as is the literal string "default", in is_default_view(...). https://github.com/SSSD/sssd/blob/sssd-1_13_0/src/providers/ipa/ipa_views.c#L274-L284 - NULL is treated as "View not defined, nothing to do", in ipa_get_ad_override_send(...). Seems possible that, if that first condition is removed, things could work like I'd expect them to? But, I'm just grasping at straws at this point... is there possibly some config field I can use to force the view name? I feel like the code that's supposed to detect the view name isn't triggering correctly in my case, and that's what is triggering the issue... On Tue, Feb 16, 2016 at 11:23 AM Mike Kelly wrote: > >> Thanks. Here's what is hopefully the relevant lines: > > > > I'm sorry, but these logs only capture how the original entry was > searched, not the overrides. Can you capture the full logs since the sssd > startup? Also please make sure the cache was invalidated prior to the > request with sss_cache -E. > > Attached are the full logs since a restart of sssd. > > I ran these commands: > > systemctl stop sssd > > echo '----MARK----' >> /var/log/sssd/sssd_home.pioto.org.log # so I could > mark were the restart happened > > sss_cache -E > > systemctl start sssd > > sss_cache -E > > id pioto > > ---- > > I still don't see the override being applied. Possibly because of this > line? > > (Tue Feb 16 11:12:27 2016) [sssd[be[home.pioto.org]]] [ipa_get_ad_override_send] > (0x4000): View not defined, nothing to do. > > So, I get the feeling that, for whatever reason, sssd isn't correctly > deciding that my id view applies to this host, or just isn't looking it up? > > Is there possibly some sort of extra configuration that I've missed to > tell SSSD to apply these views? From what I can tell, it should just pick > these up out of the box, from the configuration built by > ipa-client-install...? > -- Mike Kelly -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkupka at redhat.com Thu Feb 18 09:42:14 2016 From: dkupka at redhat.com (David Kupka) Date: Thu, 18 Feb 2016 10:42:14 +0100 Subject: [Freeipa-users] Split backup actions in stop - backup - start commands In-Reply-To: References: <56C41A8E.7040705@redhat.com> Message-ID: <56C591F6.9050509@redhat.com> On 17/02/16 10:47, Matt . wrote: > Hi David, > > I have tested your way out and it seems to be OK. > > The reason why I need this was is so I can perform a stop and > ipa-backup before I start my backup to my backupserver. (pre-command). > > If I use ipa-backup directly it errors between the stop of ipa and the > actual ipa backup. I need to check that out further. > > An ipactl start is not needed it seems as the ipa-backup command seems > to start ipa at any time again. > > Do you understand/agree here ? Hello Matt, unfortunately I don't understand. The backup procedure AFAIK should work like this: # ipa-backup && rsync -r /var/lib/ipa/backup/ backup.example.test:/ipa/ You ca run it manually or place it into the crontab or use it in your orchestration system. It will backup the ipa server with necessary stop and start and then copy the new backup to the backup server. Still I don't see the need for stopping the server manually. ipa-backup calls "ipactl start" [0]. If you remove the else branch it will not start the server. [0 ]https://git.fedorahosted.org/cgit/freeipa.git/tree/ipaserver/install/ipa_backup.py#n316 HTH, David > > > > 2016-02-17 8:00 GMT+01:00 David Kupka : >> On 16/02/16 20:26, Matt . wrote: >>> >>> Hi, >>> >>> I'm fugiring out if it's possible to strip the ipa start and stop from >>> the backup method and actually do a fullbackup manually started. >>> >>> Any idea ? >>> >>> Thanks! >>> >>> Matt >>> >> >> Hello Matt, >> you can perform data only backup where freeipa server is still running >> (ipa-backup --data --online). >> But IIUC you want full backup with stopped freeipa sever only want to >> manually run sequence ipactl stop ; ipa-backup ; ipactl start >> >> Could you please explain why do you need such behavior? Honestly, I'm unable >> to find use for this. >> >> There's no way how to do it without touching the code. If you don't mind >> editing code just remove two else branches starting on lines 293[0] and >> 316[1] in ipaserver/install/ipa_backup.py (on recent Fedoras located in >> /usr/lib/python2.7/site-packages/). >> >> With this change full backup will be performed on running server unless you >> stopped it before. It can result in inconsistent data in backup archive. >> >> [0] >> https://git.fedorahosted.org/cgit/freeipa.git/tree/ipaserver/install/ipa_backup.py#n293 >> [1] >> https://git.fedorahosted.org/cgit/freeipa.git/tree/ipaserver/install/ipa_backup.py#n316 >> >> -- >> David Kupka -- David Kupka From harenberg at physik.uni-wuppertal.de Thu Feb 18 10:11:03 2016 From: harenberg at physik.uni-wuppertal.de (Torsten Harenberg) Date: Thu, 18 Feb 2016 11:11:03 +0100 Subject: [Freeipa-users] IPA 4.2.0 / CentOS 7: krb5kdc: Server error - while fetching master key K/M for realm Message-ID: <56C598B7.4030207@physik.uni-wuppertal.de> Dear all, we run a pair of IPA servers: a master running on FC 21 and a slave running on CentOS release 7.2.1511. krb5kdc: Server error - while fetching master key K/M for realm PLEIADES.UNI-WUPPERTAL.DE To handle CVE-2015-7547, we upgraded both systems (with a simple "yum update"). The master came up fine, the slave, however, seems not to work after the upgrade. The web server did not start and we tackled that down to slapd not working and this seems not to work as krb5kdc was not enabled anymore in systemctl. So we did a systemctl enable krb5kdc and rebooted once again, but Kerberos does not start with: krb5kdc: Server error - while fetching master key K/M for realm PLEIADES.UNI-WUPPERTAL.DE and ideas how to proceed? Thanks Torsten -- Dr. Torsten Harenberg harenberg at physik.uni-wuppertal.de Bergische Universitaet Fakult?t 4 - Physik Tel.: +49 (0)202 439-3521 Gaussstr. 20 Fax : +49 (0)202 439-2811 42097 Wuppertal From harenberg at physik.uni-wuppertal.de Thu Feb 18 10:21:55 2016 From: harenberg at physik.uni-wuppertal.de (Torsten Harenberg) Date: Thu, 18 Feb 2016 11:21:55 +0100 Subject: [Freeipa-users] IPA 4.2.0 / CentOS 7: krb5kdc: Server error - while fetching master key K/M for realm In-Reply-To: <56C598B7.4030207@physik.uni-wuppertal.de> References: <56C598B7.4030207@physik.uni-wuppertal.de> Message-ID: <56C59B43.8060707@physik.uni-wuppertal.de> Sorry for self-replying. I should have mentioned that we already went through: http://www.freeipa.org/page/Troubleshooting#Service_does_not_start But it turned out that a simple ipactl stop ipactl start helped. Surprisingly, the service does not start correctly at boot time, but starting it through ipactl afterwards brings it up without any complaint. Best regards Torsten -- Dr. Torsten Harenberg harenberg at physik.uni-wuppertal.de Bergische Universitaet Fakult?t 4 - Physik Tel.: +49 (0)202 439-3521 Gaussstr. 20 Fax : +49 (0)202 439-2811 42097 Wuppertal From sbose at redhat.com Thu Feb 18 10:26:58 2016 From: sbose at redhat.com (Sumit Bose) Date: Thu, 18 Feb 2016 11:26:58 +0100 Subject: [Freeipa-users] ID Views without AD In-Reply-To: References: <20160210081945.GR12787@redhat.com> <20160211082137.GA28898@redhat.com> Message-ID: <20160218102658.GF30390@p.redhat.com> On Tue, Feb 16, 2016 at 04:23:10PM +0000, Mike Kelly wrote: > >> Thanks. Here's what is hopefully the relevant lines: > > > > I'm sorry, but these logs only capture how the original entry was > searched, not the overrides. Can you capture the full logs since the sssd > startup? Also please make sure the cache was invalidated prior to the > request with sss_cache -E. > > Attached are the full logs since a restart of sssd. Thank you, the logs helped. The IPA client reads the idview at startup time either from the cache or the IPA server. Since there is of course no idview name saved in the cache of your client the name must be looked up from the server. The lookup of the idview name is part of the request which reads other data about the IPA domain and possible trusted domains. Unfortunately the current code expects that e.g. the domain SID of the IPA domain is defined before it proceeds to read the idview. This is of course a bug and I will try to fix it. If you would like to try a work-around you can call ipa-adtrust-install on one of your IPA servers. This will create the needed data on the server. It is sufficient to call it on one server because the data will be replicated to the other servers and since you currently not plan to add a trust to a AD domain, you do not have to prepare additional services on other server (with FreeIPA-4.2 this wouldn't even be necessary if you plan to add a trust). If you can wait a day or two I'd be happy to prepare a SSSD test build with a fix. bye, Sumit > > I ran these commands: > > systemctl stop sssd > > echo '----MARK----' >> /var/log/sssd/sssd_home.pioto.org.log # so I could > mark were the restart happened > > sss_cache -E > > systemctl start sssd > > sss_cache -E > > id pioto > > ---- > > I still don't see the override being applied. Possibly because of this line? > > (Tue Feb 16 11:12:27 2016) [sssd[be[home.pioto.org]]] > [ipa_get_ad_override_send] > (0x4000): View not defined, nothing to do. > > So, I get the feeling that, for whatever reason, sssd isn't correctly > deciding that my id view applies to this host, or just isn't looking it up? > > Is there possibly some sort of extra configuration that I've missed to tell > SSSD to apply these views? From what I can tell, it should just pick these > up out of the box, from the configuration built by ipa-client-install...? > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project From Terry.John at completeautomotivesolutions.co.uk Thu Feb 18 11:41:26 2016 From: Terry.John at completeautomotivesolutions.co.uk (Terry John) Date: Thu, 18 Feb 2016 11:41:26 +0000 Subject: [Freeipa-users] 14: No supported authentication methods available Message-ID: I have an AWS instance running Centos 6.7 correctly configured for freeipa but I needed to make a backup machine which would remain live. I created a clone of the machine and changed the host name and the settings in /etc/hosts. When I tried to run ipa-client-install it told me to run the uninstall which I did. This had the worrying effect of not being able to log into my original live server but thankfully after a while it came good. I don't know why. Back on the new server I ran 'ipa-client-install --enable-dns-updates -mkhomedir' and it seemed to run ok. The host was created on the freeipa GUI and I added it to the same host group as the original server. But when I try to log in via SSH I get the error 'No supported authentication methods available'. I do have root access via the AWS Key file. As far as I can tell all the relevant settings seem the same between the two servers but one works and the other doesn't. I can kinit and klist using my freeipa account. 'getent netgroup my-servergroup' works fine. I can't seem to find anything relevant in the sssd logs and /var/log/secure just give me the same error of no supported authentication methods available I have noticed in /var/log/messages when I restart sssd and error which may be relevant but can't find anything useful so far sssd[be[my.domain.net]]: dereference processing failed : Input/output error Thanks Terry The Manheim group of companies within the UK comprises: Manheim Europe Limited (registered number: 03183918), Manheim Auctions Limited (registered number: 00448761), Manheim Retail Services Limited (registered number: 02838588), Motors.co.uk Limited (registered number: 05975777), Real Time Communications Limited (registered number: 04277845) and Complete Automotive Solutions Limited (registered number: 05302535). Each of these companies is registered in England and Wales with the registered office address of Central House, Leeds Road, Rothwell, Leeds LS26 0JE. The Manheim group of companies operates under various brand/trading names including Manheim Inspection Services, Manheim Auctions, Manheim Direct, Manheim De-fleet and Manheim Aftersales Solutions. V:0CF72C13B2AC -------------- next part -------------- An HTML attachment was scrubbed... URL: From rakesh.rajasekharan at gmail.com Thu Feb 18 13:11:23 2016 From: rakesh.rajasekharan at gmail.com (Rakesh Rajasekharan) Date: Thu, 18 Feb 2016 18:41:23 +0530 Subject: [Freeipa-users] freeipa permission denied for user Message-ID: I set up freeipa on our environment and its works perfectly for most of the hosts.. but on few I am getting a permission denied. [root at ipa-client-1c :~] ssh tempuser at localhost tempuser at localhost's password: Permission denied, please try again. tempuser at localhost's password: I checked the hbac, but that seems to be fine root at ipa-master-test-1b ] ipa hbactest --user=tempuser --host=x.x.x.x --service=sshd -------------------- Access granted: True -------------------- Matched rules: allow_all Another thing I noticed is the nsswitch.conf had the below entries after the freeipa installation passwd: files sss ldap shadow: files sss ldap group: files sss ldap hosts: files dns bootparams: nisplus [NOTFOUND=return] files ethers: files netmasks: files networks: files protocols: files rpc: files services: files sss netgroup: files sss ldap publickey: nisplus automount: files ldap aliases: files nisplus sudoers: files sss The ldap shouldn't be there above I guess.. and from the logs, i have the below errors ==> /var/log/secure <== Feb 18 03:29:33 ip-x-x-x-x sshd[24851]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=x.x.x.x user=tempuser Feb 18 03:29:33 ip-x-x-x-x sshd[24851]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=x.x.x.x user=tempuser Feb 18 03:29:33 ip-x-x-x-x sshd[24851]: pam_sss(sshd:auth): received for user tempuser: 4 (System error) Feb 18 03:29:35 ip-x-x-x-x sshd[24851]: Failed password for tempuser from x.x.x.x port 36687 ssh2 Feb 18 03:29:39 ip-x-x-x-x sshd[24853]: Connection closed by x.x.x.x Feb 18 03:34:17 ip-x-x-x-x sshd[25108]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=127.0.0.1 user=tempuser Feb 18 03:34:17 ip-x-x-x-x sshd[25108]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=127.0.0.1 user=tempuser Feb 18 03:34:17 ip-x-x-x-x sshd[25108]: pam_sss(sshd:auth): received for user tempuser: 4 (System error) Feb 18 03:34:19 ip-x-x-x-x sshd[25108]: Failed password for tempuser from 127.0.0.1 port 59870 ssh2 ==> /var/log/messages <== Feb 18 03:37:45 ip-x-x-x-x sssd[be[xyz.com]]: Shutting down Feb 18 03:37:45 ip-x-x-x-x sssd: Starting up Feb 18 03:37:46 ip-x-x-x-x sssd[be[xyz.com]]: Starting up Feb 18 03:37:46 ip-x-x-x-x sssd[nss]: Starting up Feb 18 03:37:46 ip-x-x-x-x sssd[sudo]: Starting up Feb 18 03:37:46 ip-x-x-x-x sssd[pam]: Starting up Feb 18 03:37:46 ip-x-x-x-x sssd[pac]: Starting up Feb 18 03:37:46 ip-x-x-x-x sssd[ssh]: Starting up Feb 18 03:37:46 ip-x-x-x-x sssd[be[xyz.com]]: dereference processing failed : Input/output error Feb 18 03:37:46 ip-x-x-x-x sssd[be[xyz.com]]: dereference processing failed : Input/output error Feb 18 03:38:41 ip-x-x-x-x [sssd[krb5_child[25324]]]: Permission denied Feb 18 03:38:41 ip-x-x-x-x [sssd[krb5_child[25324]]]: Permission denied -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Thu Feb 18 13:22:39 2016 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 18 Feb 2016 14:22:39 +0100 Subject: [Freeipa-users] freeipa permission denied for user In-Reply-To: References: Message-ID: <56C5C59F.5030005@redhat.com> On 02/18/2016 02:11 PM, Rakesh Rajasekharan wrote: > I set up freeipa on our environment and its works perfectly for most of the > hosts.. but on few I am getting a permission denied. > > [root at ipa-client-1c :~] ssh tempuser at localhost > tempuser at localhost's password: > Permission denied, please try again. > tempuser at localhost's password: > > > > > I checked the hbac, but that seems to be fine > > root at ipa-master-test-1b ] ipa hbactest --user=tempuser --host=x.x.x.x > --service=sshd > -------------------- > Access granted: True > -------------------- > Matched rules: allow_all > > > Another thing I noticed is the nsswitch.conf had the below entries after > the freeipa installation > passwd: files sss ldap > shadow: files sss ldap > group: files sss ldap > > hosts: files dns > > > bootparams: nisplus [NOTFOUND=return] files > > ethers: files > netmasks: files > networks: files > protocols: files > rpc: files > services: files sss > > netgroup: files sss ldap > > publickey: nisplus > > automount: files ldap > aliases: files nisplus > > sudoers: files sss > > > The ldap shouldn't be there above I guess.. > > and from the logs, i have the below errors > > ==> /var/log/secure <== > Feb 18 03:29:33 ip-x-x-x-x sshd[24851]: pam_unix(sshd:auth): authentication > failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=x.x.x.x user=tempuser > Feb 18 03:29:33 ip-x-x-x-x sshd[24851]: pam_sss(sshd:auth): authentication > failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=x.x.x.x user=tempuser > Feb 18 03:29:33 ip-x-x-x-x sshd[24851]: pam_sss(sshd:auth): received for > user tempuser: 4 (System error) > Feb 18 03:29:35 ip-x-x-x-x sshd[24851]: Failed password for tempuser from > x.x.x.x port 36687 ssh2 > Feb 18 03:29:39 ip-x-x-x-x sshd[24853]: Connection closed by x.x.x.x > Feb 18 03:34:17 ip-x-x-x-x sshd[25108]: pam_unix(sshd:auth): authentication > failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=127.0.0.1 user=tempuser > Feb 18 03:34:17 ip-x-x-x-x sshd[25108]: pam_sss(sshd:auth): authentication > failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=127.0.0.1 user=tempuser > Feb 18 03:34:17 ip-x-x-x-x sshd[25108]: pam_sss(sshd:auth): received for > user tempuser: 4 (System error) > Feb 18 03:34:19 ip-x-x-x-x sshd[25108]: Failed password for tempuser from > 127.0.0.1 port 59870 ssh2 > > > ==> /var/log/messages <== > Feb 18 03:37:45 ip-x-x-x-x sssd[be[xyz.com]]: Shutting down > Feb 18 03:37:45 ip-x-x-x-x sssd: Starting up > Feb 18 03:37:46 ip-x-x-x-x sssd[be[xyz.com]]: Starting up > Feb 18 03:37:46 ip-x-x-x-x sssd[nss]: Starting up > Feb 18 03:37:46 ip-x-x-x-x sssd[sudo]: Starting up > Feb 18 03:37:46 ip-x-x-x-x sssd[pam]: Starting up > Feb 18 03:37:46 ip-x-x-x-x sssd[pac]: Starting up > Feb 18 03:37:46 ip-x-x-x-x sssd[ssh]: Starting up > Feb 18 03:37:46 ip-x-x-x-x sssd[be[xyz.com]]: dereference processing failed > : Input/output error > Feb 18 03:37:46 ip-x-x-x-x sssd[be[xyz.com]]: dereference processing failed > : Input/output error > Feb 18 03:38:41 ip-x-x-x-x [sssd[krb5_child[25324]]]: Permission denied > Feb 18 03:38:41 ip-x-x-x-x [sssd[krb5_child[25324]]]: Permission denied Could it be caused by /etc/krb5.conf permissions as here: https://lists.fedorahosted.org/pipermail/sssd-users/2014-August/002103.html ? Some advise is also here: http://serverfault.com/questions/697113/linux-ad-integration-unable-to-login-when-using-windows-server-2012-dc Martin From rcritten at redhat.com Thu Feb 18 15:08:51 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 18 Feb 2016 10:08:51 -0500 Subject: [Freeipa-users] Split backup actions in stop - backup - start commands In-Reply-To: <56C591F6.9050509@redhat.com> References: <56C41A8E.7040705@redhat.com> <56C591F6.9050509@redhat.com> Message-ID: <56C5DE83.1000309@redhat.com> David Kupka wrote: > On 17/02/16 10:47, Matt . wrote: >> Hi David, >> >> I have tested your way out and it seems to be OK. >> >> The reason why I need this was is so I can perform a stop and >> ipa-backup before I start my backup to my backupserver. (pre-command). >> >> If I use ipa-backup directly it errors between the stop of ipa and the >> actual ipa backup. I need to check that out further. >> >> An ipactl start is not needed it seems as the ipa-backup command seems >> to start ipa at any time again. >> >> Do you understand/agree here ? > > Hello Matt, > > unfortunately I don't understand. The backup procedure AFAIK should work > like this: > > # ipa-backup && rsync -r /var/lib/ipa/backup/ backup.example.test:/ipa/ > > You ca run it manually or place it into the crontab or use it in your > orchestration system. > It will backup the ipa server with necessary stop and start and then > copy the new backup to the backup server. > > Still I don't see the need for stopping the server manually. > > ipa-backup calls "ipactl start" [0]. If you remove the else branch it > will not start the server. > > [0 > ]https://git.fedorahosted.org/cgit/freeipa.git/tree/ipaserver/install/ipa_backup.py#n316 I've also been wondering about the request to remove the stop/start. The stop should be idempotent. Is an error being thrown? rob From sbose at redhat.com Thu Feb 18 15:28:07 2016 From: sbose at redhat.com (Sumit Bose) Date: Thu, 18 Feb 2016 16:28:07 +0100 Subject: [Freeipa-users] ID Views without AD In-Reply-To: <20160218102658.GF30390@p.redhat.com> References: <20160210081945.GR12787@redhat.com> <20160211082137.GA28898@redhat.com> <20160218102658.GF30390@p.redhat.com> Message-ID: <20160218152807.GI30390@p.redhat.com> On Thu, Feb 18, 2016 at 11:26:58AM +0100, Sumit Bose wrote: > On Tue, Feb 16, 2016 at 04:23:10PM +0000, Mike Kelly wrote: > > >> Thanks. Here's what is hopefully the relevant lines: > > > > > > I'm sorry, but these logs only capture how the original entry was > > searched, not the overrides. Can you capture the full logs since the sssd > > startup? Also please make sure the cache was invalidated prior to the > > request with sss_cache -E. > > > > Attached are the full logs since a restart of sssd. > > Thank you, the logs helped. The IPA client reads the idview at startup > time either from the cache or the IPA server. Since there is of course > no idview name saved in the cache of your client the name must be looked > up from the server. The lookup of the idview name is part of the request > which reads other data about the IPA domain and possible trusted > domains. Unfortunately the current code expects that e.g. the domain SID > of the IPA domain is defined before it proceeds to read the idview. > > This is of course a bug and I will try to fix it. If you would like to > try a work-around you can call ipa-adtrust-install on one of your IPA > servers. This will create the needed data on the server. It is > sufficient to call it on one server because the data will be replicated > to the other servers and since you currently not plan to add a trust to > a AD domain, you do not have to prepare additional services on other > server (with FreeIPA-4.2 this wouldn't even be necessary if you plan to > add a trust). > > If you can wait a day or two I'd be happy to prepare a SSSD test build > with a fix. It looks it was easier than I expected. You can find test packages for RHEL/CentOS-7 at http://koji.fedoraproject.org/koji/taskinfo?taskID=13035051 (Please tell me if you need packages for a different platform) Before you upgrade the package on a client please run # ldbadd -H /var/lib/sss/db/cache_your.domain.name.ldb << EOF dn: cn=views,cn=sysdb viewName: default EOF Otherwise SSSD will not recognise the name change and still show the original values. As an alternative you can remove the cache completely before starting the new version or unapply the idview and apply it again on the server while you restart the new sssd version on the client after each change on the server. I'll try to think of a way to make this more easy without breaking the existing detection of a change in the idview name. HTH bye, Sumit > > bye, > Sumit > > > > > I ran these commands: > > > > systemctl stop sssd > > > > echo '----MARK----' >> /var/log/sssd/sssd_home.pioto.org.log # so I could > > mark were the restart happened > > > > sss_cache -E > > > > systemctl start sssd > > > > sss_cache -E > > > > id pioto > > > > ---- > > > > I still don't see the override being applied. Possibly because of this line? > > > > (Tue Feb 16 11:12:27 2016) [sssd[be[home.pioto.org]]] > > [ipa_get_ad_override_send] > > (0x4000): View not defined, nothing to do. > > > > So, I get the feeling that, for whatever reason, sssd isn't correctly > > deciding that my id view applies to this host, or just isn't looking it up? > > > > Is there possibly some sort of extra configuration that I've missed to tell > > SSSD to apply these views? From what I can tell, it should just pick these > > up out of the box, from the configuration built by ipa-client-install...? > > > > -- > > Manage your subscription for the Freeipa-users mailing list: > > https://www.redhat.com/mailman/listinfo/freeipa-users > > Go to http://freeipa.org for more info on the project > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project From bahanw042014 at gmail.com Thu Feb 18 15:46:58 2016 From: bahanw042014 at gmail.com (bahan w) Date: Thu, 18 Feb 2016 16:46:58 +0100 Subject: [Freeipa-users] About ipa passwd and kpasswd Message-ID: Hello everyone. I send you this mail because I have sometimes a problem when using ipa passwd to generate a One Time Password and then using kpasswd to set a strong random password using a password policy. When I perform the ipa passwd command and just after the kpasswd command, I got an error message. Here is the command (I have an admin TGT) : echo "onetimepwd\nonetimepwd\n" | ipa passwd ; echo "onetimepwd\n\n\n" | kpasswd And here is the result : ### ---------------------------------------------- Changed password for "@" ---------------------------------------------- Password for @: kpasswd: Preauthentication failed getting initial ticket ### When I perform a sleep 5, then the sucession of these commands complete successfully. I tried to sleep 1s or 2s, but sometimes I got the error message, and sometimes not. So I extended the sleep duration to 5s. I was wondering if it was normal behaviour from ipa-server/client 3.0.0-47 ? If yes, do you know what the minimum duration in seconds that I have to wait after setting a one time password before setting a more definitive password (a password respecting the password policy) ? Best regards. Bahan -------------- next part -------------- An HTML attachment was scrubbed... URL: From pioto at pioto.org Thu Feb 18 17:21:17 2016 From: pioto at pioto.org (Mike Kelly) Date: Thu, 18 Feb 2016 17:21:17 +0000 Subject: [Freeipa-users] ID Views without AD In-Reply-To: <20160218152807.GI30390@p.redhat.com> References: <20160210081945.GR12787@redhat.com> <20160211082137.GA28898@redhat.com> <20160218102658.GF30390@p.redhat.com> <20160218152807.GI30390@p.redhat.com> Message-ID: Thanks for the quick reply. FWIW, I'm on CentOS 7, but I haven't yet tried to apply your test sssd packages. I don't seem to have the "ldbadd" command on my client, either. Also, I tried running `sudo ipa-adtrust-install --add-sids -A pioto`, and I see more in the logs now. But, I don't seem to be seeing my UID changing like I'd expect, and I seem to no longer be able to run sudo on my client... If I unapply the view from my client's host, though, sudo again works as expected. So, it's picking up... something... just not quite everything yet. On Thu, Feb 18, 2016 at 10:28 AM Sumit Bose wrote: > On Thu, Feb 18, 2016 at 11:26:58AM +0100, Sumit Bose wrote: > > On Tue, Feb 16, 2016 at 04:23:10PM +0000, Mike Kelly wrote: > > > >> Thanks. Here's what is hopefully the relevant lines: > > > > > > > > I'm sorry, but these logs only capture how the original entry was > > > searched, not the overrides. Can you capture the full logs since the > sssd > > > startup? Also please make sure the cache was invalidated prior to the > > > request with sss_cache -E. > > > > > > Attached are the full logs since a restart of sssd. > > > > Thank you, the logs helped. The IPA client reads the idview at startup > > time either from the cache or the IPA server. Since there is of course > > no idview name saved in the cache of your client the name must be looked > > up from the server. The lookup of the idview name is part of the request > > which reads other data about the IPA domain and possible trusted > > domains. Unfortunately the current code expects that e.g. the domain SID > > of the IPA domain is defined before it proceeds to read the idview. > > > > This is of course a bug and I will try to fix it. If you would like to > > try a work-around you can call ipa-adtrust-install on one of your IPA > > servers. This will create the needed data on the server. It is > > sufficient to call it on one server because the data will be replicated > > to the other servers and since you currently not plan to add a trust to > > a AD domain, you do not have to prepare additional services on other > > server (with FreeIPA-4.2 this wouldn't even be necessary if you plan to > > add a trust). > > > > If you can wait a day or two I'd be happy to prepare a SSSD test build > > with a fix. > > It looks it was easier than I expected. You can find test packages for > RHEL/CentOS-7 at > > http://koji.fedoraproject.org/koji/taskinfo?taskID=13035051 > > (Please tell me if you need packages for a different platform) > > Before you upgrade the package on a client please run > > # ldbadd -H /var/lib/sss/db/cache_your.domain.name.ldb << EOF > dn: cn=views,cn=sysdb > viewName: default > EOF > > Otherwise SSSD will not recognise the name change and still show the > original values. As an alternative you can remove the cache completely > before starting the new version or unapply the idview and apply it again > on the server while you restart the new sssd version on the client after > each change on the server. I'll try to think of a way to make this more > easy without breaking the existing detection of a change in the idview > name. > > HTH > > bye, > Sumit > > > > > bye, > > Sumit > > > > > > > > I ran these commands: > > > > > > systemctl stop sssd > > > > > > echo '----MARK----' >> /var/log/sssd/sssd_home.pioto.org.log # so I > could > > > mark were the restart happened > > > > > > sss_cache -E > > > > > > systemctl start sssd > > > > > > sss_cache -E > > > > > > id pioto > > > > > > ---- > > > > > > I still don't see the override being applied. Possibly because of this > line? > > > > > > (Tue Feb 16 11:12:27 2016) [sssd[be[home.pioto.org]]] > > > [ipa_get_ad_override_send] > > > (0x4000): View not defined, nothing to do. > > > > > > So, I get the feeling that, for whatever reason, sssd isn't correctly > > > deciding that my id view applies to this host, or just isn't looking > it up? > > > > > > Is there possibly some sort of extra configuration that I've missed to > tell > > > SSSD to apply these views? From what I can tell, it should just pick > these > > > up out of the box, from the configuration built by > ipa-client-install...? > > > > > > > -- > > > Manage your subscription for the Freeipa-users mailing list: > > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > Go to http://freeipa.org for more info on the project > > > > -- > > Manage your subscription for the Freeipa-users mailing list: > > https://www.redhat.com/mailman/listinfo/freeipa-users > > Go to http://freeipa.org for more info on the project > -- Mike Kelly -------------- next part -------------- An HTML attachment was scrubbed... URL: From rakesh.rajasekharan at gmail.com Thu Feb 18 17:23:31 2016 From: rakesh.rajasekharan at gmail.com (Rakesh Rajasekharan) Date: Thu, 18 Feb 2016 22:53:31 +0530 Subject: [Freeipa-users] freeipa permission denied for user In-Reply-To: <56C5C59F.5030005@redhat.com> References: <56C5C59F.5030005@redhat.com> Message-ID: The permission for /etc/krb5.conf was already set to 644. So, that aspect looks fine.. I think it might be something to do with the pam settings. here is my sssd.conf [root at ipa-client :/etc/sssd] cat sssd.con [domain/xyz.com] krb5_auth_timeout = 30 cache_credentials = True krb5_store_password_if_offline = True ipa_domain = xyz.com id_provider = ipa auth_provider = ipa access_provider = ipa ldap_tls_cacert = /etc/ipa/ca.crt ipa_hostname = x.x.x.x chpass_provider = ipa ipa_server = _srv_, ipa-master.xyz.com dns_discovery_domain = xyz.com [domain/default] ldap_id_use_start_tls = True cache_credentials = True ldap_search_base = dc=ldap,dc=qa,dc=xyz,dc=com krb5_realm = xyz.com krb5_server = ipa-master.xyz.com:88 id_provider = ldap auth_provider = ldap chpass_provider = ldap ldap_uri = ldaps://ldap-int.xyz.com:636 ldap_tls_cacertdir = /etc/openldap/cacerts [sssd] services = nss, sudo, pam, ssh config_file_version = 2 domains = default, xyz.com [nss] homedir_substring = /home [pam] [sudo] [autofs] [ssh] [pac] [ifp] Thanks, Rakesh On Thu, Feb 18, 2016 at 6:52 PM, Martin Kosek wrote: > On 02/18/2016 02:11 PM, Rakesh Rajasekharan wrote: > > I set up freeipa on our environment and its works perfectly for most of > the > > hosts.. but on few I am getting a permission denied. > > > > [root at ipa-client-1c :~] ssh tempuser at localhost > > tempuser at localhost's password: > > Permission denied, please try again. > > tempuser at localhost's password: > > > > > > > > > > I checked the hbac, but that seems to be fine > > > > root at ipa-master-test-1b ] ipa hbactest --user=tempuser --host=x.x.x.x > > --service=sshd > > -------------------- > > Access granted: True > > -------------------- > > Matched rules: allow_all > > > > > > Another thing I noticed is the nsswitch.conf had the below entries after > > the freeipa installation > > passwd: files sss ldap > > shadow: files sss ldap > > group: files sss ldap > > > > hosts: files dns > > > > > > bootparams: nisplus [NOTFOUND=return] files > > > > ethers: files > > netmasks: files > > networks: files > > protocols: files > > rpc: files > > services: files sss > > > > netgroup: files sss ldap > > > > publickey: nisplus > > > > automount: files ldap > > aliases: files nisplus > > > > sudoers: files sss > > > > > > The ldap shouldn't be there above I guess.. > > > > and from the logs, i have the below errors > > > > ==> /var/log/secure <== > > Feb 18 03:29:33 ip-x-x-x-x sshd[24851]: pam_unix(sshd:auth): > authentication > > failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=x.x.x.x > user=tempuser > > Feb 18 03:29:33 ip-x-x-x-x sshd[24851]: pam_sss(sshd:auth): > authentication > > failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=x.x.x.x user=tempuser > > Feb 18 03:29:33 ip-x-x-x-x sshd[24851]: pam_sss(sshd:auth): received for > > user tempuser: 4 (System error) > > Feb 18 03:29:35 ip-x-x-x-x sshd[24851]: Failed password for tempuser from > > x.x.x.x port 36687 ssh2 > > Feb 18 03:29:39 ip-x-x-x-x sshd[24853]: Connection closed by x.x.x.x > > Feb 18 03:34:17 ip-x-x-x-x sshd[25108]: pam_unix(sshd:auth): > authentication > > failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=127.0.0.1 > user=tempuser > > Feb 18 03:34:17 ip-x-x-x-x sshd[25108]: pam_sss(sshd:auth): > authentication > > failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=127.0.0.1 > user=tempuser > > Feb 18 03:34:17 ip-x-x-x-x sshd[25108]: pam_sss(sshd:auth): received for > > user tempuser: 4 (System error) > > Feb 18 03:34:19 ip-x-x-x-x sshd[25108]: Failed password for tempuser from > > 127.0.0.1 port 59870 ssh2 > > > > > > ==> /var/log/messages <== > > Feb 18 03:37:45 ip-x-x-x-x sssd[be[xyz.com]]: Shutting down > > Feb 18 03:37:45 ip-x-x-x-x sssd: Starting up > > Feb 18 03:37:46 ip-x-x-x-x sssd[be[xyz.com]]: Starting up > > Feb 18 03:37:46 ip-x-x-x-x sssd[nss]: Starting up > > Feb 18 03:37:46 ip-x-x-x-x sssd[sudo]: Starting up > > Feb 18 03:37:46 ip-x-x-x-x sssd[pam]: Starting up > > Feb 18 03:37:46 ip-x-x-x-x sssd[pac]: Starting up > > Feb 18 03:37:46 ip-x-x-x-x sssd[ssh]: Starting up > > Feb 18 03:37:46 ip-x-x-x-x sssd[be[xyz.com]]: dereference processing > failed > > : Input/output error > > Feb 18 03:37:46 ip-x-x-x-x sssd[be[xyz.com]]: dereference processing > failed > > : Input/output error > > Feb 18 03:38:41 ip-x-x-x-x [sssd[krb5_child[25324]]]: Permission denied > > Feb 18 03:38:41 ip-x-x-x-x [sssd[krb5_child[25324]]]: Permission denied > > Could it be caused by /etc/krb5.conf permissions as here: > https://lists.fedorahosted.org/pipermail/sssd-users/2014-August/002103.html > ? > > Some advise is also here: > > http://serverfault.com/questions/697113/linux-ad-integration-unable-to-login-when-using-windows-server-2012-dc > > Martin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prashant at apigee.com Fri Feb 19 05:57:16 2016 From: prashant at apigee.com (Prashant Bapat) Date: Fri, 19 Feb 2016 11:27:16 +0530 Subject: [Freeipa-users] Wildcards in sudo external hostnames Message-ID: Hi, I'm using FreeIPA 4.1.4 with nss-pam-ldapd and the compat schema. I'm thinking of moving sudo rules to IPA and with *ou=sudoers* and sudo-ldap this works. In our setup we have lot of rules with wildcard matching for sudo hostnames. For ex webserver*, dbserver* etc. In the IPA UI, when I try to add the hostname with wildcard (*) char I get an error from UI. * is not allowed char. Looks like the UI is trying to validate the hostname using validate_dns_label in ipa/util.py and obviously * is not one of the allowed chars. Taking a look at the documentation of sudo, wildcards are pretty widely used. More info here https://www.sudo.ws/man/1.8.15/sudoers.man.html#x57696c646361726473 Other than editing the LDAP schema outside of IPA (this will work) what are the other options to solve this ? Thanks. --Prashant -------------- next part -------------- An HTML attachment was scrubbed... URL: From lslebodn at redhat.com Fri Feb 19 07:38:14 2016 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Fri, 19 Feb 2016 08:38:14 +0100 Subject: [Freeipa-users] freeipa permission denied for user In-Reply-To: References: Message-ID: <20160219073813.GA2780@mail.corp.redhat.com> On (18/02/16 18:41), Rakesh Rajasekharan wrote: >I set up freeipa on our environment and its works perfectly for most of the >hosts.. but on few I am getting a permission denied. > >[root at ipa-client-1c :~] ssh tempuser at localhost >tempuser at localhost's password: >Permission denied, please try again. >tempuser at localhost's password: > > > > >I checked the hbac, but that seems to be fine > >root at ipa-master-test-1b ] ipa hbactest --user=tempuser --host=x.x.x.x >--service=sshd >-------------------- >Access granted: True >-------------------- > Matched rules: allow_all > > >Another thing I noticed is the nsswitch.conf had the below entries after >the freeipa installation >passwd: files sss ldap >shadow: files sss ldap >group: files sss ldap > >hosts: files dns > > >bootparams: nisplus [NOTFOUND=return] files > >ethers: files >netmasks: files >networks: files >protocols: files >rpc: files >services: files sss > >netgroup: files sss ldap > >publickey: nisplus > >automount: files ldap >aliases: files nisplus > >sudoers: files sss > > >The ldap shouldn't be there above I guess.. > >and from the logs, i have the below errors > >==> /var/log/secure <== >Feb 18 03:29:33 ip-x-x-x-x sshd[24851]: pam_unix(sshd:auth): authentication >failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=x.x.x.x user=tempuser >Feb 18 03:29:33 ip-x-x-x-x sshd[24851]: pam_sss(sshd:auth): authentication >failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=x.x.x.x user=tempuser >Feb 18 03:29:33 ip-x-x-x-x sshd[24851]: pam_sss(sshd:auth): received for >user tempuser: 4 (System error) ^^^^^^^^^^^^^^^^ This usually mean critical error in sssd. Please provide log files (sssd_$domain.log and krb5_child.log) with high debug level. https://fedorahosted.org/sssd/wiki/Troubleshooting Whis version of sssd do you have? LS From Chris.Addie at datacom.com.au Fri Feb 19 05:33:00 2016 From: Chris.Addie at datacom.com.au (Chris Addie) Date: Fri, 19 Feb 2016 05:33:00 +0000 Subject: [Freeipa-users] FreeIPA -> FreeIPA trusts Message-ID: I have two separate networks each with their own FreeIPA server(s) and I would like for users from network A to be able to be able to access services in network B, but not the other way around. The documentation for ipa trust-add seems to imply this is not possibly however as ?Only trusts to Active Directory domains are supported right now.? It seems really odd that FreeIPA supports trusting a Windows AD domain but not another FreeIPA domain. Is this really the case? If so are IPA -> IPA trusts a feature that is planned for the future? Is there some other way I could achieve this? Thanks, Chris Addie Se?or Security Engineer Datacom Technical Security Services Pty Ltd | A.B.N. 84 151 241 253 Mb: +61 421 138 786 | eM: chris.addie at datacom.com.au Discreet | Niche | Tailored ############################################################################ ######### Confidentiality and Privilege Notice This document is intended solely for the named addressee. The information contained in the pages is confidential and contains legally privileged information. If you are not the addressee indicated in this message or responsible for delivery of the message to such person, you may not copy or deliver this message to anyone, and you should destroy this message and kindly notify the sender by reply email. Confidentiality and legal privilege are not waived or lost by reason of mistaken delivery to you. ############################################################################ ######### -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6266 bytes Desc: not available URL: From mkosek at redhat.com Fri Feb 19 08:57:18 2016 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 19 Feb 2016 09:57:18 +0100 Subject: [Freeipa-users] FreeIPA -> FreeIPA trusts In-Reply-To: References: Message-ID: <56C6D8EE.4040700@redhat.com> On 02/19/2016 06:33 AM, Chris Addie wrote: > I have two separate networks each with their own FreeIPA server(s) and I > would like for users from network A to be able to be able to access services > in network B, but not the other way around. The documentation for ipa > trust-add seems to imply this is not possibly however as ?Only trusts to > Active Directory domains are supported right now.? It seems really odd that > FreeIPA supports trusting a Windows AD domain but not another FreeIPA > domain. Is this really the case? Yes. > If so are IPA -> IPA trusts a feature that > is planned for the future? Yes :-) > Is there some other way I could achieve this? You can do hacks to achieve authentication part, but you would still miss authorization or other parts. Please see details to my brief answer in our FAQ section: http://www.freeipa.org/page/Frequently_Asked_Questions#When_will_we_implement_FreeIPA_to_FreeIPA_trusts.3F HTH, Martin From jhrozek at redhat.com Fri Feb 19 08:58:44 2016 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 19 Feb 2016 09:58:44 +0100 Subject: [Freeipa-users] Wildcards in sudo external hostnames In-Reply-To: References: Message-ID: <20160219085844.GI3123@hendrix> On Fri, Feb 19, 2016 at 11:27:16AM +0530, Prashant Bapat wrote: > Hi, > > I'm using FreeIPA 4.1.4 with nss-pam-ldapd and the compat schema. Why not sssd? > > I'm thinking of moving sudo rules to IPA and with *ou=sudoers* and > sudo-ldap this works. > > In our setup we have lot of rules with wildcard matching for sudo > hostnames. For ex webserver*, dbserver* etc. > > In the IPA UI, when I try to add the hostname with wildcard (*) char I get > an error from UI. * is not allowed char. > > Looks like the UI is trying to validate the hostname using > validate_dns_label in ipa/util.py and obviously * is not one of the allowed > chars. > > Taking a look at the documentation of sudo, wildcards are pretty widely > used. More info here > https://www.sudo.ws/man/1.8.15/sudoers.man.html#x57696c646361726473 > > Other than editing the LDAP schema outside of IPA (this will work) what are > the other options to solve this ? I guess hostgroups/netgroups are even better (more explicit) than wildcards. From yamakasi.014 at gmail.com Fri Feb 19 09:20:36 2016 From: yamakasi.014 at gmail.com (Matt .) Date: Fri, 19 Feb 2016 10:20:36 +0100 Subject: [Freeipa-users] Split backup actions in stop - backup - start commands In-Reply-To: <56C5DE83.1000309@redhat.com> References: <56C41A8E.7040705@redhat.com> <56C591F6.9050509@redhat.com> <56C5DE83.1000309@redhat.com> Message-ID: Hi guys, As I'm using burp for backup I get the feeling it fails obt eh ipa-backup proces itself when runned as a pre_script. I think it waits for some exitcode or already gets it before the real backup of IPA has been finished. I'm checking this out as burp also outputs messages as errors because it just does it that way. 2016-02-18 16:08 GMT+01:00 Rob Crittenden : > David Kupka wrote: >> On 17/02/16 10:47, Matt . wrote: >>> Hi David, >>> >>> I have tested your way out and it seems to be OK. >>> >>> The reason why I need this was is so I can perform a stop and >>> ipa-backup before I start my backup to my backupserver. (pre-command). >>> >>> If I use ipa-backup directly it errors between the stop of ipa and the >>> actual ipa backup. I need to check that out further. >>> >>> An ipactl start is not needed it seems as the ipa-backup command seems >>> to start ipa at any time again. >>> >>> Do you understand/agree here ? >> >> Hello Matt, >> >> unfortunately I don't understand. The backup procedure AFAIK should work >> like this: >> >> # ipa-backup && rsync -r /var/lib/ipa/backup/ backup.example.test:/ipa/ >> >> You ca run it manually or place it into the crontab or use it in your >> orchestration system. >> It will backup the ipa server with necessary stop and start and then >> copy the new backup to the backup server. >> >> Still I don't see the need for stopping the server manually. >> >> ipa-backup calls "ipactl start" [0]. If you remove the else branch it >> will not start the server. >> >> [0 >> ]https://git.fedorahosted.org/cgit/freeipa.git/tree/ipaserver/install/ipa_backup.py#n316 > > I've also been wondering about the request to remove the stop/start. The > stop should be idempotent. Is an error being thrown? > > rob > From rakesh.rajasekharan at gmail.com Fri Feb 19 09:24:43 2016 From: rakesh.rajasekharan at gmail.com (Rakesh Rajasekharan) Date: Fri, 19 Feb 2016 14:54:43 +0530 Subject: [Freeipa-users] freeipa permission denied for user In-Reply-To: <20160219073813.GA2780@mail.corp.redhat.com> References: <20160219073813.GA2780@mail.corp.redhat.com> Message-ID: > ^^^^^^^^^^^^^^^^ > This usually mean critical error in sssd. > Please provide log files (sssd_$domain.log and krb5_child.log) I found this in my sssd-$domain.log [krb5_auth_prepare_ccache_name] (0x1000): No ccache file for user [tempuser] found so searching around I found that the permissions for the /tmp directory should be 777.. setting it to 777 fixed the issue for me.. Thanks, Rakesh On Fri, Feb 19, 2016 at 1:08 PM, Lukas Slebodnik wrote: > On (18/02/16 18:41), Rakesh Rajasekharan wrote: > >I set up freeipa on our environment and its works perfectly for most of > the > >hosts.. but on few I am getting a permission denied. > > > >[root at ipa-client-1c :~] ssh tempuser at localhost > >tempuser at localhost's password: > >Permission denied, please try again. > >tempuser at localhost's password: > > > > > > > > > >I checked the hbac, but that seems to be fine > > > >root at ipa-master-test-1b ] ipa hbactest --user=tempuser --host=x.x.x.x > >--service=sshd > >-------------------- > >Access granted: True > >-------------------- > > Matched rules: allow_all > > > > > >Another thing I noticed is the nsswitch.conf had the below entries after > >the freeipa installation > >passwd: files sss ldap > >shadow: files sss ldap > >group: files sss ldap > > > >hosts: files dns > > > > > >bootparams: nisplus [NOTFOUND=return] files > > > >ethers: files > >netmasks: files > >networks: files > >protocols: files > >rpc: files > >services: files sss > > > >netgroup: files sss ldap > > > >publickey: nisplus > > > >automount: files ldap > >aliases: files nisplus > > > >sudoers: files sss > > > > > >The ldap shouldn't be there above I guess.. > > > >and from the logs, i have the below errors > > > >==> /var/log/secure <== > >Feb 18 03:29:33 ip-x-x-x-x sshd[24851]: pam_unix(sshd:auth): > authentication > >failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=x.x.x.x user=tempuser > >Feb 18 03:29:33 ip-x-x-x-x sshd[24851]: pam_sss(sshd:auth): authentication > >failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=x.x.x.x user=tempuser > >Feb 18 03:29:33 ip-x-x-x-x sshd[24851]: pam_sss(sshd:auth): received for > >user tempuser: 4 (System error) > ^^^^^^^^^^^^^^^^ > This usually mean critical error in sssd. > Please provide log files (sssd_$domain.log and krb5_child.log) > with high debug level. > https://fedorahosted.org/sssd/wiki/Troubleshooting > > Whis version of sssd do you have? > > LS > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lslebodn at redhat.com Fri Feb 19 09:29:07 2016 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Fri, 19 Feb 2016 10:29:07 +0100 Subject: [Freeipa-users] freeipa permission denied for user In-Reply-To: References: <20160219073813.GA2780@mail.corp.redhat.com> Message-ID: <20160219092906.GB2780@mail.corp.redhat.com> On (19/02/16 14:54), Rakesh Rajasekharan wrote: >> ^^^^^^^^^^^^^^^^ >> This usually mean critical error in sssd. >> Please provide log files (sssd_$domain.log and krb5_child.log) > >I found this in my sssd-$domain.log > > [krb5_auth_prepare_ccache_name] (0x1000): No ccache file for user >[tempuser] found > >so searching around I found that the permissions for the /tmp directory >should be 777.. > >setting it to 777 fixed the issue for me.. > Actually, it should be 1777 sh$ ls -ld /tmp/ drwxrwxrwt. 11 root root 260 Feb 19 10:27 /tmp/ ^ This is important. LS From pvoborni at redhat.com Fri Feb 19 09:40:13 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 19 Feb 2016 10:40:13 +0100 Subject: [Freeipa-users] About ipa passwd and kpasswd In-Reply-To: References: Message-ID: <56C6E2FD.2080508@redhat.com> On 02/18/2016 04:46 PM, bahan w wrote: > Hello everyone. > > I send you this mail because I have sometimes a problem when using ipa > passwd to generate a One Time Password and then using kpasswd to set a > strong random password using a password policy. > > When I perform the ipa passwd command and just after the kpasswd command, I > got an error message. > > Here is the command (I have an admin TGT) : > echo "onetimepwd\nonetimepwd\n" | ipa passwd ; echo > "onetimepwd\n\n\n" | kpasswd > > And here is the result : > ### > ---------------------------------------------- > Changed password for "@" > ---------------------------------------------- > Password for @: > kpasswd: Preauthentication failed getting initial ticket > ### > > When I perform a sleep 5, then the sucession of these commands complete > successfully. > I tried to sleep 1s or 2s, but sometimes I got the error message, and > sometimes not. > So I extended the sleep duration to 5s. > > I was wondering if it was normal behaviour from ipa-server/client 3.0.0-47 ? > > If yes, do you know what the minimum duration in seconds that I have to > wait after setting a one time password before setting a more definitive > password (a password respecting the password policy) ? > > Best regards. > > Bahan > > > Following works for me: ADMINPW=Secret123 TEMPPW=temppwd FINALPW=Secret1234 TESTUSER=fbar kdestroy -A echo -e "${ADMINPW}" | kinit admin klist echo -e "${TEMPPW}\n${TEMPPW}\n" | ipa passwd $TESTUSER echo -e "${TEMPPW}\n${FINALPW}\n${FINALPW}\n" | kpasswd $TESTUSER klist kdestroy -A echo -e "${FINALPW}" | kinit $TESTUSER klist kdestroy -A also works if kpasswd is changed to kinit. You can also try to use KRB5_TRACE=/dev/stdout to debug it: # KRB5_TRACE=/dev/stdout kpasswd user -- Petr Vobornik From rakesh.rajasekharan at gmail.com Fri Feb 19 09:47:43 2016 From: rakesh.rajasekharan at gmail.com (Rakesh Rajasekharan) Date: Fri, 19 Feb 2016 15:17:43 +0530 Subject: [Freeipa-users] freeipa permission denied for user In-Reply-To: <20160219092906.GB2780@mail.corp.redhat.com> References: <20160219073813.GA2780@mail.corp.redhat.com> <20160219092906.GB2780@mail.corp.redhat.com> Message-ID: >>Actually, it should be 1777 > sh$ ls -ld /tmp/ > drwxrwxrwt. 11 root root 260 Feb 19 10:27 /tmp/ ^ > This is important.> yes, I have now corrected them... Thanks... On Fri, Feb 19, 2016 at 2:59 PM, Lukas Slebodnik wrote: > On (19/02/16 14:54), Rakesh Rajasekharan wrote: > >> ^^^^^^^^^^^^^^^^ > >> This usually mean critical error in sssd. > >> Please provide log files (sssd_$domain.log and krb5_child.log) > > > >I found this in my sssd-$domain.log > > > > [krb5_auth_prepare_ccache_name] (0x1000): No ccache file for user > >[tempuser] found > > > >so searching around I found that the permissions for the /tmp directory > >should be 777.. > > > >setting it to 777 fixed the issue for me.. > > > Actually, it should be 1777 > > sh$ ls -ld /tmp/ > drwxrwxrwt. 11 root root 260 Feb 19 10:27 /tmp/ > ^ > This is important. > > LS > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pioto at pioto.org Fri Feb 19 12:12:42 2016 From: pioto at pioto.org (Mike Kelly) Date: Fri, 19 Feb 2016 12:12:42 +0000 Subject: [Freeipa-users] ID Views without AD In-Reply-To: References: <20160210081945.GR12787@redhat.com> <20160211082137.GA28898@redhat.com> <20160218102658.GF30390@p.redhat.com> <20160218152807.GI30390@p.redhat.com> Message-ID: Ahha! I seem to have gotten somewhere now! I just re-applied the view to my host, restarted sssd and cleared its cache, and it's now picking up my overridden UID and GID! (I had to manually add an entry for the overridden GID to /etc/group, because FreeIPA won't let me override the private user groups.) One odd caveat, but perhaps this is part of the design... if I do a `getent $IPA_UID` or `getent $OVERRIDE_UID`... both give the same output, my user with the overridden UID. I'd expect the first one to just give no result? ---- One side question, though... now that I have done half of the work for an AD trust... is it possible for me to make my FreeIPA server into an AD controller for the one Windows box in my house? Some searching I did before indicated no, in part because Samba required Heimdal instead of MIT Kerberos... is that still true? On Thu, Feb 18, 2016 at 12:21 PM Mike Kelly wrote: > Thanks for the quick reply. > > FWIW, I'm on CentOS 7, but I haven't yet tried to apply your test sssd > packages. > > I don't seem to have the "ldbadd" command on my client, either. > > Also, I tried running `sudo ipa-adtrust-install --add-sids -A pioto`, and > I see more in the logs now. > > But, I don't seem to be seeing my UID changing like I'd expect, and I seem > to no longer be able to run sudo on my client... > > If I unapply the view from my client's host, though, sudo again works as > expected. So, it's picking up... something... just not quite everything yet. > > > On Thu, Feb 18, 2016 at 10:28 AM Sumit Bose wrote: > >> On Thu, Feb 18, 2016 at 11:26:58AM +0100, Sumit Bose wrote: >> > On Tue, Feb 16, 2016 at 04:23:10PM +0000, Mike Kelly wrote: >> > > >> Thanks. Here's what is hopefully the relevant lines: >> > > > >> > > > I'm sorry, but these logs only capture how the original entry was >> > > searched, not the overrides. Can you capture the full logs since the >> sssd >> > > startup? Also please make sure the cache was invalidated prior to the >> > > request with sss_cache -E. >> > > >> > > Attached are the full logs since a restart of sssd. >> > >> > Thank you, the logs helped. The IPA client reads the idview at startup >> > time either from the cache or the IPA server. Since there is of course >> > no idview name saved in the cache of your client the name must be looked >> > up from the server. The lookup of the idview name is part of the request >> > which reads other data about the IPA domain and possible trusted >> > domains. Unfortunately the current code expects that e.g. the domain SID >> > of the IPA domain is defined before it proceeds to read the idview. >> > >> > This is of course a bug and I will try to fix it. If you would like to >> > try a work-around you can call ipa-adtrust-install on one of your IPA >> > servers. This will create the needed data on the server. It is >> > sufficient to call it on one server because the data will be replicated >> > to the other servers and since you currently not plan to add a trust to >> > a AD domain, you do not have to prepare additional services on other >> > server (with FreeIPA-4.2 this wouldn't even be necessary if you plan to >> > add a trust). >> > >> > If you can wait a day or two I'd be happy to prepare a SSSD test build >> > with a fix. >> >> It looks it was easier than I expected. You can find test packages for >> RHEL/CentOS-7 at >> >> http://koji.fedoraproject.org/koji/taskinfo?taskID=13035051 >> >> (Please tell me if you need packages for a different platform) >> >> Before you upgrade the package on a client please run >> >> # ldbadd -H /var/lib/sss/db/cache_your.domain.name.ldb << EOF >> dn: cn=views,cn=sysdb >> viewName: default >> EOF >> >> Otherwise SSSD will not recognise the name change and still show the >> original values. As an alternative you can remove the cache completely >> before starting the new version or unapply the idview and apply it again >> on the server while you restart the new sssd version on the client after >> each change on the server. I'll try to think of a way to make this more >> easy without breaking the existing detection of a change in the idview >> name. >> >> HTH >> >> bye, >> Sumit >> >> > >> > bye, >> > Sumit >> > >> > > >> > > I ran these commands: >> > > >> > > systemctl stop sssd >> > > >> > > echo '----MARK----' >> /var/log/sssd/sssd_home.pioto.org.log # so I >> could >> > > mark were the restart happened >> > > >> > > sss_cache -E >> > > >> > > systemctl start sssd >> > > >> > > sss_cache -E >> > > >> > > id pioto >> > > >> > > ---- >> > > >> > > I still don't see the override being applied. Possibly because of >> this line? >> > > >> > > (Tue Feb 16 11:12:27 2016) [sssd[be[home.pioto.org]]] >> > > [ipa_get_ad_override_send] >> > > (0x4000): View not defined, nothing to do. >> > > >> > > So, I get the feeling that, for whatever reason, sssd isn't correctly >> > > deciding that my id view applies to this host, or just isn't looking >> it up? >> > > >> > > Is there possibly some sort of extra configuration that I've missed >> to tell >> > > SSSD to apply these views? From what I can tell, it should just pick >> these >> > > up out of the box, from the configuration built by >> ipa-client-install...? >> > >> > >> > > -- >> > > Manage your subscription for the Freeipa-users mailing list: >> > > https://www.redhat.com/mailman/listinfo/freeipa-users >> > > Go to http://freeipa.org for more info on the project >> > >> > -- >> > Manage your subscription for the Freeipa-users mailing list: >> > https://www.redhat.com/mailman/listinfo/freeipa-users >> > Go to http://freeipa.org for more info on the project >> > -- > > Mike Kelly > -- Mike Kelly -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Fri Feb 19 12:20:52 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 19 Feb 2016 14:20:52 +0200 Subject: [Freeipa-users] ID Views without AD In-Reply-To: References: <20160210081945.GR12787@redhat.com> <20160211082137.GA28898@redhat.com> <20160218102658.GF30390@p.redhat.com> <20160218152807.GI30390@p.redhat.com> Message-ID: <20160219122052.GU4492@redhat.com> On Fri, 19 Feb 2016, Mike Kelly wrote: >Ahha! I seem to have gotten somewhere now! > >I just re-applied the view to my host, restarted sssd and cleared its >cache, and it's now picking up my overridden UID and GID! (I had to >manually add an entry for the overridden GID to /etc/group, because FreeIPA >won't let me override the private user groups.) > >One odd caveat, but perhaps this is part of the design... if I do a `getent >$IPA_UID` or `getent $OVERRIDE_UID`... both give the same output, my user >with the overridden UID. I'd expect the first one to just give no result? That's by design. >---- >One side question, though... now that I have done half of the work for an >AD trust... is it possible for me to make my FreeIPA server into an AD >controller for the one Windows box in my house? Some searching I did before >indicated no, in part because Samba required Heimdal instead of MIT >Kerberos... is that still true? Yes and no. FreeIPA cannot be made an AD controller and even when we complete porting Samba AD to use MIT Kerberos, that will not change as Samba AD is using its own, completely separate, data store and cannot be made using an external LDAP server for that. Samba AD is a special mode in Samba, different from a traditional domain controller mode used by FreeIPA. So while you are able to join your Windows machine to Samba AD with Heimdal now or with MIT Kerberos in future, this will be a join to a totally separate domain. -- / Alexander Bokovoy From pioto at pioto.org Fri Feb 19 12:26:10 2016 From: pioto at pioto.org (Mike Kelly) Date: Fri, 19 Feb 2016 12:26:10 +0000 Subject: [Freeipa-users] ID Views without AD In-Reply-To: <20160219122052.GU4492@redhat.com> References: <20160210081945.GR12787@redhat.com> <20160211082137.GA28898@redhat.com> <20160218102658.GF30390@p.redhat.com> <20160218152807.GI30390@p.redhat.com> <20160219122052.GU4492@redhat.com> Message-ID: Thanks. Ok, one final concern, though, I guess I didn't resolve the issues with sudo... [root at data ~]# sudo -l -U pioto User pioto is not allowed to run sudo on data. But, huh, after running these few commands, now I can? [root at data ~]# id pioto uid=1001(pioto) gid=1001(pioto) groups=1001(pioto),991(libvirt),988(docker),1005(backups),1009(media),1403400000 [root at data ~]# getent passwd 1403400000 admin:*:1403400000:1403400000:Administrator:/home/admin:/bin/bash [root at data ~]# getent passwd admin admin:*:1403400000:1403400000:Administrator:/home/admin:/bin/bash [root at data ~]# id pioto uid=1001(pioto) gid=1001(pioto) groups=1001(pioto),991(libvirt),988(docker),1005(backups),1009(media),1403400000(admins) [root at data ~]# sudo -l -U pioto Matching Defaults entries for pioto on this host: requiretty, !visiblepw, always_set_home, env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS", env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE", env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES", env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE", env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY", secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin User pioto may run the following commands on this host: (ALL : ALL) ALL [root at data ~]# getent group 1403400000 admins:*:1403400000:admin,pioto ---- Is there maybe some other cache that `sss_cache -E` isn't clearing? Or some other reason it didn't properly fetch the "admins" group until I looked up the "admin" user? On Fri, Feb 19, 2016 at 7:20 AM Alexander Bokovoy wrote: > On Fri, 19 Feb 2016, Mike Kelly wrote: > >Ahha! I seem to have gotten somewhere now! > > > >I just re-applied the view to my host, restarted sssd and cleared its > >cache, and it's now picking up my overridden UID and GID! (I had to > >manually add an entry for the overridden GID to /etc/group, because > FreeIPA > >won't let me override the private user groups.) > > > >One odd caveat, but perhaps this is part of the design... if I do a > `getent > >$IPA_UID` or `getent $OVERRIDE_UID`... both give the same output, my user > >with the overridden UID. I'd expect the first one to just give no result? > That's by design. > > >---- > >One side question, though... now that I have done half of the work for an > >AD trust... is it possible for me to make my FreeIPA server into an AD > >controller for the one Windows box in my house? Some searching I did > before > >indicated no, in part because Samba required Heimdal instead of MIT > >Kerberos... is that still true? > Yes and no. FreeIPA cannot be made an AD controller and even when we > complete porting Samba AD to use MIT Kerberos, that will not change as > Samba AD is using its own, completely separate, data store and cannot be > made using an external LDAP server for that. Samba AD is a special mode > in Samba, different from a traditional domain controller mode used by > FreeIPA. > > So while you are able to join your Windows machine to Samba AD with > Heimdal now or with MIT Kerberos in future, this will be a join to a > totally separate domain. > > > -- > / Alexander Bokovoy > -- Mike Kelly -------------- next part -------------- An HTML attachment was scrubbed... URL: From VKondratyev at bellintegrator.ru Fri Feb 19 12:48:40 2016 From: VKondratyev at bellintegrator.ru (Vladimir Kondratyev) Date: Fri, 19 Feb 2016 12:48:40 +0000 Subject: [Freeipa-users] Incomplete user identities on legacy clients Message-ID: <01cdcf460270490998a6a17e69619e44@msk-ex03.bell-main.bellintegrator.ru> Hi I installed latest ipa-server-4.2.0-15.el7_2.6.x86_64 with slapi-nis plugin on RHEL7.2 than installed and configured ipa-server-trust-ad-4.2.0-15.el7_2.6.x86_64 with compat-schema option and than successfully established one-way trust with Win2008R2 domain (named ad.dlink) After that following objects have been created in AD: groups: "linux admins at ad.dlink" "linux users at ad.dlink" users: "user2 at ad.dlink" - member of "linux users at ad.dlink" "user3 at ad.dlink" - member of both "linux users at ad.dlink" and "linux admins at ad.dlink" groups On IPA side i created following groups and relations: external member -> external ipa group -> posix ipa group "linux admins at ad.dlink" -> "ad_la_ext" -> "ad_la" "linux users at ad.dlink" -> "ad_lu_ext" -> "ad_lu" So "user2 at ad.dlink" being logged in to ipa-client becomes a member of "ad_lu" posix group and "user3 at ad.dlink" becomes a member of both "ad_la" and "ad_lu" groups That is working like intended for sssd1.9+ clients but not for legacy clients Steps for reproduce 1. Install RHEL5 (RHEL5.1 in my case but i tried another 5.x also) 2. Run ipa-advise config-redhat-nss-ldap on ipa trust-controller 3. login to RHEL5 as root and configure it with shell script obtained on step 2 4. reset compat ldap cache with issuing "systemctl restart dirsrv.target" on ipa-server (trust controller) 5. print user identities (or just login as user) on legacy client in following order: user2 at ad.dlink than user3 at ad.dlink [root at rhel51 ~]# id user2 at ad.dlink uid=1777801107(user2 at ad.dlink) gid=1777801107(user2 at ad.dlink) groups=1777801107(user2 at ad.dlink),120000003(ad_lu),1777801104(linux users at ad.dlink),1777800513(domain users at ad.dlink) context=root:system_r:unconfined_t:SystemLow-SystemHigh [root at rhel51 ~]# id user3 at ad.dlink uid=1777801108(user3 at ad.dlink) gid=1777801108(user3 at ad.dlink) groups=1777801108(user3 at ad.dlink),120000003(ad_lu),1777801104(linux users at ad.dlink),1777800513(domain users at ad.dlink) context=root:system_r:unconfined_t:SystemLow-SystemHigh As you can see "user3 at ad.dlink" misses "ad_la" and "linux admins at ad.dlink" groups membership! Now reset compat ldap cache with "systemctl restart dirsrv.target" again and print identities on legacy client in opposite order: user3 at ad.dlink than user2 at ad.dlink [root at rhel51 ~]# id user3 at ad.dlink uid=1777801108(user3 at ad.dlink) gid=1777801108(user3 at ad.dlink) groups=1777801108(user3 at ad.dlink),120000003(ad_lu),120000004(ad_la),1777801104(linux users at ad.dlink),1777801105(linux admins at ad.dlink),1777800513(domain users at ad.dlink) context=root:system_r:unconfined_t:SystemLow-SystemHigh [root at rhel51 ~]# id user2 at ad.dlink uid=1777801107(user2 at ad.dlink) gid=1777801107(user2 at ad.dlink) groups=1777801107(user2 at ad.dlink),120000003(ad_lu),1777801104(linux users at ad.dlink),1777800513(domain users at ad.dlink) context=root:system_r:unconfined_t:SystemLow-SystemHigh Voila, "user3 at ad.dlink" is a "ad_la" and "linux admins at ad.dlink" groups member now! So it seems external member -> posix ipa group relations are cached for first user logged (or issued id command) into legacy client after compat-cache reset and these relations are not updated on other user login Also its interesting that 2 objects with the same dn but different objectClass, memberUid and ipaAnchorUUID can be found in compat ldap after first login or executing of id [root at idm1 ~]# ldapsearch -Wx -D "cn=Directory manager" -b "cn=ad_lu,cn=groups,cn=compat,dc=ipa,dc=dlink" Enter LDAP Password: # extended LDIF # # LDAPv3 # base with scope subtree # filter: (objectclass=*) # requesting: ALL # # ad_lu, groups, compat, ipa.dlink dn: cn=ad_lu,cn=groups,cn=compat,dc=ipa,dc=dlink objectClass: ipaOverrideTarget objectClass: posixGroup objectClass: top gidNumber: 120000003 memberUid: user6 at child.ad.dlink memberUid: user7 at child.ad.dlink memberUid: user8 at child.ad.dlink memberUid: user5 at child.ad.dlink memberUid: admin memberUid: user4 at ad.dlink memberUid: user9 at child.ad.dlink memberUid: user2 at ad.dlink memberUid: user3 at ad.dlink ipaAnchorUUID:: OlNJRDpTLTEtNS0yMS0yNjgxMjU4MTQxLTE0MzYzMzM2NTUtOTY0MTEzOTI0LT EwMDM= cn: ad_lu # ad_lu, groups, compat, ipa.dlink dn: cn=ad_lu,cn=groups,cn=compat,dc=ipa,dc=dlink ipaAnchorUUID:: OklQQTppcGEuZGxpbms6ZGJhZDgyNDgtZDMxOS0xMWU1LTk0MTAtMDgwMDI3Yj E3NmNk gidNumber: 120000003 memberUid: admin objectClass: posixGroup objectClass: ipaOverrideTarget objectClass: top cn: ad_lu # search result search: 2 result: 0 Success # numResponses: 3 # numEntries: 2 P.S. I use CA-less setup with external DNS servers -- Vladimir Kondratyev From stijn.geselle at ypto.be Fri Feb 19 12:50:02 2016 From: stijn.geselle at ypto.be (Geselle Stijn) Date: Fri, 19 Feb 2016 12:50:02 +0000 Subject: [Freeipa-users] DNS operation timed out when installing IPA with forwarders Message-ID: <986ED6C5BA6EFD49B00A4CEABE2E8FDA276AC4D5@HICTATRIUEM023.msnet.railb.be> Hello fellow FreeIPA users, I'm trying to setup FreeIPA in a lab environment (VirtualBox): - ad.example.com (Windows Server 2008 R2) - 192.168.1.1 - ipa.example.com (CentOS 7.2) - 192.168.1.2 Both machines can ping each other, DNS resolving works: [root at ipa ~] nslookup ad Server: 192.168.1.1 Address: 192.168.1.1#53 Name: ad.example.com Address: 192.168.1.1 I executed: yum install -y "*ipa-server*" bind bind-dyndb-ldap ipa-server-install --domain=example.com --realm=EXAMPLE.COM --setup-dns --forwarder=192.168.1.1 But the installation wizard fails at: Checking DNS forwarders, please wait ... ipa : ERROR DNS server 192.168.1.1: query '. SOA': The DNS operation timed out after 10.00124242 seconds ipa.ipapython.install.cli.install_tool(Server): ERROR DNS server 192.168.1.1: query '. SOA': The DNS operation timed out after 10.00124242 seconds Is there some way I can better troubleshoot this? Can I increase the DNS timeout (maybe it's simply slow via VirtualBox). Thank you! -Stijn -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Fri Feb 19 12:54:33 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 19 Feb 2016 14:54:33 +0200 Subject: [Freeipa-users] Incomplete user identities on legacy clients In-Reply-To: <01cdcf460270490998a6a17e69619e44@msk-ex03.bell-main.bellintegrator.ru> References: <01cdcf460270490998a6a17e69619e44@msk-ex03.bell-main.bellintegrator.ru> Message-ID: <20160219125433.GW4492@redhat.com> On Fri, 19 Feb 2016, Vladimir Kondratyev wrote: >Hi > >I installed latest ipa-server-4.2.0-15.el7_2.6.x86_64 with slapi-nis >plugin on RHEL7.2 than installed and configured >ipa-server-trust-ad-4.2.0-15.el7_2.6.x86_64 with compat-schema option >and than successfully established one-way trust with Win2008R2 domain >(named ad.dlink) > >After that following objects have been created in AD: > >groups: >"linux admins at ad.dlink" >"linux users at ad.dlink" > >users: >"user2 at ad.dlink" - member of "linux users at ad.dlink" >"user3 at ad.dlink" - member of both "linux users at ad.dlink" and "linux admins at ad.dlink" groups > >On IPA side i created following groups and relations: > >external member -> external ipa group -> posix ipa group >"linux admins at ad.dlink" -> "ad_la_ext" -> "ad_la" >"linux users at ad.dlink" -> "ad_lu_ext" -> "ad_lu" > >So "user2 at ad.dlink" being logged in to ipa-client becomes a member of >"ad_lu" posix group and "user3 at ad.dlink" becomes a member of both >"ad_la" and "ad_lu" groups > >That is working like intended for sssd1.9+ clients but not for legacy >clients Yes, there is a complex issue in SSSD and slapi-nis that prevents AD members of IPA groups to be fully resolved for legacy clients. A good thing is that it is now almost fixed and updates for sssd and slapi-nis will appear in next RHEL 7 update. -- / Alexander Bokovoy From pspacek at redhat.com Fri Feb 19 12:58:49 2016 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 19 Feb 2016 13:58:49 +0100 Subject: [Freeipa-users] DNS operation timed out when installing IPA with forwarders In-Reply-To: <986ED6C5BA6EFD49B00A4CEABE2E8FDA276AC4D5@HICTATRIUEM023.msnet.railb.be> References: <986ED6C5BA6EFD49B00A4CEABE2E8FDA276AC4D5@HICTATRIUEM023.msnet.railb.be> Message-ID: <56C71189.3020303@redhat.com> On 19.2.2016 13:50, Geselle Stijn wrote: > Hello fellow FreeIPA users, > > I'm trying to setup FreeIPA in a lab environment (VirtualBox): > > > - ad.example.com (Windows Server 2008 R2) - 192.168.1.1 > > - ipa.example.com (CentOS 7.2) - 192.168.1.2 > Both machines can ping each other, DNS resolving works: > > [root at ipa ~] nslookup ad > Server: 192.168.1.1 > Address: 192.168.1.1#53 > > Name: ad.example.com > Address: 192.168.1.1 > > > I executed: > > yum install -y "*ipa-server*" bind bind-dyndb-ldap > ipa-server-install --domain=example.com --realm=EXAMPLE.COM --setup-dns --forwarder=192.168.1.1 > > But the installation wizard fails at: > > Checking DNS forwarders, please wait ... > ipa : ERROR DNS server 192.168.1.1: query '. SOA': The DNS operation timed out after 10.00124242 seconds > ipa.ipapython.install.cli.install_tool(Server): ERROR DNS server 192.168.1.1: query '. SOA': The DNS operation timed out after 10.00124242 seconds > > > Is there some way I can better troubleshoot this? Can I increase the DNS timeout (maybe it's simply slow via VirtualBox). Please try command $ dig @192.168.1.1 . SOA and paste the output here. Also, please run the installer again with option --debug. I will have a look. Thank you. -- Petr^2 Spacek From harald.dunkel at aixigo.de Fri Feb 19 13:03:54 2016 From: harald.dunkel at aixigo.de (Harald Dunkel) Date: Fri, 19 Feb 2016 14:03:54 +0100 Subject: [Freeipa-users] sssd 1.13.3: sss_ssh_knownhostsproxy seems to break ssh -4 Message-ID: <56C712BA.1000008@aixigo.de> Hi folks, is it just me, or does sss_ssh_knownhostsproxy break ssh -4 host.example.com ? host.example.com has A and AAAA entries in DNS, of course. If I comment out the line in ssh_config # ProxyCommand /usr/bin/sss_ssh_knownhostsproxy -p %p %h then I get the expected IPv4 connection. ??? This is sssd 1.13.3-1, built and run on Debian Jessie. Every helpful comment is highly appreciated Harri From sbose at redhat.com Fri Feb 19 13:05:03 2016 From: sbose at redhat.com (Sumit Bose) Date: Fri, 19 Feb 2016 14:05:03 +0100 Subject: [Freeipa-users] ID Views without AD In-Reply-To: References: <20160210081945.GR12787@redhat.com> <20160211082137.GA28898@redhat.com> <20160218102658.GF30390@p.redhat.com> <20160218152807.GI30390@p.redhat.com> Message-ID: <20160219130503.GA3408@p.redhat.com> On Fri, Feb 19, 2016 at 12:12:42PM +0000, Mike Kelly wrote: > Ahha! I seem to have gotten somewhere now! > > I just re-applied the view to my host, restarted sssd and cleared its yes, that's what I meant earlier with the missing view entry in the cache. SSSD tries to figure out if a view name changed at startup time and if it happened it removes the old view data. This does not work properly because of the issue we have and hence SSSD needs some help by either doing a fresh view name change with the fixed version or remove the existing cache. > cache, and it's now picking up my overridden UID and GID! (I had to > manually add an entry for the overridden GID to /etc/group, because FreeIPA > won't let me override the private user groups.) yes, this is expected, but you do not have to add the group to /etc/group but you can add a new group with the overridden GID to IPA as well. bye, Sumit (Alexander already commented on the questions below) > > One odd caveat, but perhaps this is part of the design... if I do a `getent > $IPA_UID` or `getent $OVERRIDE_UID`... both give the same output, my user > with the overridden UID. I'd expect the first one to just give no result? > > ---- > > One side question, though... now that I have done half of the work for an > AD trust... is it possible for me to make my FreeIPA server into an AD > controller for the one Windows box in my house? Some searching I did before > indicated no, in part because Samba required Heimdal instead of MIT > Kerberos... is that still true? > > On Thu, Feb 18, 2016 at 12:21 PM Mike Kelly wrote: > > > Thanks for the quick reply. > > > > FWIW, I'm on CentOS 7, but I haven't yet tried to apply your test sssd > > packages. > > > > I don't seem to have the "ldbadd" command on my client, either. > > > > Also, I tried running `sudo ipa-adtrust-install --add-sids -A pioto`, and > > I see more in the logs now. > > > > But, I don't seem to be seeing my UID changing like I'd expect, and I seem > > to no longer be able to run sudo on my client... > > > > If I unapply the view from my client's host, though, sudo again works as > > expected. So, it's picking up... something... just not quite everything yet. > > > > > > On Thu, Feb 18, 2016 at 10:28 AM Sumit Bose wrote: > > > >> On Thu, Feb 18, 2016 at 11:26:58AM +0100, Sumit Bose wrote: > >> > On Tue, Feb 16, 2016 at 04:23:10PM +0000, Mike Kelly wrote: > >> > > >> Thanks. Here's what is hopefully the relevant lines: > >> > > > > >> > > > I'm sorry, but these logs only capture how the original entry was > >> > > searched, not the overrides. Can you capture the full logs since the > >> sssd > >> > > startup? Also please make sure the cache was invalidated prior to the > >> > > request with sss_cache -E. > >> > > > >> > > Attached are the full logs since a restart of sssd. > >> > > >> > Thank you, the logs helped. The IPA client reads the idview at startup > >> > time either from the cache or the IPA server. Since there is of course > >> > no idview name saved in the cache of your client the name must be looked > >> > up from the server. The lookup of the idview name is part of the request > >> > which reads other data about the IPA domain and possible trusted > >> > domains. Unfortunately the current code expects that e.g. the domain SID > >> > of the IPA domain is defined before it proceeds to read the idview. > >> > > >> > This is of course a bug and I will try to fix it. If you would like to > >> > try a work-around you can call ipa-adtrust-install on one of your IPA > >> > servers. This will create the needed data on the server. It is > >> > sufficient to call it on one server because the data will be replicated > >> > to the other servers and since you currently not plan to add a trust to > >> > a AD domain, you do not have to prepare additional services on other > >> > server (with FreeIPA-4.2 this wouldn't even be necessary if you plan to > >> > add a trust). > >> > > >> > If you can wait a day or two I'd be happy to prepare a SSSD test build > >> > with a fix. > >> > >> It looks it was easier than I expected. You can find test packages for > >> RHEL/CentOS-7 at > >> > >> http://koji.fedoraproject.org/koji/taskinfo?taskID=13035051 > >> > >> (Please tell me if you need packages for a different platform) > >> > >> Before you upgrade the package on a client please run > >> > >> # ldbadd -H /var/lib/sss/db/cache_your.domain.name.ldb << EOF > >> dn: cn=views,cn=sysdb > >> viewName: default > >> EOF > >> > >> Otherwise SSSD will not recognise the name change and still show the > >> original values. As an alternative you can remove the cache completely > >> before starting the new version or unapply the idview and apply it again > >> on the server while you restart the new sssd version on the client after > >> each change on the server. I'll try to think of a way to make this more > >> easy without breaking the existing detection of a change in the idview > >> name. > >> > >> HTH > >> > >> bye, > >> Sumit > >> > >> > > >> > bye, > >> > Sumit > >> > > >> > > > >> > > I ran these commands: > >> > > > >> > > systemctl stop sssd > >> > > > >> > > echo '----MARK----' >> /var/log/sssd/sssd_home.pioto.org.log # so I > >> could > >> > > mark were the restart happened > >> > > > >> > > sss_cache -E > >> > > > >> > > systemctl start sssd > >> > > > >> > > sss_cache -E > >> > > > >> > > id pioto > >> > > > >> > > ---- > >> > > > >> > > I still don't see the override being applied. Possibly because of > >> this line? > >> > > > >> > > (Tue Feb 16 11:12:27 2016) [sssd[be[home.pioto.org]]] > >> > > [ipa_get_ad_override_send] > >> > > (0x4000): View not defined, nothing to do. > >> > > > >> > > So, I get the feeling that, for whatever reason, sssd isn't correctly > >> > > deciding that my id view applies to this host, or just isn't looking > >> it up? > >> > > > >> > > Is there possibly some sort of extra configuration that I've missed > >> to tell > >> > > SSSD to apply these views? From what I can tell, it should just pick > >> these > >> > > up out of the box, from the configuration built by > >> ipa-client-install...? > >> > > >> > > >> > > -- > >> > > Manage your subscription for the Freeipa-users mailing list: > >> > > https://www.redhat.com/mailman/listinfo/freeipa-users > >> > > Go to http://freeipa.org for more info on the project > >> > > >> > -- > >> > Manage your subscription for the Freeipa-users mailing list: > >> > https://www.redhat.com/mailman/listinfo/freeipa-users > >> > Go to http://freeipa.org for more info on the project > >> > > -- > > > > Mike Kelly > > > -- > > Mike Kelly From lslebodn at redhat.com Fri Feb 19 13:47:09 2016 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Fri, 19 Feb 2016 14:47:09 +0100 Subject: [Freeipa-users] sssd 1.13.3: sss_ssh_knownhostsproxy seems to break ssh -4 In-Reply-To: <56C712BA.1000008@aixigo.de> References: <56C712BA.1000008@aixigo.de> Message-ID: <20160219134708.GD2780@mail.corp.redhat.com> On (19/02/16 14:03), Harald Dunkel wrote: >Hi folks, > >is it just me, or does sss_ssh_knownhostsproxy break > > ssh -4 host.example.com > >? > >host.example.com has A and AAAA entries in DNS, of course. >If I comment out the line in ssh_config > ># ProxyCommand /usr/bin/sss_ssh_knownhostsproxy -p %p %h > >then I get the expected IPv4 connection. ??? > >This is sssd 1.13.3-1, built and run on Debian Jessie. > It's known bug https://fedorahosted.org/sssd/ticket/1498 https://bugzilla.redhat.com/show_bug.cgi?id=1063278 LS From stijn.geselle at ypto.be Fri Feb 19 13:57:22 2016 From: stijn.geselle at ypto.be (Geselle Stijn) Date: Fri, 19 Feb 2016 13:57:22 +0000 Subject: [Freeipa-users] DNS operation timed out when installing IPA with forwarders In-Reply-To: <56C71189.3020303@redhat.com> References: <986ED6C5BA6EFD49B00A4CEABE2E8FDA276AC4D5@HICTATRIUEM023.msnet.railb.be> <56C71189.3020303@redhat.com> Message-ID: <986ED6C5BA6EFD49B00A4CEABE2E8FDA276AC589@HICTATRIUEM023.msnet.railb.be> That seems to fail: [root at ipa ~]# dig @192.168.1.1 . SOA ; <<>> DiG 9.9.4-RedHat-9.9.4-29.el7_2.2 <<>> @192.168.1.1 . SOA ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 44900 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4000 ;; QUESTION SECTION: ;. IN SOA ;; Query time: 11153 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Fri Feb 19 14:42:51 CET 2016 ;; MSG SIZE rcvd: 28 But if I add a new record (e.g. CNAME) to DNS in Windows Server and try to ping to that CNAME, I get resolved correctly. -Stijn -----Original Message----- From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Petr Spacek Sent: Friday 19 February 2016 13:59 To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] DNS operation timed out when installing IPA with forwarders On 19.2.2016 13:50, Geselle Stijn wrote: > Hello fellow FreeIPA users, > > I'm trying to setup FreeIPA in a lab environment (VirtualBox): > > > - ad.example.com (Windows Server 2008 R2) - 192.168.1.1 > > - ipa.example.com (CentOS 7.2) - 192.168.1.2 > Both machines can ping each other, DNS resolving works: > > [root at ipa ~] nslookup ad > Server: 192.168.1.1 > Address: 192.168.1.1#53 > > Name: ad.example.com > Address: 192.168.1.1 > > > I executed: > > yum install -y "*ipa-server*" bind bind-dyndb-ldap ipa-server-install > --domain=example.com --realm=EXAMPLE.COM --setup-dns > --forwarder=192.168.1.1 > > But the installation wizard fails at: > > Checking DNS forwarders, please wait ... > ipa : ERROR DNS server 192.168.1.1: query '. SOA': The DNS operation timed out after 10.00124242 seconds > ipa.ipapython.install.cli.install_tool(Server): ERROR DNS server 192.168.1.1: query '. SOA': The DNS operation timed out after 10.00124242 seconds > > > Is there some way I can better troubleshoot this? Can I increase the DNS timeout (maybe it's simply slow via VirtualBox). Please try command $ dig @192.168.1.1 . SOA and paste the output here. Also, please run the installer again with option --debug. I will have a look. Thank you. -- Petr^2 Spacek -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project From mbasti at redhat.com Fri Feb 19 14:09:23 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 19 Feb 2016 15:09:23 +0100 Subject: [Freeipa-users] DNS operation timed out when installing IPA with forwarders In-Reply-To: <986ED6C5BA6EFD49B00A4CEABE2E8FDA276AC589@HICTATRIUEM023.msnet.railb.be> References: <986ED6C5BA6EFD49B00A4CEABE2E8FDA276AC4D5@HICTATRIUEM023.msnet.railb.be> <56C71189.3020303@redhat.com> <986ED6C5BA6EFD49B00A4CEABE2E8FDA276AC589@HICTATRIUEM023.msnet.railb.be> Message-ID: <56C72213.4090802@redhat.com> On 19.02.2016 14:57, Geselle Stijn wrote: > That seems to fail: > > [root at ipa ~]# dig @192.168.1.1 . SOA > > ; <<>> DiG 9.9.4-RedHat-9.9.4-29.el7_2.2 <<>> @192.168.1.1 . SOA ; (1 server found) ;; global options: +cmd ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 44900 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4000 > ;; QUESTION SECTION: > ;. IN SOA > > ;; Query time: 11153 msec > ;; SERVER: 192.168.1.1#53(192.168.1.1) > ;; WHEN: Fri Feb 19 14:42:51 CET 2016 > ;; MSG SIZE rcvd: 28 > > > But if I add a new record (e.g. CNAME) to DNS in Windows Server and try to ping to that CNAME, I get resolved correctly. > > -Stijn Hello, global forwarders, specified by --forwarder option during installation or added via ipa dnsconfig-mod, must be able to resolve root zone (your forwarder/server 192.168.1.1 is not able to return result for root zone). You probably need to specify forwardzone, for the particular windows domain you use, instead of specify it as global forwarder. ipa dnsforwardzone-add --forwarder 192.168.1.1 Martin > > -----Original Message----- > From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Petr Spacek > Sent: Friday 19 February 2016 13:59 > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] DNS operation timed out when installing IPA with forwarders > > On 19.2.2016 13:50, Geselle Stijn wrote: >> Hello fellow FreeIPA users, >> >> I'm trying to setup FreeIPA in a lab environment (VirtualBox): >> >> >> - ad.example.com (Windows Server 2008 R2) - 192.168.1.1 >> >> - ipa.example.com (CentOS 7.2) - 192.168.1.2 >> Both machines can ping each other, DNS resolving works: >> >> [root at ipa ~] nslookup ad >> Server: 192.168.1.1 >> Address: 192.168.1.1#53 >> >> Name: ad.example.com >> Address: 192.168.1.1 >> >> >> I executed: >> >> yum install -y "*ipa-server*" bind bind-dyndb-ldap ipa-server-install >> --domain=example.com --realm=EXAMPLE.COM --setup-dns >> --forwarder=192.168.1.1 >> >> But the installation wizard fails at: >> >> Checking DNS forwarders, please wait ... >> ipa : ERROR DNS server 192.168.1.1: query '. SOA': The DNS operation timed out after 10.00124242 seconds >> ipa.ipapython.install.cli.install_tool(Server): ERROR DNS server 192.168.1.1: query '. SOA': The DNS operation timed out after 10.00124242 seconds >> >> >> Is there some way I can better troubleshoot this? Can I increase the DNS timeout (maybe it's simply slow via VirtualBox). > Please try command > $ dig @192.168.1.1 . SOA > and paste the output here. > > Also, please run the installer again with option --debug. > > I will have a look. > > Thank you. > > -- > Petr^2 Spacek > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project > From Daryl.Fonseca-Holt at umanitoba.ca Fri Feb 19 14:12:32 2016 From: Daryl.Fonseca-Holt at umanitoba.ca (Daryl Fonseca-Holt) Date: Fri, 19 Feb 2016 08:12:32 -0600 Subject: [Freeipa-users] IPA 4.2.0 httpd errors Message-ID: <56C722D0.3020503@umanitoba.ca> Hello, Doing a bulk load of 150,000+ users to an IPA 4.2.0 server running RedHat Enterprise Linux 7. Running 25 parallel ipa user-add at once, waiting for completion, then starting another 25, and so on. The httpd error_log is filling with many of these messages (457,189 in four days): [Fri Feb 19 07:41:08.100903 2016] [:error] [pid 76505] [remote 10.0.1.177:40] mod_wsgi (pid=76505): Exception occurred processing WSGI script '/usr/share/ipa/wsgi.py'. [Fri Feb 19 07:41:08.100989 2016] [:error] [pid 76505] [remote 10.0.1.177:40] Traceback (most recent call last): [Fri Feb 19 07:41:08.101018 2016] [:error] [pid 76505] [remote 10.0.1.177:40] File "/usr/share/ipa/wsgi.py", line 49, in application [Fri Feb 19 07:41:08.101073 2016] [:error] [pid 76505] [remote 10.0.1.177:40] return api.Backend.wsgi_dispatch(environ, start_response) [Fri Feb 19 07:41:08.101087 2016] [:error] [pid 76505] [remote 10.0.1.177:40] File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 258, in __call__ [Fri Feb 19 07:41:08.101109 2016] [:error] [pid 76505] [remote 10.0.1.177:40] return self.route(environ, start_response) [Fri Feb 19 07:41:08.101120 2016] [:error] [pid 76505] [remote 10.0.1.177:40] File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 270, in route [Fri Feb 19 07:41:08.101140 2016] [:error] [pid 76505] [remote 10.0.1.177:40] return app(environ, start_response) [Fri Feb 19 07:41:08.101152 2016] [:error] [pid 76505] [remote 10.0.1.177:40] File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 447, in __call__ [Fri Feb 19 07:41:08.101169 2016] [:error] [pid 76505] [remote 10.0.1.177:40] response = super(jsonserver, self).__call__(environ, start_response) [Fri Feb 19 07:41:08.101180 2016] [:error] [pid 76505] [remote 10.0.1.177:40] File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 647, in __call__ [Fri Feb 19 07:41:08.101198 2016] [:error] [pid 76505] [remote 10.0.1.177:40] 'xmlserver', user_ccache, environ, start_response, headers) [Fri Feb 19 07:41:08.101210 2016] [:error] [pid 76505] [remote 10.0.1.177:40] File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 593, in finalize_kerberos_acquisition [Fri Feb 19 07:41:08.101229 2016] [:error] [pid 76505] [remote 10.0.1.177:40] session_data['ccache_data'] = load_ccache_data(ccache_name) [Fri Feb 19 07:41:08.101240 2016] [:error] [pid 76505] [remote 10.0.1.177:40] File "/usr/lib/python2.7/site-packages/ipalib/session.py", line 1231, in load_ccache_data [Fri Feb 19 07:41:08.101259 2016] [:error] [pid 76505] [remote 10.0.1.177:40] src = open(name) [Fri Feb 19 07:41:08.101294 2016] [:error] [pid 76505] [remote 10.0.1.177:40] IOError: [Errno 2] No such file or directory: '/var/run/httpd/ipa/clientcaches/admin at UOFMT1' [Fri Feb 19 07:41:09.788839 2016] [auth_gssapi:error] [pid 75336] [client 10.0.1.177:42610] failed to store delegated creds: [Unspecified GSS failure. Minor code may provide more information (Internal credentials cache error)], referer: https://mork.cc.umanitoba.ca/ipa/xml [Fri Feb 19 07:41:09.788844 2016] [auth_gssapi:error] [pid 78642] [client 10.0.1.177:42621] failed to store delegated creds: [Unspecified GSS failure. Minor code may provide more information (Internal credentials cache error)], referer: https://mork.cc.umanitoba.ca/ipa/xml [Fri Feb 19 07:41:09.788961 2016] [auth_gssapi:error] [pid 78643] [client 10.0.1.177:42613] failed to store delegated creds: [Unspecified GSS failure. Minor code may provide more information (Internal credentials cache error)], referer: https://mork.cc.umanitoba.ca/ipa/xml [Fri Feb 19 07:41:09.789154 2016] [auth_gssapi:error] [pid 77367] [client 10.0.1.177:42615] KRB5CCNAME file (/var/run/httpd/ipa/clientcaches/admin at UOFMT1) lookup failed!, referer: https://mork.cc.umanitoba.ca/ipa/xml When the batches are first started there are no errors. Started batch script at 11:34:54. First error at 12:17:31 after 48 batches of 25 users. The 25 users are each added concurrently by separate processes using ipa user-add ... When the script gets the authentication error it simply retries the user-add so the user are added anyway. I think there was a similiar incident, Subject: Client-Install failures in January 2016 but the thread seemed to fade away without an answer AFAICT. Thanks, Daryl -- -- Daryl Fonseca-Holt IST/CNS/Unix Server Team University of Manitoba 204.480.1079 From harald.dunkel at aixigo.de Fri Feb 19 14:27:50 2016 From: harald.dunkel at aixigo.de (Harald Dunkel) Date: Fri, 19 Feb 2016 15:27:50 +0100 Subject: [Freeipa-users] sssd 1.13.3: sss_ssh_knownhostsproxy seems to break ssh -4 In-Reply-To: <20160219134708.GD2780@mail.corp.redhat.com> References: <56C712BA.1000008@aixigo.de> <20160219134708.GD2780@mail.corp.redhat.com> Message-ID: <56C72666.6050500@aixigo.de> Hi Lukas, I found an ubuntu manpage saying sss_ssh_knownhostsproxy is an experimental feature. Would you suggest to drop it in ipa-client-install? IMHO this is a pretty annoying bug. I rely upon a port redirection for ssh on IPv4. For IPv6 there is no redirection, but the port is blocked in the packet filter. Regards Harri From jhrozek at redhat.com Fri Feb 19 15:04:15 2016 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 19 Feb 2016 16:04:15 +0100 Subject: [Freeipa-users] sssd 1.13.3: sss_ssh_knownhostsproxy seems to break ssh -4 In-Reply-To: <56C72666.6050500@aixigo.de> References: <56C712BA.1000008@aixigo.de> <20160219134708.GD2780@mail.corp.redhat.com> <56C72666.6050500@aixigo.de> Message-ID: <20160219150415.GH3553@hendrix.arn.redhat.com> On Fri, Feb 19, 2016 at 03:27:50PM +0100, Harald Dunkel wrote: > Hi Lukas, > > I found an ubuntu manpage saying sss_ssh_knownhostsproxy is > an experimental feature. > Would you suggest to drop it > in ipa-client-install? It's not experimental (at least upstream) for several years.. What sssd version is that? > > IMHO this is a pretty annoying bug. I rely upon a port > redirection for ssh on IPv4. For IPv6 there is no > redirection, but the port is blocked in the packet filter. Would it help to set lookup_family_order to ipv4_only here so that ipv6 is not even tried (or the other way around, depending on which AF you want to try..) From prashant at apigee.com Fri Feb 19 15:40:19 2016 From: prashant at apigee.com (Prashant Bapat) Date: Fri, 19 Feb 2016 21:10:19 +0530 Subject: [Freeipa-users] Wildcards in sudo external hostnames In-Reply-To: <20160219085844.GI3123@hendrix> References: <20160219085844.GI3123@hendrix> Message-ID: Not using SSSD because Amazon Linux does not support samba libraries required to compile it. On 19 February 2016 at 14:28, Jakub Hrozek wrote: > On Fri, Feb 19, 2016 at 11:27:16AM +0530, Prashant Bapat wrote: > > Hi, > > > > I'm using FreeIPA 4.1.4 with nss-pam-ldapd and the compat schema. > > Why not sssd? > > > > > I'm thinking of moving sudo rules to IPA and with *ou=sudoers* and > > sudo-ldap this works. > > > > In our setup we have lot of rules with wildcard matching for sudo > > hostnames. For ex webserver*, dbserver* etc. > > > > In the IPA UI, when I try to add the hostname with wildcard (*) char I > get > > an error from UI. * is not allowed char. > > > > Looks like the UI is trying to validate the hostname using > > validate_dns_label in ipa/util.py and obviously * is not one of the > allowed > > chars. > > > > Taking a look at the documentation of sudo, wildcards are pretty widely > > used. More info here > > https://www.sudo.ws/man/1.8.15/sudoers.man.html#x57696c646361726473 > > > > Other than editing the LDAP schema outside of IPA (this will work) what > are > > the other options to solve this ? > > I guess hostgroups/netgroups are even better (more explicit) than > wildcards. > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Fri Feb 19 16:02:51 2016 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 19 Feb 2016 17:02:51 +0100 Subject: [Freeipa-users] Wildcards in sudo external hostnames In-Reply-To: References: <20160219085844.GI3123@hendrix> Message-ID: <20160219160251.GJ3553@hendrix.arn.redhat.com> On Fri, Feb 19, 2016 at 09:10:19PM +0530, Prashant Bapat wrote: > Not using SSSD because Amazon Linux does not support samba libraries > required to compile it. Time to file a request against Amazon I guess :-) From lslebodn at redhat.com Fri Feb 19 16:06:01 2016 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Fri, 19 Feb 2016 17:06:01 +0100 Subject: [Freeipa-users] sssd 1.13.3: sss_ssh_knownhostsproxy seems to break ssh -4 In-Reply-To: <20160219150415.GH3553@hendrix.arn.redhat.com> References: <56C712BA.1000008@aixigo.de> <20160219134708.GD2780@mail.corp.redhat.com> <56C72666.6050500@aixigo.de> <20160219150415.GH3553@hendrix.arn.redhat.com> Message-ID: <20160219160459.GG2780@mail.corp.redhat.com> On (19/02/16 16:04), Jakub Hrozek wrote: >On Fri, Feb 19, 2016 at 03:27:50PM +0100, Harald Dunkel wrote: >> Hi Lukas, >> >> I found an ubuntu manpage saying sss_ssh_knownhostsproxy is >> an experimental feature. >> Would you suggest to drop it >> in ipa-client-install? > >It's not experimental (at least upstream) for several years.. What sssd >version is that? > @see subject :-) >> >> IMHO this is a pretty annoying bug. I rely upon a port >> redirection for ssh on IPv4. For IPv6 there is no >> redirection, but the port is blocked in the packet filter. > >Would it help to set lookup_family_order to ipv4_only here so that ipv6 >is not even tried (or the other way around, depending on which AF you >want to try..) > I briefly look at the source code and it does not seems to read sssd.conf. LS From tgeier at accertify.com Sat Feb 20 06:57:26 2016 From: tgeier at accertify.com (Timothy Geier) Date: Sat, 20 Feb 2016 06:57:26 +0000 Subject: [Freeipa-users] IPA 4.2: pki-tomcatd in terrible shape In-Reply-To: <56BE04AD.2020700@redhat.com> References: <56B86DE0.4070909@redhat.com> <7F0EB8FC-8F2F-49D1-A124-562B5B0A55A2@accertify.com> <56B9AA53.1000400@redhat.com> <56BAFC6E.6030605@redhat.com> <56BE04AD.2020700@redhat.com> Message-ID: <1455951442.25282.2.camel@accertify.com> To update this thread..timeshifting to before the certs expired (Feb. 2) brings up the interesting issue of pki-tomcatd (sometimes) starting while slapd crashes almost immediately after ipactl start is run..if it doesn't crash right away, pki-tomcatd will start, but since slapd will then go down right afterwards, the certs cannot be renewed.??After returning to real time, slapd is just fine along with everything else aside from pki-tomcatd. A core dump is attached. "This message and any attachments may contain confidential information. If you have received this message in error, any use or distribution is prohibited. Please notify us by reply e-mail if you have mistakenly received this message, and immediately and permanently delete it and any attachments. Thank you." -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: stacktrace.1455949929.txt URL: From arequipeno at gmail.com Sat Feb 20 16:58:34 2016 From: arequipeno at gmail.com (Ian Pilcher) Date: Sat, 20 Feb 2016 10:58:34 -0600 Subject: [Freeipa-users] Traceback starting pki-cad - ca.subsystem.certreq missing? Message-ID: I am running IPA 3.0.0 on CentOS 6 (32-bit x86), and I am getting a traceback every time pki-cad starts: Traceback (most recent call last): File "/usr/sbin/pki-server", line 89, in cli.execute(sys.argv) File "/usr/sbin/pki-server", line 84, in execute super(PKIServerCLI, self).execute(args) File "/usr/lib/python2.6/site-packages/pki/cli.py", line 195, in execute module.execute(module_args) File "/usr/lib/python2.6/site-packages/pki/server/cli/upgrade.py", line 103, in execute scriptlet.execute() File "/usr/lib/python2.6/site-packages/pki/server/upgrade/__init__.py", line 50, in execute cert = self.subsystem.get_system_cert('subsystem') File "/usr/lib/python2.6/site-packages/pki/server/__init__.py", line 93, in get_system_cert cert['request'] = base64.b64decode(self.config['%s.%s.certreq' % (self.prefix, tag)]) KeyError: 'ca.subsystem.certreq' Starting pki-ca: [ OK ] As you can see, the daemon does still start successfully, and the traceback doesn't appear in any of the pki-cad logs. It seems that it is looking for a ca.subsystem.certreq entry in /etc/pki-ca/CS.cfg, and sure enough it isn't there. Nor is it present in CS.cfg.bak. How can I create this entry (or otherwise fix this)? Thanks! -- ======================================================================== Ian Pilcher arequipeno at gmail.com -------- "I grew up before Mark Zuckerberg invented friendship" -------- ======================================================================== From tjaalton at ubuntu.com Mon Feb 22 05:11:14 2016 From: tjaalton at ubuntu.com (Timo Aaltonen) Date: Mon, 22 Feb 2016 07:11:14 +0200 Subject: [Freeipa-users] [freeipa-users] Configuring Automount on Ubuntu Clients In-Reply-To: <20160214071417.GA6343@eru> References: <56B8BAB4.2080007@ubuntu.com> <20160214071417.GA6343@eru> Message-ID: <56CA9872.6030608@ubuntu.com> 14.02.2016, 09:14, Filip Pytloun kirjoitti: > Hello, > > we are using Ubuntu 14.04 on FreeIPA clients and Ubuntu 16.04 on FreeIPA > server for 2 months with no critical issues. > > Using newer freeipa-client was not needed, only sssd update from here, > because trusty version is buggy: > https://launchpad.net/~sssd/+archive/ubuntu/updates?field.series_filter=trusty > > On server side, it was only needed to fix apparmor policy for bind to > fix FreeIPA DNS zones: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814314 /var/lib/sss* bits belong to the apparmor profile shipped by sssd.. mind removing them from the bind profile and testing this to /etc/apparmor.d/usr.sbin.sssd instead? @@ -33,6 +33,7 @@ /var/lib/sss/* rw, /var/lib/sss/db/* rwk, + /var/lib/sss/mc/initgroups r, /var/lib/sss/pipes/* rw, /var/lib/sss/pipes/private/* rw, /var/lib/sss/pubconf/* rw, @@ -42,6 +43,7 @@ /{,var/}run/sssd.pid rw, profile /usr/lib/@{multiarch}/sssd/* { + /var/lib/sss/pubconf/krb5.include.d/** rw, /var/lib/sss/pubconf/krb5.include.d/ rw, } -- t From prashant at apigee.com Mon Feb 22 06:39:15 2016 From: prashant at apigee.com (Prashant Bapat) Date: Mon, 22 Feb 2016 12:09:15 +0530 Subject: [Freeipa-users] Wildcards in sudo external hostnames In-Reply-To: <20160219160251.GJ3553@hendrix.arn.redhat.com> References: <20160219085844.GI3123@hendrix> <20160219160251.GJ3553@hendrix.arn.redhat.com> Message-ID: SSSD on Amazon linux is a dead end! I have tried since a year without any definitive answer. Any other suggestions ? Thanks. --Prashant On 19 February 2016 at 21:32, Jakub Hrozek wrote: > On Fri, Feb 19, 2016 at 09:10:19PM +0530, Prashant Bapat wrote: > > Not using SSSD because Amazon Linux does not support samba libraries > > required to compile it. > > Time to file a request against Amazon I guess :-) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Mon Feb 22 06:52:53 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 22 Feb 2016 08:52:53 +0200 Subject: [Freeipa-users] Wildcards in sudo external hostnames In-Reply-To: References: <20160219085844.GI3123@hendrix> <20160219160251.GJ3553@hendrix.arn.redhat.com> Message-ID: <20160222065253.GI4492@redhat.com> On Mon, 22 Feb 2016, Prashant Bapat wrote: >SSSD on Amazon linux is a dead end! I have tried since a year without any >definitive answer. > >Any other suggestions ? Switch to CentOS AMIs. -- / Alexander Bokovoy From harald.dunkel at aixigo.de Mon Feb 22 07:14:51 2016 From: harald.dunkel at aixigo.de (Harald Dunkel) Date: Mon, 22 Feb 2016 08:14:51 +0100 Subject: [Freeipa-users] sssd 1.13.3: sss_ssh_knownhostsproxy seems to break ssh -4 In-Reply-To: <20160219150415.GH3553@hendrix.arn.redhat.com> References: <56C712BA.1000008@aixigo.de> <20160219134708.GD2780@mail.corp.redhat.com> <56C72666.6050500@aixigo.de> <20160219150415.GH3553@hendrix.arn.redhat.com> Message-ID: <56CAB56B.4090802@aixigo.de> Hi Jakub, On 02/19/2016 04:04 PM, Jakub Hrozek wrote: > On Fri, Feb 19, 2016 at 03:27:50PM +0100, Harald Dunkel wrote: >> Hi Lukas, >> >> I found an ubuntu manpage saying sss_ssh_knownhostsproxy is >> an experimental feature. >> Would you suggest to drop it >> in ipa-client-install? > > It's not experimental (at least upstream) for several years.. What sssd > version is that? > Just google for sss_ssh_knownhostsproxy; its top of the list: http://manpages.ubuntu.com/manpages/precise/man1/sss_ssh_knownhostsproxy.1.html AFAIK ubuntu uses freeipa 4.1.5 and sssd 1.13.3. Maybe they did not update their man page on the web. I am using sssd 1.13.3 on Debian 8. The local man page does not say "experimental". >> >> IMHO this is a pretty annoying bug. I rely upon a port >> redirection for ssh on IPv4. For IPv6 there is no >> redirection, but the port is blocked in the packet filter. > > Would it help to set lookup_family_order to ipv4_only here so that ipv6 > is not even tried (or the other way around, depending on which AF you > want to try..) > Thats exactly what I was trying to achieve with the "-4". Sorry, but setting it globally conflicts with our efforts to propagate IPv6. I can still manually lookup the IPv4 address as a workaround. Regards Harri From mbabinsk at redhat.com Mon Feb 22 07:16:51 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 22 Feb 2016 08:16:51 +0100 Subject: [Freeipa-users] IPA 4.2.0 httpd errors In-Reply-To: <56C722D0.3020503@umanitoba.ca> References: <56C722D0.3020503@umanitoba.ca> Message-ID: <56CAB5E3.30609@redhat.com> On 02/19/2016 03:12 PM, Daryl Fonseca-Holt wrote: > Hello, > > Doing a bulk load of 150,000+ users to an IPA 4.2.0 server running > RedHat Enterprise Linux 7. > > Running 25 parallel ipa user-add at once, waiting for completion, then > starting another 25, and so on. > > The httpd error_log is filling with many of these messages (457,189 in > four days): > > [Fri Feb 19 07:41:08.100903 2016] [:error] [pid 76505] [remote > 10.0.1.177:40] mod_wsgi (pid=76505): Exception occurred processing WSGI > script '/usr/share/ipa/wsgi.py'. > [Fri Feb 19 07:41:08.100989 2016] [:error] [pid 76505] [remote > 10.0.1.177:40] Traceback (most recent call last): > [Fri Feb 19 07:41:08.101018 2016] [:error] [pid 76505] [remote > 10.0.1.177:40] File "/usr/share/ipa/wsgi.py", line 49, in application > [Fri Feb 19 07:41:08.101073 2016] [:error] [pid 76505] [remote > 10.0.1.177:40] return api.Backend.wsgi_dispatch(environ, > start_response) > [Fri Feb 19 07:41:08.101087 2016] [:error] [pid 76505] [remote > 10.0.1.177:40] File > "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 258, in > __call__ > [Fri Feb 19 07:41:08.101109 2016] [:error] [pid 76505] [remote > 10.0.1.177:40] return self.route(environ, start_response) > [Fri Feb 19 07:41:08.101120 2016] [:error] [pid 76505] [remote > 10.0.1.177:40] File > "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 270, in > route > [Fri Feb 19 07:41:08.101140 2016] [:error] [pid 76505] [remote > 10.0.1.177:40] return app(environ, start_response) > [Fri Feb 19 07:41:08.101152 2016] [:error] [pid 76505] [remote > 10.0.1.177:40] File > "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 447, in > __call__ > [Fri Feb 19 07:41:08.101169 2016] [:error] [pid 76505] [remote > 10.0.1.177:40] response = super(jsonserver, self).__call__(environ, > start_response) > [Fri Feb 19 07:41:08.101180 2016] [:error] [pid 76505] [remote > 10.0.1.177:40] File > "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 647, in > __call__ > [Fri Feb 19 07:41:08.101198 2016] [:error] [pid 76505] [remote > 10.0.1.177:40] 'xmlserver', user_ccache, environ, start_response, > headers) > [Fri Feb 19 07:41:08.101210 2016] [:error] [pid 76505] [remote > 10.0.1.177:40] File > "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 593, in > finalize_kerberos_acquisition > [Fri Feb 19 07:41:08.101229 2016] [:error] [pid 76505] [remote > 10.0.1.177:40] session_data['ccache_data'] = > load_ccache_data(ccache_name) > [Fri Feb 19 07:41:08.101240 2016] [:error] [pid 76505] [remote > 10.0.1.177:40] File > "/usr/lib/python2.7/site-packages/ipalib/session.py", line 1231, in > load_ccache_data > [Fri Feb 19 07:41:08.101259 2016] [:error] [pid 76505] [remote > 10.0.1.177:40] src = open(name) > [Fri Feb 19 07:41:08.101294 2016] [:error] [pid 76505] [remote > 10.0.1.177:40] IOError: [Errno 2] No such file or directory: > '/var/run/httpd/ipa/clientcaches/admin at UOFMT1' > [Fri Feb 19 07:41:09.788839 2016] [auth_gssapi:error] [pid 75336] > [client 10.0.1.177:42610] failed to store delegated creds: [Unspecified > GSS failure. Minor code may provide more information (Internal > credentials cache error)], referer: https://mork.cc.umanitoba.ca/ipa/xml > [Fri Feb 19 07:41:09.788844 2016] [auth_gssapi:error] [pid 78642] > [client 10.0.1.177:42621] failed to store delegated creds: [Unspecified > GSS failure. Minor code may provide more information (Internal > credentials cache error)], referer: https://mork.cc.umanitoba.ca/ipa/xml > [Fri Feb 19 07:41:09.788961 2016] [auth_gssapi:error] [pid 78643] > [client 10.0.1.177:42613] failed to store delegated creds: [Unspecified > GSS failure. Minor code may provide more information (Internal > credentials cache error)], referer: https://mork.cc.umanitoba.ca/ipa/xml > [Fri Feb 19 07:41:09.789154 2016] [auth_gssapi:error] [pid 77367] > [client 10.0.1.177:42615] KRB5CCNAME file > (/var/run/httpd/ipa/clientcaches/admin at UOFMT1) lookup failed!, referer: > https://mork.cc.umanitoba.ca/ipa/xml > > > When the batches are first started there are no errors. > Started batch script at 11:34:54. First error at 12:17:31 after 48 > batches of 25 users. > > The 25 users are each added concurrently by separate processes using ipa > user-add ... > When the script gets the authentication error it simply retries the > user-add so the user are added anyway. > > I think there was a similiar incident, Subject: Client-Install failures > in January 2016 but the thread seemed to fade away without an answer > AFAICT. > > Thanks, Daryl > Hi Daryl, it looks like you ran into https://fedorahosted.org/freeipa/ticket/5653 -- Martin^3 Babinsky From filip at pytloun.cz Mon Feb 22 08:00:52 2016 From: filip at pytloun.cz (Filip Pytloun) Date: Mon, 22 Feb 2016 09:00:52 +0100 Subject: [Freeipa-users] [freeipa-users] Configuring Automount on Ubuntu Clients In-Reply-To: <56CA9872.6030608@ubuntu.com> References: <56B8BAB4.2080007@ubuntu.com> <20160214071417.GA6343@eru> <56CA9872.6030608@ubuntu.com> Message-ID: <20160222080052.GB17882@eru> My change was already applied in bind9 (1:9.10.3.dfsg.P2-4) experimental; urgency=medium I don't know if it could be shipped by sssd package as the policy is for usr.bin.named binary. On 2016/02/22 07:11, Timo Aaltonen wrote: > 14.02.2016, 09:14, Filip Pytloun kirjoitti: > > Hello, > > > > we are using Ubuntu 14.04 on FreeIPA clients and Ubuntu 16.04 on FreeIPA > > server for 2 months with no critical issues. > > > > Using newer freeipa-client was not needed, only sssd update from here, > > because trusty version is buggy: > > https://launchpad.net/~sssd/+archive/ubuntu/updates?field.series_filter=trusty > > > > On server side, it was only needed to fix apparmor policy for bind to > > fix FreeIPA DNS zones: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814314 > > /var/lib/sss* bits belong to the apparmor profile shipped by sssd.. > mind removing them from the bind profile and testing this to > /etc/apparmor.d/usr.sbin.sssd instead? > > @@ -33,6 +33,7 @@ > > /var/lib/sss/* rw, > /var/lib/sss/db/* rwk, > + /var/lib/sss/mc/initgroups r, > /var/lib/sss/pipes/* rw, > /var/lib/sss/pipes/private/* rw, > /var/lib/sss/pubconf/* rw, > @@ -42,6 +43,7 @@ > /{,var/}run/sssd.pid rw, > > profile /usr/lib/@{multiarch}/sssd/* { > + /var/lib/sss/pubconf/krb5.include.d/** rw, > /var/lib/sss/pubconf/krb5.include.d/ rw, > } > > > > -- > t -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From tjaalton at ubuntu.com Mon Feb 22 08:03:02 2016 From: tjaalton at ubuntu.com (Timo Aaltonen) Date: Mon, 22 Feb 2016 10:03:02 +0200 Subject: [Freeipa-users] [freeipa-users] Configuring Automount on Ubuntu Clients In-Reply-To: <20160222080052.GB17882@eru> References: <56B8BAB4.2080007@ubuntu.com> <20160214071417.GA6343@eru> <56CA9872.6030608@ubuntu.com> <20160222080052.GB17882@eru> Message-ID: <56CAC0B6.1040609@ubuntu.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 22.02.2016, 10:00, Filip Pytloun kirjoitti: > My change was already applied in bind9 (1:9.10.3.dfsg.P2-4) > experimental; urgency=medium > > I don't know if it could be shipped by sssd package as the policy > is for usr.bin.named binary. oh right, good point :) I guess these rules should still get added to usr.sbin.sssd so I'll apply them. - -- t -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWysC2AAoJEMtwMWWoiYTcuOMQAJqB2A0xzUyar/AiBR2PEoON EeJEfF6m06vnpU7Vj1f4RfaBv5pcC/OxtHTStfbwc7pV+kgcX7tXe4B7LqaSt+fB bBTdr6Sef2VDzNZTM9kzetYd0vNzpSTTL9uwQ8qvlyigQ+PmFlkAD4sLhuMEGRBc Q+Dr71NtSNYCKlQrQYcK4X2HbIFIK4KlHIfHHbBAgdbOj563QyJSnSXNFtZ2BoGC b3M6hYEFm0Rml4o2Oo+zhbaEl0phLbdhcfwfC9JkZgYNMCtsKBhJce4kZH/s3LQt 4g8Xbz/dr05W02amQJ+Qj0BmM5I6NlXJZPpPojD90el86bP4O8dJGcxiqJIrvfDv RZKvWzyxk/C+IrL8dkjVF0kZFuZ/8plfRAMpqJkvAOZTDLpE27O+E5DMnZL0q9Ok zOQjZvjHup1VBTKF0G59qkDJO/f09oruLx2lspPSEjFOmyaZE8zw1rr458HE9UsC StUC4YlDyp1mFo8H7i0C2Xmr236utccaIplaawq4OhdGKojMJQDVjgAdbt08lbDn VVvf2Z8X2Fu3l5WLQpHOUsZFoNCQ+sG2lGeVdYiPdH3JHPt1WnvreM5kKf01VMj6 gvSwQXP8XloBY7Vx4qEDhk+xXE9+WCIo+lfW7Du20ggJm9pjwLwV9TYb4SoUuHPp QBUu0inQi5TLe0pfEGhQ =s2YH -----END PGP SIGNATURE----- From wdh at dds.nl Mon Feb 22 08:36:21 2016 From: wdh at dds.nl (Winfried de Heiden) Date: Mon, 22 Feb 2016 09:36:21 +0100 Subject: [Freeipa-users] could not get zone keys for secure dynamic update Message-ID: <56CAC885.4020609@dds.nl> An HTML attachment was scrubbed... URL: From prashant at apigee.com Mon Feb 22 09:08:09 2016 From: prashant at apigee.com (Prashant Bapat) Date: Mon, 22 Feb 2016 14:38:09 +0530 Subject: [Freeipa-users] Wildcards in sudo external hostnames In-Reply-To: <20160222065253.GI4492@redhat.com> References: <20160219085844.GI3123@hendrix> <20160219160251.GJ3553@hendrix.arn.redhat.com> <20160222065253.GI4492@redhat.com> Message-ID: Sorry not an option. I have couple of 1000s of instances. Aside from switching OS is there any other option? I mean "*" char is allowed in standard sudo implementation. To me it seems like there should not be a host name check on sudo hosts. On 22 February 2016 at 12:22, Alexander Bokovoy wrote: > On Mon, 22 Feb 2016, Prashant Bapat wrote: > >> SSSD on Amazon linux is a dead end! I have tried since a year without any >> definitive answer. >> >> Any other suggestions ? >> > Switch to CentOS AMIs. > > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Mon Feb 22 10:05:27 2016 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 22 Feb 2016 11:05:27 +0100 Subject: [Freeipa-users] DNS operation timed out when installing IPA with forwarders In-Reply-To: <56C72213.4090802@redhat.com> References: <986ED6C5BA6EFD49B00A4CEABE2E8FDA276AC4D5@HICTATRIUEM023.msnet.railb.be> <56C71189.3020303@redhat.com> <986ED6C5BA6EFD49B00A4CEABE2E8FDA276AC589@HICTATRIUEM023.msnet.railb.be> <56C72213.4090802@redhat.com> Message-ID: <56CADD67.8060606@redhat.com> On 19.2.2016 15:09, Martin Basti wrote: > On 19.02.2016 14:57, Geselle Stijn wrote: >> That seems to fail: >> >> [root at ipa ~]# dig @192.168.1.1 . SOA >> >> ; <<>> DiG 9.9.4-RedHat-9.9.4-29.el7_2.2 <<>> @192.168.1.1 . SOA ; (1 server >> found) ;; global options: +cmd ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 44900 ;; flags: qr rd >> ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 >> >> ;; OPT PSEUDOSECTION: >> ; EDNS: version: 0, flags:; udp: 4000 >> ;; QUESTION SECTION: >> ;. IN SOA >> >> ;; Query time: 11153 msec >> ;; SERVER: 192.168.1.1#53(192.168.1.1) >> ;; WHEN: Fri Feb 19 14:42:51 CET 2016 >> ;; MSG SIZE rcvd: 28 >> >> >> But if I add a new record (e.g. CNAME) to DNS in Windows Server and try to >> ping to that CNAME, I get resolved correctly. >> >> -Stijn > Hello, > > global forwarders, specified by --forwarder option during installation or > added via ipa dnsconfig-mod, must be able to resolve root zone (your > forwarder/server 192.168.1.1 is not able to return result for root zone). > > You probably need to specify forwardzone, for the particular windows domain > you use, instead of specify it as global forwarder. > > ipa dnsforwardzone-add --forwarder 192.168.1.1 Martin could be right, but this depends on your setup. Please read chapter "Managing DNS Forwarding" in our docs: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/managing-dns-forwarding.html It explains the difference between global and per-zone forwarding (I hope :-) so it will be easier to decide what should be used. BTW does the command $ dig @192.168.1.1 www.google.com. SOA work? (Assuming that neither google.com. nor com. are your AD domains :-)) Petr^2 Spacek >> -----Original Message----- >> From: freeipa-users-bounces at redhat.com >> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Petr Spacek >> Sent: Friday 19 February 2016 13:59 >> To: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] DNS operation timed out when installing IPA >> with forwarders >> >> On 19.2.2016 13:50, Geselle Stijn wrote: >>> Hello fellow FreeIPA users, >>> >>> I'm trying to setup FreeIPA in a lab environment (VirtualBox): >>> >>> >>> - ad.example.com (Windows Server 2008 R2) - 192.168.1.1 >>> >>> - ipa.example.com (CentOS 7.2) - 192.168.1.2 >>> Both machines can ping each other, DNS resolving works: >>> >>> [root at ipa ~] nslookup ad >>> Server: 192.168.1.1 >>> Address: 192.168.1.1#53 >>> >>> Name: ad.example.com >>> Address: 192.168.1.1 >>> >>> >>> I executed: >>> >>> yum install -y "*ipa-server*" bind bind-dyndb-ldap ipa-server-install >>> --domain=example.com --realm=EXAMPLE.COM --setup-dns >>> --forwarder=192.168.1.1 >>> >>> But the installation wizard fails at: >>> >>> Checking DNS forwarders, please wait ... >>> ipa : ERROR DNS server 192.168.1.1: query '. SOA': The DNS >>> operation timed out after 10.00124242 seconds >>> ipa.ipapython.install.cli.install_tool(Server): ERROR DNS server >>> 192.168.1.1: query '. SOA': The DNS operation timed out after 10.00124242 >>> seconds >>> >>> >>> Is there some way I can better troubleshoot this? Can I increase the DNS >>> timeout (maybe it's simply slow via VirtualBox). >> Please try command >> $ dig @192.168.1.1 . SOA >> and paste the output here. >> >> Also, please run the installer again with option --debug. >> >> I will have a look. >> >> Thank you. >> >> -- >> Petr^2 Spacek From pspacek at redhat.com Mon Feb 22 10:10:42 2016 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 22 Feb 2016 11:10:42 +0100 Subject: [Freeipa-users] could not get zone keys for secure dynamic update In-Reply-To: <56CAC885.4020609@dds.nl> References: <56CAC885.4020609@dds.nl> Message-ID: <56CADEA2.80301@redhat.com> On 22.2.2016 09:36, Winfried de Heiden wrote: > Hi all, > > I get lot's of messages in my log (journalctl -u named-pkcs11.service -p err ) > like these: > > Feb 22 09:17:32 ipa.example.com named-pkcs11[8982]: zone example.com/IN > (signed): could not get zone keys for secure dynamic update > Feb 22 09:17:32 ipa.example.com named-pkcs11[8982]: zone example.com/IN > (signed): receive_secure_serial: not found > Feb 22 09:19:06 ipa.example.com named-pkcs11[8982]: zone example.com/IN > (signed): could not get zone keys for secure dynamic update > Feb 22 09:19:06 ipa.example.com named-pkcs11[8982]: zone example.com/IN > (signed): receive_secure_serial: not found > Feb 22 09:20:06 ipa.example.com named-pkcs11[8982]: zone example.com/IN > (signed): could not get zone keys for secure dynamic update > Feb 22 09:20:06 ipa.example.com named-pkcs11[8982]: zone example.com/IN > (signed): receive_secure_serial: not found > > What's going wrong here, how to fix it? Hello, this might have multiple reasons. Please walk step-by-step through following page: http://www.freeipa.org/page/Troubleshooting#DNSSEC_signing_does_not_work Additional questions: * What version of FreeIPA and on what platform do you use? * Is the zone signed on DNSSEC key master or on replica? Does it work on one FreeIPA server but not on some other server? * Did you change something lately? -- Petr^2 Spacek From abokovoy at redhat.com Mon Feb 22 10:31:29 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 22 Feb 2016 12:31:29 +0200 Subject: [Freeipa-users] Wildcards in sudo external hostnames In-Reply-To: References: <20160219085844.GI3123@hendrix> <20160219160251.GJ3553@hendrix.arn.redhat.com> <20160222065253.GI4492@redhat.com> Message-ID: <20160222103129.GM4492@redhat.com> On Mon, 22 Feb 2016, Prashant Bapat wrote: >Sorry not an option. I have couple of 1000s of instances. Aside from >switching OS is there any other option? I mean "*" char is allowed in >standard sudo implementation. To me it seems like there should not be a >host name check on sudo hosts. sudoers.ldap has a warning that wildcards in sudo entries may not be supported by all LDAP servers. I don't think using wildcards is a good one, from multiple points of view. Applying group checks, with auto-membership plugin on IPA side used to populate the groups is much better maintenance-wise (and security too, if you ask me). > >On 22 February 2016 at 12:22, Alexander Bokovoy wrote: > >> On Mon, 22 Feb 2016, Prashant Bapat wrote: >> >>> SSSD on Amazon linux is a dead end! I have tried since a year without any >>> definitive answer. >>> >>> Any other suggestions ? >>> >> Switch to CentOS AMIs. >> >> -- >> / Alexander Bokovoy >> -- / Alexander Bokovoy From wdh at dds.nl Mon Feb 22 13:02:21 2016 From: wdh at dds.nl (Winfried de Heiden) Date: Mon, 22 Feb 2016 14:02:21 +0100 Subject: [Freeipa-users] could not get zone keys for secure dynamic update In-Reply-To: <56CADEA2.80301@redhat.com> References: <56CAC885.4020609@dds.nl> <56CADEA2.80301@redhat.com> Message-ID: <56CB06DD.7040705@dds.nl> An HTML attachment was scrubbed... URL: From Daryl.Fonseca-Holt at umanitoba.ca Mon Feb 22 13:47:41 2016 From: Daryl.Fonseca-Holt at umanitoba.ca (Daryl Fonseca-Holt) Date: Mon, 22 Feb 2016 07:47:41 -0600 Subject: [Freeipa-users] IPA 4.2.0 httpd errors In-Reply-To: <56CAB5E3.30609@redhat.com> References: <56C722D0.3020503@umanitoba.ca> <56CAB5E3.30609@redhat.com> Message-ID: <56CB117D.7080804@umanitoba.ca> On 02/22/16 01:16, Martin Babinsky wrote: > On 02/19/2016 03:12 PM, Daryl Fonseca-Holt wrote: >> Hello, >> >> Doing a bulk load of 150,000+ users to an IPA 4.2.0 server running >> RedHat Enterprise Linux 7. >> >> Running 25 parallel ipa user-add at once, waiting for completion, then >> starting another 25, and so on. >> >> The httpd error_log is filling with many of these messages (457,189 in >> four days): >> >> [Fri Feb 19 07:41:08.100903 2016] [:error] [pid 76505] [remote >> 10.0.1.177:40] mod_wsgi (pid=76505): Exception occurred processing WSGI >> script '/usr/share/ipa/wsgi.py'. >> [Fri Feb 19 07:41:08.100989 2016] [:error] [pid 76505] [remote >> 10.0.1.177:40] Traceback (most recent call last): >> [Fri Feb 19 07:41:08.101018 2016] [:error] [pid 76505] [remote >> 10.0.1.177:40] File "/usr/share/ipa/wsgi.py", line 49, in application >> [Fri Feb 19 07:41:08.101073 2016] [:error] [pid 76505] [remote >> 10.0.1.177:40] return api.Backend.wsgi_dispatch(environ, >> start_response) >> [Fri Feb 19 07:41:08.101087 2016] [:error] [pid 76505] [remote >> 10.0.1.177:40] File >> "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 258, in >> __call__ >> [Fri Feb 19 07:41:08.101109 2016] [:error] [pid 76505] [remote >> 10.0.1.177:40] return self.route(environ, start_response) >> [Fri Feb 19 07:41:08.101120 2016] [:error] [pid 76505] [remote >> 10.0.1.177:40] File >> "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 270, in >> route >> [Fri Feb 19 07:41:08.101140 2016] [:error] [pid 76505] [remote >> 10.0.1.177:40] return app(environ, start_response) >> [Fri Feb 19 07:41:08.101152 2016] [:error] [pid 76505] [remote >> 10.0.1.177:40] File >> "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 447, in >> __call__ >> [Fri Feb 19 07:41:08.101169 2016] [:error] [pid 76505] [remote >> 10.0.1.177:40] response = super(jsonserver, self).__call__(environ, >> start_response) >> [Fri Feb 19 07:41:08.101180 2016] [:error] [pid 76505] [remote >> 10.0.1.177:40] File >> "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 647, in >> __call__ >> [Fri Feb 19 07:41:08.101198 2016] [:error] [pid 76505] [remote >> 10.0.1.177:40] 'xmlserver', user_ccache, environ, start_response, >> headers) >> [Fri Feb 19 07:41:08.101210 2016] [:error] [pid 76505] [remote >> 10.0.1.177:40] File >> "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 593, in >> finalize_kerberos_acquisition >> [Fri Feb 19 07:41:08.101229 2016] [:error] [pid 76505] [remote >> 10.0.1.177:40] session_data['ccache_data'] = >> load_ccache_data(ccache_name) >> [Fri Feb 19 07:41:08.101240 2016] [:error] [pid 76505] [remote >> 10.0.1.177:40] File >> "/usr/lib/python2.7/site-packages/ipalib/session.py", line 1231, in >> load_ccache_data >> [Fri Feb 19 07:41:08.101259 2016] [:error] [pid 76505] [remote >> 10.0.1.177:40] src = open(name) >> [Fri Feb 19 07:41:08.101294 2016] [:error] [pid 76505] [remote >> 10.0.1.177:40] IOError: [Errno 2] No such file or directory: >> '/var/run/httpd/ipa/clientcaches/admin at UOFMT1' >> [Fri Feb 19 07:41:09.788839 2016] [auth_gssapi:error] [pid 75336] >> [client 10.0.1.177:42610] failed to store delegated creds: [Unspecified >> GSS failure. Minor code may provide more information (Internal >> credentials cache error)], referer: https://mork.cc.umanitoba.ca/ipa/xml >> [Fri Feb 19 07:41:09.788844 2016] [auth_gssapi:error] [pid 78642] >> [client 10.0.1.177:42621] failed to store delegated creds: [Unspecified >> GSS failure. Minor code may provide more information (Internal >> credentials cache error)], referer: https://mork.cc.umanitoba.ca/ipa/xml >> [Fri Feb 19 07:41:09.788961 2016] [auth_gssapi:error] [pid 78643] >> [client 10.0.1.177:42613] failed to store delegated creds: [Unspecified >> GSS failure. Minor code may provide more information (Internal >> credentials cache error)], referer: https://mork.cc.umanitoba.ca/ipa/xml >> [Fri Feb 19 07:41:09.789154 2016] [auth_gssapi:error] [pid 77367] >> [client 10.0.1.177:42615] KRB5CCNAME file >> (/var/run/httpd/ipa/clientcaches/admin at UOFMT1) lookup failed!, referer: >> https://mork.cc.umanitoba.ca/ipa/xml >> >> >> When the batches are first started there are no errors. >> Started batch script at 11:34:54. First error at 12:17:31 after 48 >> batches of 25 users. >> >> The 25 users are each added concurrently by separate processes using ipa >> user-add ... >> When the script gets the authentication error it simply retries the >> user-add so the user are added anyway. >> >> I think there was a similiar incident, Subject: Client-Install failures >> in January 2016 but the thread seemed to fade away without an answer >> AFAICT. >> >> Thanks, Daryl >> > Hi Daryl, > > it looks like you ran into https://fedorahosted.org/freeipa/ticket/5653 > Hi Martin, Thanks for confirming and updating the ticket. Now I can happily use retry work-around without wondering if I'm doing it wrong! -- -- Daryl Fonseca-Holt IST/CNS/Unix Server Team University of Manitoba 204.480.1079 From harald.dunkel at aixigo.de Mon Feb 22 14:09:51 2016 From: harald.dunkel at aixigo.de (Harald Dunkel) Date: Mon, 22 Feb 2016 15:09:51 +0100 Subject: [Freeipa-users] sssd went away, failed to restart Message-ID: <56CB16AF.9060303@aixigo.de> Hi folks, this morning I recognized that the sssd on our mail server went away (which is fatal). journalctl -u sssd sssd says : Feb 21 18:01:55 srvvm01.example.com sssd[199]: Killing service [example.com], not responding to pings! Feb 21 18:01:55 srvvm01.example.com sssd[199]: Killing service [nss], not responding to pings! Feb 21 18:02:15 srvvm01.example.com sssd[be[215]: Shutting down Feb 21 18:02:15 srvvm01.example.com sssd[152704]: Starting up Feb 21 18:02:17 srvvm01.example.com sssd[be[152709]: Starting up Feb 21 18:02:17 srvvm01.example.com sssd[152710]: Starting up Feb 21 18:02:21 srvvm01.example.com sssd[152711]: Starting up Feb 21 18:02:22 srvvm01.example.com sssd[199]: Exiting the SSSD. Could not restart critical service [nss]. Feb 21 18:02:37 srvvm01.example.com sssd[be[152709]: Shutting down Feb 21 18:02:37 srvvm01.example.com sssd[315]: Shutting down Feb 21 18:02:37 srvvm01.example.com sssd[313]: Shutting down Feb 21 18:02:37 srvvm01.example.com sssd[312]: Shutting down Feb 21 18:02:37 srvvm01.example.com sssd[311]: Shutting down Feb 21 18:02:37 srvvm01.example.com systemd[1]: sssd.service: main process exited, code=exited, status=1/FAILURE Feb 21 18:02:37 srvvm01.example.com systemd[1]: Unit sssd.service entered failed state. What has happened here? This was sssd version 1.12.5. I have upgraded to version 1.13.3-1 this morning. Every helpful comment is highly appreciated. Harri From mkosek at redhat.com Mon Feb 22 14:25:46 2016 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 22 Feb 2016 15:25:46 +0100 Subject: [Freeipa-users] Traceback starting pki-cad - ca.subsystem.certreq missing? In-Reply-To: References: Message-ID: <56CB1A6A.4060206@redhat.com> On 02/20/2016 05:58 PM, Ian Pilcher wrote: > I am running IPA 3.0.0 on CentOS 6 (32-bit x86), and I am getting a > traceback every time pki-cad starts: > > Traceback (most recent call last): > File "/usr/sbin/pki-server", line 89, in > cli.execute(sys.argv) > File "/usr/sbin/pki-server", line 84, in execute > super(PKIServerCLI, self).execute(args) > File "/usr/lib/python2.6/site-packages/pki/cli.py", line 195, in execute > module.execute(module_args) > File "/usr/lib/python2.6/site-packages/pki/server/cli/upgrade.py", line 103, > in execute > scriptlet.execute() > File "/usr/lib/python2.6/site-packages/pki/server/upgrade/__init__.py", line > 50, in execute > cert = self.subsystem.get_system_cert('subsystem') > File "/usr/lib/python2.6/site-packages/pki/server/__init__.py", line 93, in > get_system_cert > cert['request'] = base64.b64decode(self.config['%s.%s.certreq' % > (self.prefix, tag)]) > KeyError: 'ca.subsystem.certreq' > Starting pki-ca: [ OK ] > > As you can see, the daemon does still start successfully, and the > traceback doesn't appear in any of the pki-cad logs. > > It seems that it is looking for a ca.subsystem.certreq entry in > /etc/pki-ca/CS.cfg, and sure enough it isn't there. Nor is it present > in CS.cfg.bak. > > How can I create this entry (or otherwise fix this)? > > Thanks! This looks as something PKI specific (given it is in /usr/sbin/pki-server), CCing Endi from Dogtag team. From ellertalexandre at gmail.com Mon Feb 22 14:34:52 2016 From: ellertalexandre at gmail.com (Alexandre Ellert) Date: Mon, 22 Feb 2016 15:34:52 +0100 Subject: [Freeipa-users] Duplicate sudo rule Message-ID: Hello, I've just deployed a new IPA server 4.2 / Centos 7.2 and I create my first sudo rule via web UI but it was duplicate (I don't know why...) Now I have two rules with the same name and I can't delete them : # ipa sudorule-find --all -------------------- 2 Sudo Rules matched -------------------- dn: ipaUniqueID=faa8de54-d96d-11e5-b75f-00505693334c,cn=sudorules,cn=sudo,dc=numeezy,dc=intra Rule name: allow sysadmins everywher Enabled: TRUE ipauniqueid: faa8de54-d96d-11e5-b75f-00505693334c objectclass: ipasudorule, ipaassociation dn: ipaUniqueID=faac52c8-d96d-11e5-b61d-00505693334c,cn=sudorules,cn=sudo,dc=numeezy,dc=intra Rule name: allow sysadmins everywher Enabled: TRUE ipauniqueid: faac52c8-d96d-11e5-b61d-00505693334c objectclass: ipasudorule, ipaassociation ---------------------------- Number of entries returned 2 ---------------------------- # ipa sudorule-del "allow sysadmins everywher" ipa: ERROR: The search criteria was not specific enough. Expected 1 and found 2. Thanks for your help. Alexandre From jhrozek at redhat.com Mon Feb 22 14:51:52 2016 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 22 Feb 2016 15:51:52 +0100 Subject: [Freeipa-users] sssd went away, failed to restart In-Reply-To: <56CB16AF.9060303@aixigo.de> References: <56CB16AF.9060303@aixigo.de> Message-ID: <20160222145152.GB3321@hendrix.arn.redhat.com> On Mon, Feb 22, 2016 at 03:09:51PM +0100, Harald Dunkel wrote: > Hi folks, > > this morning I recognized that the sssd on our mail server > went away (which is fatal). journalctl -u sssd sssd says > > : > Feb 21 18:01:55 srvvm01.example.com sssd[199]: Killing service [example.com], not responding to pings! > Feb 21 18:01:55 srvvm01.example.com sssd[199]: Killing service [nss], not responding to pings! > Feb 21 18:02:15 srvvm01.example.com sssd[be[215]: Shutting down > Feb 21 18:02:15 srvvm01.example.com sssd[152704]: Starting up > Feb 21 18:02:17 srvvm01.example.com sssd[be[152709]: Starting up > Feb 21 18:02:17 srvvm01.example.com sssd[152710]: Starting up > Feb 21 18:02:21 srvvm01.example.com sssd[152711]: Starting up > Feb 21 18:02:22 srvvm01.example.com sssd[199]: Exiting the SSSD. Could not restart critical service [nss]. > Feb 21 18:02:37 srvvm01.example.com sssd[be[152709]: Shutting down > Feb 21 18:02:37 srvvm01.example.com sssd[315]: Shutting down > Feb 21 18:02:37 srvvm01.example.com sssd[313]: Shutting down > Feb 21 18:02:37 srvvm01.example.com sssd[312]: Shutting down > Feb 21 18:02:37 srvvm01.example.com sssd[311]: Shutting down > Feb 21 18:02:37 srvvm01.example.com systemd[1]: sssd.service: main process exited, code=exited, status=1/FAILURE > Feb 21 18:02:37 srvvm01.example.com systemd[1]: Unit sssd.service entered failed state. > > What has happened here? > > This was sssd version 1.12.5. I have upgraded to version 1.13.3-1 > this morning. Is there anything else in the logs (/var/log/sssd/*) Do you run with enumeration enabled? From ellertalexandre at gmail.com Mon Feb 22 14:55:00 2016 From: ellertalexandre at gmail.com (Alexandre Ellert) Date: Mon, 22 Feb 2016 15:55:00 +0100 Subject: [Freeipa-users] Duplicate sudo rule In-Reply-To: References: Message-ID: I create another rule via web UI and it's fine now...don't remember why the first one was duplicated. Is it safe to delete these entries directly from LDAP ? : ipaUniqueID=faac52c8-d96d-11e5-b61d-00505693334c,cn=sudorules,cn=sudo,dc=xxx,dc=xxx and ipaUniqueID=faa8de54-d96d-11e5-b75f-00505693334c,cn=sudorules,cn=sudo,dc=xxx,dc=xxx 2016-02-22 15:34 GMT+01:00 Alexandre Ellert : > Hello, > > I've just deployed a new IPA server 4.2 / Centos 7.2 and I create my > first sudo rule via web UI but it was duplicate (I don't know why...) > Now I have two rules with the same name and I can't delete them : > > # ipa sudorule-find --all > -------------------- > 2 Sudo Rules matched > -------------------- > dn: ipaUniqueID=faa8de54-d96d-11e5-b75f-00505693334c,cn=sudorules,cn=sudo,dc=numeezy,dc=intra > Rule name: allow sysadmins everywher > Enabled: TRUE > ipauniqueid: faa8de54-d96d-11e5-b75f-00505693334c > objectclass: ipasudorule, ipaassociation > > dn: ipaUniqueID=faac52c8-d96d-11e5-b61d-00505693334c,cn=sudorules,cn=sudo,dc=numeezy,dc=intra > Rule name: allow sysadmins everywher > Enabled: TRUE > ipauniqueid: faac52c8-d96d-11e5-b61d-00505693334c > objectclass: ipasudorule, ipaassociation > ---------------------------- > Number of entries returned 2 > ---------------------------- > > # ipa sudorule-del "allow sysadmins everywher" > ipa: ERROR: The search criteria was not specific enough. Expected 1 and found 2. > > Thanks for your help. > > Alexandre From lkrispen at redhat.com Mon Feb 22 15:21:35 2016 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Mon, 22 Feb 2016 16:21:35 +0100 Subject: [Freeipa-users] IPA 4.2: pki-tomcatd in terrible shape In-Reply-To: <1455951442.25282.2.camel@accertify.com> References: <56B86DE0.4070909@redhat.com> <7F0EB8FC-8F2F-49D1-A124-562B5B0A55A2@accertify.com> <56B9AA53.1000400@redhat.com> <56BAFC6E.6030605@redhat.com> <56BE04AD.2020700@redhat.com> <1455951442.25282.2.camel@accertify.com> Message-ID: <56CB277F.2000309@redhat.com> The crash is an abort because of a failed assertion in the kerberos code Thread 1 (Thread 0x7fa7d4c88700 (LWP 3125)): #0 0x00007fa7e6ace5f7 in raise () from /lib64/libc.so.6 No symbol table info available. #1 0x00007fa7e6acfce8 in abort () from /lib64/libc.so.6 No symbol table info available. #2 0x00007fa7e6ac7566 in __assert_fail_base () from /lib64/libc.so.6 No symbol table info available. #3 0x00007fa7e6ac7612 in __assert_fail () from /lib64/libc.so.6 No symbol table info available. #4 0x00007fa7e8d71b83 in k5_mutex_lock.part.1 () from /lib64/libkrb5.so.3 No symbol table info available. #5 0x00007fa7e8d7bda1 in k5_cc_mutex_lock () from /lib64/libkrb5.so.3 No symbol table info available. #6 0x00007fa7e8d851bf in krb5_mcc_store () from /lib64/libkrb5.so.3 No symbol table info available. #7 0x00007fa7e8d88070 in krb5_cc_store_cred () from /lib64/libkrb5.so.3 No symbol table info available. #8 0x00007fa7e8d98be3 in complete () from /lib64/libkrb5.so.3 No symbol table info available. #9 0x00007fa7e8d99ba1 in krb5_tkt_creds_step () from /lib64/libkrb5.so.3 No symbol table info available. #10 0x00007fa7e8d9a637 in krb5_tkt_creds_get () from /lib64/libkrb5.so.3 No symbol table info available. #11 0x00007fa7e8d9a75c in krb5_get_credentials () from /lib64/libkrb5.so.3 No symbol table info available. #12 0x00007fa7e0f6736a in krb5_gss_init_sec_context_ext () from /lib64/libgssapi_krb5.so.2 No symbol table info available. #13 0x00007fa7e0f67c97 in krb5_gss_init_sec_context () from /lib64/libgssapi_krb5.so.2 No symbol table info available. #14 0x00007fa7e0f516ab in gss_init_sec_context () from /lib64/libgssapi_krb5.so.2 No symbol table info available. #15 0x00007fa7e118ac44 in gssapi_client_mech_step () from /usr/lib64/sasl2/libgssapiv2.so No symbol table info available. #16 0x00007fa7e72847f5 in sasl_client_step () from /lib64/libsasl2.so.3 No symbol table info available. #17 0x00007fa7e7284b76 in sasl_client_start () from /lib64/libsasl2.so.3 No symbol table info available. #18 0x00007fa7e8475e73 in ldap_int_sasl_bind () from /lib64/libldap_r-2.4.so.2 No symbol table info available. #19 0x00007fa7e8479492 in ldap_sasl_interactive_bind () from /lib64/libldap_r-2.4.so.2 No symbol table info available. #20 0x00007fa7e84796bd in ldap_sasl_interactive_bind_s () from /lib64/libldap_r-2.4.so.2 Directory server tries to open a replication connetion usig GSSAPI. I don't know which assertion fails in krb, but - could you try with the replication agreement disabled ? - Rob, you have been discussing renewals of keytabs, would we have to renew the ds.keytab ? On 02/20/2016 07:57 AM, Timothy Geier wrote: > To update this thread..timeshifting to before the certs expired (Feb. > 2) brings up the interesting issue of pki-tomcatd (sometimes) starting > while slapd crashes almost immediately after ipactl start is run..if it > doesn't crash right away, pki-tomcatd will start, but since slapd will > then go down right afterwards, the certs cannot be renewed. After > returning to real time, slapd is just fine along with everything else > aside from pki-tomcatd. > > A core dump is attached. > > > "This message and any attachments may contain confidential information. If you > have received this message in error, any use or distribution is prohibited. > Please notify us by reply e-mail if you have mistakenly received this message, > and immediately and permanently delete it and any attachments. Thank you." > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Mon Feb 22 15:31:52 2016 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 22 Feb 2016 16:31:52 +0100 Subject: [Freeipa-users] could not get zone keys for secure dynamic update In-Reply-To: <56CB06DD.7040705@dds.nl> References: <56CAC885.4020609@dds.nl> <56CADEA2.80301@redhat.com> <56CB06DD.7040705@dds.nl> Message-ID: <56CB29E8.8020502@redhat.com> On 22.2.2016 14:02, Winfried de Heiden wrote: > Hi all, > > Following > http://www.freeipa.org/page/Troubleshooting#DNSSEC_signing_does_not_work was > most usefull, It turned out the package "freeipa-server-dns"was missing. > Strange, I am running DNS, but...: > > * I upgraded form Fedora 22 to 23 includng upgrading from IPA 4.1 to 4.2. > * Also: I'm running this on a Bananapi "server"..... > * There's no slave. > > > Anyway, ipa dnszone-show tells DNSsec was ebabled: > > > Allow in-line DNSSEC signing: TRUE > > but most likely due to the missing freeipa-server-dns it was missing > dependencies as well, for example the package opendnssec was missing. > > After installing freeipa-server-dns all packages seems to be in place, but the > kasp.db file is empty: > > root at ipa ~]# ls -l /var/opendnssec/kasp.db > -rw-rw----. 1 ods ods 0 Feb 22 11:29 /var/opendnssec/kasp.db > > No wonder I still get messages like "could not get zone keys". > > Shouldn't a key be added? How? (without blowing the current DNS....) DNSSEC key master should do that automatically. Please continue with next steps as described on http://www.freeipa.org/page/Troubleshooting#DNSSEC_master_is_not_configured and we will see. Petr^2 Spacek > > Winny > > > Op 22-02-16 om 11:10 schreef Petr Spaceopendnssec >> On 22.2.2016 09:36, Winfried de Heiden wrote: >>> Hi all, >>> >>> I get lot's of messages in my log (journalctl -u named-pkcs11.service -p err ) >>> like these: >>> >>> Feb 22 09:17:32 ipa.example.com named-pkcs11[8982]: zone example.com/IN >>> (signed): could not get zone keys for secure dynamic update >>> Feb 22 09:17:32 ipa.example.com named-pkcs11[8982]: zone example.com/IN >>> (signed): receive_secure_serial: not found >>> Feb 22 09:19:06 ipa.example.com named-pkcs11[8982]: zone example.com/IN >>> (signed): could not get zone keys for secure dynamic update >>> Feb 22 09:19:06 ipa.example.com named-pkcs11[8982]: zone example.com/IN >>> (signed): receive_secure_serial: not found >>> Feb 22 09:20:06 ipa.example.com named-pkcs11[8982]: zone example.com/IN >>> (signed): could not get zone keys for secure dynamic update >>> Feb 22 09:20:06 ipa.example.com named-pkcs11[8982]: zone example.com/IN >>> (signed): receive_secure_serial: not found >>> >>> What's going wrong here, how to fix it? >> Hello, >> >> this might have multiple reasons. >> >> Please walk step-by-step through following page: >> http://www.freeipa.org/page/Troubleshooting#DNSSEC_signing_does_not_work >> >> Additional questions: >> * What version of FreeIPA and on what platform do you use? >> * Is the zone signed on DNSSEC key master or on replica? Does it work on one >> FreeIPA server but not on some other server? >> * Did you change something lately? From michael.rainey.ctr at nrlssc.navy.mil Mon Feb 22 16:03:37 2016 From: michael.rainey.ctr at nrlssc.navy.mil (Michael Rainey (Contractor)) Date: Mon, 22 Feb 2016 10:03:37 -0600 Subject: [Freeipa-users] Smart Card Login on Fedora 23. Message-ID: Greetings, I have a question about using smart card authentication on Fedora 23. We have worked out a procedure for setting up smart card login on our SL7.2 systems and it seems to be working very well. However, when trying to use the same process on a Fedora 23 system the process starts to fall apart. On SL7.2, smart card login on GDM needs to disabled so SSSD can do its job of authenticating. Does the same option need to be disabled for SSSD perform the smart card login on Fedora 23? Are there any other details that may vary from the RHEL7.2 release? -- *Michael Rainey* -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbose at redhat.com Mon Feb 22 16:17:52 2016 From: sbose at redhat.com (Sumit Bose) Date: Mon, 22 Feb 2016 17:17:52 +0100 Subject: [Freeipa-users] Smart Card Login on Fedora 23. In-Reply-To: References: Message-ID: <20160222161752.GE7535@p.redhat.com> On Mon, Feb 22, 2016 at 10:03:37AM -0600, Michael Rainey (Contractor) wrote: > Greetings, > > I have a question about using smart card authentication on Fedora 23. We > have worked out a procedure for setting up smart card login on our SL7.2 > systems and it seems to be working very well. However, when trying to use > the same process on a Fedora 23 system the process starts to fall apart. On > SL7.2, smart card login on GDM needs to disabled so SSSD can do its job of > authenticating. Does the same option need to be disabled for SSSD perform > the smart card login on Fedora 23? Are there any other details that may > vary from the RHEL7.2 release? yes, smart card login on GDM needs to disabled as well. Additionally please check if you PAM configuration in /etc/pam.d/password-auth and /etc/pam.d/system-auth contain ... auth [default=1 success=ok] pam_localuser.so auth [success=done ignore=ignore default=die] pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 1000 quiet_success auth sufficient pam_sss.so forward_pass ... If not, running 'authconfig --updateall' might help. HTH bye, Sumit > -- > *Michael Rainey* > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project From mbasti at redhat.com Mon Feb 22 17:01:03 2016 From: mbasti at redhat.com (Martin Basti) Date: Mon, 22 Feb 2016 18:01:03 +0100 Subject: [Freeipa-users] Duplicate sudo rule In-Reply-To: References: Message-ID: <56CB3ECF.2050607@redhat.com> On 22.02.2016 15:55, Alexandre Ellert wrote: > I create another rule via web UI and it's fine now...don't remember > why the first one was duplicated. > Is it safe to delete these entries directly from LDAP ? : > ipaUniqueID=faac52c8-d96d-11e5-b61d-00505693334c,cn=sudorules,cn=sudo,dc=xxx,dc=xxx > and > ipaUniqueID=faa8de54-d96d-11e5-b75f-00505693334c,cn=sudorules,cn=sudo,dc=xxx,dc=xxx Hello, yes, it is safe to remove it by ldapdelete Martin > > 2016-02-22 15:34 GMT+01:00 Alexandre Ellert : >> Hello, >> >> I've just deployed a new IPA server 4.2 / Centos 7.2 and I create my >> first sudo rule via web UI but it was duplicate (I don't know why...) >> Now I have two rules with the same name and I can't delete them : >> >> # ipa sudorule-find --all >> -------------------- >> 2 Sudo Rules matched >> -------------------- >> dn: ipaUniqueID=faa8de54-d96d-11e5-b75f-00505693334c,cn=sudorules,cn=sudo,dc=numeezy,dc=intra >> Rule name: allow sysadmins everywher >> Enabled: TRUE >> ipauniqueid: faa8de54-d96d-11e5-b75f-00505693334c >> objectclass: ipasudorule, ipaassociation >> >> dn: ipaUniqueID=faac52c8-d96d-11e5-b61d-00505693334c,cn=sudorules,cn=sudo,dc=numeezy,dc=intra >> Rule name: allow sysadmins everywher >> Enabled: TRUE >> ipauniqueid: faac52c8-d96d-11e5-b61d-00505693334c >> objectclass: ipasudorule, ipaassociation >> ---------------------------- >> Number of entries returned 2 >> ---------------------------- >> >> # ipa sudorule-del "allow sysadmins everywher" >> ipa: ERROR: The search criteria was not specific enough. Expected 1 and found 2. >> >> Thanks for your help. >> >> Alexandre From natxo.asenjo at gmail.com Mon Feb 22 17:42:04 2016 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Mon, 22 Feb 2016 18:42:04 +0100 Subject: [Freeipa-users] Traceback starting pki-cad - ca.subsystem.certreq missing? In-Reply-To: References: Message-ID: On Sat, Feb 20, 2016 at 5:58 PM, Ian Pilcher wrote: > I am running IPA 3.0.0 on CentOS 6 (32-bit x86), and I am getting a > traceback every time pki-cad starts: > > Traceback (most recent call last): > File "/usr/sbin/pki-server", line 89, in > cli.execute(sys.argv) > File "/usr/sbin/pki-server", line 84, in execute > super(PKIServerCLI, self).execute(args) > File "/usr/lib/python2.6/site-packages/pki/cli.py", line 195, in execute > module.execute(module_args) > File "/usr/lib/python2.6/site-packages/pki/server/cli/upgrade.py", line > 103, in execute > scriptlet.execute() > File "/usr/lib/python2.6/site-packages/pki/server/upgrade/__init__.py", > line 50, in execute > cert = self.subsystem.get_system_cert('subsystem') > File "/usr/lib/python2.6/site-packages/pki/server/__init__.py", line 93, > in get_system_cert > cert['request'] = base64.b64decode(self.config['%s.%s.certreq' % > (self.prefix, tag)]) > KeyError: 'ca.subsystem.certreq' > Starting pki-ca: [ OK ] > > As you can see, the daemon does still start successfully, and the > traceback doesn't appear in any of the pki-cad logs. > > yes, I see this too after the last round of updates. Curiously enough, just on one of the kdcs, the other does not have this traceback. Both are centos 6.7 fully patched, 32 bits. -- Groeten, natxo -------------- next part -------------- An HTML attachment was scrubbed... URL: From tgeier at accertify.com Mon Feb 22 22:51:20 2016 From: tgeier at accertify.com (Timothy Geier) Date: Mon, 22 Feb 2016 22:51:20 +0000 Subject: [Freeipa-users] IPA 4.2: pki-tomcatd in terrible shape In-Reply-To: <56CB277F.2000309@redhat.com> References: <56B86DE0.4070909@redhat.com> <7F0EB8FC-8F2F-49D1-A124-562B5B0A55A2@accertify.com> <56B9AA53.1000400@redhat.com> <56BAFC6E.6030605@redhat.com> <56BE04AD.2020700@redhat.com> <1455951442.25282.2.camel@accertify.com> <56CB277F.2000309@redhat.com> Message-ID: On Feb 22, 2016, at 9:21 AM, Ludwig Krispenz > wrote: The crash is an abort because of a failed assertion in the kerberos code Thread 1 (Thread 0x7fa7d4c88700 (LWP 3125)): #0 0x00007fa7e6ace5f7 in raise () from /lib64/libc.so.6 No symbol table info available. #1 0x00007fa7e6acfce8 in abort () from /lib64/libc.so.6 No symbol table info available. #2 0x00007fa7e6ac7566 in __assert_fail_base () from /lib64/libc.so.6 No symbol table info available. #3 0x00007fa7e6ac7612 in __assert_fail () from /lib64/libc.so.6 No symbol table info available. #4 0x00007fa7e8d71b83 in k5_mutex_lock.part.1 () from /lib64/libkrb5.so.3 No symbol table info available. #5 0x00007fa7e8d7bda1 in k5_cc_mutex_lock () from /lib64/libkrb5.so.3 No symbol table info available. #6 0x00007fa7e8d851bf in krb5_mcc_store () from /lib64/libkrb5.so.3 No symbol table info available. #7 0x00007fa7e8d88070 in krb5_cc_store_cred () from /lib64/libkrb5.so.3 No symbol table info available. #8 0x00007fa7e8d98be3 in complete () from /lib64/libkrb5.so.3 No symbol table info available. #9 0x00007fa7e8d99ba1 in krb5_tkt_creds_step () from /lib64/libkrb5.so.3 No symbol table info available. #10 0x00007fa7e8d9a637 in krb5_tkt_creds_get () from /lib64/libkrb5.so.3 No symbol table info available. #11 0x00007fa7e8d9a75c in krb5_get_credentials () from /lib64/libkrb5.so.3 No symbol table info available. #12 0x00007fa7e0f6736a in krb5_gss_init_sec_context_ext () from /lib64/libgssapi_krb5.so.2 No symbol table info available. #13 0x00007fa7e0f67c97 in krb5_gss_init_sec_context () from /lib64/libgssapi_krb5.so.2 No symbol table info available. #14 0x00007fa7e0f516ab in gss_init_sec_context () from /lib64/libgssapi_krb5.so.2 No symbol table info available. #15 0x00007fa7e118ac44 in gssapi_client_mech_step () from /usr/lib64/sasl2/libgssapiv2.so No symbol table info available. #16 0x00007fa7e72847f5 in sasl_client_step () from /lib64/libsasl2.so.3 No symbol table info available. #17 0x00007fa7e7284b76 in sasl_client_start () from /lib64/libsasl2.so.3 No symbol table info available. #18 0x00007fa7e8475e73 in ldap_int_sasl_bind () from /lib64/libldap_r-2.4.so.2 No symbol table info available. #19 0x00007fa7e8479492 in ldap_sasl_interactive_bind () from /lib64/libldap_r-2.4.so.2 No symbol table info available. #20 0x00007fa7e84796bd in ldap_sasl_interactive_bind_s () from /lib64/libldap_r-2.4.so.2 Directory server tries to open a replication connetion usig GSSAPI. I don't know which assertion fails in krb, but - could you try with the replication agreement disabled ? - Rob, you have been discussing renewals of keytabs, would we have to renew the ds.keytab ? What?s the established procedure to start a 389 instance without any replication agreements enabled? The only thing that seemed close on google (http://directory.fedoraproject.org/docs/389ds/howto/howto-fix-and-reset-time-skew.html) seems risky and couldn?t be done trivially in a production environment. Thanks, On 02/20/2016 07:57 AM, Timothy Geier wrote: To update this thread..timeshifting to before the certs expired (Feb. 2) brings up the interesting issue of pki-tomcatd (sometimes) starting while slapd crashes almost immediately after ipactl start is run..if it doesn't crash right away, pki-tomcatd will start, but since slapd will then go down right afterwards, the certs cannot be renewed. After returning to real time, slapd is just fine along with everything else aside from pki-tomcatd. A core dump is attached. "This message and any attachments may contain confidential information. If you have received this message in error, any use or distribution is prohibited. Please notify us by reply e-mail if you have mistakenly received this message, and immediately and permanently delete it and any attachments. Thank you." -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project "This message and any attachments may contain confidential information. If you have received this message in error, any use or distribution is prohibited. Please notify us by reply e-mail if you have mistakenly received this message, and immediately and permanently delete it and any attachments. Thank you." -------------- next part -------------- An HTML attachment was scrubbed... URL: From harald.dunkel at aixigo.de Tue Feb 23 07:11:58 2016 From: harald.dunkel at aixigo.de (Harald Dunkel) Date: Tue, 23 Feb 2016 08:11:58 +0100 Subject: [Freeipa-users] sssd went away, failed to restart In-Reply-To: <20160222145152.GB3321@hendrix.arn.redhat.com> References: <56CB16AF.9060303@aixigo.de> <20160222145152.GB3321@hendrix.arn.redhat.com> Message-ID: <56CC063E.7080900@aixigo.de> On 02/22/2016 03:51 PM, Jakub Hrozek wrote: > > Is there anything else in the logs (/var/log/sssd/*) > Only some events after sssd went away: srvvm01:/var/log/sssd# cat sssd.log.1 (Sun Feb 21 18:02:21 2016) [sssd] [monitor_restart_service] (0x0010): Process [nss], definitely stopped! srvvm01:/var/log/sssd# cat sssd_nss.log.1 (Sun Feb 21 18:02:15 2016) [sssd[nss]] [sss_dp_init] (0x0010): Failed to connect to monitor services. (Sun Feb 21 18:02:15 2016) [sssd[nss]] [sss_process_init] (0x0010): fatal error setting up backend connector (Sun Feb 21 18:02:15 2016) [sssd[nss]] [nss_process_init] (0x0010): sss_process_init() failed (Sun Feb 21 18:02:17 2016) [sssd[nss]] [sss_dp_init] (0x0010): Failed to connect to monitor services. (Sun Feb 21 18:02:17 2016) [sssd[nss]] [sss_process_init] (0x0010): fatal error setting up backend connector (Sun Feb 21 18:02:17 2016) [sssd[nss]] [nss_process_init] (0x0010): sss_process_init() failed (Sun Feb 21 18:02:21 2016) [sssd[nss]] [sss_dp_init] (0x0010): Failed to connect to monitor services. (Sun Feb 21 18:02:21 2016) [sssd[nss]] [sss_process_init] (0x0010): fatal error setting up backend connector (Sun Feb 21 18:02:21 2016) [sssd[nss]] [nss_process_init] (0x0010): sss_process_init() failed srvvm01:/var/log/sssd# cat sssd_pac.log.1 (Sun Feb 21 18:02:31 2016) [sssd[pac]] [pac_dp_reconnect_init] (0x0010): Could not reconnect to example.com provider. > Do you run with enumeration enabled? > Nope. sssd.conf (as generated by ipa-client-install): [domain/example.com] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = example.com id_provider = ipa auth_provider = ipa access_provider = ipa ldap_tls_cacert = /etc/ipa/ca.crt ipa_hostname = srvvm01.example.com chpass_provider = ipa ipa_server = _srv_, ipa2.example.com dns_discovery_domain = example.com [sssd] services = nss, sudo, pam, ssh config_file_version = 2 domains = example.com [nss] homedir_substring = /home [pam] [sudo] [autofs] [ssh] [pac] [ifp] I have to mention that I missed to add ipa2.example.com to the local /etc/hosts. This is fixed now. sssd.conf says now : ipa_server = _srv_, ipa2.example.com, ipa1.example.com : Would you recommend to enable enumeration? Regards Harri From jhrozek at redhat.com Tue Feb 23 09:00:03 2016 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 23 Feb 2016 10:00:03 +0100 Subject: [Freeipa-users] sssd went away, failed to restart In-Reply-To: <56CC063E.7080900@aixigo.de> References: <56CB16AF.9060303@aixigo.de> <20160222145152.GB3321@hendrix.arn.redhat.com> <56CC063E.7080900@aixigo.de> Message-ID: <20160223090003.GA3131@hendrix.redhat.com> On Tue, Feb 23, 2016 at 08:11:58AM +0100, Harald Dunkel wrote: > On 02/22/2016 03:51 PM, Jakub Hrozek wrote: > > > > Is there anything else in the logs (/var/log/sssd/*) > > > > Only some events after sssd went away: > > srvvm01:/var/log/sssd# cat sssd.log.1 > (Sun Feb 21 18:02:21 2016) [sssd] [monitor_restart_service] (0x0010): Process [nss], definitely stopped! > > srvvm01:/var/log/sssd# cat sssd_nss.log.1 > (Sun Feb 21 18:02:15 2016) [sssd[nss]] [sss_dp_init] (0x0010): Failed to connect to monitor services. > (Sun Feb 21 18:02:15 2016) [sssd[nss]] [sss_process_init] (0x0010): fatal error setting up backend connector > (Sun Feb 21 18:02:15 2016) [sssd[nss]] [nss_process_init] (0x0010): sss_process_init() failed > (Sun Feb 21 18:02:17 2016) [sssd[nss]] [sss_dp_init] (0x0010): Failed to connect to monitor services. > (Sun Feb 21 18:02:17 2016) [sssd[nss]] [sss_process_init] (0x0010): fatal error setting up backend connector > (Sun Feb 21 18:02:17 2016) [sssd[nss]] [nss_process_init] (0x0010): sss_process_init() failed > (Sun Feb 21 18:02:21 2016) [sssd[nss]] [sss_dp_init] (0x0010): Failed to connect to monitor services. > (Sun Feb 21 18:02:21 2016) [sssd[nss]] [sss_process_init] (0x0010): fatal error setting up backend connector > (Sun Feb 21 18:02:21 2016) [sssd[nss]] [nss_process_init] (0x0010): sss_process_init() failed Then unfortunately I can only suggest to set a more verbose debug_level (maybe coupled with a logrotate settings to avoid flooding your disk with logs) and monitor sssd. Typically, this happens when the machine SSSD is running on is very busy, the sssd_be process is blocked writing some large result from LDAP, the monitor process considers it stuck and kills it. However, we /should/ restart and reconnect the subprocesses. From harald.dunkel at aixigo.de Tue Feb 23 09:15:19 2016 From: harald.dunkel at aixigo.de (Harald Dunkel) Date: Tue, 23 Feb 2016 10:15:19 +0100 Subject: [Freeipa-users] WARNING: Using deny rules is deprecated, the option ipa_hbac_treat_deny_as will be removed in the next upstream version Message-ID: <56CC2327.8040607@aixigo.de> Hi folks, journalctl shows me a bazillion of Logfile entries: Jan 12 20:02:04 host.example.com sssd[be[2362]: WARNING: Using deny rules is deprecated, the option ipa_hbac_treat_deny_as will be removed in the next upstream version This makes about 10% of the whole log. What am I supposed to do to get rid of these messages? Regards Harri From jhrozek at redhat.com Tue Feb 23 09:27:52 2016 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 23 Feb 2016 10:27:52 +0100 Subject: [Freeipa-users] WARNING: Using deny rules is deprecated, the option ipa_hbac_treat_deny_as will be removed in the next upstream version In-Reply-To: <56CC2327.8040607@aixigo.de> References: <56CC2327.8040607@aixigo.de> Message-ID: <20160223092752.GD3131@hendrix.redhat.com> On Tue, Feb 23, 2016 at 10:15:19AM +0100, Harald Dunkel wrote: > Hi folks, > > journalctl shows me a bazillion of Logfile entries: > > Jan 12 20:02:04 host.example.com sssd[be[2362]: WARNING: Using deny rules is deprecated, the option ipa_hbac_treat_deny_as will be removed in the next upstream version > > This makes about 10% of the whole log. > > > What am I supposed to do to get rid of these messages? ipa_hbac_treat_deny_as = ignore should get rid of these (and any deny rules will be ignored as an effect, but with a recent enough IPA server, there's no way to set them either IIRC) From harald.dunkel at aixigo.de Tue Feb 23 09:55:18 2016 From: harald.dunkel at aixigo.de (Harald Dunkel) Date: Tue, 23 Feb 2016 10:55:18 +0100 Subject: [Freeipa-users] sssd went away, failed to restart In-Reply-To: <20160223090003.GA3131@hendrix.redhat.com> References: <56CB16AF.9060303@aixigo.de> <20160222145152.GB3321@hendrix.arn.redhat.com> <56CC063E.7080900@aixigo.de> <20160223090003.GA3131@hendrix.redhat.com> Message-ID: <56CC2C86.8040109@aixigo.de> On 02/23/2016 10:00 AM, Jakub Hrozek wrote: > > Typically, this happens when the machine SSSD is running on is very > busy, the sssd_be process is blocked writing some large result from > LDAP, the monitor process considers it stuck and kills it. However, we > /should/ restart and reconnect the subprocesses. > Shoot the slow horse? Sorry to say, but I doubt that this is a reasonable approach. Can I turn off this feature? I would like to avoid to move my mailhost back to NIS client, but ypbind was never shot. Incoming EMails have been lost. What would you suggest? Regards Harri From lkrispen at redhat.com Tue Feb 23 10:22:56 2016 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Tue, 23 Feb 2016 11:22:56 +0100 Subject: [Freeipa-users] IPA 4.2: pki-tomcatd in terrible shape In-Reply-To: References: <56B86DE0.4070909@redhat.com> <7F0EB8FC-8F2F-49D1-A124-562B5B0A55A2@accertify.com> <56B9AA53.1000400@redhat.com> <56BAFC6E.6030605@redhat.com> <56BE04AD.2020700@redhat.com> <1455951442.25282.2.camel@accertify.com> <56CB277F.2000309@redhat.com> Message-ID: <56CC3300.9060608@redhat.com> On 02/22/2016 11:51 PM, Timothy Geier wrote: > > What?s the established procedure to start a 389 instance without any > replication agreements enabled? The only thing that seemed close on > google > (http://directory.fedoraproject.org/docs/389ds/howto/howto-fix-and-reset-time-skew.html) > seems risky and couldn?t be done > trivially in a production environment. no, this is about how to get out of problems when replication could no longer synchronize its csn time generation, either by too many accumulate time drifts o playing with system time, hope you don't have to go thru this. Enabling disabling a replication agreement can be done by setting the configuration parameter: look for replication agreements (entries with objectclass=nsDS5ReplicationAgreement) and set nsds5ReplicaEnabled: off you can do this with an ldapmodify when the server is running or by editing /etc/dirsrv/slapd-/dse.ldif when teh server is stopped From jhrozek at redhat.com Tue Feb 23 10:57:09 2016 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 23 Feb 2016 11:57:09 +0100 Subject: [Freeipa-users] sssd went away, failed to restart In-Reply-To: <56CC2C86.8040109@aixigo.de> References: <56CB16AF.9060303@aixigo.de> <20160222145152.GB3321@hendrix.arn.redhat.com> <56CC063E.7080900@aixigo.de> <20160223090003.GA3131@hendrix.redhat.com> <56CC2C86.8040109@aixigo.de> Message-ID: <20160223105709.GK3131@hendrix.redhat.com> On Tue, Feb 23, 2016 at 10:55:18AM +0100, Harald Dunkel wrote: > On 02/23/2016 10:00 AM, Jakub Hrozek wrote: > > > > Typically, this happens when the machine SSSD is running on is very > > busy, the sssd_be process is blocked writing some large result from > > LDAP, the monitor process considers it stuck and kills it. However, we > > /should/ restart and reconnect the subprocesses. > > > > Shoot the slow horse? Sorry to say, but I doubt that this is > a reasonable approach. Can I turn off this feature? Well, the debug logs could have some clue, without them, I'm really just guessing. But in general you can increase the 'timeout' option in the [domain] section up from the default '10'. Some users even move their cache to tmpfs. We're also working on performance enhancements for the next version. From lslebodn at redhat.com Tue Feb 23 10:58:25 2016 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Tue, 23 Feb 2016 11:58:25 +0100 Subject: [Freeipa-users] sssd went away, failed to restart In-Reply-To: <56CC2C86.8040109@aixigo.de> References: <56CB16AF.9060303@aixigo.de> <20160222145152.GB3321@hendrix.arn.redhat.com> <56CC063E.7080900@aixigo.de> <20160223090003.GA3131@hendrix.redhat.com> <56CC2C86.8040109@aixigo.de> Message-ID: <20160223105825.GC2468@mail.corp.redhat.com> On (23/02/16 10:55), Harald Dunkel wrote: >On 02/23/2016 10:00 AM, Jakub Hrozek wrote: >> >> Typically, this happens when the machine SSSD is running on is very >> busy, the sssd_be process is blocked writing some large result from >> LDAP, the monitor process considers it stuck and kills it. However, we >> /should/ restart and reconnect the subprocesses. >> > >Shoot the slow horse? Sorry to say, but I doubt that this is >a reasonable approach. Can I turn off this feature? > >I would like to avoid to move my mailhost back to NIS client, >but ypbind was never shot. Incoming EMails have been lost. >What would you suggest? > I would rather focus on different thing. Why is sssd_be process blocked for long time? Do you use enumeration? If yes do you really need it. Workaround might be to increate timeout between heartbeats which are used to ensure that the process is alive and capable of answering requests. The default value is 10 seconds. Double it should be enough because there is by default 6 heartbeats IIRC. LS From harald.dunkel at aixigo.de Tue Feb 23 12:01:09 2016 From: harald.dunkel at aixigo.de (Harald Dunkel) Date: Tue, 23 Feb 2016 13:01:09 +0100 Subject: [Freeipa-users] sssd went away, failed to restart In-Reply-To: <20160223105825.GC2468@mail.corp.redhat.com> References: <56CB16AF.9060303@aixigo.de> <20160222145152.GB3321@hendrix.arn.redhat.com> <56CC063E.7080900@aixigo.de> <20160223090003.GA3131@hendrix.redhat.com> <56CC2C86.8040109@aixigo.de> <20160223105825.GC2468@mail.corp.redhat.com> Message-ID: <56CC4A05.5040503@aixigo.de> On 02/23/2016 11:58 AM, Lukas Slebodnik wrote: > I would rather focus on different thing. > Why is sssd_be process blocked for long time? > I have no idea. Was it really blocked? > Do you use enumeration? > If yes do you really need it. Nope. > > Workaround might be to increate timeout between heartbeats > which are used to ensure that the process is alive and capable of answering > requests. The default value is 10 seconds. Double it should be enough > because there is by default 6 heartbeats IIRC. > 10 seconds is surely not OK. On Unix its not unlikely that a job is swapped out for 20 seconds or more. (Zabbix said that memory was fine, so this is not the case here.) Does it really have to be watched? Wouldn't it be the job of systemd to restart the service when it dies? Regards Harri From lslebodn at redhat.com Tue Feb 23 12:46:02 2016 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Tue, 23 Feb 2016 13:46:02 +0100 Subject: [Freeipa-users] sssd went away, failed to restart In-Reply-To: <56CC4A05.5040503@aixigo.de> References: <56CB16AF.9060303@aixigo.de> <20160222145152.GB3321@hendrix.arn.redhat.com> <56CC063E.7080900@aixigo.de> <20160223090003.GA3131@hendrix.redhat.com> <56CC2C86.8040109@aixigo.de> <20160223105825.GC2468@mail.corp.redhat.com> <56CC4A05.5040503@aixigo.de> Message-ID: <20160223124602.GH2468@mail.corp.redhat.com> On (23/02/16 13:01), Harald Dunkel wrote: >On 02/23/2016 11:58 AM, Lukas Slebodnik wrote: >> I would rather focus on different thing. >> Why is sssd_be process blocked for long time? >> > >I have no idea. Was it really blocked? > It needn't be blocked itself. But it was busy with some non-blocking operation which main process considered as bad state. Would you mind to share sssd log files with high debug level? >> Do you use enumeration? >> If yes do you really need it. > >Nope. > >> >> Workaround might be to increate timeout between heartbeats >> which are used to ensure that the process is alive and capable of answering >> requests. The default value is 10 seconds. Double it should be enough >> because there is by default 6 heartbeats IIRC. >> > >10 seconds is surely not OK. On Unix its not unlikely >that a job is swapped out for 20 seconds or more. >(Zabbix said that memory was fine, so this is not the >case here.) > >Does it really have to be watched? Wouldn't it be the >job of systemd to restart the service when it dies? > sssd works also on non-systemd distribution. We plan to reply on systemd. If you want to speed-up process then patches are always welcomed. And moreover systemd would not solve the main issue. we should try to find out why sssd_be did not respond for long time. LS From wdh at dds.nl Tue Feb 23 13:18:02 2016 From: wdh at dds.nl (Winfried de Heiden) Date: Tue, 23 Feb 2016 14:18:02 +0100 Subject: [Freeipa-users] could not get zone keys for secure dynamic update In-Reply-To: <56CB29E8.8020502@redhat.com> References: <56CAC885.4020609@dds.nl> <56CADEA2.80301@redhat.com> <56CB06DD.7040705@dds.nl> <56CB29E8.8020502@redhat.com> Message-ID: <56CC5C0A.2080102@dds.nl> An HTML attachment was scrubbed... URL: From karl.forner at gmail.com Tue Feb 23 13:31:22 2016 From: karl.forner at gmail.com (Karl Forner) Date: Tue, 23 Feb 2016 14:31:22 +0100 Subject: [Freeipa-users] Error setting krbpasswordexpiration using ipa user-mod Message-ID: Hello, I tried to postpone a password expiration date, as indicated here: https://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/pwd-expiration.html % ipa user-mod myuser --setattr=krbpasswordexpiration=20170301121443Z ipa: ERROR: Insufficient access: Insufficient 'write' privilege to the 'krbPasswordExpiration' attribute of entry 'uid=myuser,cn=users,cn=accounts,dc=quartzbio,dc=com'. Is this expected ? What is the canonical way of doing this ? Thanks, Karl -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Tue Feb 23 13:52:06 2016 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 23 Feb 2016 14:52:06 +0100 Subject: [Freeipa-users] could not get zone keys for secure dynamic update In-Reply-To: <56CC5C0A.2080102@dds.nl> References: <56CAC885.4020609@dds.nl> <56CADEA2.80301@redhat.com> <56CB06DD.7040705@dds.nl> <56CB29E8.8020502@redhat.com> <56CC5C0A.2080102@dds.nl> Message-ID: <56CC6406.6010301@redhat.com> On 23.2.2016 14:18, Winfried de Heiden wrote: > Hi all, > > And so did I, following > http://www.freeipa.org/page/Troubleshooting#DNSSEC_master_is_not_configured: > > ipa-dns-install --dnssec-master > > The log file for this installation can be found in /var/log/ipaserver-install.log > ============================================================================== > This program will setup DNS for the FreeIPA Server. > > This includes: > * Configure DNS (bind) > * Configure SoftHSM (required by DNSSEC) > * Configure ipa-dnskeysyncd (required by DNSSEC) > * Configure ipa-ods-exporter (required by DNSSEC key master) > * Configure OpenDNSSEC (required by DNSSEC key master) > * Generate DNSSEC master key (required by DNSSEC key master) > > NOTE: DNSSEC zone signing is not enabled by default > > Plan carefully, replacing DNSSEC key master is not recommended > > > To accept the default shown in brackets, press the Enter key. > > Do you want to setup this IPA server as DNSSEC key master? [no]: yes > DNSSEC signing is already enabled for following zone(s): example.com. > Installation cannot continue without the OpenDNSSEC database file from the > original DNSSEC master server. > Please use option --kasp-db to specify location of the kasp.db file copied from > the original DNSSEC master server. > WARNING: Zones will become unavailable if you do not provide the original > kasp.db file. > > However, it seems like I don't have a key, that was the problem in the first > place.... Right. This is a special case so you need to provide --force option to override the check and continue with installation. When you do that, please go through the Troubleshooting page again, hopefully it will help. Petr^2 Spacek > Anyway, trying to continue: > > bash-4.3$ ods-ksmutil zone list > zonelist filename set to /etc/opendnssec/zonelist.xml. > Cannot open destination file, will not make backup. > No zones in DB or zonelist. > > Indeed, the file /etc/opendnssec/zonelist.xml is the installed by default, only > having the not-used example zones. > > Also, python2 /usr/lib/python2.*/site-packages/ipapython/dnssec/localhsm.py does > not show any zone private keys. > > Is still looks like these are not created. > > So, it still looks like DNSSEC signing is enabled, but the key is not there. > > Winny > > Op 22-02-16 om 16:31 schreef Petr Spacek: >> On 22.2.2016 14:02, Winfried de Heiden wrote: >>> Hi all, >>> >>> Following >>> http://www.freeipa.org/page/Troubleshooting#DNSSEC_signing_does_not_work was >>> most usefull, It turned out the package "freeipa-server-dns"was missing. >>> Strange, I am running DNS, but...: >>> >>> * I upgraded form Fedora 22 to 23 includng upgrading from IPA 4.1 to 4.2. >>> * Also: I'm running this on a Bananapi "server"..... >>> * There's no slave. >>> >>> >>> Anyway, ipa dnszone-show tells DNSsec was ebabled: >>> >>> >>> Allow in-line DNSSEC signing: TRUE >>> >>> but most likely due to the missing freeipa-server-dns it was missing >>> dependencies as well, for example the package opendnssec was missing. >>> >>> After installing freeipa-server-dns all packages seems to be in place, but the >>> kasp.db file is empty: >>> >>> root at ipa ~]# ls -l /var/opendnssec/kasp.db >>> -rw-rw----. 1 ods ods 0 Feb 22 11:29 /var/opendnssec/kasp.db >>> >>> No wonder I still get messages like "could not get zone keys". >>> >>> Shouldn't a key be added? How? (without blowing the current DNS....) >> DNSSEC key master should do that automatically. >> >> Please continue with next steps as described on >> http://www.freeipa.org/page/Troubleshooting#DNSSEC_master_is_not_configured >> and we will see. >> >> Petr^2 Spacek >> >>> Winny >>> >>> >>> Op 22-02-16 om 11:10 schreef Petr Spaceopendnssec >>>> On 22.2.2016 09:36, Winfried de Heiden wrote: >>>>> Hi all, >>>>> >>>>> I get lot's of messages in my log (journalctl -u named-pkcs11.service -p err ) >>>>> like these: >>>>> >>>>> Feb 22 09:17:32 ipa.example.com named-pkcs11[8982]: zone example.com/IN >>>>> (signed): could not get zone keys for secure dynamic update >>>>> Feb 22 09:17:32 ipa.example.com named-pkcs11[8982]: zone example.com/IN >>>>> (signed): receive_secure_serial: not found >>>>> Feb 22 09:19:06 ipa.example.com named-pkcs11[8982]: zone example.com/IN >>>>> (signed): could not get zone keys for secure dynamic update >>>>> Feb 22 09:19:06 ipa.example.com named-pkcs11[8982]: zone example.com/IN >>>>> (signed): receive_secure_serial: not found >>>>> Feb 22 09:20:06 ipa.example.com named-pkcs11[8982]: zone example.com/IN >>>>> (signed): could not get zone keys for secure dynamic update >>>>> Feb 22 09:20:06 ipa.example.com named-pkcs11[8982]: zone example.com/IN >>>>> (signed): receive_secure_serial: not found >>>>> >>>>> What's going wrong here, how to fix it? >>>> Hello, >>>> >>>> this might have multiple reasons. >>>> >>>> Please walk step-by-step through following page: >>>> http://www.freeipa.org/page/Troubleshooting#DNSSEC_signing_does_not_work >>>> >>>> Additional questions: >>>> * What version of FreeIPA and on what platform do you use? >>>> * Is the zone signed on DNSSEC key master or on replica? Does it work on one >>>> FreeIPA server but not on some other server? >>>> * Did you change something lately? From Andy.Thompson at e-tcc.com Tue Feb 23 14:02:36 2016 From: Andy.Thompson at e-tcc.com (Andy Thompson) Date: Tue, 23 Feb 2016 14:02:36 +0000 Subject: [Freeipa-users] lock table errors Message-ID: <50b86529cc684505ab02d6e9dbdf4aa8@TCCCORPEXCH02.TCC.local> Came across one of my replicas this morning with the following in the error log [20/Feb/2016:17:23:38 -0500] - libdb: BDB2055 Lock table is out of available lock entries [20/Feb/2016:17:23:38 -0500] entryrdn-index - _entryrdn_delete_key: Deleting C1 failed; Cannot allocate memory(12) [20/Feb/2016:17:23:38 -0500] - database index operation failed BAD 1031, err=12 Cannot allocate memory [20/Feb/2016:17:23:38 -0500] - index_del_entry(changenumber=1328662,cn=changelog, 0x26) failed (12) [20/Feb/2016:17:23:38 -0500] DSRetroclPlugin - delete_changerecord: could not delete change record 1328662 (rc: 1) [20/Feb/2016:17:23:38 -0500] - libdb: BDB2055 Lock table is out of available lock entries [20/Feb/2016:17:23:38 -0500] entryrdn-index - _entryrdn_get_elem: Failed to position cursor at the key: 1328666: Cannot allocate memory(12) [20/Feb/2016:17:23:38 -0500] entryrdn-index - _entryrdn_delete_key: Failed to position cursor at the key: 1328666: Cannot allocate memory(12) [20/Feb/2016:17:23:38 -0500] - libdb: BDB2055 Lock table is out of available lock entries [20/Feb/2016:17:23:38 -0500] - database index operation failed BAD 1031, err=12 Cannot allocate memory [20/Feb/2016:17:23:38 -0500] - index_del_entry(changenumber=1328663,cn=changelog, 0x26) failed (12) [20/Feb/2016:17:23:38 -0500] NSMMReplicationPlugin - changelog program - _cl5CompactDBs: failed to compact 5f1d2b12-cf1411e4-b055ba8a-f4b484f7; db error - 12 Cannot allocate memory [20/Feb/2016:17:23:38 -0500] DSRetroclPlugin - delete_changerecord: could not delete change record 1328663 (rc: 1) [20/Feb/2016:17:23:41 -0500] ldbm_back_delete - conn=0 op=0 [retry: 1] No original_tombstone for changenumber=1330335,cn=changelog!! And then nothing. Was troubleshooting some clients that were having issues resolving some trusted domain users. I restarted IPA and it rolled through a few thousand missing change records 23/Feb/2016:08:39:34 -0500] DSRetroclPlugin - delete_changerecord: could not delete change record 1328696 (rc: 32) Any thoughts as to what might have caused the lock table errors? Thanks -andy *** This communication may contain privileged and/or confidential information. It is intended solely for the use of the addressee. If you are not the intended recipient, you are strictly prohibited from disclosing, copying, distributing or using any of this information. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. *** From karl.forner at gmail.com Tue Feb 23 14:11:20 2016 From: karl.forner at gmail.com (Karl Forner) Date: Tue, 23 Feb 2016 15:11:20 +0100 Subject: [Freeipa-users] Error setting krbpasswordexpiration using ipa user-mod In-Reply-To: References: Message-ID: I forgot to say that I did a "kinit admin" before the ipa user-mod. On Tue, Feb 23, 2016 at 2:31 PM, Karl Forner wrote: > Hello, > > I tried to postpone a password expiration date, as indicated here: > > https://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/pwd-expiration.html > > % ipa user-mod myuser --setattr=krbpasswordexpiration=20170301121443Z > > ipa: ERROR: Insufficient access: Insufficient 'write' privilege to the > 'krbPasswordExpiration' attribute of entry > 'uid=myuser,cn=users,cn=accounts,dc=quartzbio,dc=com'. > > Is this expected ? What is the canonical way of doing this ? > > > Thanks, > Karl > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lkrispen at redhat.com Tue Feb 23 14:31:15 2016 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Tue, 23 Feb 2016 15:31:15 +0100 Subject: [Freeipa-users] lock table errors In-Reply-To: <50b86529cc684505ab02d6e9dbdf4aa8@TCCCORPEXCH02.TCC.local> References: <50b86529cc684505ab02d6e9dbdf4aa8@TCCCORPEXCH02.TCC.local> Message-ID: <56CC6D33.3010807@redhat.com> On 02/23/2016 03:02 PM, Andy Thompson wrote: > Came across one of my replicas this morning with the following in the error log > > [20/Feb/2016:17:23:38 -0500] - libdb: BDB2055 Lock table is out of available lock entries > [20/Feb/2016:17:23:38 -0500] entryrdn-index - _entryrdn_delete_key: Deleting C1 failed; Cannot allocate memory(12) > [20/Feb/2016:17:23:38 -0500] - database index operation failed BAD 1031, err=12 Cannot allocate memory > [20/Feb/2016:17:23:38 -0500] - index_del_entry(changenumber=1328662,cn=changelog, 0x26) failed (12) > [20/Feb/2016:17:23:38 -0500] DSRetroclPlugin - delete_changerecord: could not delete change record 1328662 (rc: 1) > [20/Feb/2016:17:23:38 -0500] - libdb: BDB2055 Lock table is out of available lock entries > [20/Feb/2016:17:23:38 -0500] entryrdn-index - _entryrdn_get_elem: Failed to position cursor at the key: 1328666: Cannot allocate memory(12) > [20/Feb/2016:17:23:38 -0500] entryrdn-index - _entryrdn_delete_key: Failed to position cursor at the key: 1328666: Cannot allocate memory(12) > [20/Feb/2016:17:23:38 -0500] - libdb: BDB2055 Lock table is out of available lock entries > [20/Feb/2016:17:23:38 -0500] - database index operation failed BAD 1031, err=12 Cannot allocate memory > [20/Feb/2016:17:23:38 -0500] - index_del_entry(changenumber=1328663,cn=changelog, 0x26) failed (12) > [20/Feb/2016:17:23:38 -0500] NSMMReplicationPlugin - changelog program - _cl5CompactDBs: failed to compact 5f1d2b12-cf1411e4-b055ba8a-f4b484f7; db error - 12 Cannot allocate memory > [20/Feb/2016:17:23:38 -0500] DSRetroclPlugin - delete_changerecord: could not delete change record 1328663 (rc: 1) > [20/Feb/2016:17:23:41 -0500] ldbm_back_delete - conn=0 op=0 [retry: 1] No original_tombstone for changenumber=1330335,cn=changelog!! > > And then nothing. Was troubleshooting some clients that were having issues resolving some trusted domain users. > > I restarted IPA and it rolled through a few thousand missing change records > > 23/Feb/2016:08:39:34 -0500] DSRetroclPlugin - delete_changerecord: could not delete change record 1328696 (rc: 32) > > Any thoughts as to what might have caused the lock table errors? in BerkeleyDB this means that the number of pages which would have to be locked in one transaction exceeds the configured number of locks. This could happen if eg a large group is deleted and for each member of the group inside the same transaction the memberof attribute has to be modified > > Thanks > > -andy > > > > *** This communication may contain privileged and/or confidential information. It is intended solely for the use of the addressee. If you are not the intended recipient, you are strictly prohibited from disclosing, copying, distributing or using any of this information. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. *** > > From Andy.Thompson at e-tcc.com Tue Feb 23 14:43:55 2016 From: Andy.Thompson at e-tcc.com (Andy Thompson) Date: Tue, 23 Feb 2016 14:43:55 +0000 Subject: [Freeipa-users] lock table errors In-Reply-To: <56CC6D33.3010807@redhat.com> References: <50b86529cc684505ab02d6e9dbdf4aa8@TCCCORPEXCH02.TCC.local> <56CC6D33.3010807@redhat.com> Message-ID: <7d2418895d7a40b8905be5e1da38463f@TCCCORPEXCH02.TCC.local> > -----Original Message----- > From: freeipa-users-bounces at redhat.com [mailto:freeipa-users- > bounces at redhat.com] On Behalf Of Ludwig Krispenz > Sent: Tuesday, February 23, 2016 9:31 AM > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] lock table errors > > > On 02/23/2016 03:02 PM, Andy Thompson wrote: > > Came across one of my replicas this morning with the following in the > > error log > > > > [20/Feb/2016:17:23:38 -0500] - libdb: BDB2055 Lock table is out of > > available lock entries > > [20/Feb/2016:17:23:38 -0500] entryrdn-index - _entryrdn_delete_key: > > Deleting C1 failed; Cannot allocate memory(12) > > [20/Feb/2016:17:23:38 -0500] - database index operation failed BAD > > 1031, err=12 Cannot allocate memory > > [20/Feb/2016:17:23:38 -0500] - > > index_del_entry(changenumber=1328662,cn=changelog, 0x26) failed (12) > > [20/Feb/2016:17:23:38 -0500] DSRetroclPlugin - delete_changerecord: > > could not delete change record 1328662 (rc: 1) > > [20/Feb/2016:17:23:38 -0500] - libdb: BDB2055 Lock table is out of > > available lock entries > > [20/Feb/2016:17:23:38 -0500] entryrdn-index - _entryrdn_get_elem: > > Failed to position cursor at the key: 1328666: Cannot allocate > > memory(12) > > [20/Feb/2016:17:23:38 -0500] entryrdn-index - _entryrdn_delete_key: > > Failed to position cursor at the key: 1328666: Cannot allocate > > memory(12) > > [20/Feb/2016:17:23:38 -0500] - libdb: BDB2055 Lock table is out of > > available lock entries > > [20/Feb/2016:17:23:38 -0500] - database index operation failed BAD > > 1031, err=12 Cannot allocate memory > > [20/Feb/2016:17:23:38 -0500] - > > index_del_entry(changenumber=1328663,cn=changelog, 0x26) failed (12) > > [20/Feb/2016:17:23:38 -0500] NSMMReplicationPlugin - changelog program > > - _cl5CompactDBs: failed to compact > > 5f1d2b12-cf1411e4-b055ba8a-f4b484f7; db error - 12 Cannot allocate > > memory > > [20/Feb/2016:17:23:38 -0500] DSRetroclPlugin - delete_changerecord: > > could not delete change record 1328663 (rc: 1) > > [20/Feb/2016:17:23:41 -0500] ldbm_back_delete - conn=0 op=0 [retry: 1] > No original_tombstone for changenumber=1330335,cn=changelog!! > > > > And then nothing. Was troubleshooting some clients that were having > issues resolving some trusted domain users. > > > > I restarted IPA and it rolled through a few thousand missing change > > records > > > > 23/Feb/2016:08:39:34 -0500] DSRetroclPlugin - delete_changerecord: > > could not delete change record 1328696 (rc: 32) > > > > Any thoughts as to what might have caused the lock table errors? > in BerkeleyDB this means that the number of pages which would have to be > locked in one transaction exceeds the configured number of locks. This could > happen if eg a large group is deleted and for each member of the group > inside the same transaction the memberof attribute has to be modified > > Are there any configuration options to increase that setting? And would it have caused the replica to become unresponsive? From edewata at redhat.com Tue Feb 23 14:57:24 2016 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 23 Feb 2016 08:57:24 -0600 Subject: [Freeipa-users] Upgrading from 3.0.0 CentOS6 to 4.2.3 CentOS7 In-Reply-To: <826785667.16953246.1454013909460.JavaMail.zimbra@redhat.com> References: <564F46BB.8060906@redhat.com> <56A79741.30707@redhat.com> <56A870AB.6080304@redhat.com> <826785667.16953246.1454013909460.JavaMail.zimbra@redhat.com> Message-ID: <56CC7354.3090801@redhat.com> On 1/28/2016 2:45 PM, Endi Sukma Dewata wrote: > Hi, > > If you're cloning from an IPA running on RHEL/CentOS 6 with CA signed by another CA you are likely hitting this issue: > https://bugzilla.redhat.com/show_bug.cgi?id=1291747 > > The bug has been fixed in this package: pki-ca-9.0.3-45. You'll need to install it on the master, then restart the server, then try cloning again. > > The latest PKI available on RHEL/CentOS 7 is version 10.2.5, but it's patched with relevant bug fixes from newer versions. > > If you're still having a problem, try enabling the debug log on the master and clone by setting the following property in CS.cfg: > debug.level=1 > > See also: http://pki.fedoraproject.org/wiki/PKI_Server_Logs > > -- > Endi S. Dewata Just a note, I believe the fix is already available on CentOS 6: http://mirror.centos.org/centos/6.7/updates/x86_64/Packages/ -- Endi S. Dewata From peljasz at yahoo.co.uk Tue Feb 23 14:58:34 2016 From: peljasz at yahoo.co.uk (lejeczek) Date: Tue, 23 Feb 2016 14:58:34 +0000 Subject: [Freeipa-users] server installation but client part fails Message-ID: <56CC739A.3030700@yahoo.co.uk> hi everybody I'm trying server installation but it fails, I think very last leg, and I was hoping you could suggest places which I should start looking at. [7/7]: configuring ipa-dnskeysyncd to start on boot Done configuring DNS key synchronization service (ipa-dnskeysyncd). Restarting ipa-dnskeysyncd Restarting named Restarting the web server ipa.ipapython.install.cli.install_tool(Server): ERROR Configuration of client side components failed! ipa-client-install returned: Command ''/usr/sbin/ipa-client-install' '--on-master' '--unattended' '--domain' '.private.my.private' '--server' '.private.my.private' '--realm' 'PRIVATE.MY.PRIVATE' '--hostname' '.private.my.private'' returned non-zero exit status 1 many thanks From wdh at dds.nl Tue Feb 23 15:02:16 2016 From: wdh at dds.nl (Winfried de Heiden) Date: Tue, 23 Feb 2016 16:02:16 +0100 Subject: [Freeipa-users] could not get zone keys for secure dynamic update In-Reply-To: <56CC6406.6010301@redhat.com> References: <56CAC885.4020609@dds.nl> <56CADEA2.80301@redhat.com> <56CB06DD.7040705@dds.nl> <56CB29E8.8020502@redhat.com> <56CC5C0A.2080102@dds.nl> <56CC6406.6010301@redhat.com> Message-ID: <56CC7478.5000908@dds.nl> An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue Feb 23 15:04:10 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 23 Feb 2016 10:04:10 -0500 Subject: [Freeipa-users] server installation but client part fails In-Reply-To: <56CC739A.3030700@yahoo.co.uk> References: <56CC739A.3030700@yahoo.co.uk> Message-ID: <56CC74EA.1080406@redhat.com> lejeczek wrote: > hi everybody > > I'm trying server installation but it fails, I think very last leg, and > I was hoping you could suggest places which I should start looking at. > > [7/7]: configuring ipa-dnskeysyncd to start on boot > Done configuring DNS key synchronization service (ipa-dnskeysyncd). > Restarting ipa-dnskeysyncd > Restarting named > Restarting the web server > ipa.ipapython.install.cli.install_tool(Server): ERROR Configuration of > client side components failed! > ipa-client-install returned: Command ''/usr/sbin/ipa-client-install' > '--on-master' '--unattended' '--domain' '.private.my.private' '--server' > '.private.my.private' '--realm' 'PRIVATE.MY.PRIVATE' '--hostname' > '.private.my.private'' returned non-zero exit status 1 > > many thanks > Look in /var/log/ipaserver-install.log and /var/log/ipaclient-install.log for a more detailed reason. rob From rcritten at redhat.com Tue Feb 23 15:37:16 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 23 Feb 2016 10:37:16 -0500 Subject: [Freeipa-users] Error setting krbpasswordexpiration using ipa user-mod In-Reply-To: References: Message-ID: <56CC7CAC.2040504@redhat.com> Karl Forner wrote: > I forgot to say that I did a "kinit admin" before the ipa user-mod. > > On Tue, Feb 23, 2016 at 2:31 PM, Karl Forner > wrote: > > Hello, > > I tried to postpone a password expiration date, as indicated here: > https://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/pwd-expiration.html > > % ipa user-mod myuser --setattr=krbpasswordexpiration=20170301121443Z > > ipa: ERROR: Insufficient access: Insufficient 'write' privilege to > the 'krbPasswordExpiration' attribute of entry > 'uid=myuser,cn=users,cn=accounts,dc=quartzbio,dc=com'. > > Is this expected ? What is the canonical way of doing this ? The docs you are referring to are quite old: 5 full Fedora releases, several IPA releases. To fix you'd need to add a new ACI that grants write access to this attribute in the user container. You can either do this via the permission/privilege/role route and add the admins gropu to the new role, or you can directly add an ACI (more direct but also less supportable and error-prone). rob From lkrispen at redhat.com Tue Feb 23 15:46:08 2016 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Tue, 23 Feb 2016 16:46:08 +0100 Subject: [Freeipa-users] lock table errors In-Reply-To: <7d2418895d7a40b8905be5e1da38463f@TCCCORPEXCH02.TCC.local> References: <50b86529cc684505ab02d6e9dbdf4aa8@TCCCORPEXCH02.TCC.local> <56CC6D33.3010807@redhat.com> <7d2418895d7a40b8905be5e1da38463f@TCCCORPEXCH02.TCC.local> Message-ID: <56CC7EC0.1090401@redhat.com> On 02/23/2016 03:43 PM, Andy Thompson wrote: >> -----Original Message----- >> From: freeipa-users-bounces at redhat.com [mailto:freeipa-users- >> bounces at redhat.com] On Behalf Of Ludwig Krispenz >> Sent: Tuesday, February 23, 2016 9:31 AM >> To: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] lock table errors >> >> >> On 02/23/2016 03:02 PM, Andy Thompson wrote: >>> Came across one of my replicas this morning with the following in the >>> error log >>> >>> [20/Feb/2016:17:23:38 -0500] - libdb: BDB2055 Lock table is out of >>> available lock entries >>> [20/Feb/2016:17:23:38 -0500] entryrdn-index - _entryrdn_delete_key: >>> Deleting C1 failed; Cannot allocate memory(12) >>> [20/Feb/2016:17:23:38 -0500] - database index operation failed BAD >>> 1031, err=12 Cannot allocate memory >>> [20/Feb/2016:17:23:38 -0500] - >>> index_del_entry(changenumber=1328662,cn=changelog, 0x26) failed (12) >>> [20/Feb/2016:17:23:38 -0500] DSRetroclPlugin - delete_changerecord: >>> could not delete change record 1328662 (rc: 1) >>> [20/Feb/2016:17:23:38 -0500] - libdb: BDB2055 Lock table is out of >>> available lock entries >>> [20/Feb/2016:17:23:38 -0500] entryrdn-index - _entryrdn_get_elem: >>> Failed to position cursor at the key: 1328666: Cannot allocate >>> memory(12) >>> [20/Feb/2016:17:23:38 -0500] entryrdn-index - _entryrdn_delete_key: >>> Failed to position cursor at the key: 1328666: Cannot allocate >>> memory(12) >>> [20/Feb/2016:17:23:38 -0500] - libdb: BDB2055 Lock table is out of >>> available lock entries >>> [20/Feb/2016:17:23:38 -0500] - database index operation failed BAD >>> 1031, err=12 Cannot allocate memory >>> [20/Feb/2016:17:23:38 -0500] - >>> index_del_entry(changenumber=1328663,cn=changelog, 0x26) failed (12) >>> [20/Feb/2016:17:23:38 -0500] NSMMReplicationPlugin - changelog program >>> - _cl5CompactDBs: failed to compact >>> 5f1d2b12-cf1411e4-b055ba8a-f4b484f7; db error - 12 Cannot allocate >>> memory >>> [20/Feb/2016:17:23:38 -0500] DSRetroclPlugin - delete_changerecord: >>> could not delete change record 1328663 (rc: 1) >>> [20/Feb/2016:17:23:41 -0500] ldbm_back_delete - conn=0 op=0 [retry: 1] >> No original_tombstone for changenumber=1330335,cn=changelog!! >>> And then nothing. Was troubleshooting some clients that were having >> issues resolving some trusted domain users. >>> I restarted IPA and it rolled through a few thousand missing change >>> records >>> >>> 23/Feb/2016:08:39:34 -0500] DSRetroclPlugin - delete_changerecord: >>> could not delete change record 1328696 (rc: 32) >>> >>> Any thoughts as to what might have caused the lock table errors? >> in BerkeleyDB this means that the number of pages which would have to be >> locked in one transaction exceeds the configured number of locks. This could >> happen if eg a large group is deleted and for each member of the group >> inside the same transaction the memberof attribute has to be modified > > Are there any configuration options to increase that setting? And would it have caused the replica to become unresponsive? you can change nsslapd-db-locks in the entry: dn: cn=config,cn=ldbm database,cn=plugins,cn=config yes. in that state it would not process updates, the txn should be finally aborted and the system should recover,but .. From rcritten at redhat.com Tue Feb 23 15:50:23 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 23 Feb 2016 10:50:23 -0500 Subject: [Freeipa-users] IPA 4.2: pki-tomcatd in terrible shape In-Reply-To: <56CB277F.2000309@redhat.com> References: <56B86DE0.4070909@redhat.com> <7F0EB8FC-8F2F-49D1-A124-562B5B0A55A2@accertify.com> <56B9AA53.1000400@redhat.com> <56BAFC6E.6030605@redhat.com> <56BE04AD.2020700@redhat.com> <1455951442.25282.2.camel@accertify.com> <56CB277F.2000309@redhat.com> Message-ID: <56CC7FBF.1040006@redhat.com> Ludwig Krispenz wrote: > The crash is an abort because of a failed assertion in the kerberos code > > Thread 1 (Thread 0x7fa7d4c88700 (LWP 3125)): > #0 0x00007fa7e6ace5f7 in raise () from /lib64/libc.so.6 > No symbol table info available. > #1 0x00007fa7e6acfce8 in abort () from /lib64/libc.so.6 > No symbol table info available. > #2 0x00007fa7e6ac7566 in __assert_fail_base () from /lib64/libc.so.6 > No symbol table info available. > #3 0x00007fa7e6ac7612 in __assert_fail () from /lib64/libc.so.6 > No symbol table info available. > #4 0x00007fa7e8d71b83 in k5_mutex_lock.part.1 () from /lib64/libkrb5.so.3 > No symbol table info available. > #5 0x00007fa7e8d7bda1 in k5_cc_mutex_lock () from /lib64/libkrb5.so.3 > No symbol table info available. > #6 0x00007fa7e8d851bf in krb5_mcc_store () from /lib64/libkrb5.so.3 > No symbol table info available. > #7 0x00007fa7e8d88070 in krb5_cc_store_cred () from /lib64/libkrb5.so.3 > No symbol table info available. > #8 0x00007fa7e8d98be3 in complete () from /lib64/libkrb5.so.3 > No symbol table info available. > #9 0x00007fa7e8d99ba1 in krb5_tkt_creds_step () from /lib64/libkrb5.so.3 > No symbol table info available. > #10 0x00007fa7e8d9a637 in krb5_tkt_creds_get () from /lib64/libkrb5.so.3 > No symbol table info available. > #11 0x00007fa7e8d9a75c in krb5_get_credentials () from /lib64/libkrb5.so.3 > No symbol table info available. > #12 0x00007fa7e0f6736a in krb5_gss_init_sec_context_ext () from > /lib64/libgssapi_krb5.so.2 > No symbol table info available. > #13 0x00007fa7e0f67c97 in krb5_gss_init_sec_context () from > /lib64/libgssapi_krb5.so.2 > No symbol table info available. > #14 0x00007fa7e0f516ab in gss_init_sec_context () from > /lib64/libgssapi_krb5.so.2 > No symbol table info available. > #15 0x00007fa7e118ac44 in gssapi_client_mech_step () from > /usr/lib64/sasl2/libgssapiv2.so > No symbol table info available. > #16 0x00007fa7e72847f5 in sasl_client_step () from /lib64/libsasl2.so.3 > No symbol table info available. > #17 0x00007fa7e7284b76 in sasl_client_start () from /lib64/libsasl2.so.3 > No symbol table info available. > #18 0x00007fa7e8475e73 in ldap_int_sasl_bind () from > /lib64/libldap_r-2.4.so.2 > No symbol table info available. > #19 0x00007fa7e8479492 in ldap_sasl_interactive_bind () from > /lib64/libldap_r-2.4.so.2 > No symbol table info available. > #20 0x00007fa7e84796bd in ldap_sasl_interactive_bind_s () from > /lib64/libldap_r-2.4.so.2 > > Directory server tries to open a replication connetion usig GSSAPI. I > don't know which assertion fails in krb, but > - could you try with the replication agreement disabled ? > - Rob, you have been discussing renewals of keytabs, would we have to > renew the ds.keytab ? This is in the context of renewing certificates, not keytabs. I guess installing the krb5 debuginfo might give more details on where it is crashing. rob From Andy.Thompson at e-tcc.com Tue Feb 23 16:10:39 2016 From: Andy.Thompson at e-tcc.com (Andy Thompson) Date: Tue, 23 Feb 2016 16:10:39 +0000 Subject: [Freeipa-users] lock table errors In-Reply-To: <56CC7EC0.1090401@redhat.com> References: <50b86529cc684505ab02d6e9dbdf4aa8@TCCCORPEXCH02.TCC.local> <56CC6D33.3010807@redhat.com> <7d2418895d7a40b8905be5e1da38463f@TCCCORPEXCH02.TCC.local> <56CC7EC0.1090401@redhat.com> Message-ID: > >> On 02/23/2016 03:02 PM, Andy Thompson wrote: > >>> Came across one of my replicas this morning with the following in > >>> the error log > >>> > >>> [20/Feb/2016:17:23:38 -0500] - libdb: BDB2055 Lock table is out of > >>> available lock entries > >>> [20/Feb/2016:17:23:38 -0500] entryrdn-index - _entryrdn_delete_key: > >>> Deleting C1 failed; Cannot allocate memory(12) > >>> [20/Feb/2016:17:23:38 -0500] - database index operation failed BAD > >>> 1031, err=12 Cannot allocate memory > >>> [20/Feb/2016:17:23:38 -0500] - > >>> index_del_entry(changenumber=1328662,cn=changelog, 0x26) failed > (12) > >>> [20/Feb/2016:17:23:38 -0500] DSRetroclPlugin - delete_changerecord: > >>> could not delete change record 1328662 (rc: 1) > >>> [20/Feb/2016:17:23:38 -0500] - libdb: BDB2055 Lock table is out of > >>> available lock entries > >>> [20/Feb/2016:17:23:38 -0500] entryrdn-index - _entryrdn_get_elem: > >>> Failed to position cursor at the key: 1328666: Cannot allocate > >>> memory(12) > >>> [20/Feb/2016:17:23:38 -0500] entryrdn-index - _entryrdn_delete_key: > >>> Failed to position cursor at the key: 1328666: Cannot allocate > >>> memory(12) > >>> [20/Feb/2016:17:23:38 -0500] - libdb: BDB2055 Lock table is out of > >>> available lock entries > >>> [20/Feb/2016:17:23:38 -0500] - database index operation failed BAD > >>> 1031, err=12 Cannot allocate memory > >>> [20/Feb/2016:17:23:38 -0500] - > >>> index_del_entry(changenumber=1328663,cn=changelog, 0x26) failed > (12) > >>> [20/Feb/2016:17:23:38 -0500] NSMMReplicationPlugin - changelog > >>> program > >>> - _cl5CompactDBs: failed to compact > >>> 5f1d2b12-cf1411e4-b055ba8a-f4b484f7; db error - 12 Cannot allocate > >>> memory > >>> [20/Feb/2016:17:23:38 -0500] DSRetroclPlugin - delete_changerecord: > >>> could not delete change record 1328663 (rc: 1) > >>> [20/Feb/2016:17:23:41 -0500] ldbm_back_delete - conn=0 op=0 [retry: > >>> 1] > >> No original_tombstone for changenumber=1330335,cn=changelog!! > >>> And then nothing. Was troubleshooting some clients that were having > >> issues resolving some trusted domain users. > >>> I restarted IPA and it rolled through a few thousand missing change > >>> records > >>> > >>> 23/Feb/2016:08:39:34 -0500] DSRetroclPlugin - delete_changerecord: > >>> could not delete change record 1328696 (rc: 32) > >>> > >>> Any thoughts as to what might have caused the lock table errors? > >> in BerkeleyDB this means that the number of pages which would have to > >> be locked in one transaction exceeds the configured number of locks. > >> This could happen if eg a large group is deleted and for each member > >> of the group inside the same transaction the memberof attribute has > >> to be modified > > > > Are there any configuration options to increase that setting? And would it > have caused the replica to become unresponsive? > you can change > > nsslapd-db-locks > > in the entry: > > dn: cn=config,cn=ldbm database,cn=plugins,cn=config > > yes. in that state it would not process updates, the txn should be finally > aborted and the system should recover,but .. Is there any rule of thumb or anything I can look at to get an idea of what I should increase that to or should it even be necessary? The current setting has a default of 10000 cn=database,cn=monitor,cn=ldbm database,cn=plugins,cn=config currently shows nsslapd-db-current-locks: 82 What might cause that to spike up that significantly to deplete the locks? That's a pretty huge jump. Running 389-ds-base-1.3.4.0-26.el7_2.x86_64 -andy From lkrispen at redhat.com Tue Feb 23 16:19:06 2016 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Tue, 23 Feb 2016 17:19:06 +0100 Subject: [Freeipa-users] lock table errors In-Reply-To: References: <50b86529cc684505ab02d6e9dbdf4aa8@TCCCORPEXCH02.TCC.local> <56CC6D33.3010807@redhat.com> <7d2418895d7a40b8905be5e1da38463f@TCCCORPEXCH02.TCC.local> <56CC7EC0.1090401@redhat.com> Message-ID: <56CC867A.7070101@redhat.com> On 02/23/2016 05:10 PM, Andy Thompson wrote: >>>> On 02/23/2016 03:02 PM, Andy Thompson wrote: >>>>> Came across one of my replicas this morning with the following in >>>>> the error log >>>>> >>>>> [20/Feb/2016:17:23:38 -0500] - libdb: BDB2055 Lock table is out of >>>>> available lock entries >>>>> [20/Feb/2016:17:23:38 -0500] entryrdn-index - _entryrdn_delete_key: >>>>> Deleting C1 failed; Cannot allocate memory(12) >>>>> [20/Feb/2016:17:23:38 -0500] - database index operation failed BAD >>>>> 1031, err=12 Cannot allocate memory >>>>> [20/Feb/2016:17:23:38 -0500] - >>>>> index_del_entry(changenumber=1328662,cn=changelog, 0x26) failed >> (12) >>>>> [20/Feb/2016:17:23:38 -0500] DSRetroclPlugin - delete_changerecord: >>>>> could not delete change record 1328662 (rc: 1) >>>>> [20/Feb/2016:17:23:38 -0500] - libdb: BDB2055 Lock table is out of >>>>> available lock entries >>>>> [20/Feb/2016:17:23:38 -0500] entryrdn-index - _entryrdn_get_elem: >>>>> Failed to position cursor at the key: 1328666: Cannot allocate >>>>> memory(12) >>>>> [20/Feb/2016:17:23:38 -0500] entryrdn-index - _entryrdn_delete_key: >>>>> Failed to position cursor at the key: 1328666: Cannot allocate >>>>> memory(12) >>>>> [20/Feb/2016:17:23:38 -0500] - libdb: BDB2055 Lock table is out of >>>>> available lock entries >>>>> [20/Feb/2016:17:23:38 -0500] - database index operation failed BAD >>>>> 1031, err=12 Cannot allocate memory >>>>> [20/Feb/2016:17:23:38 -0500] - >>>>> index_del_entry(changenumber=1328663,cn=changelog, 0x26) failed >> (12) >>>>> [20/Feb/2016:17:23:38 -0500] NSMMReplicationPlugin - changelog >>>>> program >>>>> - _cl5CompactDBs: failed to compact >>>>> 5f1d2b12-cf1411e4-b055ba8a-f4b484f7; db error - 12 Cannot allocate >>>>> memory >>>>> [20/Feb/2016:17:23:38 -0500] DSRetroclPlugin - delete_changerecord: >>>>> could not delete change record 1328663 (rc: 1) >>>>> [20/Feb/2016:17:23:41 -0500] ldbm_back_delete - conn=0 op=0 [retry: >>>>> 1] >>>> No original_tombstone for changenumber=1330335,cn=changelog!! >>>>> And then nothing. Was troubleshooting some clients that were having >>>> issues resolving some trusted domain users. >>>>> I restarted IPA and it rolled through a few thousand missing change >>>>> records >>>>> >>>>> 23/Feb/2016:08:39:34 -0500] DSRetroclPlugin - delete_changerecord: >>>>> could not delete change record 1328696 (rc: 32) >>>>> >>>>> Any thoughts as to what might have caused the lock table errors? >>>> in BerkeleyDB this means that the number of pages which would have to >>>> be locked in one transaction exceeds the configured number of locks. >>>> This could happen if eg a large group is deleted and for each member >>>> of the group inside the same transaction the memberof attribute has >>>> to be modified >>> Are there any configuration options to increase that setting? And would it >> have caused the replica to become unresponsive? >> you can change >> >> nsslapd-db-locks >> >> in the entry: >> >> dn: cn=config,cn=ldbm database,cn=plugins,cn=config >> >> yes. in that state it would not process updates, the txn should be finally >> aborted and the system should recover,but .. > Is there any rule of thumb or anything I can look at to get an idea of what I should increase that to or should it even be necessary? > > The current setting has a default of 10000 > > cn=database,cn=monitor,cn=ldbm database,cn=plugins,cn=config > > currently shows > > nsslapd-db-current-locks: 82 > > What might cause that to spike up that significantly to deplete the locks? That's a pretty huge jump. I have given you an example of what operation could use a high number of page locks, to find out what was going on in your case would require to investigate which operations were active when the problem started, what the entries modified added looked like ...... > > Running 389-ds-base-1.3.4.0-26.el7_2.x86_64 > > -andy > From peljasz at yahoo.co.uk Tue Feb 23 16:38:56 2016 From: peljasz at yahoo.co.uk (lejeczek) Date: Tue, 23 Feb 2016 16:38:56 +0000 Subject: [Freeipa-users] server installation but client part fails In-Reply-To: <56CC74EA.1080406@redhat.com> References: <56CC739A.3030700@yahoo.co.uk> <56CC74EA.1080406@redhat.com> Message-ID: <56CC8B20.3020102@yahoo.co.uk> On 23/02/16 15:04, Rob Crittenden wrote: > lejeczek wrote: >> hi everybody >> >> I'm trying server installation but it fails, I think very last leg, and >> I was hoping you could suggest places which I should start looking at. >> >> [7/7]: configuring ipa-dnskeysyncd to start on boot >> Done configuring DNS key synchronization service (ipa-dnskeysyncd). >> Restarting ipa-dnskeysyncd >> Restarting named >> Restarting the web server >> ipa.ipapython.install.cli.install_tool(Server): ERROR Configuration of >> client side components failed! >> ipa-client-install returned: Command ''/usr/sbin/ipa-client-install' >> '--on-master' '--unattended' '--domain' '.private.my.private' '--server' >> '.private.my.private' '--realm' 'PRIVATE.MY.PRIVATE' '--hostname' >> '.private.my.private'' returned non-zero exit status 1 >> >> many thanks >> > Look in /var/log/ipaserver-install.log and > /var/log/ipaclient-install.log for a more detailed reason. > > rob > thanks Rob, I was missing client part of logs. I just have to be careful with my finely grained configuration & config files. If anybody stumbles upon similar errors - first thing to do is to make sure your already existing httpd config(s) does not exclude *.conf from Apache's main dir, which is where IPA renders its files. From karl.forner at gmail.com Tue Feb 23 17:07:24 2016 From: karl.forner at gmail.com (Karl Forner) Date: Tue, 23 Feb 2016 18:07:24 +0100 Subject: [Freeipa-users] Error setting krbpasswordexpiration using ipa user-mod In-Reply-To: <56CC7CAC.2040504@redhat.com> References: <56CC7CAC.2040504@redhat.com> Message-ID: > > The docs you are referring to are quite old: 5 full Fedora releases, > several IPA releases. > You're right, sorry. I found this documentation https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/pwd-expiration.html which has updated instructions based on ldapmodify which worked for me. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Andy.Thompson at e-tcc.com Tue Feb 23 17:12:07 2016 From: Andy.Thompson at e-tcc.com (Andy Thompson) Date: Tue, 23 Feb 2016 17:12:07 +0000 Subject: [Freeipa-users] lock table errors In-Reply-To: <56CC867A.7070101@redhat.com> References: <50b86529cc684505ab02d6e9dbdf4aa8@TCCCORPEXCH02.TCC.local> <56CC6D33.3010807@redhat.com> <7d2418895d7a40b8905be5e1da38463f@TCCCORPEXCH02.TCC.local> <56CC7EC0.1090401@redhat.com> <56CC867A.7070101@redhat.com> Message-ID: <8a53729f7ab04b4da82ae55b10334fd3@TCCCORPEXCH02.TCC.local> > On 02/23/2016 05:10 PM, Andy Thompson wrote: > >>>> On 02/23/2016 03:02 PM, Andy Thompson wrote: > >>>>> Came across one of my replicas this morning with the following in > >>>>> the error log > >>>>> > >>>>> [20/Feb/2016:17:23:38 -0500] - libdb: BDB2055 Lock table is out of > >>>>> available lock entries > >>>>> [20/Feb/2016:17:23:38 -0500] entryrdn-index - > _entryrdn_delete_key: > >>>>> Deleting C1 failed; Cannot allocate memory(12) > >>>>> [20/Feb/2016:17:23:38 -0500] - database index operation failed BAD > >>>>> 1031, err=12 Cannot allocate memory > >>>>> [20/Feb/2016:17:23:38 -0500] - > >>>>> index_del_entry(changenumber=1328662,cn=changelog, 0x26) failed > >> (12) > >>>>> [20/Feb/2016:17:23:38 -0500] DSRetroclPlugin - delete_changerecord: > >>>>> could not delete change record 1328662 (rc: 1) > >>>>> [20/Feb/2016:17:23:38 -0500] - libdb: BDB2055 Lock table is out of > >>>>> available lock entries > >>>>> [20/Feb/2016:17:23:38 -0500] entryrdn-index - _entryrdn_get_elem: > >>>>> Failed to position cursor at the key: 1328666: Cannot allocate > >>>>> memory(12) > >>>>> [20/Feb/2016:17:23:38 -0500] entryrdn-index - > _entryrdn_delete_key: > >>>>> Failed to position cursor at the key: 1328666: Cannot allocate > >>>>> memory(12) > >>>>> [20/Feb/2016:17:23:38 -0500] - libdb: BDB2055 Lock table is out of > >>>>> available lock entries > >>>>> [20/Feb/2016:17:23:38 -0500] - database index operation failed BAD > >>>>> 1031, err=12 Cannot allocate memory > >>>>> [20/Feb/2016:17:23:38 -0500] - > >>>>> index_del_entry(changenumber=1328663,cn=changelog, 0x26) failed > >> (12) > >>>>> [20/Feb/2016:17:23:38 -0500] NSMMReplicationPlugin - changelog > >>>>> program > >>>>> - _cl5CompactDBs: failed to compact > >>>>> 5f1d2b12-cf1411e4-b055ba8a-f4b484f7; db error - 12 Cannot allocate > >>>>> memory > >>>>> [20/Feb/2016:17:23:38 -0500] DSRetroclPlugin - delete_changerecord: > >>>>> could not delete change record 1328663 (rc: 1) > >>>>> [20/Feb/2016:17:23:41 -0500] ldbm_back_delete - conn=0 op=0 [retry: > >>>>> 1] > >>>> No original_tombstone for changenumber=1330335,cn=changelog!! > >>>>> And then nothing. Was troubleshooting some clients that were > >>>>> having > >>>> issues resolving some trusted domain users. > >>>>> I restarted IPA and it rolled through a few thousand missing > >>>>> change records > >>>>> > >>>>> 23/Feb/2016:08:39:34 -0500] DSRetroclPlugin - delete_changerecord: > >>>>> could not delete change record 1328696 (rc: 32) > >>>>> > >>>>> Any thoughts as to what might have caused the lock table errors? > >>>> in BerkeleyDB this means that the number of pages which would have > >>>> to be locked in one transaction exceeds the configured number of > locks. > >>>> This could happen if eg a large group is deleted and for each > >>>> member of the group inside the same transaction the memberof > >>>> attribute has to be modified > >>> Are there any configuration options to increase that setting? And > >>> would it > >> have caused the replica to become unresponsive? > >> you can change > >> > >> nsslapd-db-locks > >> > >> in the entry: > >> > >> dn: cn=config,cn=ldbm database,cn=plugins,cn=config > >> > >> yes. in that state it would not process updates, the txn should be > >> finally aborted and the system should recover,but .. > > Is there any rule of thumb or anything I can look at to get an idea of what I > should increase that to or should it even be necessary? > > > > The current setting has a default of 10000 > > > > cn=database,cn=monitor,cn=ldbm database,cn=plugins,cn=config > > > > currently shows > > > > nsslapd-db-current-locks: 82 > > > > What might cause that to spike up that significantly to deplete the locks? > That's a pretty huge jump. > I have given you an example of what operation could use a high number of > page locks, to find out what was going on in your case would require to > investigate which operations were active when the problem started, what > the entries modified added looked like ...... > > Right, is there anything I can look at now that might give me any useful information? Access log looks pretty normal around that time. At the time the error occurred there would have been very little going on in the system other than internal processing and normal user access. My environment is almost entirely an AD trust setup with HBAC and sudo. There are very few users and groups in the local database for a large transaction to even be in the scope of possible that I can think of. I'm checking with the windows group to see if there was anything out of the ordinary going on in AD at the time but there were no changes scheduled. Is it possible that AD changes could be suspect? -andy From jester2.0 at gmail.com Tue Feb 23 18:32:11 2016 From: jester2.0 at gmail.com (Jester) Date: Tue, 23 Feb 2016 13:32:11 -0500 Subject: [Freeipa-users] Client Auth Failing - Ubuntu 15.10 Message-ID: New IPA install of Fedora 23 with FreeIPA 4.2.3. Client is Ubuntu Desktop 15.10 (nuc) with IPA client 4.1.4. ipa-client-install was successful. Host object created, DNS updated, etc. I am not able to log into the Ubuntu client with any user aside from Admin. I get inconsistent password prompting behavior. It doesn't always prompt. Most of the time, it just gives the client not found message. kinit works with all users on the IPA server directly. root at nuc0:/var/lib/sss# kinit admin Password for admin at MRJESTER.NET: root at nuc0:/var/lib/sss# kinit jon kinit: Client 'jon at MRJESTER.NET' not found in Kerberos database while getting initial credentials root at nuc0:/var/lib/sss# kinit jon-test Password for jon-test at MRJESTER.NET: Password expired. You must change it now. Enter new password: Enter it again: kinit: Password change failed while getting initial credentials root at nuc0:/var/lib/sss# kinit jon-test kinit: Client 'jon-test at MRJESTER.NET' not found in Kerberos database while getting initial credentials root at nuc0:/var/lib/sss# I am able to do GSSAPI auth from the client. /usr/bin/ldapsearch -LLL -H ldap://dir0.mrjester.net/ -Y GSSAPI -N -b "dc=mrjester,dc=net" cn Some various messages I see that stand out as possibly related. SSSD debug level 8 [parse_krb5_map_user] (0x0200): Warning: krb5_map_user is empty! [sssd[be[mrjester.net]]] [sdap_get_tgt_recv] (0x0400): Child responded: 14 [Decrypt integrity check failed], expired on [0] [sssd[be[mrjester.net]]] [sdap_kinit_done] (0x0100): Could not get TGT: 14 [Bad address] [sssd[be[mrjester.net]]] [sdap_cli_kinit_done] (0x0400): Cannot get a TGT: ret [1432158219](Authentication Failed) [sssd[be[mrjester.net]]] [fo_set_port_status] (0x0100): Marking port 389 of server 'dir0.mrjester.net' as 'not working' [sssd[be[mrjester.net]]] [fo_set_port_status] (0x0400): Marking port 389 of duplicate server 'dir0.mrjester.net' as 'not working' [sssd[be[mrjester.net]]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit [sssd[be[mrjester.net]]] [be_get_account_info] (0x0200): Got request for [0x1001][1][name=*] [sssd[be[mrjester.net]]] [be_req_set_domain] (0x0400): Changing request domain from [mrjester.net] to [mrjester.net] [sssd[be[mrjester.net]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] [sssd[be[mrjester.net]]] [sdap_search_user_next_base] (0x0400): Searching for users with base [cn=accounts,dc=mrjester,dc=net] [sssd[be[mrjester.net]]] [sdap_print_server] (0x2000): Searching 10.8.10.40 [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(uid=\2a)(objectclass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNumber=0))))][cn=accounts,dc=mrjester,dc=net]. [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uid] [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userPassword] [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uidNumber] [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gidNumber] [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gecos] [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [homeDirectory] [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginShell] [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [krbPrincipalName] [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberOf] [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaUniqueID] [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaNTSecurityIdentifier] [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [modifyTimestamp] [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [entryUSN] [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowLastChange] [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowMin] [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowMax] [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowWarning] [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowInactive] [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowExpire] [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowFlag] [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [krbLastPwdChange] [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [krbPasswordExpiration] [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [pwdAttribute] [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [authorizedService] [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [accountExpires] [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userAccountControl] [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [nsAccountLock] [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [host] [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginDisabled] [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginExpirationTime] [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginAllowedTimeMap] [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaSshPubKey] [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaUserAuthType] [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 12 [sssd[be[mrjester.net]]] [sdap_process_result] (0x2000): Trace: sh[0x1b6d100], connected[1], ops[0x1b6e810], ldap[0x1b7a970] [sssd[be[mrjester.net]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set [sssd[be[mrjester.net]]] [sdap_search_user_process] (0x0400): Search for users, returned 0 results. [sssd[be[mrjester.net]]] [sdap_get_users_done] (0x0040): Failed to retrieve users [sssd[be[mrjester.net]]] [sysdb_search_by_name] (0x0400): No such entry [sssd[be[mrjester.net]]] [sysdb_search_groups] (0x2000): Search groups with filter: (&(objectclass=group)(ghost=\2a)) [sssd[be[mrjester.net]]] [sysdb_search_groups] (0x2000): No such entry [sssd[be[mrjester.net]]] [sysdb_delete_user] (0x0400): Error: 2 (No such file or directory) [sssd[be[mrjester.net]]] [sysdb_search_by_name] (0x0400): No such entry [sssd[be[mrjester.net]]] [ipa_id_get_account_info_orig_done] (0x0080): Object not found, ending request [sssd[be[mrjester.net]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,0,Account info lookup failed [sssd[be[mrjester.net]]] [sdap_process_result] (0x2000): Trace: sh[0x1b6d100], connected[1], ops[(nil)], ldap[0x1b7a970] [sssd[be[mrjester.net]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! What additional information can I provide or things I can try? Thanks From marat.vyshegorodtsev at gmail.com Tue Feb 23 19:21:41 2016 From: marat.vyshegorodtsev at gmail.com (Marat Vyshegorodtsev) Date: Tue, 23 Feb 2016 11:21:41 -0800 Subject: [Freeipa-users] Recovering from data-only backup doesn't recover Kerberos keys properly Message-ID: Hi! I've been doing backups using the tool like this: ipa-backup --data --online I didn't want any configuration to be backed up, since it is managed from a chef recipe. However, when I tried to recover the backup to a fresh FreeIPA install, Kerberos (GSSAPI) broke ? I can't authenticate myself anywhere using Kerberos: CLI, HTTP, etc. LDAP password-based authentication works alright. After some googling and reading through the mailing list, I followed this manual and updated all keytabs for all services ? dirsrv, httpd, kadmin: http://www.freeipa.org/page/V3/Backup_and_Restore#Backup.2C_uninstall.2C_reinstall.2C_restore_JUST_the_LDAP_server Then it broke in a different way: for a correct session it says that my session is expired or just does nothing, for an incorrect password it responds with "password incorrect" (see screenshot). https://yadi.sk/i/WVe8u1_ZpNh3w For CLI it just says that the credentials are incorrect regardless of what credentials I provide. I suppose that all krbPrincipalKey fields are tied to some other encryption key that is not included in data-only backup. Could you please let me know how to regenerate krbPrincipalKey for all users or how to work around this issue? Best regards, Marat From ocervello at cccis.com Tue Feb 23 19:41:42 2016 From: ocervello at cccis.com (Olivier Cervello) Date: Tue, 23 Feb 2016 19:41:42 +0000 Subject: [Freeipa-users] Delete DNS record along with hostname Message-ID: Hello, I am trying to delete DNS record with the --updatedns options of ipa host-del command. The steps I followed were: root at server$ kinit admin root at server$ ipa host-del --updatedns 'ipa: ERROR: : host not found'. The following: ipa host-del (without --updatedns flag) doesn't return this error. ipa dnsrecord-del works fine as well, meaning I have permission to view and delete DNS records. I think it might be related to the following issue: https://fedorahosted.org/freeipa/ticket/4329 Please advise. Best, Olivier Cervello | DevOps Engineer CCC Information Services Inc. 222 Merchandise Mart Plaza, Suite 900 Chicago, IL 60654 Cell : 312-918-6018 ocervello at cccis.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Tue Feb 23 19:54:53 2016 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 23 Feb 2016 20:54:53 +0100 Subject: [Freeipa-users] Client Auth Failing - Ubuntu 15.10 In-Reply-To: References: Message-ID: <20160223195453.GB3625@hendrix> On Tue, Feb 23, 2016 at 01:32:11PM -0500, Jester wrote: > New IPA install of Fedora 23 with FreeIPA 4.2.3. Client is Ubuntu > Desktop 15.10 (nuc) with IPA client 4.1.4. > > ipa-client-install was successful. Host object created, DNS updated, etc. > > I am not able to log into the Ubuntu client with any user aside from > Admin. I get inconsistent password prompting behavior. It doesn't > always prompt. Most of the time, it just gives the client not found > message. kinit works with all users on the IPA server directly. > > root at nuc0:/var/lib/sss# kinit admin > Password for admin at MRJESTER.NET: > root at nuc0:/var/lib/sss# kinit jon > kinit: Client 'jon at MRJESTER.NET' not found in Kerberos database while > getting initial credentials > root at nuc0:/var/lib/sss# kinit jon-test > Password for jon-test at MRJESTER.NET: > Password expired. You must change it now. > Enter new password: > Enter it again: > kinit: Password change failed while getting initial credentials > root at nuc0:/var/lib/sss# kinit jon-test > kinit: Client 'jon-test at MRJESTER.NET' not found in Kerberos database > while getting initial credentials > root at nuc0:/var/lib/sss# > > I am able to do GSSAPI auth from the client. > > /usr/bin/ldapsearch -LLL -H ldap://dir0.mrjester.net/ -Y GSSAPI -N -b > "dc=mrjester,dc=net" cn > > Some various messages I see that stand out as possibly related. SSSD > debug level 8 > > [parse_krb5_map_user] (0x0200): Warning: krb5_map_user is empty! > > > [sssd[be[mrjester.net]]] [sdap_get_tgt_recv] (0x0400): Child > responded: 14 [Decrypt integrity check failed], expired on [0] Please look into ldap_child with high debug level, it looks like sssd has some issues authenticating to the directory. > > > [sssd[be[mrjester.net]]] [sdap_kinit_done] (0x0100): Could not get > TGT: 14 [Bad address] > [sssd[be[mrjester.net]]] [sdap_cli_kinit_done] (0x0400): Cannot get a > TGT: ret [1432158219](Authentication Failed) > [sssd[be[mrjester.net]]] [fo_set_port_status] (0x0100): Marking port > 389 of server 'dir0.mrjester.net' as 'not working' > [sssd[be[mrjester.net]]] [fo_set_port_status] (0x0400): Marking port > 389 of duplicate server 'dir0.mrjester.net' as 'not working' > > > [sssd[be[mrjester.net]]] [sbus_get_sender_id_send] (0x2000): Not a > sysbus message, quit > [sssd[be[mrjester.net]]] [be_get_account_info] (0x0200): Got request > for [0x1001][1][name=*] > [sssd[be[mrjester.net]]] [be_req_set_domain] (0x0400): Changing > request domain from [mrjester.net] to [mrjester.net] > [sssd[be[mrjester.net]]] [sdap_idmap_domain_has_algorithmic_mapping] > (0x0080): Could not parse domain SID from [(null)] > [sssd[be[mrjester.net]]] [sdap_search_user_next_base] (0x0400): > Searching for users with base [cn=accounts,dc=mrjester,dc=net] > [sssd[be[mrjester.net]]] [sdap_print_server] (0x2000): Searching 10.8.10.40 > [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x0400): calling > ldap_search_ext with > [(&(uid=\2a)(objectclass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNumber=0))))][cn=accounts,dc=mrjester,dc=net]. Do you use enumerate=true? > [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > Requesting attrs: [objectClass] > [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > Requesting attrs: [uid] > [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > Requesting attrs: [userPassword] > [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > Requesting attrs: [uidNumber] > [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > Requesting attrs: [gidNumber] > [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > Requesting attrs: [gecos] > [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > Requesting attrs: [homeDirectory] > [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > Requesting attrs: [loginShell] > [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > Requesting attrs: [krbPrincipalName] > [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > Requesting attrs: [cn] > [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > Requesting attrs: [memberOf] > [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > Requesting attrs: [ipaUniqueID] > [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > Requesting attrs: [ipaNTSecurityIdentifier] > [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > Requesting attrs: [modifyTimestamp] > [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > Requesting attrs: [entryUSN] > [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > Requesting attrs: [shadowLastChange] > [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > Requesting attrs: [shadowMin] > [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > Requesting attrs: [shadowMax] > [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > Requesting attrs: [shadowWarning] > [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > Requesting attrs: [shadowInactive] > [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > Requesting attrs: [shadowExpire] > [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > Requesting attrs: [shadowFlag] > [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > Requesting attrs: [krbLastPwdChange] > [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > Requesting attrs: [krbPasswordExpiration] > [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > Requesting attrs: [pwdAttribute] > [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > Requesting attrs: [authorizedService] > [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > Requesting attrs: [accountExpires] > [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > Requesting attrs: [userAccountControl] > [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > Requesting attrs: [nsAccountLock] > [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > Requesting attrs: [host] > [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > Requesting attrs: [loginDisabled] > [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > Requesting attrs: [loginExpirationTime] > [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > Requesting attrs: [loginAllowedTimeMap] > [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > Requesting attrs: [ipaSshPubKey] > [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > Requesting attrs: [ipaUserAuthType] > [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x2000): > ldap_search_ext called, msgid = 12 > [sssd[be[mrjester.net]]] [sdap_process_result] (0x2000): Trace: > sh[0x1b6d100], connected[1], ops[0x1b6e810], ldap[0x1b7a970] > [sssd[be[mrjester.net]]] [sdap_get_generic_op_finished] (0x0400): > Search result: Success(0), no errmsg set > [sssd[be[mrjester.net]]] [sdap_search_user_process] (0x0400): Search > for users, returned 0 results. > [sssd[be[mrjester.net]]] [sdap_get_users_done] (0x0040): Failed to > retrieve users > [sssd[be[mrjester.net]]] [sysdb_search_by_name] (0x0400): No such entry > [sssd[be[mrjester.net]]] [sysdb_search_groups] (0x2000): Search groups > with filter: (&(objectclass=group)(ghost=\2a)) > [sssd[be[mrjester.net]]] [sysdb_search_groups] (0x2000): No such entry > [sssd[be[mrjester.net]]] [sysdb_delete_user] (0x0400): Error: 2 (No > such file or directory) > [sssd[be[mrjester.net]]] [sysdb_search_by_name] (0x0400): No such entry > [sssd[be[mrjester.net]]] [ipa_id_get_account_info_orig_done] (0x0080): > Object not found, ending request > [sssd[be[mrjester.net]]] [acctinfo_callback] (0x0100): Request > processed. Returned 3,0,Account info lookup failed > [sssd[be[mrjester.net]]] [sdap_process_result] (0x2000): Trace: > sh[0x1b6d100], connected[1], ops[(nil)], ldap[0x1b7a970] > [sssd[be[mrjester.net]]] [sdap_process_result] (0x2000): Trace: > ldap_result found nothing! > > > > What additional information can I provide or things I can try? > > Thanks > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project From jester2.0 at gmail.com Tue Feb 23 20:14:20 2016 From: jester2.0 at gmail.com (Jester) Date: Tue, 23 Feb 2016 15:14:20 -0500 Subject: [Freeipa-users] Client Auth Failing - Ubuntu 15.10 In-Reply-To: <20160223195453.GB3625@hendrix> References: <20160223195453.GB3625@hendrix> Message-ID: Recent events from ldap_child. (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] [main] (0x0400): ldap_child started. (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] [main] (0x2000): context initialized (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] [unpack_buffer] (0x1000): total buffer size: 52 (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] [unpack_buffer] (0x1000): realm_str size: 9 (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] [unpack_buffer] (0x1000): got realm_str: MRJESTER.NET (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] [unpack_buffer] (0x1000): princ_str size: 19 (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] [unpack_buffer] (0x1000): got princ_str: host/nuc0.mrjester.net (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] [unpack_buffer] (0x1000): keytab_name size: 0 (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] [unpack_buffer] (0x1000): lifetime: 86400 (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] [unpack_buffer] (0x0200): Will run as [0][0]. (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] [privileged_krb5_setup] (0x2000): Kerberos context initialized (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] [main] (0x2000): Kerberos context initialized (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] [become_user] (0x0200): Trying to become user [0][0]. (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] [become_user] (0x0200): Already user [0]. (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] [main] (0x2000): Running as [0][0]. (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] [main] (0x2000): getting TGT sync (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] [ldap_child_get_tgt_sync] (0x2000): got realm_name: [MRJESTER.NET] (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] [ldap_child_get_tgt_sync] (0x0100): Principal name is: [host/nuc0.mrjester.net at MRJESTER.NET] (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] [ldap_child_get_tgt_sync] (0x0100): Using keytab [MEMORY:/etc/krb5.keytab] (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] [ldap_child_get_tgt_sync] (0x0100): Will canonicalize principals (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Decrypt integrity check failed (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] [ldap_child_get_tgt_sync] (0x2000): Unlinking [/var/lib/sss/db/ccache_MRJESTER.NET_GsnnAd] (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] [main] (0x0020): ldap_child_get_tgt_sync failed. (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] [prepare_response] (0x0400): Building response for result [-1765328353] (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] [pack_buffer] (0x2000): response size: 50 (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] [pack_buffer] (0x1000): result [14] krberr [-1765328353] msgsize [30] msg [Decrypt integrity check failed] (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] [main] (0x0400): ldap_child completed successfully (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] [main] (0x0400): ldap_child started. (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] [main] (0x2000): context initialized (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] [unpack_buffer] (0x1000): total buffer size: 52 (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] [unpack_buffer] (0x1000): realm_str size: 9 (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] [unpack_buffer] (0x1000): got realm_str: MRJESTER.NET (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] [unpack_buffer] (0x1000): princ_str size: 19 (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] [unpack_buffer] (0x1000): got princ_str: host/nuc0.mrjester.net (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] [unpack_buffer] (0x1000): keytab_name size: 0 (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] [unpack_buffer] (0x1000): lifetime: 86400 (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] [unpack_buffer] (0x0200): Will run as [0][0]. (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] [privileged_krb5_setup] (0x2000): Kerberos context initialized (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] [main] (0x2000): Kerberos context initialized (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] [become_user] (0x0200): Trying to become user [0][0]. (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] [become_user] (0x0200): Already user [0]. (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] [main] (0x2000): Running as [0][0]. (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] [main] (0x2000): getting TGT sync (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] [ldap_child_get_tgt_sync] (0x2000): got realm_name: [MRJESTER.NET] (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] [ldap_child_get_tgt_sync] (0x0100): Principal name is: [host/nuc0.mrjester.net at MRJESTER.NET] (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] [ldap_child_get_tgt_sync] (0x0100): Using keytab [MEMORY:/etc/krb5.keytab] (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] [ldap_child_get_tgt_sync] (0x0100): Will canonicalize principals (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Decrypt integrity check failed (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] [ldap_child_get_tgt_sync] (0x2000): Unlinking [/var/lib/sss/db/ccache_MRJESTER.NET_2fcAih] (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] [main] (0x0020): ldap_child_get_tgt_sync failed. (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] [prepare_response] (0x0400): Building response for result [-1765328353] (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] [pack_buffer] (0x2000): response size: 50 (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] [pack_buffer] (0x1000): result [14] krberr [-1765328353] msgsize [30] msg [Decrypt integrity check failed] (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] [main] (0x0400): ldap_child completed successfully (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] [main] (0x0400): ldap_child started. (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] [main] (0x2000): context initialized (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] [unpack_buffer] (0x1000): total buffer size: 52 (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] [unpack_buffer] (0x1000): realm_str size: 9 (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] [unpack_buffer] (0x1000): got realm_str: MRJESTER.NET (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] [unpack_buffer] (0x1000): princ_str size: 19 (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] [unpack_buffer] (0x1000): got princ_str: host/nuc0.mrjester.net (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] [unpack_buffer] (0x1000): keytab_name size: 0 (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] [unpack_buffer] (0x1000): lifetime: 86400 (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] [unpack_buffer] (0x0200): Will run as [0][0]. (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] [privileged_krb5_setup] (0x2000): Kerberos context initialized (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] [main] (0x2000): Kerberos context initialized (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] [become_user] (0x0200): Trying to become user [0][0]. (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] [become_user] (0x0200): Already user [0]. (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] [main] (0x2000): Running as [0][0]. (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] [main] (0x2000): getting TGT sync (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] [ldap_child_get_tgt_sync] (0x2000): got realm_name: [MRJESTER.NET] (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] [ldap_child_get_tgt_sync] (0x0100): Principal name is: [host/nuc0.mrjester.net at MRJESTER.NET] (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] [ldap_child_get_tgt_sync] (0x0100): Using keytab [MEMORY:/etc/krb5.keytab] (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] [ldap_child_get_tgt_sync] (0x0100): Will canonicalize principals (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] [ldap_child_get_tgt_sync] (0x2000): credentials initialized (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] [ldap_child_get_tgt_sync] (0x2000): keytab ccname: [FILE:/var/lib/sss/db/ccache_MRJESTER.NET_dnwqng] (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] [ldap_child_get_tgt_sync] (0x2000): credentials stored (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] [ldap_child_get_tgt_sync] (0x2000): Got KDC time offset (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] [ldap_child_get_tgt_sync] (0x2000): Renaming [/var/lib/sss/db/ccache_MRJESTER.NET_dnwqng] to [/var/lib/sss/db/ccache_MRJESTER.NET] (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] [prepare_response] (0x0400): Building response for result [0] (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] [pack_buffer] (0x2000): response size: 57 (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] [pack_buffer] (0x1000): result [0] krberr [0] msgsize [37] msg [FILE:/var/lib/sss/db/ccache_MRJESTER.NET] (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] [main] (0x0400): ldap_child completed successfully (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] [main] (0x0400): ldap_child started. (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] [main] (0x2000): context initialized (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] [unpack_buffer] (0x1000): total buffer size: 52 (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] [unpack_buffer] (0x1000): realm_str size: 9 (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] [unpack_buffer] (0x1000): got realm_str: MRJESTER.NET (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] [unpack_buffer] (0x1000): princ_str size: 19 (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] [unpack_buffer] (0x1000): got princ_str: host/nuc0.mrjester.net (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] [unpack_buffer] (0x1000): keytab_name size: 0 (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] [unpack_buffer] (0x1000): lifetime: 86400 (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] [unpack_buffer] (0x0200): Will run as [0][0]. (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] [privileged_krb5_setup] (0x2000): Kerberos context initialized (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] [main] (0x2000): Kerberos context initialized (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] [become_user] (0x0200): Trying to become user [0][0]. (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] [become_user] (0x0200): Already user [0]. (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] [main] (0x2000): Running as [0][0]. (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] [main] (0x2000): getting TGT sync (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] [ldap_child_get_tgt_sync] (0x2000): got realm_name: [MRJESTER.NET] (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] [ldap_child_get_tgt_sync] (0x0100): Principal name is: [host/nuc0.mrjester.net at MRJESTER.NET] (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] [ldap_child_get_tgt_sync] (0x0100): Using keytab [MEMORY:/etc/krb5.keytab] (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] [ldap_child_get_tgt_sync] (0x0100): Will canonicalize principals (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] [ldap_child_get_tgt_sync] (0x2000): credentials initialized (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] [ldap_child_get_tgt_sync] (0x2000): keytab ccname: [FILE:/var/lib/sss/db/ccache_MRJESTER.NET_QHqE3c] (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] [ldap_child_get_tgt_sync] (0x2000): credentials stored (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] [ldap_child_get_tgt_sync] (0x2000): Got KDC time offset (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] [ldap_child_get_tgt_sync] (0x2000): Renaming [/var/lib/sss/db/ccache_MRJESTER.NET_QHqE3c] to [/var/lib/sss/db/ccache_MRJESTER.NET] (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] [prepare_response] (0x0400): Building response for result [0] (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] [pack_buffer] (0x2000): response size: 57 (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] [pack_buffer] (0x1000): result [0] krberr [0] msgsize [37] msg [FILE:/var/lib/sss/db/ccache_MRJESTER.NET] (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] [main] (0x0400): ldap_child completed successfully On Tue, Feb 23, 2016 at 2:54 PM, Jakub Hrozek wrote: > On Tue, Feb 23, 2016 at 01:32:11PM -0500, Jester wrote: >> New IPA install of Fedora 23 with FreeIPA 4.2.3. Client is Ubuntu >> Desktop 15.10 (nuc) with IPA client 4.1.4. >> >> ipa-client-install was successful. Host object created, DNS updated, etc. >> >> I am not able to log into the Ubuntu client with any user aside from >> Admin. I get inconsistent password prompting behavior. It doesn't >> always prompt. Most of the time, it just gives the client not found >> message. kinit works with all users on the IPA server directly. >> >> root at nuc0:/var/lib/sss# kinit admin >> Password for admin at MRJESTER.NET: >> root at nuc0:/var/lib/sss# kinit jon >> kinit: Client 'jon at MRJESTER.NET' not found in Kerberos database while >> getting initial credentials >> root at nuc0:/var/lib/sss# kinit jon-test >> Password for jon-test at MRJESTER.NET: >> Password expired. You must change it now. >> Enter new password: >> Enter it again: >> kinit: Password change failed while getting initial credentials >> root at nuc0:/var/lib/sss# kinit jon-test >> kinit: Client 'jon-test at MRJESTER.NET' not found in Kerberos database >> while getting initial credentials >> root at nuc0:/var/lib/sss# >> >> I am able to do GSSAPI auth from the client. >> >> /usr/bin/ldapsearch -LLL -H ldap://dir0.mrjester.net/ -Y GSSAPI -N -b >> "dc=mrjester,dc=net" cn >> >> Some various messages I see that stand out as possibly related. SSSD >> debug level 8 >> >> [parse_krb5_map_user] (0x0200): Warning: krb5_map_user is empty! >> >> >> [sssd[be[mrjester.net]]] [sdap_get_tgt_recv] (0x0400): Child >> responded: 14 [Decrypt integrity check failed], expired on [0] > > Please look into ldap_child with high debug level, it looks like sssd > has some issues authenticating to the directory. > >> >> >> [sssd[be[mrjester.net]]] [sdap_kinit_done] (0x0100): Could not get >> TGT: 14 [Bad address] >> [sssd[be[mrjester.net]]] [sdap_cli_kinit_done] (0x0400): Cannot get a >> TGT: ret [1432158219](Authentication Failed) >> [sssd[be[mrjester.net]]] [fo_set_port_status] (0x0100): Marking port >> 389 of server 'dir0.mrjester.net' as 'not working' >> [sssd[be[mrjester.net]]] [fo_set_port_status] (0x0400): Marking port >> 389 of duplicate server 'dir0.mrjester.net' as 'not working' >> >> >> [sssd[be[mrjester.net]]] [sbus_get_sender_id_send] (0x2000): Not a >> sysbus message, quit >> [sssd[be[mrjester.net]]] [be_get_account_info] (0x0200): Got request >> for [0x1001][1][name=*] >> [sssd[be[mrjester.net]]] [be_req_set_domain] (0x0400): Changing >> request domain from [mrjester.net] to [mrjester.net] >> [sssd[be[mrjester.net]]] [sdap_idmap_domain_has_algorithmic_mapping] >> (0x0080): Could not parse domain SID from [(null)] >> [sssd[be[mrjester.net]]] [sdap_search_user_next_base] (0x0400): >> Searching for users with base [cn=accounts,dc=mrjester,dc=net] >> [sssd[be[mrjester.net]]] [sdap_print_server] (0x2000): Searching 10.8.10.40 >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x0400): calling >> ldap_search_ext with >> [(&(uid=\2a)(objectclass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNumber=0))))][cn=accounts,dc=mrjester,dc=net]. > > Do you use enumerate=true? > >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> Requesting attrs: [objectClass] >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> Requesting attrs: [uid] >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> Requesting attrs: [userPassword] >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> Requesting attrs: [uidNumber] >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> Requesting attrs: [gidNumber] >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> Requesting attrs: [gecos] >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> Requesting attrs: [homeDirectory] >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> Requesting attrs: [loginShell] >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> Requesting attrs: [krbPrincipalName] >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> Requesting attrs: [cn] >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> Requesting attrs: [memberOf] >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> Requesting attrs: [ipaUniqueID] >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> Requesting attrs: [ipaNTSecurityIdentifier] >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> Requesting attrs: [modifyTimestamp] >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> Requesting attrs: [entryUSN] >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> Requesting attrs: [shadowLastChange] >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> Requesting attrs: [shadowMin] >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> Requesting attrs: [shadowMax] >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> Requesting attrs: [shadowWarning] >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> Requesting attrs: [shadowInactive] >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> Requesting attrs: [shadowExpire] >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> Requesting attrs: [shadowFlag] >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> Requesting attrs: [krbLastPwdChange] >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> Requesting attrs: [krbPasswordExpiration] >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> Requesting attrs: [pwdAttribute] >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> Requesting attrs: [authorizedService] >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> Requesting attrs: [accountExpires] >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> Requesting attrs: [userAccountControl] >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> Requesting attrs: [nsAccountLock] >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> Requesting attrs: [host] >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> Requesting attrs: [loginDisabled] >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> Requesting attrs: [loginExpirationTime] >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> Requesting attrs: [loginAllowedTimeMap] >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> Requesting attrs: [ipaSshPubKey] >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> Requesting attrs: [ipaUserAuthType] >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x2000): >> ldap_search_ext called, msgid = 12 >> [sssd[be[mrjester.net]]] [sdap_process_result] (0x2000): Trace: >> sh[0x1b6d100], connected[1], ops[0x1b6e810], ldap[0x1b7a970] >> [sssd[be[mrjester.net]]] [sdap_get_generic_op_finished] (0x0400): >> Search result: Success(0), no errmsg set >> [sssd[be[mrjester.net]]] [sdap_search_user_process] (0x0400): Search >> for users, returned 0 results. >> [sssd[be[mrjester.net]]] [sdap_get_users_done] (0x0040): Failed to >> retrieve users >> [sssd[be[mrjester.net]]] [sysdb_search_by_name] (0x0400): No such entry >> [sssd[be[mrjester.net]]] [sysdb_search_groups] (0x2000): Search groups >> with filter: (&(objectclass=group)(ghost=\2a)) >> [sssd[be[mrjester.net]]] [sysdb_search_groups] (0x2000): No such entry >> [sssd[be[mrjester.net]]] [sysdb_delete_user] (0x0400): Error: 2 (No >> such file or directory) >> [sssd[be[mrjester.net]]] [sysdb_search_by_name] (0x0400): No such entry >> [sssd[be[mrjester.net]]] [ipa_id_get_account_info_orig_done] (0x0080): >> Object not found, ending request >> [sssd[be[mrjester.net]]] [acctinfo_callback] (0x0100): Request >> processed. Returned 3,0,Account info lookup failed >> [sssd[be[mrjester.net]]] [sdap_process_result] (0x2000): Trace: >> sh[0x1b6d100], connected[1], ops[(nil)], ldap[0x1b7a970] >> [sssd[be[mrjester.net]]] [sdap_process_result] (0x2000): Trace: >> ldap_result found nothing! >> >> >> >> What additional information can I provide or things I can try? >> >> Thanks >> >> -- >> Manage your subscription for the Freeipa-users mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-users >> Go to http://freeipa.org for more info on the project > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project From jhrozek at redhat.com Tue Feb 23 20:22:53 2016 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 23 Feb 2016 21:22:53 +0100 Subject: [Freeipa-users] Client Auth Failing - Ubuntu 15.10 In-Reply-To: References: <20160223195453.GB3625@hendrix> Message-ID: <20160223202253.GG3625@hendrix> On Tue, Feb 23, 2016 at 03:14:20PM -0500, Jester wrote: > Recent events from ldap_child. > > > (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] [main] (0x0400): > ldap_child started. > (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] [main] (0x2000): > context initialized > (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] [unpack_buffer] > (0x1000): total buffer size: 52 > (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] [unpack_buffer] > (0x1000): realm_str size: 9 > (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] [unpack_buffer] > (0x1000): got realm_str: MRJESTER.NET > (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] [unpack_buffer] > (0x1000): princ_str size: 19 > (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] [unpack_buffer] > (0x1000): got princ_str: host/nuc0.mrjester.net > (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] [unpack_buffer] > (0x1000): keytab_name size: 0 > (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] [unpack_buffer] > (0x1000): lifetime: 86400 > (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] [unpack_buffer] > (0x0200): Will run as [0][0]. > (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] > [privileged_krb5_setup] (0x2000): Kerberos context initialized > (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] [main] (0x2000): > Kerberos context initialized > (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] [become_user] > (0x0200): Trying to become user [0][0]. > (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] [become_user] > (0x0200): Already user [0]. > (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] [main] (0x2000): > Running as [0][0]. > (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] [main] (0x2000): > getting TGT sync > (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] > [ldap_child_get_tgt_sync] (0x2000): got realm_name: [MRJESTER.NET] > (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] > [ldap_child_get_tgt_sync] (0x0100): Principal name is: > [host/nuc0.mrjester.net at MRJESTER.NET] > (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] > [ldap_child_get_tgt_sync] (0x0100): Using keytab > [MEMORY:/etc/krb5.keytab] > (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] > [ldap_child_get_tgt_sync] (0x0100): Will canonicalize principals > (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] > [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: > Decrypt integrity check failed > (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] > [ldap_child_get_tgt_sync] (0x2000): Unlinking > [/var/lib/sss/db/ccache_MRJESTER.NET_GsnnAd] > (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] [main] (0x0020): > ldap_child_get_tgt_sync failed. > (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] > [prepare_response] (0x0400): Building response for result > [-1765328353] > (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] [pack_buffer] > (0x2000): response size: 50 > (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] [pack_buffer] > (0x1000): result [14] krberr [-1765328353] msgsize [30] msg [Decrypt > integrity check failed] Here authenticating with the keytab failed.. > (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] [main] (0x0400): > ldap_child completed successfully > (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] [main] (0x0400): > ldap_child started. > (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] [main] (0x2000): > context initialized > (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] [unpack_buffer] > (0x1000): total buffer size: 52 > (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] [unpack_buffer] > (0x1000): realm_str size: 9 > (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] [unpack_buffer] > (0x1000): got realm_str: MRJESTER.NET > (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] [unpack_buffer] > (0x1000): princ_str size: 19 > (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] [unpack_buffer] > (0x1000): got princ_str: host/nuc0.mrjester.net > (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] [unpack_buffer] > (0x1000): keytab_name size: 0 > (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] [unpack_buffer] > (0x1000): lifetime: 86400 > (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] [unpack_buffer] > (0x0200): Will run as [0][0]. > (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] > [privileged_krb5_setup] (0x2000): Kerberos context initialized > (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] [main] (0x2000): > Kerberos context initialized > (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] [become_user] > (0x0200): Trying to become user [0][0]. > (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] [become_user] > (0x0200): Already user [0]. > (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] [main] (0x2000): > Running as [0][0]. > (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] [main] (0x2000): > getting TGT sync > (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] > [ldap_child_get_tgt_sync] (0x2000): got realm_name: [MRJESTER.NET] > (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] > [ldap_child_get_tgt_sync] (0x0100): Principal name is: > [host/nuc0.mrjester.net at MRJESTER.NET] > (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] > [ldap_child_get_tgt_sync] (0x0100): Using keytab > [MEMORY:/etc/krb5.keytab] > (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] > [ldap_child_get_tgt_sync] (0x0100): Will canonicalize principals > (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] > [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: > Decrypt integrity check failed > (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] > [ldap_child_get_tgt_sync] (0x2000): Unlinking > [/var/lib/sss/db/ccache_MRJESTER.NET_2fcAih] > (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] [main] (0x0020): > ldap_child_get_tgt_sync failed. > (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] > [prepare_response] (0x0400): Building response for result > [-1765328353] > (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] [pack_buffer] > (0x2000): response size: 50 > (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] [pack_buffer] > (0x1000): result [14] krberr [-1765328353] msgsize [30] msg [Decrypt > integrity check failed] > (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] [main] (0x0400): > ldap_child completed successfully > (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] [main] (0x0400): > ldap_child started. > (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] [main] (0x2000): > context initialized > (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] [unpack_buffer] > (0x1000): total buffer size: 52 > (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] [unpack_buffer] > (0x1000): realm_str size: 9 > (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] [unpack_buffer] > (0x1000): got realm_str: MRJESTER.NET > (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] [unpack_buffer] > (0x1000): princ_str size: 19 > (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] [unpack_buffer] > (0x1000): got princ_str: host/nuc0.mrjester.net > (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] [unpack_buffer] > (0x1000): keytab_name size: 0 > (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] [unpack_buffer] > (0x1000): lifetime: 86400 > (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] [unpack_buffer] > (0x0200): Will run as [0][0]. > (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] > [privileged_krb5_setup] (0x2000): Kerberos context initialized > (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] [main] (0x2000): > Kerberos context initialized > (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] [become_user] > (0x0200): Trying to become user [0][0]. > (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] [become_user] > (0x0200): Already user [0]. > (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] [main] (0x2000): > Running as [0][0]. > (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] [main] (0x2000): > getting TGT sync > (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] > [ldap_child_get_tgt_sync] (0x2000): got realm_name: [MRJESTER.NET] > (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] > [ldap_child_get_tgt_sync] (0x0100): Principal name is: > [host/nuc0.mrjester.net at MRJESTER.NET] > (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] > [ldap_child_get_tgt_sync] (0x0100): Using keytab > [MEMORY:/etc/krb5.keytab] > (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] > [ldap_child_get_tgt_sync] (0x0100): Will canonicalize principals > (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] > [ldap_child_get_tgt_sync] (0x2000): credentials initialized > (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] > [ldap_child_get_tgt_sync] (0x2000): keytab ccname: > [FILE:/var/lib/sss/db/ccache_MRJESTER.NET_dnwqng] > (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] > [ldap_child_get_tgt_sync] (0x2000): credentials stored > (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] > [ldap_child_get_tgt_sync] (0x2000): Got KDC time offset > (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] > [ldap_child_get_tgt_sync] (0x2000): Renaming > [/var/lib/sss/db/ccache_MRJESTER.NET_dnwqng] to > [/var/lib/sss/db/ccache_MRJESTER.NET] > (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] > [prepare_response] (0x0400): Building response for result [0] > (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] [pack_buffer] > (0x2000): response size: 57 > (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] [pack_buffer] > (0x1000): result [0] krberr [0] msgsize [37] msg > [FILE:/var/lib/sss/db/ccache_MRJESTER.NET] > (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] [main] (0x0400): > ldap_child completed successfully > (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] [main] (0x0400): > ldap_child started. > (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] [main] (0x2000): > context initialized > (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] [unpack_buffer] > (0x1000): total buffer size: 52 > (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] [unpack_buffer] > (0x1000): realm_str size: 9 > (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] [unpack_buffer] > (0x1000): got realm_str: MRJESTER.NET > (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] [unpack_buffer] > (0x1000): princ_str size: 19 > (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] [unpack_buffer] > (0x1000): got princ_str: host/nuc0.mrjester.net > (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] [unpack_buffer] > (0x1000): keytab_name size: 0 > (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] [unpack_buffer] > (0x1000): lifetime: 86400 > (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] [unpack_buffer] > (0x0200): Will run as [0][0]. > (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] > [privileged_krb5_setup] (0x2000): Kerberos context initialized > (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] [main] (0x2000): > Kerberos context initialized > (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] [become_user] > (0x0200): Trying to become user [0][0]. > (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] [become_user] > (0x0200): Already user [0]. > (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] [main] (0x2000): > Running as [0][0]. > (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] [main] (0x2000): > getting TGT sync > (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] > [ldap_child_get_tgt_sync] (0x2000): got realm_name: [MRJESTER.NET] > (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] > [ldap_child_get_tgt_sync] (0x0100): Principal name is: > [host/nuc0.mrjester.net at MRJESTER.NET] > (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] > [ldap_child_get_tgt_sync] (0x0100): Using keytab > [MEMORY:/etc/krb5.keytab] > (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] > [ldap_child_get_tgt_sync] (0x0100): Will canonicalize principals > (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] > [ldap_child_get_tgt_sync] (0x2000): credentials initialized > (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] > [ldap_child_get_tgt_sync] (0x2000): keytab ccname: > [FILE:/var/lib/sss/db/ccache_MRJESTER.NET_QHqE3c] > (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] > [ldap_child_get_tgt_sync] (0x2000): credentials stored > (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] > [ldap_child_get_tgt_sync] (0x2000): Got KDC time offset > (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] > [ldap_child_get_tgt_sync] (0x2000): Renaming > [/var/lib/sss/db/ccache_MRJESTER.NET_QHqE3c] to > [/var/lib/sss/db/ccache_MRJESTER.NET] ...but here it succeeded...with the same principal.. did you maybe change the keytab in the meantime? Or, if you crank up the debug_level even higher, you should see the IP address of the KDC you're talking to. I wonder if it's always the one you'd expect.. > (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] > [prepare_response] (0x0400): Building response for result [0] > (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] [pack_buffer] > (0x2000): response size: 57 > (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] [pack_buffer] > (0x1000): result [0] krberr [0] msgsize [37] msg > [FILE:/var/lib/sss/db/ccache_MRJESTER.NET] > (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] [main] (0x0400): > ldap_child completed successfully > > > > On Tue, Feb 23, 2016 at 2:54 PM, Jakub Hrozek wrote: > > On Tue, Feb 23, 2016 at 01:32:11PM -0500, Jester wrote: > >> New IPA install of Fedora 23 with FreeIPA 4.2.3. Client is Ubuntu > >> Desktop 15.10 (nuc) with IPA client 4.1.4. > >> > >> ipa-client-install was successful. Host object created, DNS updated, etc. > >> > >> I am not able to log into the Ubuntu client with any user aside from > >> Admin. I get inconsistent password prompting behavior. It doesn't > >> always prompt. Most of the time, it just gives the client not found > >> message. kinit works with all users on the IPA server directly. > >> > >> root at nuc0:/var/lib/sss# kinit admin > >> Password for admin at MRJESTER.NET: > >> root at nuc0:/var/lib/sss# kinit jon > >> kinit: Client 'jon at MRJESTER.NET' not found in Kerberos database while > >> getting initial credentials > >> root at nuc0:/var/lib/sss# kinit jon-test > >> Password for jon-test at MRJESTER.NET: > >> Password expired. You must change it now. > >> Enter new password: > >> Enter it again: > >> kinit: Password change failed while getting initial credentials > >> root at nuc0:/var/lib/sss# kinit jon-test > >> kinit: Client 'jon-test at MRJESTER.NET' not found in Kerberos database > >> while getting initial credentials > >> root at nuc0:/var/lib/sss# > >> > >> I am able to do GSSAPI auth from the client. > >> > >> /usr/bin/ldapsearch -LLL -H ldap://dir0.mrjester.net/ -Y GSSAPI -N -b > >> "dc=mrjester,dc=net" cn > >> > >> Some various messages I see that stand out as possibly related. SSSD > >> debug level 8 > >> > >> [parse_krb5_map_user] (0x0200): Warning: krb5_map_user is empty! > >> > >> > >> [sssd[be[mrjester.net]]] [sdap_get_tgt_recv] (0x0400): Child > >> responded: 14 [Decrypt integrity check failed], expired on [0] > > > > Please look into ldap_child with high debug level, it looks like sssd > > has some issues authenticating to the directory. > > > >> > >> > >> [sssd[be[mrjester.net]]] [sdap_kinit_done] (0x0100): Could not get > >> TGT: 14 [Bad address] > >> [sssd[be[mrjester.net]]] [sdap_cli_kinit_done] (0x0400): Cannot get a > >> TGT: ret [1432158219](Authentication Failed) > >> [sssd[be[mrjester.net]]] [fo_set_port_status] (0x0100): Marking port > >> 389 of server 'dir0.mrjester.net' as 'not working' > >> [sssd[be[mrjester.net]]] [fo_set_port_status] (0x0400): Marking port > >> 389 of duplicate server 'dir0.mrjester.net' as 'not working' > >> > >> > >> [sssd[be[mrjester.net]]] [sbus_get_sender_id_send] (0x2000): Not a > >> sysbus message, quit > >> [sssd[be[mrjester.net]]] [be_get_account_info] (0x0200): Got request > >> for [0x1001][1][name=*] > >> [sssd[be[mrjester.net]]] [be_req_set_domain] (0x0400): Changing > >> request domain from [mrjester.net] to [mrjester.net] > >> [sssd[be[mrjester.net]]] [sdap_idmap_domain_has_algorithmic_mapping] > >> (0x0080): Could not parse domain SID from [(null)] > >> [sssd[be[mrjester.net]]] [sdap_search_user_next_base] (0x0400): > >> Searching for users with base [cn=accounts,dc=mrjester,dc=net] > >> [sssd[be[mrjester.net]]] [sdap_print_server] (0x2000): Searching 10.8.10.40 > >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x0400): calling > >> ldap_search_ext with > >> [(&(uid=\2a)(objectclass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNumber=0))))][cn=accounts,dc=mrjester,dc=net]. > > > > Do you use enumerate=true? > > > >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > >> Requesting attrs: [objectClass] > >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > >> Requesting attrs: [uid] > >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > >> Requesting attrs: [userPassword] > >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > >> Requesting attrs: [uidNumber] > >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > >> Requesting attrs: [gidNumber] > >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > >> Requesting attrs: [gecos] > >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > >> Requesting attrs: [homeDirectory] > >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > >> Requesting attrs: [loginShell] > >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > >> Requesting attrs: [krbPrincipalName] > >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > >> Requesting attrs: [cn] > >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > >> Requesting attrs: [memberOf] > >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > >> Requesting attrs: [ipaUniqueID] > >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > >> Requesting attrs: [ipaNTSecurityIdentifier] > >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > >> Requesting attrs: [modifyTimestamp] > >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > >> Requesting attrs: [entryUSN] > >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > >> Requesting attrs: [shadowLastChange] > >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > >> Requesting attrs: [shadowMin] > >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > >> Requesting attrs: [shadowMax] > >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > >> Requesting attrs: [shadowWarning] > >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > >> Requesting attrs: [shadowInactive] > >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > >> Requesting attrs: [shadowExpire] > >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > >> Requesting attrs: [shadowFlag] > >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > >> Requesting attrs: [krbLastPwdChange] > >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > >> Requesting attrs: [krbPasswordExpiration] > >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > >> Requesting attrs: [pwdAttribute] > >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > >> Requesting attrs: [authorizedService] > >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > >> Requesting attrs: [accountExpires] > >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > >> Requesting attrs: [userAccountControl] > >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > >> Requesting attrs: [nsAccountLock] > >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > >> Requesting attrs: [host] > >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > >> Requesting attrs: [loginDisabled] > >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > >> Requesting attrs: [loginExpirationTime] > >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > >> Requesting attrs: [loginAllowedTimeMap] > >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > >> Requesting attrs: [ipaSshPubKey] > >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): > >> Requesting attrs: [ipaUserAuthType] > >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x2000): > >> ldap_search_ext called, msgid = 12 > >> [sssd[be[mrjester.net]]] [sdap_process_result] (0x2000): Trace: > >> sh[0x1b6d100], connected[1], ops[0x1b6e810], ldap[0x1b7a970] > >> [sssd[be[mrjester.net]]] [sdap_get_generic_op_finished] (0x0400): > >> Search result: Success(0), no errmsg set > >> [sssd[be[mrjester.net]]] [sdap_search_user_process] (0x0400): Search > >> for users, returned 0 results. > >> [sssd[be[mrjester.net]]] [sdap_get_users_done] (0x0040): Failed to > >> retrieve users > >> [sssd[be[mrjester.net]]] [sysdb_search_by_name] (0x0400): No such entry > >> [sssd[be[mrjester.net]]] [sysdb_search_groups] (0x2000): Search groups > >> with filter: (&(objectclass=group)(ghost=\2a)) > >> [sssd[be[mrjester.net]]] [sysdb_search_groups] (0x2000): No such entry > >> [sssd[be[mrjester.net]]] [sysdb_delete_user] (0x0400): Error: 2 (No > >> such file or directory) > >> [sssd[be[mrjester.net]]] [sysdb_search_by_name] (0x0400): No such entry > >> [sssd[be[mrjester.net]]] [ipa_id_get_account_info_orig_done] (0x0080): > >> Object not found, ending request > >> [sssd[be[mrjester.net]]] [acctinfo_callback] (0x0100): Request > >> processed. Returned 3,0,Account info lookup failed > >> [sssd[be[mrjester.net]]] [sdap_process_result] (0x2000): Trace: > >> sh[0x1b6d100], connected[1], ops[(nil)], ldap[0x1b7a970] > >> [sssd[be[mrjester.net]]] [sdap_process_result] (0x2000): Trace: > >> ldap_result found nothing! > >> > >> > >> > >> What additional information can I provide or things I can try? > >> > >> Thanks > >> > >> -- > >> Manage your subscription for the Freeipa-users mailing list: > >> https://www.redhat.com/mailman/listinfo/freeipa-users > >> Go to http://freeipa.org for more info on the project > > > > -- > > Manage your subscription for the Freeipa-users mailing list: > > https://www.redhat.com/mailman/listinfo/freeipa-users > > Go to http://freeipa.org for more info on the project From jester2.0 at gmail.com Tue Feb 23 20:33:31 2016 From: jester2.0 at gmail.com (Jester) Date: Tue, 23 Feb 2016 15:33:31 -0500 Subject: [Freeipa-users] Client Auth Failing - Ubuntu 15.10 In-Reply-To: <20160223202253.GG3625@hendrix> References: <20160223195453.GB3625@hendrix> <20160223202253.GG3625@hendrix> Message-ID: Made no changes to the system between posting. Only tried a couple of kinits to generate some logs. Set sssd debug to 9, restarted, did a few kinits. root at nuc0:/var/log/sssd# service sssd start root at nuc0:/var/log/sssd# kinit admin Password for admin at MRJESTER.NET: root at nuc0:/var/log/sssd# kinit jon kinit: Client 'jon at MRJESTER.NET' not found in Kerberos database while getting initial credentials root at nuc0:/var/log/sssd# kinit jon-test Password for jon-test at MRJESTER.NET: kinit: Client 'jon-test at MRJESTER.NET' not found in Kerberos database while getting initial credentials On Tue, Feb 23, 2016 at 3:22 PM, Jakub Hrozek wrote: > On Tue, Feb 23, 2016 at 03:14:20PM -0500, Jester wrote: >> Recent events from ldap_child. >> >> >> (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] [main] (0x0400): >> ldap_child started. >> (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] [main] (0x2000): >> context initialized >> (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] [unpack_buffer] >> (0x1000): total buffer size: 52 >> (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] [unpack_buffer] >> (0x1000): realm_str size: 9 >> (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] [unpack_buffer] >> (0x1000): got realm_str: MRJESTER.NET >> (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] [unpack_buffer] >> (0x1000): princ_str size: 19 >> (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] [unpack_buffer] >> (0x1000): got princ_str: host/nuc0.mrjester.net >> (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] [unpack_buffer] >> (0x1000): keytab_name size: 0 >> (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] [unpack_buffer] >> (0x1000): lifetime: 86400 >> (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] [unpack_buffer] >> (0x0200): Will run as [0][0]. >> (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] >> [privileged_krb5_setup] (0x2000): Kerberos context initialized >> (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] [main] (0x2000): >> Kerberos context initialized >> (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] [become_user] >> (0x0200): Trying to become user [0][0]. >> (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] [become_user] >> (0x0200): Already user [0]. >> (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] [main] (0x2000): >> Running as [0][0]. >> (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] [main] (0x2000): >> getting TGT sync >> (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] >> [ldap_child_get_tgt_sync] (0x2000): got realm_name: [MRJESTER.NET] >> (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] >> [ldap_child_get_tgt_sync] (0x0100): Principal name is: >> [host/nuc0.mrjester.net at MRJESTER.NET] >> (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] >> [ldap_child_get_tgt_sync] (0x0100): Using keytab >> [MEMORY:/etc/krb5.keytab] >> (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] >> [ldap_child_get_tgt_sync] (0x0100): Will canonicalize principals >> (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] >> [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: >> Decrypt integrity check failed >> (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] >> [ldap_child_get_tgt_sync] (0x2000): Unlinking >> [/var/lib/sss/db/ccache_MRJESTER.NET_GsnnAd] >> (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] [main] (0x0020): >> ldap_child_get_tgt_sync failed. >> (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] >> [prepare_response] (0x0400): Building response for result >> [-1765328353] >> (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] [pack_buffer] >> (0x2000): response size: 50 >> (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] [pack_buffer] >> (0x1000): result [14] krberr [-1765328353] msgsize [30] msg [Decrypt >> integrity check failed] > > Here authenticating with the keytab failed.. > >> (Tue Feb 23 14:52:37 2016) [[sssd[ldap_child[5646]]]] [main] (0x0400): >> ldap_child completed successfully >> (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] [main] (0x0400): >> ldap_child started. >> (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] [main] (0x2000): >> context initialized >> (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] [unpack_buffer] >> (0x1000): total buffer size: 52 >> (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] [unpack_buffer] >> (0x1000): realm_str size: 9 >> (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] [unpack_buffer] >> (0x1000): got realm_str: MRJESTER.NET >> (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] [unpack_buffer] >> (0x1000): princ_str size: 19 >> (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] [unpack_buffer] >> (0x1000): got princ_str: host/nuc0.mrjester.net >> (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] [unpack_buffer] >> (0x1000): keytab_name size: 0 >> (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] [unpack_buffer] >> (0x1000): lifetime: 86400 >> (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] [unpack_buffer] >> (0x0200): Will run as [0][0]. >> (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] >> [privileged_krb5_setup] (0x2000): Kerberos context initialized >> (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] [main] (0x2000): >> Kerberos context initialized >> (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] [become_user] >> (0x0200): Trying to become user [0][0]. >> (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] [become_user] >> (0x0200): Already user [0]. >> (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] [main] (0x2000): >> Running as [0][0]. >> (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] [main] (0x2000): >> getting TGT sync >> (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] >> [ldap_child_get_tgt_sync] (0x2000): got realm_name: [MRJESTER.NET] >> (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] >> [ldap_child_get_tgt_sync] (0x0100): Principal name is: >> [host/nuc0.mrjester.net at MRJESTER.NET] >> (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] >> [ldap_child_get_tgt_sync] (0x0100): Using keytab >> [MEMORY:/etc/krb5.keytab] >> (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] >> [ldap_child_get_tgt_sync] (0x0100): Will canonicalize principals >> (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] >> [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: >> Decrypt integrity check failed >> (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] >> [ldap_child_get_tgt_sync] (0x2000): Unlinking >> [/var/lib/sss/db/ccache_MRJESTER.NET_2fcAih] >> (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] [main] (0x0020): >> ldap_child_get_tgt_sync failed. >> (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] >> [prepare_response] (0x0400): Building response for result >> [-1765328353] >> (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] [pack_buffer] >> (0x2000): response size: 50 >> (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] [pack_buffer] >> (0x1000): result [14] krberr [-1765328353] msgsize [30] msg [Decrypt >> integrity check failed] >> (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5647]]]] [main] (0x0400): >> ldap_child completed successfully >> (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] [main] (0x0400): >> ldap_child started. >> (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] [main] (0x2000): >> context initialized >> (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] [unpack_buffer] >> (0x1000): total buffer size: 52 >> (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] [unpack_buffer] >> (0x1000): realm_str size: 9 >> (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] [unpack_buffer] >> (0x1000): got realm_str: MRJESTER.NET >> (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] [unpack_buffer] >> (0x1000): princ_str size: 19 >> (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] [unpack_buffer] >> (0x1000): got princ_str: host/nuc0.mrjester.net >> (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] [unpack_buffer] >> (0x1000): keytab_name size: 0 >> (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] [unpack_buffer] >> (0x1000): lifetime: 86400 >> (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] [unpack_buffer] >> (0x0200): Will run as [0][0]. >> (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] >> [privileged_krb5_setup] (0x2000): Kerberos context initialized >> (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] [main] (0x2000): >> Kerberos context initialized >> (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] [become_user] >> (0x0200): Trying to become user [0][0]. >> (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] [become_user] >> (0x0200): Already user [0]. >> (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] [main] (0x2000): >> Running as [0][0]. >> (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] [main] (0x2000): >> getting TGT sync >> (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] >> [ldap_child_get_tgt_sync] (0x2000): got realm_name: [MRJESTER.NET] >> (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] >> [ldap_child_get_tgt_sync] (0x0100): Principal name is: >> [host/nuc0.mrjester.net at MRJESTER.NET] >> (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] >> [ldap_child_get_tgt_sync] (0x0100): Using keytab >> [MEMORY:/etc/krb5.keytab] >> (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] >> [ldap_child_get_tgt_sync] (0x0100): Will canonicalize principals >> (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] >> [ldap_child_get_tgt_sync] (0x2000): credentials initialized >> (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] >> [ldap_child_get_tgt_sync] (0x2000): keytab ccname: >> [FILE:/var/lib/sss/db/ccache_MRJESTER.NET_dnwqng] >> (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] >> [ldap_child_get_tgt_sync] (0x2000): credentials stored >> (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] >> [ldap_child_get_tgt_sync] (0x2000): Got KDC time offset >> (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] >> [ldap_child_get_tgt_sync] (0x2000): Renaming >> [/var/lib/sss/db/ccache_MRJESTER.NET_dnwqng] to >> [/var/lib/sss/db/ccache_MRJESTER.NET] >> (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] >> [prepare_response] (0x0400): Building response for result [0] >> (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] [pack_buffer] >> (0x2000): response size: 57 >> (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] [pack_buffer] >> (0x1000): result [0] krberr [0] msgsize [37] msg >> [FILE:/var/lib/sss/db/ccache_MRJESTER.NET] >> (Tue Feb 23 14:52:38 2016) [[sssd[ldap_child[5648]]]] [main] (0x0400): >> ldap_child completed successfully >> (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] [main] (0x0400): >> ldap_child started. >> (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] [main] (0x2000): >> context initialized >> (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] [unpack_buffer] >> (0x1000): total buffer size: 52 >> (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] [unpack_buffer] >> (0x1000): realm_str size: 9 >> (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] [unpack_buffer] >> (0x1000): got realm_str: MRJESTER.NET >> (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] [unpack_buffer] >> (0x1000): princ_str size: 19 >> (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] [unpack_buffer] >> (0x1000): got princ_str: host/nuc0.mrjester.net >> (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] [unpack_buffer] >> (0x1000): keytab_name size: 0 >> (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] [unpack_buffer] >> (0x1000): lifetime: 86400 >> (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] [unpack_buffer] >> (0x0200): Will run as [0][0]. >> (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] >> [privileged_krb5_setup] (0x2000): Kerberos context initialized >> (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] [main] (0x2000): >> Kerberos context initialized >> (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] [become_user] >> (0x0200): Trying to become user [0][0]. >> (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] [become_user] >> (0x0200): Already user [0]. >> (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] [main] (0x2000): >> Running as [0][0]. >> (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] [main] (0x2000): >> getting TGT sync >> (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] >> [ldap_child_get_tgt_sync] (0x2000): got realm_name: [MRJESTER.NET] >> (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] >> [ldap_child_get_tgt_sync] (0x0100): Principal name is: >> [host/nuc0.mrjester.net at MRJESTER.NET] >> (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] >> [ldap_child_get_tgt_sync] (0x0100): Using keytab >> [MEMORY:/etc/krb5.keytab] >> (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] >> [ldap_child_get_tgt_sync] (0x0100): Will canonicalize principals >> (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] >> [ldap_child_get_tgt_sync] (0x2000): credentials initialized >> (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] >> [ldap_child_get_tgt_sync] (0x2000): keytab ccname: >> [FILE:/var/lib/sss/db/ccache_MRJESTER.NET_QHqE3c] >> (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] >> [ldap_child_get_tgt_sync] (0x2000): credentials stored >> (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] >> [ldap_child_get_tgt_sync] (0x2000): Got KDC time offset >> (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] >> [ldap_child_get_tgt_sync] (0x2000): Renaming >> [/var/lib/sss/db/ccache_MRJESTER.NET_QHqE3c] to >> [/var/lib/sss/db/ccache_MRJESTER.NET] > > ...but here it succeeded...with the same principal.. > > did you maybe change the keytab in the meantime? > > Or, if you crank up the debug_level even higher, you should see the IP > address of the KDC you're talking to. I wonder if it's always the one > you'd expect.. > >> (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] >> [prepare_response] (0x0400): Building response for result [0] >> (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] [pack_buffer] >> (0x2000): response size: 57 >> (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] [pack_buffer] >> (0x1000): result [0] krberr [0] msgsize [37] msg >> [FILE:/var/lib/sss/db/ccache_MRJESTER.NET] >> (Tue Feb 23 15:07:40 2016) [[sssd[ldap_child[5745]]]] [main] (0x0400): >> ldap_child completed successfully >> >> >> >> On Tue, Feb 23, 2016 at 2:54 PM, Jakub Hrozek wrote: >> > On Tue, Feb 23, 2016 at 01:32:11PM -0500, Jester wrote: >> >> New IPA install of Fedora 23 with FreeIPA 4.2.3. Client is Ubuntu >> >> Desktop 15.10 (nuc) with IPA client 4.1.4. >> >> >> >> ipa-client-install was successful. Host object created, DNS updated, etc. >> >> >> >> I am not able to log into the Ubuntu client with any user aside from >> >> Admin. I get inconsistent password prompting behavior. It doesn't >> >> always prompt. Most of the time, it just gives the client not found >> >> message. kinit works with all users on the IPA server directly. >> >> >> >> root at nuc0:/var/lib/sss# kinit admin >> >> Password for admin at MRJESTER.NET: >> >> root at nuc0:/var/lib/sss# kinit jon >> >> kinit: Client 'jon at MRJESTER.NET' not found in Kerberos database while >> >> getting initial credentials >> >> root at nuc0:/var/lib/sss# kinit jon-test >> >> Password for jon-test at MRJESTER.NET: >> >> Password expired. You must change it now. >> >> Enter new password: >> >> Enter it again: >> >> kinit: Password change failed while getting initial credentials >> >> root at nuc0:/var/lib/sss# kinit jon-test >> >> kinit: Client 'jon-test at MRJESTER.NET' not found in Kerberos database >> >> while getting initial credentials >> >> root at nuc0:/var/lib/sss# >> >> >> >> I am able to do GSSAPI auth from the client. >> >> >> >> /usr/bin/ldapsearch -LLL -H ldap://dir0.mrjester.net/ -Y GSSAPI -N -b >> >> "dc=mrjester,dc=net" cn >> >> >> >> Some various messages I see that stand out as possibly related. SSSD >> >> debug level 8 >> >> >> >> [parse_krb5_map_user] (0x0200): Warning: krb5_map_user is empty! >> >> >> >> >> >> [sssd[be[mrjester.net]]] [sdap_get_tgt_recv] (0x0400): Child >> >> responded: 14 [Decrypt integrity check failed], expired on [0] >> > >> > Please look into ldap_child with high debug level, it looks like sssd >> > has some issues authenticating to the directory. >> > >> >> >> >> >> >> [sssd[be[mrjester.net]]] [sdap_kinit_done] (0x0100): Could not get >> >> TGT: 14 [Bad address] >> >> [sssd[be[mrjester.net]]] [sdap_cli_kinit_done] (0x0400): Cannot get a >> >> TGT: ret [1432158219](Authentication Failed) >> >> [sssd[be[mrjester.net]]] [fo_set_port_status] (0x0100): Marking port >> >> 389 of server 'dir0.mrjester.net' as 'not working' >> >> [sssd[be[mrjester.net]]] [fo_set_port_status] (0x0400): Marking port >> >> 389 of duplicate server 'dir0.mrjester.net' as 'not working' >> >> >> >> >> >> [sssd[be[mrjester.net]]] [sbus_get_sender_id_send] (0x2000): Not a >> >> sysbus message, quit >> >> [sssd[be[mrjester.net]]] [be_get_account_info] (0x0200): Got request >> >> for [0x1001][1][name=*] >> >> [sssd[be[mrjester.net]]] [be_req_set_domain] (0x0400): Changing >> >> request domain from [mrjester.net] to [mrjester.net] >> >> [sssd[be[mrjester.net]]] [sdap_idmap_domain_has_algorithmic_mapping] >> >> (0x0080): Could not parse domain SID from [(null)] >> >> [sssd[be[mrjester.net]]] [sdap_search_user_next_base] (0x0400): >> >> Searching for users with base [cn=accounts,dc=mrjester,dc=net] >> >> [sssd[be[mrjester.net]]] [sdap_print_server] (0x2000): Searching 10.8.10.40 >> >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x0400): calling >> >> ldap_search_ext with >> >> [(&(uid=\2a)(objectclass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNumber=0))))][cn=accounts,dc=mrjester,dc=net]. >> > >> > Do you use enumerate=true? >> > >> >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> >> Requesting attrs: [objectClass] >> >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> >> Requesting attrs: [uid] >> >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> >> Requesting attrs: [userPassword] >> >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> >> Requesting attrs: [uidNumber] >> >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> >> Requesting attrs: [gidNumber] >> >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> >> Requesting attrs: [gecos] >> >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> >> Requesting attrs: [homeDirectory] >> >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> >> Requesting attrs: [loginShell] >> >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> >> Requesting attrs: [krbPrincipalName] >> >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> >> Requesting attrs: [cn] >> >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> >> Requesting attrs: [memberOf] >> >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> >> Requesting attrs: [ipaUniqueID] >> >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> >> Requesting attrs: [ipaNTSecurityIdentifier] >> >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> >> Requesting attrs: [modifyTimestamp] >> >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> >> Requesting attrs: [entryUSN] >> >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> >> Requesting attrs: [shadowLastChange] >> >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> >> Requesting attrs: [shadowMin] >> >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> >> Requesting attrs: [shadowMax] >> >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> >> Requesting attrs: [shadowWarning] >> >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> >> Requesting attrs: [shadowInactive] >> >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> >> Requesting attrs: [shadowExpire] >> >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> >> Requesting attrs: [shadowFlag] >> >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> >> Requesting attrs: [krbLastPwdChange] >> >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> >> Requesting attrs: [krbPasswordExpiration] >> >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> >> Requesting attrs: [pwdAttribute] >> >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> >> Requesting attrs: [authorizedService] >> >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> >> Requesting attrs: [accountExpires] >> >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> >> Requesting attrs: [userAccountControl] >> >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> >> Requesting attrs: [nsAccountLock] >> >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> >> Requesting attrs: [host] >> >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> >> Requesting attrs: [loginDisabled] >> >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> >> Requesting attrs: [loginExpirationTime] >> >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> >> Requesting attrs: [loginAllowedTimeMap] >> >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> >> Requesting attrs: [ipaSshPubKey] >> >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x1000): >> >> Requesting attrs: [ipaUserAuthType] >> >> [sssd[be[mrjester.net]]] [sdap_get_generic_ext_step] (0x2000): >> >> ldap_search_ext called, msgid = 12 >> >> [sssd[be[mrjester.net]]] [sdap_process_result] (0x2000): Trace: >> >> sh[0x1b6d100], connected[1], ops[0x1b6e810], ldap[0x1b7a970] >> >> [sssd[be[mrjester.net]]] [sdap_get_generic_op_finished] (0x0400): >> >> Search result: Success(0), no errmsg set >> >> [sssd[be[mrjester.net]]] [sdap_search_user_process] (0x0400): Search >> >> for users, returned 0 results. >> >> [sssd[be[mrjester.net]]] [sdap_get_users_done] (0x0040): Failed to >> >> retrieve users >> >> [sssd[be[mrjester.net]]] [sysdb_search_by_name] (0x0400): No such entry >> >> [sssd[be[mrjester.net]]] [sysdb_search_groups] (0x2000): Search groups >> >> with filter: (&(objectclass=group)(ghost=\2a)) >> >> [sssd[be[mrjester.net]]] [sysdb_search_groups] (0x2000): No such entry >> >> [sssd[be[mrjester.net]]] [sysdb_delete_user] (0x0400): Error: 2 (No >> >> such file or directory) >> >> [sssd[be[mrjester.net]]] [sysdb_search_by_name] (0x0400): No such entry >> >> [sssd[be[mrjester.net]]] [ipa_id_get_account_info_orig_done] (0x0080): >> >> Object not found, ending request >> >> [sssd[be[mrjester.net]]] [acctinfo_callback] (0x0100): Request >> >> processed. Returned 3,0,Account info lookup failed >> >> [sssd[be[mrjester.net]]] [sdap_process_result] (0x2000): Trace: >> >> sh[0x1b6d100], connected[1], ops[(nil)], ldap[0x1b7a970] >> >> [sssd[be[mrjester.net]]] [sdap_process_result] (0x2000): Trace: >> >> ldap_result found nothing! >> >> >> >> >> >> >> >> What additional information can I provide or things I can try? >> >> >> >> Thanks >> >> >> >> -- >> >> Manage your subscription for the Freeipa-users mailing list: >> >> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> Go to http://freeipa.org for more info on the project >> > >> > -- >> > Manage your subscription for the Freeipa-users mailing list: >> > https://www.redhat.com/mailman/listinfo/freeipa-users >> > Go to http://freeipa.org for more info on the project -------------- next part -------------- A non-text attachment was scrubbed... Name: sssd_mrjester.net.log Type: text/x-log Size: 503437 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ldap_child.log Type: text/x-log Size: 8491 bytes Desc: not available URL: From jhrozek at redhat.com Tue Feb 23 20:42:38 2016 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 23 Feb 2016 21:42:38 +0100 Subject: [Freeipa-users] Client Auth Failing - Ubuntu 15.10 In-Reply-To: References: <20160223195453.GB3625@hendrix> <20160223202253.GG3625@hendrix> Message-ID: <20160223204238.GI3625@hendrix> On Tue, Feb 23, 2016 at 03:33:31PM -0500, Jester wrote: > Made no changes to the system between posting. Only tried a couple of > kinits to generate some logs. > > Set sssd debug to 9, restarted, did a few kinits. kinit doesn't hit sssd, but goes directly to the KDC. > > root at nuc0:/var/log/sssd# service sssd start > root at nuc0:/var/log/sssd# kinit admin > Password for admin at MRJESTER.NET: > root at nuc0:/var/log/sssd# kinit jon > kinit: Client 'jon at MRJESTER.NET' not found in Kerberos database while Again, if you're sure the principal 'jon' exists on the server, then I would suggest to try: KRB5_TRACE=/dev/stderr kinit jon and see if you talk to the KDC you expect. From jester2.0 at gmail.com Tue Feb 23 20:48:23 2016 From: jester2.0 at gmail.com (Jester) Date: Tue, 23 Feb 2016 15:48:23 -0500 Subject: [Freeipa-users] Client Auth Failing - Ubuntu 15.10 In-Reply-To: <20160223204238.GI3625@hendrix> References: <20160223195453.GB3625@hendrix> <20160223202253.GG3625@hendrix> <20160223204238.GI3625@hendrix> Message-ID: It looks like I have a replication issue. What process manages replication? root at nuc0:/var/log/sssd# KRB5_TRACE=/dev/stderr kinit jon [6175] 1456260239.45010: Resolving unique ccache of type KEYRING [6175] 1456260239.45131: Getting initial credentials for jon at MRJESTER.NET [6175] 1456260239.45497: Sending request (157 bytes) to MRJESTER.NET [6175] 1456260239.47271: Resolving hostname dir1.mrjester.net. [6175] 1456260239.48927: Sending initial UDP request to dgram 10.8.10.41:88 [6175] 1456260239.330215: Received answer (162 bytes) from dgram 10.8.10.41:88 [6175] 1456260239.330749: Response was from master KDC [6175] 1456260239.330781: Received error from KDC: -1765328378/Client not found in Kerberos database kinit: Client 'jon at MRJESTER.NET' not found in Kerberos database while getting initial credentials root at nuc0:/var/log/sssd# KRB5_TRACE=/dev/stderr kinit jon [6176] 1456260254.528974: Resolving unique ccache of type KEYRING [6176] 1456260254.529030: Getting initial credentials for jon at MRJESTER.NET [6176] 1456260254.529189: Sending request (157 bytes) to MRJESTER.NET [6176] 1456260254.530384: Resolving hostname dir1.mrjester.net. [6176] 1456260254.531265: Sending initial UDP request to dgram 10.8.10.41:88 [6176] 1456260254.533058: Received answer (162 bytes) from dgram 10.8.10.41:88 [6176] 1456260254.533548: Response was from master KDC [6176] 1456260254.533598: Received error from KDC: -1765328378/Client not found in Kerberos database kinit: Client 'jon at MRJESTER.NET' not found in Kerberos database while getting initial credentials root at nuc0:/var/log/sssd# KRB5_TRACE=/dev/stderr kinit jon [6177] 1456260255.920994: Resolving unique ccache of type KEYRING [6177] 1456260255.921053: Getting initial credentials for jon at MRJESTER.NET [6177] 1456260255.921216: Sending request (157 bytes) to MRJESTER.NET [6177] 1456260255.922335: Resolving hostname dir0.mrjester.net. [6177] 1456260255.923163: Sending initial UDP request to dgram 10.8.10.40:88 [6177] 1456260255.924918: Received answer (164 bytes) from dgram 10.8.10.40:88 [6177] 1456260255.925408: Response was from master KDC [6177] 1456260255.925452: Received error from KDC: -1765328361/Password has expired [6177] 1456260255.925471: Principal expired; getting changepw ticket [6177] 1456260255.925481: Getting initial credentials for jon at MRJESTER.NET [6177] 1456260255.925502: Setting initial creds service to kadmin/changepw [6177] 1456260255.925531: Sending request (156 bytes) to MRJESTER.NET (master) [6177] 1456260255.926385: Resolving hostname dir0.mrjester.net. [6177] 1456260255.926895: Sending initial UDP request to dgram 10.8.10.40:88 [6177] 1456260256.927253: Received answer (243 bytes) from dgram 10.8.10.40:88 [6177] 1456260256.927330: Received error from KDC: -1765328359/Additional pre-authentication required [6177] 1456260256.927382: Processing preauth types: 136, 19, 2, 133 [6177] 1456260256.927410: Selected etype info: etype aes256-cts, salt "v7Avt65hL wrote: > On Tue, Feb 23, 2016 at 03:33:31PM -0500, Jester wrote: >> Made no changes to the system between posting. Only tried a couple of >> kinits to generate some logs. >> >> Set sssd debug to 9, restarted, did a few kinits. > > kinit doesn't hit sssd, but goes directly to the KDC. > >> >> root at nuc0:/var/log/sssd# service sssd start >> root at nuc0:/var/log/sssd# kinit admin >> Password for admin at MRJESTER.NET: >> root at nuc0:/var/log/sssd# kinit jon >> kinit: Client 'jon at MRJESTER.NET' not found in Kerberos database while > > Again, if you're sure the principal 'jon' exists on the server, then I > would suggest to try: > KRB5_TRACE=/dev/stderr kinit jon > and see if you talk to the KDC you expect. From jester2.0 at gmail.com Tue Feb 23 21:16:48 2016 From: jester2.0 at gmail.com (Jester 2.0) Date: Tue, 23 Feb 2016 16:16:48 -0500 Subject: [Freeipa-users] Client Auth Failing - Ubuntu 15.10 In-Reply-To: <20160223204238.GI3625@hendrix> References: <20160223195453.GB3625@hendrix> <20160223202253.GG3625@hendrix> <20160223204238.GI3625@hendrix> Message-ID: The "KRB5_TRACE=/dev/stderr kinit jon" command helped out immensely by pointing out that it was failing on dir1, but not dir0. Turns out it was a DNS issue on my second directory server was breaking replication. Thank you for the assistance. On Tue, Feb 23, 2016 at 3:42 PM, Jakub Hrozek wrote: > On Tue, Feb 23, 2016 at 03:33:31PM -0500, Jester wrote: > > Made no changes to the system between posting. Only tried a couple of > > kinits to generate some logs. > > > > Set sssd debug to 9, restarted, did a few kinits. > > kinit doesn't hit sssd, but goes directly to the KDC. > > > > > root at nuc0:/var/log/sssd# service sssd start > > root at nuc0:/var/log/sssd# kinit admin > > Password for admin at MRJESTER.NET: > > root at nuc0:/var/log/sssd# kinit jon > > kinit: Client 'jon at MRJESTER.NET' not found in Kerberos database while > > Again, if you're sure the principal 'jon' exists on the server, then I > would suggest to try: > KRB5_TRACE=/dev/stderr kinit jon > and see if you talk to the KDC you expect. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From harri at afaics.de Tue Feb 23 22:50:10 2016 From: harri at afaics.de (Harald Dunkel) Date: Tue, 23 Feb 2016 23:50:10 +0100 Subject: [Freeipa-users] sssd went away, failed to restart In-Reply-To: <20160223124602.GH2468@mail.corp.redhat.com> References: <56CB16AF.9060303@aixigo.de> <20160222145152.GB3321@hendrix.arn.redhat.com> <56CC063E.7080900@aixigo.de> <20160223090003.GA3131@hendrix.redhat.com> <56CC2C86.8040109@aixigo.de> <20160223105825.GC2468@mail.corp.redhat.com> <56CC4A05.5040503@aixigo.de> <20160223124602.GH2468@mail.corp.redhat.com> Message-ID: <56CCE222.8010209@afaics.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Lukas, On 02/23/16 13:46, Lukas Slebodnik wrote: > On (23/02/16 13:01), Harald Dunkel wrote: >> On 02/23/2016 11:58 AM, Lukas Slebodnik wrote: >>> I would rather focus on different thing. Why is sssd_be process blocked for long time? >>> >> >> I have no idea. Was it really blocked? >> > It needn't be blocked itself. But it was busy with some non-blocking operation which main process considered as bad state. > Do you think this is OK? Did it try to terminate the unresponsive sssd_be, or did it just try to start a new one and ran into a conflict with the old? > Would you mind to share sssd log files with high debug level? > Surely I can increase the log level for sssd. I wonder why sssd_be doesn't write its own log file? >> >> Does it really have to be watched? Wouldn't it be the job of systemd to restart the service when it dies? >> > sssd works also on non-systemd distribution. We plan to reply on systemd. If you want to speed-up process then patches are always welcomed. > I highly appreciate your effort on providing compatibility with sysv init and others, but do you know that ipa-client-install (4.0.5) dies without systemd? I cannot tell for more recent ipa versions, since they are not available for Debian 8. > And moreover systemd would not solve the main issue. we should try to find out why sssd_be did not respond for long time. > Maybe it would help to improve the way how the monitor checks for un- responsive threads instead? We have no indication that sssd_be had any problem, except for sssd trying to start a new one. Since sssd couldn't I would assume that the old sssd_be was still up and running and that sssd was the buggy part. Would you agree to that? Regards Harri -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWzOIiAAoJEAqeKp5m04HLBRoH/3mxHo35XDqUlBFqNsB9k9Cj e+G+7I0gZtQr1+a0aWt5mSFTOesJIhL0xEUZZcr+6PTgGch8w9OThz9udYAqsa89 4s4KRwBHtMMggyQ4Z1eb+2KfOL4RmZbw85EfdN+8ExLY/Ui07SQDkiEpXW6WgeRx BIcUGqD877CH8q0hIrQte/VNY94LeN4rgxYhkAeijY7+tOSngP39ZHph2sx4a0ES jE5RgiVh799iRZLIk7OTrUmYKhAo1ZLfeMUqiOZYovjL3ZpxckbMr68vWkmePoj7 EFyZGjpZeOfix77iZ7h3kcQDH3nUv90F17F7N+BLmKEaKSgoe8YItEp98g4LO/4= =/Tr1 -----END PGP SIGNATURE----- From arequipeno at gmail.com Tue Feb 23 23:57:56 2016 From: arequipeno at gmail.com (Ian Pilcher) Date: Tue, 23 Feb 2016 17:57:56 -0600 Subject: [Freeipa-users] Traceback starting pki-cad - ca.subsystem.certreq missing? In-Reply-To: <56CB1A6A.4060206@redhat.com> References: <56CB1A6A.4060206@redhat.com> Message-ID: <56CCF204.3010001@gmail.com> > This looks as something PKI specific (given it is in /usr/sbin/pki-server), > CCing Endi from Dogtag team. From doing some additional Googling, it seems like the request should be in the PKI-CA dirsrv instance. Thus far, I haven't been able to figure out the incantation necessary to get ldapsearch to connect, though. -- ======================================================================== Ian Pilcher arequipeno at gmail.com -------- "I grew up before Mark Zuckerberg invented friendship" -------- ======================================================================== From jhrozek at redhat.com Wed Feb 24 08:24:47 2016 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 24 Feb 2016 09:24:47 +0100 Subject: [Freeipa-users] sssd went away, failed to restart In-Reply-To: <56CCE222.8010209@afaics.de> References: <56CB16AF.9060303@aixigo.de> <20160222145152.GB3321@hendrix.arn.redhat.com> <56CC063E.7080900@aixigo.de> <20160223090003.GA3131@hendrix.redhat.com> <56CC2C86.8040109@aixigo.de> <20160223105825.GC2468@mail.corp.redhat.com> <56CC4A05.5040503@aixigo.de> <20160223124602.GH2468@mail.corp.redhat.com> <56CCE222.8010209@afaics.de> Message-ID: <20160224082447.GL3625@hendrix> On Tue, Feb 23, 2016 at 11:50:10PM +0100, Harald Dunkel wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Hi Lukas, > > On 02/23/16 13:46, Lukas Slebodnik wrote: > > On (23/02/16 13:01), Harald Dunkel wrote: > >> On 02/23/2016 11:58 AM, Lukas Slebodnik wrote: > >>> I would rather focus on different thing. Why is sssd_be process blocked for long time? > >>> > >> > >> I have no idea. Was it really blocked? > >> > > It needn't be blocked itself. But it was busy with some non-blocking operation which main process considered as bad state. > > > > Do you think this is OK? Did it try to terminate the unresponsive > sssd_be, or did it just try to start a new one and ran into a > conflict with the old? We should have started a new one. Again, I'm speculating, but I /think/ that because the system might have been under load, the sssd_be took too long to restart and the monitor (sssd itself) gave up on it. Of course, it's something we should fix, but without a better idea how to reproduce the error in the first place, I'm not sure how to start to be honest. > > > Would you mind to share sssd log files with high debug level? > > > > Surely I can increase the log level for sssd. I wonder why > sssd_be doesn't write its own log file? Do you have debug_level=N in the [domain] section? > > >> > >> Does it really have to be watched? Wouldn't it be the job of systemd to restart the service when it dies? > >> > > sssd works also on non-systemd distribution. We plan to reply on systemd. If you want to speed-up process then patches are always welcomed. > > > > I highly appreciate your effort on providing compatibility with > sysv init and others, but do you know that ipa-client-install (4.0.5) > dies without systemd? I cannot tell for more recent ipa versions, > since they are not available for Debian 8. > > > And moreover systemd would not solve the main issue. we should try to find out why sssd_be did not respond for long time. > > > > Maybe it would help to improve the way how the monitor checks for un- > responsive threads instead? We have no indication that sssd_be had > any problem, except for sssd trying to start a new one. Since sssd > couldn't I would assume that the old sssd_be was still up and running > and that sssd was the buggy part. In future we would like to make heavier use of systemd features, we need to socket-activate the parts as a first step. Using systemd's watchdog would also be nice, but we're not there yet. From lslebodn at redhat.com Wed Feb 24 08:30:16 2016 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Wed, 24 Feb 2016 09:30:16 +0100 Subject: [Freeipa-users] sssd went away, failed to restart In-Reply-To: <56CCE222.8010209@afaics.de> References: <56CB16AF.9060303@aixigo.de> <20160222145152.GB3321@hendrix.arn.redhat.com> <56CC063E.7080900@aixigo.de> <20160223090003.GA3131@hendrix.redhat.com> <56CC2C86.8040109@aixigo.de> <20160223105825.GC2468@mail.corp.redhat.com> <56CC4A05.5040503@aixigo.de> <20160223124602.GH2468@mail.corp.redhat.com> <56CCE222.8010209@afaics.de> Message-ID: <20160224083015.GA1234@mail.corp.redhat.com> On (23/02/16 23:50), Harald Dunkel wrote: >Hi Lukas, > >On 02/23/16 13:46, Lukas Slebodnik wrote: >> On (23/02/16 13:01), Harald Dunkel wrote: >>> On 02/23/2016 11:58 AM, Lukas Slebodnik wrote: >>>> I would rather focus on different thing. Why is sssd_be process blocked for long time? >>>> >>> >>> I have no idea. Was it really blocked? >>> >> It needn't be blocked itself. But it was busy with some non-blocking operation which main process considered as bad state. >> > >Do you think this is OK? Did it try to terminate the unresponsive >sssd_be, or did it just try to start a new one and ran into a >conflict with the old? > It never tries to start new one. It just restart old one. >> Would you mind to share sssd log files with high debug level? >> > >Surely I can increase the log level for sssd. I wonder why >sssd_be doesn't write its own log file? > Only critical error messages are logged by default therefore you need to increase debug_level. >>> >>> Does it really have to be watched? Wouldn't it be the job of systemd to restart the service when it dies? >>> >> sssd works also on non-systemd distribution. We plan to reply on systemd. If you want to speed-up process then patches are always welcomed. >> > >I highly appreciate your effort on providing compatibility with >sysv init and others, but do you know that ipa-client-install (4.0.5) >dies without systemd? I cannot tell for more recent ipa versions, >since they are not available for Debian 8. > It's not problem of sssd but ipa-client-install. ipa-client-install != sssd. ipa-client-install just configure sssd to work with FreeIPA. sssd can work also with plain LDAP and/or Active Directory. >> And moreover systemd would not solve the main issue. we should try to find out why sssd_be did not respond for long time. >> > >Maybe it would help to improve the way how the monitor checks for un- >responsive threads instead? We have no indication that sssd_be had >any problem, except for sssd trying to start a new one. Since sssd ^^^^^^^^^^^^^^^ restart sssd_be >couldn't I would assume that the old sssd_be was still up and running >and that sssd was the buggy part. I woudl not assume it. But let's try to find out why sssd_be did not respond for long time. LS From mbasti at redhat.com Wed Feb 24 09:05:33 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 24 Feb 2016 10:05:33 +0100 Subject: [Freeipa-users] Delete DNS record along with hostname In-Reply-To: References: Message-ID: <56CD725D.1080408@redhat.com> On 23.02.2016 20:41, Olivier Cervello wrote: > > Hello, > > > I am trying to delete DNS record with the /--updatedns/ options of > /ipa host-del/ command. > > The steps I followed were: > > / > / > > /root at server$ kinit admin/ > > /root at server$ ipa host-del --updatedns/ > > /'ipa: ERROR: : host not found'./ > > > The following: > > > /ipa host-del / (without /--updatedns/ flag) doesn't return > this error. > > /ipa dnsrecord-del / works fine as well, meaning I > have permission to view and delete DNS records. > > > I think it might be related to the following issue: > > https://fedorahosted.org/freeipa/ticket/4329 > > > Please advise. > > > Best, > > > > Olivier Cervello | DevOps Engineer > CCC Information Services Inc. > 222 Merchandise Mart Plaza, Suite 900 Chicago, IL 60654 > Cell : 312-918-6018 > _ocervello at cccis.com_ > > > Hello, if you are kinited as admin, it should work. I need more information, what is your zone, record and hostname which are failing. Or better, if you are willing to do some debugging 1. please set debug=true in /etc/ipa/default.conf on server 2. apachectl graceful 3. execute host-del --updatedns 4. send us related entries from /var/log/httpd/error_log 5. remove debug line from default.conf and apachectl graceful Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Wed Feb 24 09:55:15 2016 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 24 Feb 2016 10:55:15 +0100 Subject: [Freeipa-users] server installation but client part fails In-Reply-To: <56CC8B20.3020102@yahoo.co.uk> References: <56CC739A.3030700@yahoo.co.uk> <56CC74EA.1080406@redhat.com> <56CC8B20.3020102@yahoo.co.uk> Message-ID: <56CD7E03.2060509@redhat.com> On 02/23/2016 05:38 PM, lejeczek wrote: > On 23/02/16 15:04, Rob Crittenden wrote: >> lejeczek wrote: >>> hi everybody >>> >>> I'm trying server installation but it fails, I think very last leg, and >>> I was hoping you could suggest places which I should start looking at. >>> >>> [7/7]: configuring ipa-dnskeysyncd to start on boot >>> Done configuring DNS key synchronization service (ipa-dnskeysyncd). >>> Restarting ipa-dnskeysyncd >>> Restarting named >>> Restarting the web server >>> ipa.ipapython.install.cli.install_tool(Server): ERROR Configuration of >>> client side components failed! >>> ipa-client-install returned: Command ''/usr/sbin/ipa-client-install' >>> '--on-master' '--unattended' '--domain' '.private.my.private' '--server' >>> '.private.my.private' '--realm' 'PRIVATE.MY.PRIVATE' '--hostname' >>> '.private.my.private'' returned non-zero exit status 1 >>> >>> many thanks >>> >> Look in /var/log/ipaserver-install.log and >> /var/log/ipaclient-install.log for a more detailed reason. >> >> rob >> > thanks Rob, I was missing client part of logs. > I just have to be careful with my finely grained configuration & config files. > If anybody stumbles upon similar errors - first thing to do is to make sure > your already existing httpd config(s) does not exclude *.conf from Apache's > main dir, which is where IPA renders its files. > This looks as a "+1" to this FreeIPA RFE: https://fedorahosted.org/freeipa/ticket/4431 If we carry our own minimal hardened httpd.conf, issues like this should not happen... From peljasz at yahoo.co.uk Wed Feb 24 11:21:13 2016 From: peljasz at yahoo.co.uk (lejeczek) Date: Wed, 24 Feb 2016 11:21:13 +0000 Subject: [Freeipa-users] installation of ipa-server successful but sssd fails.. Message-ID: <56CD9229.2000406@yahoo.co.uk> he everybody, my first tampering with install gets me: Feb 24 11:04:22 my.host.fake sssd[be[host.fake]][17425]: Starting up Feb 24 11:04:22 my.host.fake sssd[be[host.fake]][17425]: Failed to read keytab [default]: Bad address Feb 24 11:04:22 my.host.fake sssd[17406]: Exiting the SSSD. Could not restart critical service [host.fake]. Feb 24 11:04:22 my.host.fake systemd[1]: sssd.service: control process exited, code=exited status=1 Feb 24 11:04:22 my.host.fake systemd[1]: Failed to start System Security Services Daemon. Feb 24 11:04:22 my.host.fake systemd[1]: Unit sssd.service entered failed state. Feb 24 11:04:22 my.host.fake systemd[1]: sssd.service failed. And just after install process finishes I try: $ kinit admin kinit: Improper format of Kerberos configuration file while initializing Kerberos 5 library here is keytab server installer created/amended: (one thing that I'm not sure is the fact that my new "host.fake" domain is different from my previously existing ldap search "dc=xxx,dc=zzzzzzzz" - if it matters at all? Otherwise I have no clue. [domain/host.fake] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = host.fake id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = my.host.fake chpass_provider = ipa ipa_server = my.host.fake ipa_server_mode = True ldap_tls_cacert = /etc/ipa/ca.crt [domain/default] autofs_provider = ldap cache_credentials = True krb5_realm = # ldap_search_base = dc=xxx,dc=zzzzzzzz id_provider = ldap auth_provider = ldap chpass_provider = ldap ldap_uri = ldap://my.host.fake:1389/ ldap_id_use_start_tls = True ldap_tls_cacertdir = /etc/openldap/cacerts krb5_server = my.host.fake:88 [sssd] services = nss, sudo, pam, autofs, ssh config_file_version = 2 domains = host.fake [nss] memcache_timeout = 600 homedir_substring = /home regards. From sbose at redhat.com Wed Feb 24 11:26:26 2016 From: sbose at redhat.com (Sumit Bose) Date: Wed, 24 Feb 2016 12:26:26 +0100 Subject: [Freeipa-users] installation of ipa-server successful but sssd fails.. In-Reply-To: <56CD9229.2000406@yahoo.co.uk> References: <56CD9229.2000406@yahoo.co.uk> Message-ID: <20160224112626.GY7535@p.redhat.com> On Wed, Feb 24, 2016 at 11:21:13AM +0000, lejeczek wrote: > he everybody, > my first tampering with install gets me: > > Feb 24 11:04:22 my.host.fake sssd[be[host.fake]][17425]: Starting up > Feb 24 11:04:22 my.host.fake sssd[be[host.fake]][17425]: Failed to read > keytab [default]: Bad address > Feb 24 11:04:22 my.host.fake sssd[17406]: Exiting the SSSD. Could not > restart critical service [host.fake]. > Feb 24 11:04:22 my.host.fake systemd[1]: sssd.service: control process > exited, code=exited status=1 > Feb 24 11:04:22 my.host.fake systemd[1]: Failed to start System Security > Services Daemon. > Feb 24 11:04:22 my.host.fake systemd[1]: Unit sssd.service entered failed > state. > Feb 24 11:04:22 my.host.fake systemd[1]: sssd.service failed. > > And just after install process finishes I try: > $ kinit admin > kinit: Improper format of Kerberos configuration file while initializing > Kerberos 5 library I would recommend to check /etc/krb5.conf first. Since the library call SSSD uses the read the keytab will read /etc/krb5.conf as well, this might be the reason for the SSSD issue as well. HTH bye, Sumit > > here is keytab server installer created/amended: (one thing that I'm not > sure is the fact that my new "host.fake" domain is different from my > previously existing ldap search > "dc=xxx,dc=zzzzzzzz" - if it matters at all? Otherwise I have no clue. > > [domain/host.fake] > > cache_credentials = True > krb5_store_password_if_offline = True > ipa_domain = host.fake > id_provider = ipa > auth_provider = ipa > access_provider = ipa > ipa_hostname = my.host.fake > chpass_provider = ipa > ipa_server = my.host.fake > ipa_server_mode = True > ldap_tls_cacert = /etc/ipa/ca.crt > [domain/default] > autofs_provider = ldap > cache_credentials = True > krb5_realm = # > ldap_search_base = dc=xxx,dc=zzzzzzzz > id_provider = ldap > auth_provider = ldap > chpass_provider = ldap > ldap_uri = ldap://my.host.fake:1389/ > ldap_id_use_start_tls = True > ldap_tls_cacertdir = /etc/openldap/cacerts > > krb5_server = my.host.fake:88 > [sssd] > services = nss, sudo, pam, autofs, ssh > config_file_version = 2 > > domains = host.fake > > [nss] > memcache_timeout = 600 > homedir_substring = /home > > > regards. > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project From alex_sun at terra.com.br Wed Feb 24 11:53:01 2016 From: alex_sun at terra.com.br (Alexandre Borges) Date: Wed, 24 Feb 2016 08:53:01 -0300 Subject: [Freeipa-users] RHEL 7.2/Oracle Linux 7.2 - DNS FORWARD ZONE doesn't work! Message-ID: <000001d16ef9$ea6a92a0$bf3fb7e0$@terra.com.br> Dear colleagues, How are you? I?ve been facing a horrible problem with RHEL 7.2 (and Oracle Linux 7.2) when configuring IPA dnsforwardzone during the Active Directory integration. My configuration follows: IPA Server: 192.168.1.195 (rhel72-1.example.com) Win2012 (AD): 192.168.1.229 (win2012.example.local) ? different domains!!! Last command executed: [root at rhel72-1 ~]# ipa dnszone-find Zone name: 1.168.192.in-addr.arpa. Active zone: TRUE Authoritative nameserver: rhel72-1.example.com. Administrator e-mail address: hostmaster.example.com. SOA serial: 1456310858 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3600 Allow query: any; Allow transfer: none; Zone name: example.com. Active zone: TRUE Authoritative nameserver: rhel72-1.example.com. Administrator e-mail address: hostmaster.example.com. SOA serial: 1456310858 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3600 Allow query: any; Allow transfer: none; Allow in-line DNSSEC signing: FALSE ---------------------------- Number of entries returned 2 ---------------------------- [root at rhel72-1 ~]# ipa dnsconfig-show Global forwarders: 8.8.8.8, 8.8.4.4 [root at rhel72-1 ~]# ipa dnsforwardzone-add example.local --forwarder=192.168.1.229 --forward-policy=only Server will check DNS forwarder(s). This may take some time, please wait ... ipa: WARNING: DNSSEC validation failed: record 'example.local. SOA' failed DNSSEC validation on server 192.168.1.195. Please verify your DNSSEC configuration or disable DNSSEC validation on all IPA servers. Zone name: example.local. Active zone: TRUE Zone forwarders: 192.168.1.229 Forward policy: only [root at rhel72-1 ~]# ipa dnsforwardzone-find Zone name: example.local. Active zone: TRUE Zone forwarders: 192.168.1.229 Forward policy: only ---------------------------- Number of entries returned 1 ---------------------------- [root at rhel72-1 ~]# ping win2012.example.local ping: unknown host win2012.example.local I?ve already rebooted the host, but it hasn?t worked. The same problem is happening with Oracle Linux 7.2. Please, could you help me, please? I hope you have a nice day. Alexandre Borges. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus -------------- next part -------------- An HTML attachment was scrubbed... URL: From stijn.geselle at ypto.be Wed Feb 24 12:19:49 2016 From: stijn.geselle at ypto.be (Geselle Stijn) Date: Wed, 24 Feb 2016 12:19:49 +0000 Subject: [Freeipa-users] DNS operation timed out when installing IPA with forwarders In-Reply-To: <56CADD67.8060606@redhat.com> References: <986ED6C5BA6EFD49B00A4CEABE2E8FDA276AC4D5@HICTATRIUEM023.msnet.railb.be> <56C71189.3020303@redhat.com> <986ED6C5BA6EFD49B00A4CEABE2E8FDA276AC589@HICTATRIUEM023.msnet.railb.be> <56C72213.4090802@redhat.com> <56CADD67.8060606@redhat.com> Message-ID: <986ED6C5BA6EFD49B00A4CEABE2E8FDA276AD7A2@HICTATRIUEM023.msnet.railb.be> Adding a forward zone like Martin suggested works. I will definitely read the section you linked to get a better understanding of the differences between both. Doing a dig for google.com won't work in our case, because the servers are not internet-facing. Stijn -----Original Message----- From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Petr Spacek Sent: Monday 22 February 2016 11:05 To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] DNS operation timed out when installing IPA with forwarders On 19.2.2016 15:09, Martin Basti wrote: > On 19.02.2016 14:57, Geselle Stijn wrote: >> That seems to fail: >> >> [root at ipa ~]# dig @192.168.1.1 . SOA >> >> ; <<>> DiG 9.9.4-RedHat-9.9.4-29.el7_2.2 <<>> @192.168.1.1 . SOA ; (1 >> server >> found) ;; global options: +cmd ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 44900 ;; flags: >> qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 >> >> ;; OPT PSEUDOSECTION: >> ; EDNS: version: 0, flags:; udp: 4000 ;; QUESTION SECTION: >> ;. IN SOA >> >> ;; Query time: 11153 msec >> ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Fri Feb 19 14:42:51 >> CET 2016 ;; MSG SIZE rcvd: 28 >> >> >> But if I add a new record (e.g. CNAME) to DNS in Windows Server and >> try to ping to that CNAME, I get resolved correctly. >> >> -Stijn > Hello, > > global forwarders, specified by --forwarder option during installation > or added via ipa dnsconfig-mod, must be able to resolve root zone > (your forwarder/server 192.168.1.1 is not able to return result for root zone). > > You probably need to specify forwardzone, for the particular windows > domain you use, instead of specify it as global forwarder. > > ipa dnsforwardzone-add --forwarder 192.168.1.1 Martin could be right, but this depends on your setup. Please read chapter "Managing DNS Forwarding" in our docs: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/managing-dns-forwarding.html It explains the difference between global and per-zone forwarding (I hope :-) so it will be easier to decide what should be used. BTW does the command $ dig @192.168.1.1 www.google.com. SOA work? (Assuming that neither google.com. nor com. are your AD domains :-)) Petr^2 Spacek >> -----Original Message----- >> From: freeipa-users-bounces at redhat.com >> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Petr Spacek >> Sent: Friday 19 February 2016 13:59 >> To: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] DNS operation timed out when installing >> IPA with forwarders >> >> On 19.2.2016 13:50, Geselle Stijn wrote: >>> Hello fellow FreeIPA users, >>> >>> I'm trying to setup FreeIPA in a lab environment (VirtualBox): >>> >>> >>> - ad.example.com (Windows Server 2008 R2) - 192.168.1.1 >>> >>> - ipa.example.com (CentOS 7.2) - 192.168.1.2 >>> Both machines can ping each other, DNS resolving works: >>> >>> [root at ipa ~] nslookup ad >>> Server: 192.168.1.1 >>> Address: 192.168.1.1#53 >>> >>> Name: ad.example.com >>> Address: 192.168.1.1 >>> >>> >>> I executed: >>> >>> yum install -y "*ipa-server*" bind bind-dyndb-ldap >>> ipa-server-install --domain=example.com --realm=EXAMPLE.COM >>> --setup-dns >>> --forwarder=192.168.1.1 >>> >>> But the installation wizard fails at: >>> >>> Checking DNS forwarders, please wait ... >>> ipa : ERROR DNS server 192.168.1.1: query '. SOA': The DNS >>> operation timed out after 10.00124242 seconds >>> ipa.ipapython.install.cli.install_tool(Server): ERROR DNS server >>> 192.168.1.1: query '. SOA': The DNS operation timed out after >>> 10.00124242 seconds >>> >>> >>> Is there some way I can better troubleshoot this? Can I increase the >>> DNS timeout (maybe it's simply slow via VirtualBox). >> Please try command >> $ dig @192.168.1.1 . SOA >> and paste the output here. >> >> Also, please run the installer again with option --debug. >> >> I will have a look. >> >> Thank you. >> >> -- >> Petr^2 Spacek -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project From mbasti at redhat.com Wed Feb 24 12:28:12 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 24 Feb 2016 13:28:12 +0100 Subject: [Freeipa-users] RHEL 7.2/Oracle Linux 7.2 - DNS FORWARD ZONE doesn't work! In-Reply-To: <000001d16ef9$ea6a92a0$bf3fb7e0$@terra.com.br> References: <000001d16ef9$ea6a92a0$bf3fb7e0$@terra.com.br> Message-ID: <56CDA1DC.2010505@redhat.com> On 24.02.2016 12:53, Alexandre Borges wrote: > > Dear colleagues, > > How are you? > > I?ve been facing a horrible problem with RHEL 7.2 (and Oracle Linux > 7.2) when configuring IPA dnsforwardzone during the Active Directory > integration. > > My configuration follows: > > IPA Server: 192.168.1.195 (rhel72-1.example.com) > > Win2012 (AD): 192.168.1.229 (win2012.example.local) ? different domains!!! > > Last command executed: > > [root at rhel72-1 ~]# *ipa dnszone-find* > > Zone name: 1.168.192.in-addr.arpa. > > Active zone: TRUE > > Authoritative nameserver: rhel72-1.example.com. > > Administrator e-mail address: hostmaster.example.com. > > SOA serial: 1456310858 > > SOA refresh: 3600 > > SOA retry: 900 > > SOA expire: 1209600 > > SOA minimum: 3600 > > Allow query: any; > > Allow transfer: none; > > Zone name: example.com. > > Active zone: TRUE > > Authoritative nameserver: rhel72-1.example.com. > > Administrator e-mail address: hostmaster.example.com. > > SOA serial: 1456310858 > > SOA refresh: 3600 > > SOA retry: 900 > > SOA expire: 1209600 > > SOA minimum: 3600 > > Allow query: any; > > Allow transfer: none; > > Allow in-line DNSSEC signing: FALSE > > ---------------------------- > > Number of entries returned 2 > > ---------------------------- > > [root at rhel72-1 ~]# *ipa dnsconfig-show* > > Global forwarders: 8.8.8.8, 8.8.4.4 > > [root at rhel72-1 ~]# *ipa dnsforwardzone-add example.local > --forwarder=192.168.1.229 --forward-policy=only* > > Server will check DNS forwarder(s). > > This may take some time, please wait ... > > ipa: WARNING: DNSSEC validation failed: record 'example.local. SOA' > failed DNSSEC validation on server 192.168.1.195. > > Please verify your DNSSEC configuration or disable DNSSEC validation > on all IPA servers. > > Zone name: example.local. > > Active zone: TRUE > > Zone forwarders: 192.168.1.229 > > Forward policy: only > > [root at rhel72-1 ~]# *ipa dnsforwardzone-find* > > Zone name: example.local. > > Active zone: TRUE > > Zone forwarders: 192.168.1.229 > > Forward policy: only > > ---------------------------- > > Number of entries returned 1 > > ---------------------------- > > *[root at rhel72-1 ~]#* *ping win2012.example.local* > > ping: unknown host win2012.example.local > > I?ve already rebooted the host, but it hasn?t worked. > > The same problem is happening with Oracle Linux 7.2. > > Please, could you help me, please? > > I hope you have a nice day. > > Alexandre Borges. > Hello Alexandre, because you use .local TLD domain, it will be never DNSSEC valid domain, please disable DNSSEC validation on all DNS servers, as warning from dnsforwardzone-add suggested. /etc/named.conf set dnssec-validation to no Martin Basti > > This email has been sent from a > virus-free computer protected by Avast. > www.avast.com > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkupka at redhat.com Wed Feb 24 12:29:49 2016 From: dkupka at redhat.com (David Kupka) Date: Wed, 24 Feb 2016 13:29:49 +0100 Subject: [Freeipa-users] Recovering from data-only backup doesn't recover Kerberos keys properly In-Reply-To: References: Message-ID: <56CDA23D.7050801@redhat.com> On 23/02/16 20:21, Marat Vyshegorodtsev wrote: > Hi! > > I've been doing backups using the tool like this: > ipa-backup --data --online > > I didn't want any configuration to be backed up, since it is managed > from a chef recipe. > > However, when I tried to recover the backup to a fresh FreeIPA > install, Kerberos (GSSAPI) broke ? I can't authenticate myself > anywhere using Kerberos: CLI, HTTP, etc. > > LDAP password-based authentication works alright. > > After some googling and reading through the mailing list, I followed > this manual and updated all keytabs for all services ? dirsrv, httpd, > kadmin: http://www.freeipa.org/page/V3/Backup_and_Restore#Backup.2C_uninstall.2C_reinstall.2C_restore_JUST_the_LDAP_server > > Then it broke in a different way: for a correct session it says that > my session is expired or just does nothing, for an incorrect password > it responds with "password incorrect" (see screenshot). > https://yadi.sk/i/WVe8u1_ZpNh3w > > For CLI it just says that the credentials are incorrect regardless of > what credentials I provide. > > I suppose that all krbPrincipalKey fields are tied to some other > encryption key that is not included in data-only backup. > > Could you please let me know how to regenerate krbPrincipalKey for all > users or how to work around this issue? > > Best regards, > Marat > Hello Marat, I would say that this is expected. During freeipa-server installation all service and host kerberos keys are generated randomly, stored in Directory Server and in keytab accessible to the host/service. When you reinstall freeipa-server all keys are regenerated and no longer matches the ones stored in your backup. You can use ipa-getkeytab(1) with Directory Manager credentials to retrieve new keys but think it's not enough to make it work again. Hopefully, someone, who understand kerberos better will advice. -- David Kupka From harenberg at physik.uni-wuppertal.de Wed Feb 24 12:45:25 2016 From: harenberg at physik.uni-wuppertal.de (Torsten Harenberg) Date: Wed, 24 Feb 2016 13:45:25 +0100 Subject: [Freeipa-users] sssd went away, failed to restart In-Reply-To: <20160224083015.GA1234@mail.corp.redhat.com> References: <56CB16AF.9060303@aixigo.de> <20160222145152.GB3321@hendrix.arn.redhat.com> <56CC063E.7080900@aixigo.de> <20160223090003.GA3131@hendrix.redhat.com> <56CC2C86.8040109@aixigo.de> <20160223105825.GC2468@mail.corp.redhat.com> <56CC4A05.5040503@aixigo.de> <20160223124602.GH2468@mail.corp.redhat.com> <56CCE222.8010209@afaics.de> <20160224083015.GA1234@mail.corp.redhat.com> Message-ID: <56CDA5E5.5060901@physik.uni-wuppertal.de> Hi, we had some trouble with sssd in the past as well on machines which suffer from a high IO load (cluster nodes running scientific calculations). Following a suggestion from the list here, we moved the local sssd cache into a tmpfs, so our fstab contains now a tmpfs /var/lib/sss/db tmpfs size=50M,auto 1 2 That solved our problem with sssd. I'm not sure it would help you, but maybe still worth a thought.. BR TH -- Dr. Torsten Harenberg harenberg at physik.uni-wuppertal.de Bergische Universitaet Fakult?t 4 - Physik Tel.: +49 (0)202 439-3521 Gaussstr. 20 Fax : +49 (0)202 439-2811 42097 Wuppertal From peljasz at yahoo.co.uk Wed Feb 24 12:45:55 2016 From: peljasz at yahoo.co.uk (lejeczek) Date: Wed, 24 Feb 2016 12:45:55 +0000 Subject: [Freeipa-users] installation of ipa-server successful but sssd fails.. In-Reply-To: <20160224112626.GY7535@p.redhat.com> References: <56CD9229.2000406@yahoo.co.uk> <20160224112626.GY7535@p.redhat.com> Message-ID: <56CDA603.9060004@yahoo.co.uk> On 24/02/16 11:26, Sumit Bose wrote: > On Wed, Feb 24, 2016 at 11:21:13AM +0000, lejeczek wrote: >> he everybody, >> my first tampering with install gets me: >> >> Feb 24 11:04:22 my.host.fake sssd[be[host.fake]][17425]: Starting up >> Feb 24 11:04:22 my.host.fake sssd[be[host.fake]][17425]: Failed to read >> keytab [default]: Bad address >> Feb 24 11:04:22 my.host.fake sssd[17406]: Exiting the SSSD. Could not >> restart critical service [host.fake]. >> Feb 24 11:04:22 my.host.fake systemd[1]: sssd.service: control process >> exited, code=exited status=1 >> Feb 24 11:04:22 my.host.fake systemd[1]: Failed to start System Security >> Services Daemon. >> Feb 24 11:04:22 my.host.fake systemd[1]: Unit sssd.service entered failed >> state. >> Feb 24 11:04:22 my.host.fake systemd[1]: sssd.service failed. >> >> And just after install process finishes I try: >> $ kinit admin >> kinit: Improper format of Kerberos configuration file while initializing >> Kerberos 5 library > I would recommend to check /etc/krb5.conf first. Since the library call > SSSD uses the read the keytab will read /etc/krb5.conf as well, this > might be the reason for the SSSD issue as well. I said keytab, I meant config, which is below included. > > HTH > > bye, > Sumit > >> here is keytab server installer created/amended: (one thing that I'm not >> sure is the fact that my new "host.fake" domain is different from my >> previously existing ldap search >> "dc=xxx,dc=zzzzzzzz" - if it matters at all? Otherwise I have no clue. >> >> [domain/host.fake] >> >> cache_credentials = True >> krb5_store_password_if_offline = True >> ipa_domain = host.fake >> id_provider = ipa >> auth_provider = ipa >> access_provider = ipa >> ipa_hostname = my.host.fake >> chpass_provider = ipa >> ipa_server = my.host.fake >> ipa_server_mode = True >> ldap_tls_cacert = /etc/ipa/ca.crt >> [domain/default] >> autofs_provider = ldap >> cache_credentials = True >> krb5_realm = # >> ldap_search_base = dc=xxx,dc=zzzzzzzz >> id_provider = ldap >> auth_provider = ldap >> chpass_provider = ldap >> ldap_uri = ldap://my.host.fake:1389/ >> ldap_id_use_start_tls = True >> ldap_tls_cacertdir = /etc/openldap/cacerts >> >> krb5_server = my.host.fake:88 >> [sssd] >> services = nss, sudo, pam, autofs, ssh >> config_file_version = 2 >> >> domains = host.fake >> >> [nss] >> memcache_timeout = 600 >> homedir_substring = /home >> >> >> regards. >> >> -- >> Manage your subscription for the Freeipa-users mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-users >> Go to http://freeipa.org for more info on the project From jpazdziora at redhat.com Wed Feb 24 12:51:19 2016 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Wed, 24 Feb 2016 13:51:19 +0100 Subject: [Freeipa-users] FreeIPA server in Docker containers -- master/fedora-23 updated Message-ID: <20160224125118.GC25950@redhat.com> Hello FreeIPA users interested in running the server in containers, I have now merged the systemd-based work into master and fedora-23 branches of https://github.com/adelton/docker-freeipa while making sure the output of ipa-server-install (instead of systemd service start messages) are shown during docker run to make behaviour as close to the old images as possible. The container will upgrade the data in the data volume automatically but it's certainly advisable to have backup before moving to the new image. You need to invoke docker run with -v /sys/fs/cgroup:/sys/fs/cgroup:ro to make systemd in the container happy. Unfortunatelly, the automated builds at Docker hub seem to be broken due to (likely) bug https://github.com/docker/docker/issues/6980 on Docker hub build servers. Docker support was notified (ticket 11208). Please build the images from sources until the issue is resolved. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat From sor-ipa at bofh.czest.pl Wed Feb 24 12:30:11 2016 From: sor-ipa at bofh.czest.pl (Daniel) Date: Wed, 24 Feb 2016 13:30:11 +0100 Subject: [Freeipa-users] FreeIPA problem with AD trust setup Message-ID: <922d4f078a8b1de538c499ea5855c304@bofh.czest.pl> Hello, I'm trying to setup trust with our AD domain in test environment, but I've got an error: ipa trust-add --type=ad test.local --two-way=1 --admin Administrator --password ipa: ERROR: CIFS server communication error: code "-1073741725", message "User exists" (both may be "None"). After enabling log level = 100 in /var/log/httpd/error_log I have: s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fcca804f880 s4_tevent: Run immediate event "tevent_req_trigger": 0x7fcca804f880 lsa_CreateTrustedDomainEx2: struct lsa_CreateTrustedDomainEx2 out: struct lsa_CreateTrustedDomainEx2 trustdom_handle : * trustdom_handle: struct policy_handle handle_type : 0x00000000 (0) uuid : 00000000-0000-0000-0000-000000000000 result : NT_STATUS_USER_EXISTS rpc reply data: [0000] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ [0010] 00 00 00 00 63 00 00 C0 ....c... [Wed Feb 24 12:44:21.039930 2016] [:error] [pid 17911] ipa: INFO: [jsonserver_kerb] admin at LINUX.TEST.LOCAL: trust_add(u'test.local', trust_type=u'ad', realm_admin=u'Administrator', realm_passwd=u'********', bidirectional=True, all=False, raw=False, version=u'2.156'): RemoteRetrieveError FreeIPA domain is configured as subdomain linux.test.local of our main domain test.local (on DNS I've added NS records for subdomain delegation). FreeIPA server: CentOS 7.2 ipa-server-4.2.0-15.el7_2.6.x86_64 ipa-server-trust-ad-4.2.0-15.el7_2.6.x86_64 AD server: Windows 2012 with about 2k users. -- Regards Daniel Kubiak From rcritten at redhat.com Wed Feb 24 14:07:03 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 24 Feb 2016 09:07:03 -0500 Subject: [Freeipa-users] Recovering from data-only backup doesn't recover Kerberos keys properly In-Reply-To: <56CDA23D.7050801@redhat.com> References: <56CDA23D.7050801@redhat.com> Message-ID: <56CDB907.20707@redhat.com> David Kupka wrote: > On 23/02/16 20:21, Marat Vyshegorodtsev wrote: >> Hi! >> >> I've been doing backups using the tool like this: >> ipa-backup --data --online >> >> I didn't want any configuration to be backed up, since it is managed >> from a chef recipe. >> >> However, when I tried to recover the backup to a fresh FreeIPA >> install, Kerberos (GSSAPI) broke ? I can't authenticate myself >> anywhere using Kerberos: CLI, HTTP, etc. >> >> LDAP password-based authentication works alright. >> >> After some googling and reading through the mailing list, I followed >> this manual and updated all keytabs for all services ? dirsrv, httpd, >> kadmin: >> http://www.freeipa.org/page/V3/Backup_and_Restore#Backup.2C_uninstall.2C_reinstall.2C_restore_JUST_the_LDAP_server >> >> >> Then it broke in a different way: for a correct session it says that >> my session is expired or just does nothing, for an incorrect password >> it responds with "password incorrect" (see screenshot). >> https://yadi.sk/i/WVe8u1_ZpNh3w >> >> For CLI it just says that the credentials are incorrect regardless of >> what credentials I provide. >> >> I suppose that all krbPrincipalKey fields are tied to some other >> encryption key that is not included in data-only backup. >> >> Could you please let me know how to regenerate krbPrincipalKey for all >> users or how to work around this issue? >> >> Best regards, >> Marat >> > > Hello Marat, > I would say that this is expected. During freeipa-server installation > all service and host kerberos keys are generated randomly, stored in > Directory Server and in keytab accessible to the host/service. > When you reinstall freeipa-server all keys are regenerated and no longer > matches the ones stored in your backup. > > You can use ipa-getkeytab(1) with Directory Manager credentials to > retrieve new keys but think it's not enough to make it work again. > Hopefully, someone, who understand kerberos better will advice. > It sounds like he already re-generated those keytabs. The Kerberos master key is stored in LDAP so you should already have it. Seeing the KDC and/or httpd logs might be useful. Are you just toying with this or did something go horribly wrong and you're trying to restore a production environment? The instructions you used were strictly a brain dump, something I goofed around with as an interesting thought project but didn't entirely nail down. It is quite possible I didn't document some important step in there. rob From sbose at redhat.com Wed Feb 24 14:22:38 2016 From: sbose at redhat.com (Sumit Bose) Date: Wed, 24 Feb 2016 15:22:38 +0100 Subject: [Freeipa-users] installation of ipa-server successful but sssd fails.. In-Reply-To: <56CDA603.9060004@yahoo.co.uk> References: <56CD9229.2000406@yahoo.co.uk> <20160224112626.GY7535@p.redhat.com> <56CDA603.9060004@yahoo.co.uk> Message-ID: <20160224142238.GD7535@p.redhat.com> On Wed, Feb 24, 2016 at 12:45:55PM +0000, lejeczek wrote: > On 24/02/16 11:26, Sumit Bose wrote: > >On Wed, Feb 24, 2016 at 11:21:13AM +0000, lejeczek wrote: > >>he everybody, > >>my first tampering with install gets me: > >> > >>Feb 24 11:04:22 my.host.fake sssd[be[host.fake]][17425]: Starting up > >>Feb 24 11:04:22 my.host.fake sssd[be[host.fake]][17425]: Failed to read > >>keytab [default]: Bad address > >>Feb 24 11:04:22 my.host.fake sssd[17406]: Exiting the SSSD. Could not > >>restart critical service [host.fake]. > >>Feb 24 11:04:22 my.host.fake systemd[1]: sssd.service: control process > >>exited, code=exited status=1 > >>Feb 24 11:04:22 my.host.fake systemd[1]: Failed to start System Security > >>Services Daemon. > >>Feb 24 11:04:22 my.host.fake systemd[1]: Unit sssd.service entered failed > >>state. > >>Feb 24 11:04:22 my.host.fake systemd[1]: sssd.service failed. > >> > >>And just after install process finishes I try: > >>$ kinit admin > >>kinit: Improper format of Kerberos configuration file while initializing > >>Kerberos 5 library > >I would recommend to check /etc/krb5.conf first. Since the library call > >SSSD uses the read the keytab will read /etc/krb5.conf as well, this > >might be the reason for the SSSD issue as well. > I said keytab, I meant config, which is below included. This is the SSSD config file /etc/sssd/sssd.conf, I really meant /etc/krb5.conf. bye, Sumit > > > >HTH > > > >bye, > >Sumit > > > >>here is keytab server installer created/amended: (one thing that I'm not > >>sure is the fact that my new "host.fake" domain is different from my > >>previously existing ldap search > >>"dc=xxx,dc=zzzzzzzz" - if it matters at all? Otherwise I have no clue. > >> > >>[domain/host.fake] > >> > >>cache_credentials = True > >>krb5_store_password_if_offline = True > >>ipa_domain = host.fake > >>id_provider = ipa > >>auth_provider = ipa > >>access_provider = ipa > >>ipa_hostname = my.host.fake > >>chpass_provider = ipa > >>ipa_server = my.host.fake > >>ipa_server_mode = True > >>ldap_tls_cacert = /etc/ipa/ca.crt > >>[domain/default] > >>autofs_provider = ldap > >>cache_credentials = True > >>krb5_realm = # > >>ldap_search_base = dc=xxx,dc=zzzzzzzz > >>id_provider = ldap > >>auth_provider = ldap > >>chpass_provider = ldap > >>ldap_uri = ldap://my.host.fake:1389/ > >>ldap_id_use_start_tls = True > >>ldap_tls_cacertdir = /etc/openldap/cacerts > >> > >>krb5_server = my.host.fake:88 > >>[sssd] > >>services = nss, sudo, pam, autofs, ssh > >>config_file_version = 2 > >> > >>domains = host.fake > >> > >>[nss] > >>memcache_timeout = 600 > >>homedir_substring = /home > >> > >> > >>regards. > >> > >>-- > >>Manage your subscription for the Freeipa-users mailing list: > >>https://www.redhat.com/mailman/listinfo/freeipa-users > >>Go to http://freeipa.org for more info on the project > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project From sbose at redhat.com Wed Feb 24 14:34:59 2016 From: sbose at redhat.com (Sumit Bose) Date: Wed, 24 Feb 2016 15:34:59 +0100 Subject: [Freeipa-users] FreeIPA problem with AD trust setup In-Reply-To: <922d4f078a8b1de538c499ea5855c304@bofh.czest.pl> References: <922d4f078a8b1de538c499ea5855c304@bofh.czest.pl> Message-ID: <20160224143459.GE7535@p.redhat.com> On Wed, Feb 24, 2016 at 01:30:11PM +0100, Daniel wrote: > Hello, > > I'm trying to setup trust with our AD domain in test environment, but I've > got an error: > ipa trust-add --type=ad test.local --two-way=1 --admin Administrator > --password > > ipa: ERROR: CIFS server communication error: code "-1073741725", > message "User exists" (both may be "None"). > > After enabling log level = 100 in /var/log/httpd/error_log I have: > s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7fcca804f880 > s4_tevent: Run immediate event "tevent_req_trigger": 0x7fcca804f880 > lsa_CreateTrustedDomainEx2: struct lsa_CreateTrustedDomainEx2 > out: struct lsa_CreateTrustedDomainEx2 > trustdom_handle : * > trustdom_handle: struct policy_handle > handle_type : 0x00000000 (0) > uuid : > 00000000-0000-0000-0000-000000000000 > result : NT_STATUS_USER_EXISTS > rpc reply data: > [0000] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ > [0010] 00 00 00 00 63 00 00 C0 ....c... > [Wed Feb 24 12:44:21.039930 2016] [:error] [pid 17911] ipa: INFO: > [jsonserver_kerb] admin at LINUX.TEST.LOCAL: trust_add(u'test.local', > trust_type=u'ad', realm_admin=u'Administrator', realm_passwd=u'********', > bidirectional=True, all=False, raw=False, version=u'2.156'): > RemoteRetrieveError The error indicates that there already is a trust on the AD side to a domain which either has linux.test.local as domain name or the same NetBIOS domain name. The default NetBIOS domain name in your case would be LINUX. You can check the names of the trusted domains with e.g. ldapsearch -H ldap://ad-server.ad.domain' -b 'dc=ad,dc=domain' 'objectClass=trustedDomain' name flatName trustPartner If you cannot find a collision here there might be a collision with the NetBIOS name of a host. You can check this with ldapsearch -H ldap://ad-server.ad.domain -b 'dc=ad,dc=domain' 'objectClass=computer' sAMAccountName HTH bye, Sumit > > FreeIPA domain is configured as subdomain linux.test.local of our main > domain test.local (on DNS I've added NS records for subdomain delegation). > > FreeIPA server: > CentOS 7.2 > ipa-server-4.2.0-15.el7_2.6.x86_64 > ipa-server-trust-ad-4.2.0-15.el7_2.6.x86_64 > > AD server: > Windows 2012 with about 2k users. > > -- > Regards > Daniel Kubiak > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project From peljasz at yahoo.co.uk Wed Feb 24 17:20:30 2016 From: peljasz at yahoo.co.uk (lejeczek) Date: Wed, 24 Feb 2016 17:20:30 +0000 Subject: [Freeipa-users] installation of ipa-server successful but sssd fails.. In-Reply-To: <20160224142238.GD7535@p.redhat.com> References: <56CD9229.2000406@yahoo.co.uk> <20160224112626.GY7535@p.redhat.com> <56CDA603.9060004@yahoo.co.uk> <20160224142238.GD7535@p.redhat.com> Message-ID: <56CDE65E.9050909@yahoo.co.uk> On 24/02/16 14:22, Sumit Bose wrote: > On Wed, Feb 24, 2016 at 12:45:55PM +0000, lejeczek wrote: >> On 24/02/16 11:26, Sumit Bose wrote: >>> On Wed, Feb 24, 2016 at 11:21:13AM +0000, lejeczek wrote: >>>> he everybody, >>>> my first tampering with install gets me: >>>> >>>> Feb 24 11:04:22 my.host.fake sssd[be[host.fake]][17425]: Starting up >>>> Feb 24 11:04:22 my.host.fake sssd[be[host.fake]][17425]: Failed to read >>>> keytab [default]: Bad address >>>> Feb 24 11:04:22 my.host.fake sssd[17406]: Exiting the SSSD. Could not >>>> restart critical service [host.fake]. >>>> Feb 24 11:04:22 my.host.fake systemd[1]: sssd.service: control process >>>> exited, code=exited status=1 >>>> Feb 24 11:04:22 my.host.fake systemd[1]: Failed to start System Security >>>> Services Daemon. >>>> Feb 24 11:04:22 my.host.fake systemd[1]: Unit sssd.service entered failed >>>> state. >>>> Feb 24 11:04:22 my.host.fake systemd[1]: sssd.service failed. >>>> >>>> And just after install process finishes I try: >>>> $ kinit admin >>>> kinit: Improper format of Kerberos configuration file while initializing >>>> Kerberos 5 library >>> I would recommend to check /etc/krb5.conf first. Since the library call >>> SSSD uses the read the keytab will read /etc/krb5.conf as well, this >>> might be the reason for the SSSD issue as well. >> I said keytab, I meant config, which is below included. > This is the SSSD config file /etc/sssd/sssd.conf, I really meant > /etc/krb5.conf. I wonder if it can be one use case where install script/process does not realize it fails. I did run install on a virtually identical machine, actually virtual kvm centos and it worked there, only exception is no sssd there, not sure about 100% though. Most worryingly when I try to restart dirsrv@ I see this: [ 762.293817] ns-slapd[8772]: segfault at 8 ip 00007f3186a02b29 sp 00007ffe73055d60 error 4 in libipa_pwd_extop.so[7f31869f1000+2a000] [ 779.072156] SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs [ 801.098886] ns-slapd[8958]: segfault at 8 ip 00007fe875c5ab29 sp 00007ffc2c6c26e0 error 4 in libipa_pwd_extop.so[7fe875c49000+2a000] I'm not an expert, it looks pretty regular to me, here krb config: [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] default_realm = # dns_lookup_realm = false dns_lookup_kdc = true rdns = false ticket_lifetime = 24h forwardable = yes udp_preference_limit = 0 default_ccache_name = KEYRING:persistent:%{uid} [realms] HOST.FAKE = { kdc = my.host.fake:88 master_kdc = my.host.fake:88 admin_server = my.host.fake:749 default_domain = host.fake pkinit_anchors = FILE:/etc/ipa/ca.crt } # = { kdc = my.host.fake:88 admin_server = my.host.fake:749 } [domain_realm] .host.fake = HOST.FAKE host.fake = HOST.FAKE # = # .# = # [dbmodules] HOST.FAKE = { db_library = ipadb.so } > > bye, > Sumit > >>> HTH >>> >>> bye, >>> Sumit >>> >>>> here is keytab server installer created/amended: (one thing that I'm not >>>> sure is the fact that my new "host.fake" domain is different from my >>>> previously existing ldap search >>>> "dc=xxx,dc=zzzzzzzz" - if it matters at all? Otherwise I have no clue. >>>> >>>> [domain/host.fake] >>>> >>>> cache_credentials = True >>>> krb5_store_password_if_offline = True >>>> ipa_domain = host.fake >>>> id_provider = ipa >>>> auth_provider = ipa >>>> access_provider = ipa >>>> ipa_hostname = my.host.fake >>>> chpass_provider = ipa >>>> ipa_server = my.host.fake >>>> ipa_server_mode = True >>>> ldap_tls_cacert = /etc/ipa/ca.crt >>>> [domain/default] >>>> autofs_provider = ldap >>>> cache_credentials = True >>>> krb5_realm = # >>>> ldap_search_base = dc=xxx,dc=zzzzzzzz >>>> id_provider = ldap >>>> auth_provider = ldap >>>> chpass_provider = ldap >>>> ldap_uri = ldap://my.host.fake:1389/ >>>> ldap_id_use_start_tls = True >>>> ldap_tls_cacertdir = /etc/openldap/cacerts >>>> >>>> krb5_server = my.host.fake:88 >>>> [sssd] >>>> services = nss, sudo, pam, autofs, ssh >>>> config_file_version = 2 >>>> >>>> domains = host.fake >>>> >>>> [nss] >>>> memcache_timeout = 600 >>>> homedir_substring = /home >>>> >>>> >>>> regards. >>>> >>>> -- >>>> Manage your subscription for the Freeipa-users mailing list: >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>> Go to http://freeipa.org for more info on the project >> -- >> Manage your subscription for the Freeipa-users mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-users >> Go to http://freeipa.org for more info on the project From sor-ipa at bofh.czest.pl Wed Feb 24 18:08:58 2016 From: sor-ipa at bofh.czest.pl (Daniel) Date: Wed, 24 Feb 2016 19:08:58 +0100 Subject: [Freeipa-users] FreeIPA problem with AD trust setup Message-ID: <994534c0f3d641d511210d8c3186997c@bofh.czest.pl> W dniu 2016-02-24 15:34, Sumit Bose napisa?(a): > The error indicates that there already is a trust on the AD side to a > domain which either has linux.test.local as domain name or the same > NetBIOS domain name. The default NetBIOS domain name in your case would > be LINUX. > > You can check the names of the trusted domains with e.g. > > ldapsearch -H ldap://ad-server.ad.domain' -b 'dc=ad,dc=domain' > 'objectClass=trustedDomain' name flatName trustPartner > > If you cannot find a collision here there might be a collision with the > NetBIOS name of a host. You can check this with > > ldapsearch -H ldap://ad-server.ad.domain -b 'dc=ad,dc=domain' > 'objectClass=computer' sAMAccountName Thank you for help. I've found computer account called linux.test.local in test.local domain tree. After account was removed trust setup went fine. Regards Daniel From lslebodn at redhat.com Wed Feb 24 18:35:45 2016 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Wed, 24 Feb 2016 19:35:45 +0100 Subject: [Freeipa-users] sssd went away, failed to restart In-Reply-To: <56CDA5E5.5060901@physik.uni-wuppertal.de> References: <20160222145152.GB3321@hendrix.arn.redhat.com> <56CC063E.7080900@aixigo.de> <20160223090003.GA3131@hendrix.redhat.com> <56CC2C86.8040109@aixigo.de> <20160223105825.GC2468@mail.corp.redhat.com> <56CC4A05.5040503@aixigo.de> <20160223124602.GH2468@mail.corp.redhat.com> <56CCE222.8010209@afaics.de> <20160224083015.GA1234@mail.corp.redhat.com> <56CDA5E5.5060901@physik.uni-wuppertal.de> Message-ID: <20160224183544.GJ1234@mail.corp.redhat.com> On (24/02/16 13:45), Torsten Harenberg wrote: >Hi, > >we had some trouble with sssd in the past as well on machines which >suffer from a high IO load (cluster nodes running scientific calculations). > >Following a suggestion from the list here, we moved the local sssd cache >into a tmpfs, so our fstab contains now a > >tmpfs /var/lib/sss/db tmpfs size=50M,auto 1 2 > >That solved our problem with sssd. I'm not sure it would help you, but >maybe still worth a thought.. > it's just a workaround and might solve symptoms. But It would good to see a log files. BTW we plan to do performance enhancement in 1.14 https://fedorahosted.org/sssd/ticket/2602 If you want you can add to CC in ticket and we can then provide test build. But if we identify issue in log files we might fix it as part of performance work in sssd-1.14 LS From peljasz at yahoo.co.uk Wed Feb 24 22:27:36 2016 From: peljasz at yahoo.co.uk (lejeczek) Date: Wed, 24 Feb 2016 22:27:36 +0000 Subject: [Freeipa-users] installation of ipa-server successful but sssd fails.. In-Reply-To: <56CDE65E.9050909@yahoo.co.uk> References: <56CD9229.2000406@yahoo.co.uk> <20160224112626.GY7535@p.redhat.com> <56CDA603.9060004@yahoo.co.uk> <20160224142238.GD7535@p.redhat.com> <56CDE65E.9050909@yahoo.co.uk> Message-ID: <56CE2E58.3000300@yahoo.co.uk> On 24/02/16 17:20, lejeczek wrote: > On 24/02/16 14:22, Sumit Bose wrote: >> On Wed, Feb 24, 2016 at 12:45:55PM +0000, lejeczek wrote: >>> On 24/02/16 11:26, Sumit Bose wrote: >>>> On Wed, Feb 24, 2016 at 11:21:13AM +0000, lejeczek wrote: >>>>> he everybody, >>>>> my first tampering with install gets me: >>>>> >>>>> Feb 24 11:04:22 my.host.fake >>>>> sssd[be[host.fake]][17425]: Starting up >>>>> Feb 24 11:04:22 my.host.fake >>>>> sssd[be[host.fake]][17425]: Failed to read >>>>> keytab [default]: Bad address >>>>> Feb 24 11:04:22 my.host.fake sssd[17406]: Exiting the >>>>> SSSD. Could not >>>>> restart critical service [host.fake]. >>>>> Feb 24 11:04:22 my.host.fake systemd[1]: sssd.service: >>>>> control process >>>>> exited, code=exited status=1 >>>>> Feb 24 11:04:22 my.host.fake systemd[1]: Failed to >>>>> start System Security >>>>> Services Daemon. >>>>> Feb 24 11:04:22 my.host.fake systemd[1]: Unit >>>>> sssd.service entered failed >>>>> state. >>>>> Feb 24 11:04:22 my.host.fake systemd[1]: sssd.service >>>>> failed. >>>>> >>>>> And just after install process finishes I try: >>>>> $ kinit admin >>>>> kinit: Improper format of Kerberos configuration file >>>>> while initializing >>>>> Kerberos 5 library >>>> I would recommend to check /etc/krb5.conf first. Since >>>> the library call >>>> SSSD uses the read the keytab will read /etc/krb5.conf >>>> as well, this >>>> might be the reason for the SSSD issue as well. >>> I said keytab, I meant config, which is below included. >> This is the SSSD config file /etc/sssd/sssd.conf, I >> really meant >> /etc/krb5.conf. > I wonder if it can be one use case where install > script/process does not realize it fails. I did run > install on a virtually identical machine, actually virtual > kvm centos and it worked there, only exception is no sssd > there, not sure about 100% though. > ok, this problem seems to be a valid candidate for bugzilla, and it should be easy to reproduce, I'd guess you Sumit might be interested. How to - just have your sssd already configured to use an ldap backend for both password & users, have your (open)ldap run on non-conflicting ports and then try: $ ipa-server-install -p ${myPass} -a ${myPass} --setup-dns --no-forwarders process completes without errors but sssd fails and kerberos won't work. Suffices to disable ldap & sssd in authentication pipeline (prior to ipa installer run) and installer successfully sets up sssd and kerberos works. That error: Failed to read keytab [default]: Bad address was saying a lot, that was default domain in sssd conf which was set up to ldap, and ipa installer was doing something with it. I'm only puzzled nobody stumbled upon it earlier. What do you think Sumit? I'm going to dive deeper into ipa to see if it really is okey now. > Most worryingly when I try to restart dirsrv@ I see this: > > [ 762.293817] ns-slapd[8772]: segfault at 8 ip > 00007f3186a02b29 sp 00007ffe73055d60 error 4 in > libipa_pwd_extop.so[7f31869f1000+2a000] > [ 779.072156] SELinux: initialized (dev tmpfs, type > tmpfs), uses transition SIDs > [ 801.098886] ns-slapd[8958]: segfault at 8 ip > 00007fe875c5ab29 sp 00007ffc2c6c26e0 error 4 in > libipa_pwd_extop.so[7fe875c49000+2a000] > > I'm not an expert, it looks pretty regular to me, here krb > config: > > [logging] > default = FILE:/var/log/krb5libs.log > kdc = FILE:/var/log/krb5kdc.log > admin_server = FILE:/var/log/kadmind.log > > [libdefaults] > default_realm = # > dns_lookup_realm = false > dns_lookup_kdc = true > rdns = false > ticket_lifetime = 24h > forwardable = yes > udp_preference_limit = 0 > default_ccache_name = KEYRING:persistent:%{uid} > > [realms] > HOST.FAKE = { > kdc = my.host.fake:88 > master_kdc = my.host.fake:88 > admin_server = my.host.fake:749 > default_domain = host.fake > pkinit_anchors = FILE:/etc/ipa/ca.crt > } > > # = { > kdc = my.host.fake:88 > admin_server = my.host.fake:749 > } > > [domain_realm] > .host.fake = HOST.FAKE > host.fake = HOST.FAKE > > # = # > .# = # > [dbmodules] > HOST.FAKE = { > db_library = ipadb.so > } > >> >> bye, >> Sumit >> >>>> HTH >>>> >>>> bye, >>>> Sumit >>>> >>>>> here is keytab server installer created/amended: (one >>>>> thing that I'm not >>>>> sure is the fact that my new "host.fake" domain is >>>>> different from my >>>>> previously existing ldap search >>>>> "dc=xxx,dc=zzzzzzzz" - if it matters at all? Otherwise >>>>> I have no clue. >>>>> >>>>> [domain/host.fake] >>>>> >>>>> cache_credentials = True >>>>> krb5_store_password_if_offline = True >>>>> ipa_domain = host.fake >>>>> id_provider = ipa >>>>> auth_provider = ipa >>>>> access_provider = ipa >>>>> ipa_hostname = my.host.fake >>>>> chpass_provider = ipa >>>>> ipa_server = my.host.fake >>>>> ipa_server_mode = True >>>>> ldap_tls_cacert = /etc/ipa/ca.crt >>>>> [domain/default] >>>>> autofs_provider = ldap >>>>> cache_credentials = True >>>>> krb5_realm = # >>>>> ldap_search_base = dc=xxx,dc=zzzzzzzz >>>>> id_provider = ldap >>>>> auth_provider = ldap >>>>> chpass_provider = ldap >>>>> ldap_uri = ldap://my.host.fake:1389/ >>>>> ldap_id_use_start_tls = True >>>>> ldap_tls_cacertdir = /etc/openldap/cacerts >>>>> >>>>> krb5_server = my.host.fake:88 >>>>> [sssd] >>>>> services = nss, sudo, pam, autofs, ssh >>>>> config_file_version = 2 >>>>> >>>>> domains = host.fake >>>>> >>>>> [nss] >>>>> memcache_timeout = 600 >>>>> homedir_substring = /home >>>>> >>>>> >>>>> regards. >>>>> >>>>> -- >>>>> Manage your subscription for the Freeipa-users mailing >>>>> list: >>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>> Go to http://freeipa.org for more info on the project >>> -- >>> Manage your subscription for the Freeipa-users mailing >>> list: >>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> Go to http://freeipa.org for more info on the project > From marat.vyshegorodtsev at gmail.com Wed Feb 24 22:28:58 2016 From: marat.vyshegorodtsev at gmail.com (Marat Vyshegorodtsev) Date: Wed, 24 Feb 2016 14:28:58 -0800 Subject: [Freeipa-users] Recovering from data-only backup doesn't recover Kerberos keys properly In-Reply-To: <56CDB907.20707@redhat.com> References: <56CDA23D.7050801@redhat.com> <56CDB907.20707@redhat.com> Message-ID: > Are you just toying with this or did something go horribly wrong and you're trying to restore a production environment? This. :-( I have actually rebuilt the environment from scratch, then wrote a perl script that just recreated all users from the ldif using ipa user-add and reset password for everyone. After the fresh install the following command was used for each user: ipa user-add --first='John' --last='Doe' --uid=1603600001 --gid=1603600001 --email='john.doe at contoso.com' --sshpubkey='ssh-rsa ' --random john.doe I had to force uids/gids, so that users don't lose access to their home folders. I have regenerated keytabs on all client hosts, but now there is some weird behavior is demonstrated by sssd: users intermittently fail to login. This is a log from a client machine (Amazon Linux 2015.09): (Wed Feb 24 22:08:49 2016) [sssd[ssh]] [accept_fd_handler] (0x0400): Client connected! (Wed Feb 24 22:08:49 2016) [sssd[ssh]] [sss_cmd_get_version] (0x0200): Received client version [0]. (Wed Feb 24 22:08:49 2016) [sssd[ssh]] [sss_cmd_get_version] (0x0200): Offered version [0]. (Wed Feb 24 22:08:49 2016) [sssd[ssh]] [ssh_cmd_parse_request] (0x0400): Requested domain [] (Wed Feb 24 22:08:49 2016) [sssd[ssh]] [ssh_cmd_parse_request] (0x0400): Parsing name [marat.vyshegorodtsev][] (Wed Feb 24 22:08:49 2016) [sssd[ssh]] [sss_parse_name_for_domains] (0x0200): name 'marat.vyshegorodtsev' matched without domain, user is marat.vyshegorodtsev (Wed Feb 24 22:08:49 2016) [sssd[ssh]] [sss_ssh_cmd_get_user_pubkeys] (0x0400): Requesting SSH user public keys for [marat.vyshegorodtsev] from [] (Wed Feb 24 22:08:49 2016) [sssd[ssh]] [sss_dp_issue_request] (0x0400): Issuing request for [0x40b2d0:1:marat.vyshegorodtsev at contoso.com] (Wed Feb 24 22:08:49 2016) [sssd[ssh]] [sss_dp_get_account_msg] (0x0400): Creating request for [contoso.com][1][1][name=marat.vyshegorodtsev] (Wed Feb 24 22:08:49 2016) [sssd[ssh]] [sbus_add_timeout] (0x2000): 0xb99c10 (Wed Feb 24 22:08:49 2016) [sssd[ssh]] [sss_dp_internal_get_send] (0x0400): Entering request [0x40b2d0:1:marat.vyshegorodtsev at contoso.com] (Wed Feb 24 22:08:49 2016) [sssd[ssh]] [sbus_remove_timeout] (0x2000): 0xb99c10 (Wed Feb 24 22:08:49 2016) [sssd[ssh]] [sss_dp_get_reply] (0x1000): Got reply from Data Provider - DP error code: 1 errno: 11 error message: Offline (Wed Feb 24 22:08:49 2016) [sssd[ssh]] [ssh_user_pubkeys_search_dp_callback] (0x0040): Unable to get information from Data Provider Error: 1, 11, Offline (Wed Feb 24 22:08:49 2016) [sssd[ssh]] [ssh_user_pubkeys_search_next] (0x0400): Requesting SSH user public keys for [marat.vyshegorodtsev at contoso.com] (Wed Feb 24 22:08:49 2016) [sssd[ssh]] [sss_dp_req_destructor] (0x0400): Deleting request: [0x40b2d0:1:marat.vyshegorodtsev at contoso.com] (Wed Feb 24 22:08:49 2016) [sssd[ssh]] [client_recv] (0x0200): Client disconnected! (Wed Feb 24 22:08:49 2016) [sssd[ssh]] [client_destructor] (0x2000): Terminated client [0xb90dd0][17] This was produced in response to command /usr/bin/sss_ssh_authorizedkeys marat.vyshegorodtsev The whole log file has a lot of garbage in it like this: (Wed Feb 24 22:28:09 2016) [sssd[ssh]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Wed Feb 24 22:28:19 2016) [sssd[ssh]] [sbus_message_handler] (0x2000): Received SBUS method org.freedesktop.sssd.service.ping on path /org/freedesktop/sssd/service I can do a ldapsearch on the IPA server successfully using login/password, but sssd just doesn't work. The server runs Fedora 23 with FreeIPA 4.2.3-2.fc23. Best regards, Marat On Wed, Feb 24, 2016 at 6:07 AM, Rob Crittenden wrote: > David Kupka wrote: >> On 23/02/16 20:21, Marat Vyshegorodtsev wrote: >>> Hi! >>> >>> I've been doing backups using the tool like this: >>> ipa-backup --data --online >>> >>> I didn't want any configuration to be backed up, since it is managed >>> from a chef recipe. >>> >>> However, when I tried to recover the backup to a fresh FreeIPA >>> install, Kerberos (GSSAPI) broke ? I can't authenticate myself >>> anywhere using Kerberos: CLI, HTTP, etc. >>> >>> LDAP password-based authentication works alright. >>> >>> After some googling and reading through the mailing list, I followed >>> this manual and updated all keytabs for all services ? dirsrv, httpd, >>> kadmin: >>> http://www.freeipa.org/page/V3/Backup_and_Restore#Backup.2C_uninstall.2C_reinstall.2C_restore_JUST_the_LDAP_server >>> >>> >>> Then it broke in a different way: for a correct session it says that >>> my session is expired or just does nothing, for an incorrect password >>> it responds with "password incorrect" (see screenshot). >>> https://yadi.sk/i/WVe8u1_ZpNh3w >>> >>> For CLI it just says that the credentials are incorrect regardless of >>> what credentials I provide. >>> >>> I suppose that all krbPrincipalKey fields are tied to some other >>> encryption key that is not included in data-only backup. >>> >>> Could you please let me know how to regenerate krbPrincipalKey for all >>> users or how to work around this issue? >>> >>> Best regards, >>> Marat >>> >> >> Hello Marat, >> I would say that this is expected. During freeipa-server installation >> all service and host kerberos keys are generated randomly, stored in >> Directory Server and in keytab accessible to the host/service. >> When you reinstall freeipa-server all keys are regenerated and no longer >> matches the ones stored in your backup. >> >> You can use ipa-getkeytab(1) with Directory Manager credentials to >> retrieve new keys but think it's not enough to make it work again. >> Hopefully, someone, who understand kerberos better will advice. >> > > It sounds like he already re-generated those keytabs. > > The Kerberos master key is stored in LDAP so you should already have it. > Seeing the KDC and/or httpd logs might be useful. > > Are you just toying with this or did something go horribly wrong and > you're trying to restore a production environment? > > The instructions you used were strictly a brain dump, something I goofed > around with as an interesting thought project but didn't entirely nail > down. It is quite possible I didn't document some important step in there. > > rob From supul at jithpl.com Thu Feb 25 05:13:53 2016 From: supul at jithpl.com (Supul Wickaramartna) Date: Thu, 25 Feb 2016 10:43:53 +0530 Subject: [Freeipa-users] PA Soalris client- Kerberos error Message-ID: <00d401d16f8b$52767fd0$f7637f70$@jithpl.com> Hi, I have configured Solaris server ( 5.10 Generic_118833-33, sun4u sparc UNW, Sun-Fire-V240) as IPA client. ldap is working, ldap user can login with 'su' command and 'id' command displays ldap users identity information. But Kerberos authentication failed with following error. Kinit at EXAMPLE.COM Segmentation Fault (core dumped) I have tested with Solaris 10 and 11 (x86) platforms, but I haven't seen this error on Solaris 10 and 11 (x86) platforms. And I notice that Segmentation Fault (core dumped) error only generates correct ldap user names, because I tried with non-existing username it generates following error "client not found in Kerberos database while getting initial credentials" How to work around this issue ? Thanks, supul -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbose at redhat.com Thu Feb 25 08:21:26 2016 From: sbose at redhat.com (Sumit Bose) Date: Thu, 25 Feb 2016 09:21:26 +0100 Subject: [Freeipa-users] installation of ipa-server successful but sssd fails.. In-Reply-To: <56CDE65E.9050909@yahoo.co.uk> References: <56CD9229.2000406@yahoo.co.uk> <20160224112626.GY7535@p.redhat.com> <56CDA603.9060004@yahoo.co.uk> <20160224142238.GD7535@p.redhat.com> <56CDE65E.9050909@yahoo.co.uk> Message-ID: <20160225082126.GJ7535@p.redhat.com> On Wed, Feb 24, 2016 at 05:20:30PM +0000, lejeczek wrote: > On 24/02/16 14:22, Sumit Bose wrote: > >On Wed, Feb 24, 2016 at 12:45:55PM +0000, lejeczek wrote: > >>On 24/02/16 11:26, Sumit Bose wrote: > >>>On Wed, Feb 24, 2016 at 11:21:13AM +0000, lejeczek wrote: > >>>>he everybody, > >>>>my first tampering with install gets me: > >>>> > >>>>Feb 24 11:04:22 my.host.fake sssd[be[host.fake]][17425]: Starting up > >>>>Feb 24 11:04:22 my.host.fake sssd[be[host.fake]][17425]: Failed to read > >>>>keytab [default]: Bad address > >>>>Feb 24 11:04:22 my.host.fake sssd[17406]: Exiting the SSSD. Could not > >>>>restart critical service [host.fake]. > >>>>Feb 24 11:04:22 my.host.fake systemd[1]: sssd.service: control process > >>>>exited, code=exited status=1 > >>>>Feb 24 11:04:22 my.host.fake systemd[1]: Failed to start System Security > >>>>Services Daemon. > >>>>Feb 24 11:04:22 my.host.fake systemd[1]: Unit sssd.service entered failed > >>>>state. > >>>>Feb 24 11:04:22 my.host.fake systemd[1]: sssd.service failed. > >>>> > >>>>And just after install process finishes I try: > >>>>$ kinit admin > >>>>kinit: Improper format of Kerberos configuration file while initializing > >>>>Kerberos 5 library > >>>I would recommend to check /etc/krb5.conf first. Since the library call > >>>SSSD uses the read the keytab will read /etc/krb5.conf as well, this > >>>might be the reason for the SSSD issue as well. > >>I said keytab, I meant config, which is below included. > >This is the SSSD config file /etc/sssd/sssd.conf, I really meant > >/etc/krb5.conf. > I wonder if it can be one use case where install script/process does not > realize it fails. I did run install on a virtually identical machine, > actually virtual kvm centos and it worked there, only exception is no sssd > there, not sure about 100% though. > > Most worryingly when I try to restart dirsrv@ I see this: > > [ 762.293817] ns-slapd[8772]: segfault at 8 ip 00007f3186a02b29 sp > 00007ffe73055d60 error 4 in libipa_pwd_extop.so[7f31869f1000+2a000] > [ 779.072156] SELinux: initialized (dev tmpfs, type tmpfs), uses transition > SIDs > [ 801.098886] ns-slapd[8958]: segfault at 8 ip 00007fe875c5ab29 sp > 00007ffc2c6c26e0 error 4 in libipa_pwd_extop.so[7fe875c49000+2a000] > > I'm not an expert, it looks pretty regular to me, here krb config: unfortunately it is broken, nearly every line with a '#' is wrong and causes libkrb5 to fail parsing the file. I think this is caused by an issue with authconfig (https://bugzilla.redhat.com/show_bug.cgi?id=1184639). Please try to upgrade to authconfig-6.2.8-10.el7 or higher. Nevertheless I think neither authconfig nor ipa-client-install will be able to fix the broken file completely and you have to delete the following lines manually. > > [logging] > default = FILE:/var/log/krb5libs.log > kdc = FILE:/var/log/krb5kdc.log > admin_server = FILE:/var/log/kadmind.log > > [libdefaults] > default_realm = # ^^^ delete ^^^ > dns_lookup_realm = false > dns_lookup_kdc = true > rdns = false > ticket_lifetime = 24h > forwardable = yes > udp_preference_limit = 0 > default_ccache_name = KEYRING:persistent:%{uid} > > [realms] > HOST.FAKE = { > kdc = my.host.fake:88 > master_kdc = my.host.fake:88 > admin_server = my.host.fake:749 > default_domain = host.fake > pkinit_anchors = FILE:/etc/ipa/ca.crt > } > > # = { ^^^ delete ^^^ > kdc = my.host.fake:88 ^^^ delete ^^^ > admin_server = my.host.fake:749 ^^^ delete ^^^ > } ^^^ delete ^^^ > > [domain_realm] > .host.fake = HOST.FAKE > host.fake = HOST.FAKE > > # = # ^^^ delete ^^^ > .# = # ^^^ delete ^^^ > [dbmodules] > HOST.FAKE = { > db_library = ipadb.so > } > bye, Sumit > > > >bye, > >Sumit > > > >>>HTH > >>> > >>>bye, > >>>Sumit > >>> > >>>>here is keytab server installer created/amended: (one thing that I'm not > >>>>sure is the fact that my new "host.fake" domain is different from my > >>>>previously existing ldap search > >>>>"dc=xxx,dc=zzzzzzzz" - if it matters at all? Otherwise I have no clue. > >>>> > >>>>[domain/host.fake] > >>>> > >>>>cache_credentials = True > >>>>krb5_store_password_if_offline = True > >>>>ipa_domain = host.fake > >>>>id_provider = ipa > >>>>auth_provider = ipa > >>>>access_provider = ipa > >>>>ipa_hostname = my.host.fake > >>>>chpass_provider = ipa > >>>>ipa_server = my.host.fake > >>>>ipa_server_mode = True > >>>>ldap_tls_cacert = /etc/ipa/ca.crt > >>>>[domain/default] > >>>>autofs_provider = ldap > >>>>cache_credentials = True > >>>>krb5_realm = # > >>>>ldap_search_base = dc=xxx,dc=zzzzzzzz > >>>>id_provider = ldap > >>>>auth_provider = ldap > >>>>chpass_provider = ldap > >>>>ldap_uri = ldap://my.host.fake:1389/ > >>>>ldap_id_use_start_tls = True > >>>>ldap_tls_cacertdir = /etc/openldap/cacerts > >>>> > >>>>krb5_server = my.host.fake:88 > >>>>[sssd] > >>>>services = nss, sudo, pam, autofs, ssh > >>>>config_file_version = 2 > >>>> > >>>>domains = host.fake > >>>> > >>>>[nss] > >>>>memcache_timeout = 600 > >>>>homedir_substring = /home > >>>> > >>>> > >>>>regards. > >>>> > >>>>-- > >>>>Manage your subscription for the Freeipa-users mailing list: > >>>>https://www.redhat.com/mailman/listinfo/freeipa-users > >>>>Go to http://freeipa.org for more info on the project > >>-- > >>Manage your subscription for the Freeipa-users mailing list: > >>https://www.redhat.com/mailman/listinfo/freeipa-users > >>Go to http://freeipa.org for more info on the project > From sbose at redhat.com Thu Feb 25 08:24:08 2016 From: sbose at redhat.com (Sumit Bose) Date: Thu, 25 Feb 2016 09:24:08 +0100 Subject: [Freeipa-users] installation of ipa-server successful but sssd fails.. In-Reply-To: <56CE2E58.3000300@yahoo.co.uk> References: <56CD9229.2000406@yahoo.co.uk> <20160224112626.GY7535@p.redhat.com> <56CDA603.9060004@yahoo.co.uk> <20160224142238.GD7535@p.redhat.com> <56CDE65E.9050909@yahoo.co.uk> <56CE2E58.3000300@yahoo.co.uk> Message-ID: <20160225082408.GK7535@p.redhat.com> On Wed, Feb 24, 2016 at 10:27:36PM +0000, lejeczek wrote: > > > On 24/02/16 17:20, lejeczek wrote: > >On 24/02/16 14:22, Sumit Bose wrote: > >>On Wed, Feb 24, 2016 at 12:45:55PM +0000, lejeczek wrote: > >>>On 24/02/16 11:26, Sumit Bose wrote: > >>>>On Wed, Feb 24, 2016 at 11:21:13AM +0000, lejeczek wrote: > >>>>>he everybody, > >>>>>my first tampering with install gets me: > >>>>> > >>>>>Feb 24 11:04:22 my.host.fake sssd[be[host.fake]][17425]: Starting > >>>>>up > >>>>>Feb 24 11:04:22 my.host.fake sssd[be[host.fake]][17425]: Failed to > >>>>>read > >>>>>keytab [default]: Bad address > >>>>>Feb 24 11:04:22 my.host.fake sssd[17406]: Exiting the SSSD. Could > >>>>>not > >>>>>restart critical service [host.fake]. > >>>>>Feb 24 11:04:22 my.host.fake systemd[1]: sssd.service: control > >>>>>process > >>>>>exited, code=exited status=1 > >>>>>Feb 24 11:04:22 my.host.fake systemd[1]: Failed to start System > >>>>>Security > >>>>>Services Daemon. > >>>>>Feb 24 11:04:22 my.host.fake systemd[1]: Unit sssd.service entered > >>>>>failed > >>>>>state. > >>>>>Feb 24 11:04:22 my.host.fake systemd[1]: sssd.service failed. > >>>>> > >>>>>And just after install process finishes I try: > >>>>>$ kinit admin > >>>>>kinit: Improper format of Kerberos configuration file while > >>>>>initializing > >>>>>Kerberos 5 library > >>>>I would recommend to check /etc/krb5.conf first. Since the library > >>>>call > >>>>SSSD uses the read the keytab will read /etc/krb5.conf as well, this > >>>>might be the reason for the SSSD issue as well. > >>>I said keytab, I meant config, which is below included. > >>This is the SSSD config file /etc/sssd/sssd.conf, I really meant > >>/etc/krb5.conf. > >I wonder if it can be one use case where install script/process does not > >realize it fails. I did run install on a virtually identical machine, > >actually virtual kvm centos and it worked there, only exception is no sssd > >there, not sure about 100% though. > > > ok, this problem seems to be a valid candidate for bugzilla, and it should > be easy to reproduce, I'd guess you Sumit might be interested. > How to - just have your sssd already configured to use an ldap backend for > both password & users, have your (open)ldap run on non-conflicting ports and > then try: > $ ipa-server-install -p ${myPass} -a ${myPass} --setup-dns --no-forwarders > process completes without errors but sssd fails and kerberos won't work. > Suffices to disable ldap & sssd in authentication pipeline (prior to ipa > installer run) and installer successfully sets up sssd and kerberos works. > That error: > Failed to read keytab [default]: Bad address > was saying a lot, that was default domain in sssd conf which was set up to > ldap, and ipa installer was doing something with it. > I'm only puzzled nobody stumbled upon it earlier. > What do you think Sumit? > I'm going to dive deeper into ipa to see if it really is okey now. Please see my other email about the issues in krb5.conf and authconfig. Kerberos is one of the most basic parts of IPA and a broken krb5.conf may cause all kind of issue. Please fix krb5.conf first before trying anything else. bye, Sumit > > >Most worryingly when I try to restart dirsrv@ I see this: > > > >[ 762.293817] ns-slapd[8772]: segfault at 8 ip 00007f3186a02b29 sp > >00007ffe73055d60 error 4 in libipa_pwd_extop.so[7f31869f1000+2a000] > >[ 779.072156] SELinux: initialized (dev tmpfs, type tmpfs), uses > >transition SIDs > >[ 801.098886] ns-slapd[8958]: segfault at 8 ip 00007fe875c5ab29 sp > >00007ffc2c6c26e0 error 4 in libipa_pwd_extop.so[7fe875c49000+2a000] > > > >I'm not an expert, it looks pretty regular to me, here krb config: > > > >[logging] > > default = FILE:/var/log/krb5libs.log > > kdc = FILE:/var/log/krb5kdc.log > > admin_server = FILE:/var/log/kadmind.log > > > >[libdefaults] > > default_realm = # > > dns_lookup_realm = false > > dns_lookup_kdc = true > > rdns = false > > ticket_lifetime = 24h > > forwardable = yes > > udp_preference_limit = 0 > > default_ccache_name = KEYRING:persistent:%{uid} > > > >[realms] > > HOST.FAKE = { > > kdc = my.host.fake:88 > > master_kdc = my.host.fake:88 > > admin_server = my.host.fake:749 > > default_domain = host.fake > > pkinit_anchors = FILE:/etc/ipa/ca.crt > >} > > > > # = { > > kdc = my.host.fake:88 > > admin_server = my.host.fake:749 > > } > > > >[domain_realm] > > .host.fake = HOST.FAKE > > host.fake = HOST.FAKE > > > > # = # > > .# = # > >[dbmodules] > > HOST.FAKE = { > > db_library = ipadb.so > > } > > > >> > >>bye, > >>Sumit > >> > >>>>HTH > >>>> > >>>>bye, > >>>>Sumit > >>>> > >>>>>here is keytab server installer created/amended: (one thing that > >>>>>I'm not > >>>>>sure is the fact that my new "host.fake" domain is different from > >>>>>my > >>>>>previously existing ldap search > >>>>>"dc=xxx,dc=zzzzzzzz" - if it matters at all? Otherwise I have no > >>>>>clue. > >>>>> > >>>>>[domain/host.fake] > >>>>> > >>>>>cache_credentials = True > >>>>>krb5_store_password_if_offline = True > >>>>>ipa_domain = host.fake > >>>>>id_provider = ipa > >>>>>auth_provider = ipa > >>>>>access_provider = ipa > >>>>>ipa_hostname = my.host.fake > >>>>>chpass_provider = ipa > >>>>>ipa_server = my.host.fake > >>>>>ipa_server_mode = True > >>>>>ldap_tls_cacert = /etc/ipa/ca.crt > >>>>>[domain/default] > >>>>>autofs_provider = ldap > >>>>>cache_credentials = True > >>>>>krb5_realm = # > >>>>>ldap_search_base = dc=xxx,dc=zzzzzzzz > >>>>>id_provider = ldap > >>>>>auth_provider = ldap > >>>>>chpass_provider = ldap > >>>>>ldap_uri = ldap://my.host.fake:1389/ > >>>>>ldap_id_use_start_tls = True > >>>>>ldap_tls_cacertdir = /etc/openldap/cacerts > >>>>> > >>>>>krb5_server = my.host.fake:88 > >>>>>[sssd] > >>>>>services = nss, sudo, pam, autofs, ssh > >>>>>config_file_version = 2 > >>>>> > >>>>>domains = host.fake > >>>>> > >>>>>[nss] > >>>>>memcache_timeout = 600 > >>>>>homedir_substring = /home > >>>>> > >>>>> > >>>>>regards. > >>>>> > >>>>>-- > >>>>>Manage your subscription for the Freeipa-users mailing list: > >>>>>https://www.redhat.com/mailman/listinfo/freeipa-users > >>>>>Go to http://freeipa.org for more info on the project > >>>-- > >>>Manage your subscription for the Freeipa-users mailing list: > >>>https://www.redhat.com/mailman/listinfo/freeipa-users > >>>Go to http://freeipa.org for more info on the project > > > From peljasz at yahoo.co.uk Thu Feb 25 09:21:06 2016 From: peljasz at yahoo.co.uk (lejeczek) Date: Thu, 25 Feb 2016 09:21:06 +0000 Subject: [Freeipa-users] installation of ipa-server successful but sssd fails.. In-Reply-To: <20160225082126.GJ7535@p.redhat.com> References: <56CD9229.2000406@yahoo.co.uk> <20160224112626.GY7535@p.redhat.com> <56CDA603.9060004@yahoo.co.uk> <20160224142238.GD7535@p.redhat.com> <56CDE65E.9050909@yahoo.co.uk> <20160225082126.GJ7535@p.redhat.com> Message-ID: <56CEC782.1060004@yahoo.co.uk> On 25/02/16 08:21, Sumit Bose wrote: > On Wed, Feb 24, 2016 at 05:20:30PM +0000, lejeczek wrote: >> On 24/02/16 14:22, Sumit Bose wrote: >>> On Wed, Feb 24, 2016 at 12:45:55PM +0000, lejeczek wrote: >>>> On 24/02/16 11:26, Sumit Bose wrote: >>>>> On Wed, Feb 24, 2016 at 11:21:13AM +0000, lejeczek wrote: >>>>>> he everybody, >>>>>> my first tampering with install gets me: >>>>>> >>>>>> Feb 24 11:04:22 my.host.fake sssd[be[host.fake]][17425]: Starting up >>>>>> Feb 24 11:04:22 my.host.fake sssd[be[host.fake]][17425]: Failed to read >>>>>> keytab [default]: Bad address >>>>>> Feb 24 11:04:22 my.host.fake sssd[17406]: Exiting the SSSD. Could not >>>>>> restart critical service [host.fake]. >>>>>> Feb 24 11:04:22 my.host.fake systemd[1]: sssd.service: control process >>>>>> exited, code=exited status=1 >>>>>> Feb 24 11:04:22 my.host.fake systemd[1]: Failed to start System Security >>>>>> Services Daemon. >>>>>> Feb 24 11:04:22 my.host.fake systemd[1]: Unit sssd.service entered failed >>>>>> state. >>>>>> Feb 24 11:04:22 my.host.fake systemd[1]: sssd.service failed. >>>>>> >>>>>> And just after install process finishes I try: >>>>>> $ kinit admin >>>>>> kinit: Improper format of Kerberos configuration file while initializing >>>>>> Kerberos 5 library >>>>> I would recommend to check /etc/krb5.conf first. Since the library call >>>>> SSSD uses the read the keytab will read /etc/krb5.conf as well, this >>>>> might be the reason for the SSSD issue as well. >>>> I said keytab, I meant config, which is below included. >>> This is the SSSD config file /etc/sssd/sssd.conf, I really meant >>> /etc/krb5.conf. >> I wonder if it can be one use case where install script/process does not >> realize it fails. I did run install on a virtually identical machine, >> actually virtual kvm centos and it worked there, only exception is no sssd >> there, not sure about 100% though. >> >> Most worryingly when I try to restart dirsrv@ I see this: >> >> [ 762.293817] ns-slapd[8772]: segfault at 8 ip 00007f3186a02b29 sp >> 00007ffe73055d60 error 4 in libipa_pwd_extop.so[7f31869f1000+2a000] >> [ 779.072156] SELinux: initialized (dev tmpfs, type tmpfs), uses transition >> SIDs >> [ 801.098886] ns-slapd[8958]: segfault at 8 ip 00007fe875c5ab29 sp >> 00007ffc2c6c26e0 error 4 in libipa_pwd_extop.so[7fe875c49000+2a000] >> >> I'm not an expert, it looks pretty regular to me, here krb config: > unfortunately it is broken, nearly every line with a '#' is wrong and > causes libkrb5 to fail parsing the file. I think this is caused by an > issue with authconfig > (https://bugzilla.redhat.com/show_bug.cgi?id=1184639). Please try to > upgrade to authconfig-6.2.8-10.el7 or higher. Nevertheless I think > neither authconfig nor ipa-client-install will be able to fix the broken > file completely and you have to delete the following lines manually. yes, indeed it seems that when I used authconf (not tui) to disable ldap & ssd configs were cleared of # char. I cannot only be sure 100% as I had a look at configs after ipa install. But I'll also say it would be nice to have kerberos smart and able to digest these special cases, handle these chars regardless, no? >> [logging] >> default = FILE:/var/log/krb5libs.log >> kdc = FILE:/var/log/krb5kdc.log >> admin_server = FILE:/var/log/kadmind.log >> >> [libdefaults] >> default_realm = # > ^^^ delete ^^^ >> dns_lookup_realm = false >> dns_lookup_kdc = true >> rdns = false >> ticket_lifetime = 24h >> forwardable = yes >> udp_preference_limit = 0 >> default_ccache_name = KEYRING:persistent:%{uid} >> >> [realms] >> HOST.FAKE = { >> kdc = my.host.fake:88 >> master_kdc = my.host.fake:88 >> admin_server = my.host.fake:749 >> default_domain = host.fake >> pkinit_anchors = FILE:/etc/ipa/ca.crt >> } >> >> # = { > ^^^ delete ^^^ >> kdc = my.host.fake:88 > ^^^ delete ^^^ >> admin_server = my.host.fake:749 > ^^^ delete ^^^ >> } > ^^^ delete ^^^ >> [domain_realm] >> .host.fake = HOST.FAKE >> host.fake = HOST.FAKE >> >> # = # > ^^^ delete ^^^ >> .# = # > ^^^ delete ^^^ >> [dbmodules] >> HOST.FAKE = { >> db_library = ipadb.so >> } >> > bye, > Sumit > >>> bye, >>> Sumit >>> >>>>> HTH >>>>> >>>>> bye, >>>>> Sumit >>>>> >>>>>> here is keytab server installer created/amended: (one thing that I'm not >>>>>> sure is the fact that my new "host.fake" domain is different from my >>>>>> previously existing ldap search >>>>>> "dc=xxx,dc=zzzzzzzz" - if it matters at all? Otherwise I have no clue. >>>>>> >>>>>> [domain/host.fake] >>>>>> >>>>>> cache_credentials = True >>>>>> krb5_store_password_if_offline = True >>>>>> ipa_domain = host.fake >>>>>> id_provider = ipa >>>>>> auth_provider = ipa >>>>>> access_provider = ipa >>>>>> ipa_hostname = my.host.fake >>>>>> chpass_provider = ipa >>>>>> ipa_server = my.host.fake >>>>>> ipa_server_mode = True >>>>>> ldap_tls_cacert = /etc/ipa/ca.crt >>>>>> [domain/default] >>>>>> autofs_provider = ldap >>>>>> cache_credentials = True >>>>>> krb5_realm = # >>>>>> ldap_search_base = dc=xxx,dc=zzzzzzzz >>>>>> id_provider = ldap >>>>>> auth_provider = ldap >>>>>> chpass_provider = ldap >>>>>> ldap_uri = ldap://my.host.fake:1389/ >>>>>> ldap_id_use_start_tls = True >>>>>> ldap_tls_cacertdir = /etc/openldap/cacerts >>>>>> >>>>>> krb5_server = my.host.fake:88 >>>>>> [sssd] >>>>>> services = nss, sudo, pam, autofs, ssh >>>>>> config_file_version = 2 >>>>>> >>>>>> domains = host.fake >>>>>> >>>>>> [nss] >>>>>> memcache_timeout = 600 >>>>>> homedir_substring = /home >>>>>> >>>>>> >>>>>> regards. >>>>>> >>>>>> -- >>>>>> Manage your subscription for the Freeipa-users mailing list: >>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>>> Go to http://freeipa.org for more info on the project >>>> -- >>>> Manage your subscription for the Freeipa-users mailing list: >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>> Go to http://freeipa.org for more info on the project From sbose at redhat.com Thu Feb 25 09:32:42 2016 From: sbose at redhat.com (Sumit Bose) Date: Thu, 25 Feb 2016 10:32:42 +0100 Subject: [Freeipa-users] installation of ipa-server successful but sssd fails.. In-Reply-To: <56CEC782.1060004@yahoo.co.uk> References: <56CD9229.2000406@yahoo.co.uk> <20160224112626.GY7535@p.redhat.com> <56CDA603.9060004@yahoo.co.uk> <20160224142238.GD7535@p.redhat.com> <56CDE65E.9050909@yahoo.co.uk> <20160225082126.GJ7535@p.redhat.com> <56CEC782.1060004@yahoo.co.uk> Message-ID: <20160225093242.GN7535@p.redhat.com> On Thu, Feb 25, 2016 at 09:21:06AM +0000, lejeczek wrote: > On 25/02/16 08:21, Sumit Bose wrote: > >On Wed, Feb 24, 2016 at 05:20:30PM +0000, lejeczek wrote: > >>On 24/02/16 14:22, Sumit Bose wrote: > >>>On Wed, Feb 24, 2016 at 12:45:55PM +0000, lejeczek wrote: > >>>>On 24/02/16 11:26, Sumit Bose wrote: > >>>>>On Wed, Feb 24, 2016 at 11:21:13AM +0000, lejeczek wrote: > >>>>>>he everybody, > >>>>>>my first tampering with install gets me: > >>>>>> > >>>>>>Feb 24 11:04:22 my.host.fake sssd[be[host.fake]][17425]: Starting up > >>>>>>Feb 24 11:04:22 my.host.fake sssd[be[host.fake]][17425]: Failed to read > >>>>>>keytab [default]: Bad address > >>>>>>Feb 24 11:04:22 my.host.fake sssd[17406]: Exiting the SSSD. Could not > >>>>>>restart critical service [host.fake]. > >>>>>>Feb 24 11:04:22 my.host.fake systemd[1]: sssd.service: control process > >>>>>>exited, code=exited status=1 > >>>>>>Feb 24 11:04:22 my.host.fake systemd[1]: Failed to start System Security > >>>>>>Services Daemon. > >>>>>>Feb 24 11:04:22 my.host.fake systemd[1]: Unit sssd.service entered failed > >>>>>>state. > >>>>>>Feb 24 11:04:22 my.host.fake systemd[1]: sssd.service failed. > >>>>>> > >>>>>>And just after install process finishes I try: > >>>>>>$ kinit admin > >>>>>>kinit: Improper format of Kerberos configuration file while initializing > >>>>>>Kerberos 5 library > >>>>>I would recommend to check /etc/krb5.conf first. Since the library call > >>>>>SSSD uses the read the keytab will read /etc/krb5.conf as well, this > >>>>>might be the reason for the SSSD issue as well. > >>>>I said keytab, I meant config, which is below included. > >>>This is the SSSD config file /etc/sssd/sssd.conf, I really meant > >>>/etc/krb5.conf. > >>I wonder if it can be one use case where install script/process does not > >>realize it fails. I did run install on a virtually identical machine, > >>actually virtual kvm centos and it worked there, only exception is no sssd > >>there, not sure about 100% though. > >> > >>Most worryingly when I try to restart dirsrv@ I see this: > >> > >>[ 762.293817] ns-slapd[8772]: segfault at 8 ip 00007f3186a02b29 sp > >>00007ffe73055d60 error 4 in libipa_pwd_extop.so[7f31869f1000+2a000] > >>[ 779.072156] SELinux: initialized (dev tmpfs, type tmpfs), uses transition > >>SIDs > >>[ 801.098886] ns-slapd[8958]: segfault at 8 ip 00007fe875c5ab29 sp > >>00007ffc2c6c26e0 error 4 in libipa_pwd_extop.so[7fe875c49000+2a000] > >> > >>I'm not an expert, it looks pretty regular to me, here krb config: > >unfortunately it is broken, nearly every line with a '#' is wrong and > >causes libkrb5 to fail parsing the file. I think this is caused by an > >issue with authconfig > >(https://bugzilla.redhat.com/show_bug.cgi?id=1184639). Please try to > >upgrade to authconfig-6.2.8-10.el7 or higher. Nevertheless I think > >neither authconfig nor ipa-client-install will be able to fix the broken > >file completely and you have to delete the following lines manually. > yes, indeed it seems that when I used authconf (not tui) to disable ldap & > ssd configs were cleared of # char. I cannot only be sure 100% as I had a > look at configs after ipa install. > But I'll also say it would be nice to have kerberos smart and able to digest > these special cases, handle these chars regardless, no? no, because it is not about the '#' character, this is handled properly as a comment. This means there is a dangling '}' because the '{' was commented out before. The other '#' seems to do no harm but I suggested to remove them to be on the safe side. bye, Sumit > >>[logging] > >> default = FILE:/var/log/krb5libs.log > >> kdc = FILE:/var/log/krb5kdc.log > >> admin_server = FILE:/var/log/kadmind.log > >> > >>[libdefaults] > >> default_realm = # > > ^^^ delete ^^^ > >> dns_lookup_realm = false > >> dns_lookup_kdc = true > >> rdns = false > >> ticket_lifetime = 24h > >> forwardable = yes > >> udp_preference_limit = 0 > >> default_ccache_name = KEYRING:persistent:%{uid} > >> > >>[realms] > >> HOST.FAKE = { > >> kdc = my.host.fake:88 > >> master_kdc = my.host.fake:88 > >> admin_server = my.host.fake:749 > >> default_domain = host.fake > >> pkinit_anchors = FILE:/etc/ipa/ca.crt > >>} > >> > >> # = { > > ^^^ delete ^^^ > >> kdc = my.host.fake:88 > > ^^^ delete ^^^ > >> admin_server = my.host.fake:749 > > ^^^ delete ^^^ > >> } > > ^^^ delete ^^^ > >>[domain_realm] > >> .host.fake = HOST.FAKE > >> host.fake = HOST.FAKE > >> > >> # = # > > ^^^ delete ^^^ > >> .# = # > > ^^^ delete ^^^ > >>[dbmodules] > >> HOST.FAKE = { > >> db_library = ipadb.so > >> } > >> > >bye, > >Sumit > > > >>>bye, > >>>Sumit > >>> > >>>>>HTH > >>>>> > >>>>>bye, > >>>>>Sumit > >>>>> > >>>>>>here is keytab server installer created/amended: (one thing that I'm not > >>>>>>sure is the fact that my new "host.fake" domain is different from my > >>>>>>previously existing ldap search > >>>>>>"dc=xxx,dc=zzzzzzzz" - if it matters at all? Otherwise I have no clue. > >>>>>> > >>>>>>[domain/host.fake] > >>>>>> > >>>>>>cache_credentials = True > >>>>>>krb5_store_password_if_offline = True > >>>>>>ipa_domain = host.fake > >>>>>>id_provider = ipa > >>>>>>auth_provider = ipa > >>>>>>access_provider = ipa > >>>>>>ipa_hostname = my.host.fake > >>>>>>chpass_provider = ipa > >>>>>>ipa_server = my.host.fake > >>>>>>ipa_server_mode = True > >>>>>>ldap_tls_cacert = /etc/ipa/ca.crt > >>>>>>[domain/default] > >>>>>>autofs_provider = ldap > >>>>>>cache_credentials = True > >>>>>>krb5_realm = # > >>>>>>ldap_search_base = dc=xxx,dc=zzzzzzzz > >>>>>>id_provider = ldap > >>>>>>auth_provider = ldap > >>>>>>chpass_provider = ldap > >>>>>>ldap_uri = ldap://my.host.fake:1389/ > >>>>>>ldap_id_use_start_tls = True > >>>>>>ldap_tls_cacertdir = /etc/openldap/cacerts > >>>>>> > >>>>>>krb5_server = my.host.fake:88 > >>>>>>[sssd] > >>>>>>services = nss, sudo, pam, autofs, ssh > >>>>>>config_file_version = 2 > >>>>>> > >>>>>>domains = host.fake > >>>>>> > >>>>>>[nss] > >>>>>>memcache_timeout = 600 > >>>>>>homedir_substring = /home > >>>>>> > >>>>>> > >>>>>>regards. > >>>>>> > >>>>>>-- > >>>>>>Manage your subscription for the Freeipa-users mailing list: > >>>>>>https://www.redhat.com/mailman/listinfo/freeipa-users > >>>>>>Go to http://freeipa.org for more info on the project > >>>>-- > >>>>Manage your subscription for the Freeipa-users mailing list: > >>>>https://www.redhat.com/mailman/listinfo/freeipa-users > >>>>Go to http://freeipa.org for more info on the project > From pspacek at redhat.com Thu Feb 25 10:16:41 2016 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 25 Feb 2016 11:16:41 +0100 Subject: [Freeipa-users] RHEL 7.2/Oracle Linux 7.2 - DNS FORWARD ZONE doesn't work! In-Reply-To: <56CDA1DC.2010505@redhat.com> References: <000001d16ef9$ea6a92a0$bf3fb7e0$@terra.com.br> <56CDA1DC.2010505@redhat.com> Message-ID: <56CED489.9040504@redhat.com> On 24.2.2016 13:28, Martin Basti wrote: > > > On 24.02.2016 12:53, Alexandre Borges wrote: >> >> Dear colleagues, >> >> How are you? >> >> I?ve been facing a horrible problem with RHEL 7.2 (and Oracle Linux 7.2) >> when configuring IPA dnsforwardzone during the Active Directory integration. >> >> My configuration follows: >> >> IPA Server: 192.168.1.195 (rhel72-1.example.com) >> >> Win2012 (AD): 192.168.1.229 (win2012.example.local) ? different domains!!! >> >> Last command executed: >> >> [root at rhel72-1 ~]# *ipa dnszone-find* >> >> Zone name: 1.168.192.in-addr.arpa. >> >> Active zone: TRUE >> >> Authoritative nameserver: rhel72-1.example.com. >> >> Administrator e-mail address: hostmaster.example.com. >> >> SOA serial: 1456310858 >> >> SOA refresh: 3600 >> >> SOA retry: 900 >> >> SOA expire: 1209600 >> >> SOA minimum: 3600 >> >> Allow query: any; >> >> Allow transfer: none; >> >> Zone name: example.com. >> >> Active zone: TRUE >> >> Authoritative nameserver: rhel72-1.example.com. >> >> Administrator e-mail address: hostmaster.example.com. >> >> SOA serial: 1456310858 >> >> SOA refresh: 3600 >> >> SOA retry: 900 >> >> SOA expire: 1209600 >> >> SOA minimum: 3600 >> >> Allow query: any; >> >> Allow transfer: none; >> >> Allow in-line DNSSEC signing: FALSE >> >> ---------------------------- >> >> Number of entries returned 2 >> >> ---------------------------- >> >> [root at rhel72-1 ~]# *ipa dnsconfig-show* >> >> Global forwarders: 8.8.8.8, 8.8.4.4 >> >> [root at rhel72-1 ~]# *ipa dnsforwardzone-add example.local >> --forwarder=192.168.1.229 --forward-policy=only* >> >> Server will check DNS forwarder(s). >> >> This may take some time, please wait ... >> >> ipa: WARNING: DNSSEC validation failed: record 'example.local. SOA' failed >> DNSSEC validation on server 192.168.1.195. >> >> Please verify your DNSSEC configuration or disable DNSSEC validation on all >> IPA servers. >> >> Zone name: example.local. >> >> Active zone: TRUE >> >> Zone forwarders: 192.168.1.229 >> >> Forward policy: only >> >> [root at rhel72-1 ~]# *ipa dnsforwardzone-find* >> >> Zone name: example.local. >> >> Active zone: TRUE >> >> Zone forwarders: 192.168.1.229 >> >> Forward policy: only >> >> ---------------------------- >> >> Number of entries returned 1 >> >> ---------------------------- >> >> *[root at rhel72-1 ~]#* *ping win2012.example.local* >> >> ping: unknown host win2012.example.local >> >> I?ve already rebooted the host, but it hasn?t worked. >> >> The same problem is happening with Oracle Linux 7.2. >> >> Please, could you help me, please? >> >> I hope you have a nice day. >> >> Alexandre Borges. >> > > Hello Alexandre, > > because you use .local TLD domain, it will be never DNSSEC valid domain, > please disable DNSSEC validation on all DNS servers, as warning from > dnsforwardzone-add suggested. Please note that this is only workaround for inherently broken configuration. It goes directly against "System Prerequisites" stated on https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/prerequisites.html#dns-reqs and https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/sec-Securing_DNS_Traffic_with_DNSSEC.html#sec-Recommended_Naming_Practices It should work but you might face various problems later on. This configuration with made-up names is strongly discouraged. FreeIPA upstream has the same recommendations in different words if you wish: http://www.freeipa.org/page/DNS#Caveats I hope this helps. Petr^2 Spacek > > /etc/named.conf > set dnssec-validation to no > > Martin Basti From peljasz at yahoo.co.uk Thu Feb 25 11:58:04 2016 From: peljasz at yahoo.co.uk (lejeczek) Date: Thu, 25 Feb 2016 11:58:04 +0000 Subject: [Freeipa-users] installation of ipa-server successful but sssd fails.. In-Reply-To: <20160225093242.GN7535@p.redhat.com> References: <56CD9229.2000406@yahoo.co.uk> <20160224112626.GY7535@p.redhat.com> <56CDA603.9060004@yahoo.co.uk> <20160224142238.GD7535@p.redhat.com> <56CDE65E.9050909@yahoo.co.uk> <20160225082126.GJ7535@p.redhat.com> <56CEC782.1060004@yahoo.co.uk> <20160225093242.GN7535@p.redhat.com> Message-ID: <56CEEC4C.7080002@yahoo.co.uk> On 25/02/16 09:32, Sumit Bose wrote: > On Thu, Feb 25, 2016 at 09:21:06AM +0000, lejeczek wrote: >> On 25/02/16 08:21, Sumit Bose wrote: >>> On Wed, Feb 24, 2016 at 05:20:30PM +0000, lejeczek wrote: >>>> On 24/02/16 14:22, Sumit Bose wrote: >>>>> On Wed, Feb 24, 2016 at 12:45:55PM +0000, lejeczek wrote: >>>>>> On 24/02/16 11:26, Sumit Bose wrote: >>>>>>> On Wed, Feb 24, 2016 at 11:21:13AM +0000, lejeczek wrote: >>>>>>>> he everybody, >>>>>>>> my first tampering with install gets me: >>>>>>>> >>>>>>>> Feb 24 11:04:22 my.host.fake sssd[be[host.fake]][17425]: Starting up >>>>>>>> Feb 24 11:04:22 my.host.fake sssd[be[host.fake]][17425]: Failed to read >>>>>>>> keytab [default]: Bad address >>>>>>>> Feb 24 11:04:22 my.host.fake sssd[17406]: Exiting the SSSD. Could not >>>>>>>> restart critical service [host.fake]. >>>>>>>> Feb 24 11:04:22 my.host.fake systemd[1]: sssd.service: control process >>>>>>>> exited, code=exited status=1 >>>>>>>> Feb 24 11:04:22 my.host.fake systemd[1]: Failed to start System Security >>>>>>>> Services Daemon. >>>>>>>> Feb 24 11:04:22 my.host.fake systemd[1]: Unit sssd.service entered failed >>>>>>>> state. >>>>>>>> Feb 24 11:04:22 my.host.fake systemd[1]: sssd.service failed. >>>>>>>> >>>>>>>> And just after install process finishes I try: >>>>>>>> $ kinit admin >>>>>>>> kinit: Improper format of Kerberos configuration file while initializing >>>>>>>> Kerberos 5 library >>>>>>> I would recommend to check /etc/krb5.conf first. Since the library call >>>>>>> SSSD uses the read the keytab will read /etc/krb5.conf as well, this >>>>>>> might be the reason for the SSSD issue as well. >>>>>> I said keytab, I meant config, which is below included. >>>>> This is the SSSD config file /etc/sssd/sssd.conf, I really meant >>>>> /etc/krb5.conf. >>>> I wonder if it can be one use case where install script/process does not >>>> realize it fails. I did run install on a virtually identical machine, >>>> actually virtual kvm centos and it worked there, only exception is no sssd >>>> there, not sure about 100% though. >>>> >>>> Most worryingly when I try to restart dirsrv@ I see this: >>>> >>>> [ 762.293817] ns-slapd[8772]: segfault at 8 ip 00007f3186a02b29 sp >>>> 00007ffe73055d60 error 4 in libipa_pwd_extop.so[7f31869f1000+2a000] >>>> [ 779.072156] SELinux: initialized (dev tmpfs, type tmpfs), uses transition >>>> SIDs >>>> [ 801.098886] ns-slapd[8958]: segfault at 8 ip 00007fe875c5ab29 sp >>>> 00007ffc2c6c26e0 error 4 in libipa_pwd_extop.so[7fe875c49000+2a000] >>>> >>>> I'm not an expert, it looks pretty regular to me, here krb config: >>> unfortunately it is broken, nearly every line with a '#' is wrong and >>> causes libkrb5 to fail parsing the file. I think this is caused by an >>> issue with authconfig >>> (https://bugzilla.redhat.com/show_bug.cgi?id=1184639). Please try to >>> upgrade to authconfig-6.2.8-10.el7 or higher. Nevertheless I think >>> neither authconfig nor ipa-client-install will be able to fix the broken >>> file completely and you have to delete the following lines manually. >> yes, indeed it seems that when I used authconf (not tui) to disable ldap & >> ssd configs were cleared of # char. I cannot only be sure 100% as I had a >> look at configs after ipa install. >> But I'll also say it would be nice to have kerberos smart and able to digest >> these special cases, handle these chars regardless, no? > no, because it is not about the '#' character, this is handled properly > as a comment. This means there is a dangling '}' because the '{' was > commented out before. The other '#' seems to do no harm but I suggested > to remove them to be on the safe side. > > bye, > Sumit thanks Sumit, should I make it a bug report? > >>>> [logging] >>>> default = FILE:/var/log/krb5libs.log >>>> kdc = FILE:/var/log/krb5kdc.log >>>> admin_server = FILE:/var/log/kadmind.log >>>> >>>> [libdefaults] >>>> default_realm = # >>> ^^^ delete ^^^ >>>> dns_lookup_realm = false >>>> dns_lookup_kdc = true >>>> rdns = false >>>> ticket_lifetime = 24h >>>> forwardable = yes >>>> udp_preference_limit = 0 >>>> default_ccache_name = KEYRING:persistent:%{uid} >>>> >>>> [realms] >>>> HOST.FAKE = { >>>> kdc = my.host.fake:88 >>>> master_kdc = my.host.fake:88 >>>> admin_server = my.host.fake:749 >>>> default_domain = host.fake >>>> pkinit_anchors = FILE:/etc/ipa/ca.crt >>>> } >>>> >>>> # = { >>> ^^^ delete ^^^ >>>> kdc = my.host.fake:88 >>> ^^^ delete ^^^ >>>> admin_server = my.host.fake:749 >>> ^^^ delete ^^^ >>>> } >>> ^^^ delete ^^^ >>>> [domain_realm] >>>> .host.fake = HOST.FAKE >>>> host.fake = HOST.FAKE >>>> >>>> # = # >>> ^^^ delete ^^^ >>>> .# = # >>> ^^^ delete ^^^ >>>> [dbmodules] >>>> HOST.FAKE = { >>>> db_library = ipadb.so >>>> } >>>> >>> bye, >>> Sumit >>> >>>>> bye, >>>>> Sumit >>>>> >>>>>>> HTH >>>>>>> >>>>>>> bye, >>>>>>> Sumit >>>>>>> >>>>>>>> here is keytab server installer created/amended: (one thing that I'm not >>>>>>>> sure is the fact that my new "host.fake" domain is different from my >>>>>>>> previously existing ldap search >>>>>>>> "dc=xxx,dc=zzzzzzzz" - if it matters at all? Otherwise I have no clue. >>>>>>>> >>>>>>>> [domain/host.fake] >>>>>>>> >>>>>>>> cache_credentials = True >>>>>>>> krb5_store_password_if_offline = True >>>>>>>> ipa_domain = host.fake >>>>>>>> id_provider = ipa >>>>>>>> auth_provider = ipa >>>>>>>> access_provider = ipa >>>>>>>> ipa_hostname = my.host.fake >>>>>>>> chpass_provider = ipa >>>>>>>> ipa_server = my.host.fake >>>>>>>> ipa_server_mode = True >>>>>>>> ldap_tls_cacert = /etc/ipa/ca.crt >>>>>>>> [domain/default] >>>>>>>> autofs_provider = ldap >>>>>>>> cache_credentials = True >>>>>>>> krb5_realm = # >>>>>>>> ldap_search_base = dc=xxx,dc=zzzzzzzz >>>>>>>> id_provider = ldap >>>>>>>> auth_provider = ldap >>>>>>>> chpass_provider = ldap >>>>>>>> ldap_uri = ldap://my.host.fake:1389/ >>>>>>>> ldap_id_use_start_tls = True >>>>>>>> ldap_tls_cacertdir = /etc/openldap/cacerts >>>>>>>> >>>>>>>> krb5_server = my.host.fake:88 >>>>>>>> [sssd] >>>>>>>> services = nss, sudo, pam, autofs, ssh >>>>>>>> config_file_version = 2 >>>>>>>> >>>>>>>> domains = host.fake >>>>>>>> >>>>>>>> [nss] >>>>>>>> memcache_timeout = 600 >>>>>>>> homedir_substring = /home >>>>>>>> >>>>>>>> >>>>>>>> regards. >>>>>>>> >>>>>>>> -- >>>>>>>> Manage your subscription for the Freeipa-users mailing list: >>>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>>>>> Go to http://freeipa.org for more info on the project >>>>>> -- >>>>>> Manage your subscription for the Freeipa-users mailing list: >>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>>> Go to http://freeipa.org for more info on the project From sbose at redhat.com Thu Feb 25 12:29:55 2016 From: sbose at redhat.com (Sumit Bose) Date: Thu, 25 Feb 2016 13:29:55 +0100 Subject: [Freeipa-users] installation of ipa-server successful but sssd fails.. In-Reply-To: <56CEEC4C.7080002@yahoo.co.uk> References: <56CD9229.2000406@yahoo.co.uk> <20160224112626.GY7535@p.redhat.com> <56CDA603.9060004@yahoo.co.uk> <20160224142238.GD7535@p.redhat.com> <56CDE65E.9050909@yahoo.co.uk> <20160225082126.GJ7535@p.redhat.com> <56CEC782.1060004@yahoo.co.uk> <20160225093242.GN7535@p.redhat.com> <56CEEC4C.7080002@yahoo.co.uk> Message-ID: <20160225122955.GQ7535@p.redhat.com> On Thu, Feb 25, 2016 at 11:58:04AM +0000, lejeczek wrote: > On 25/02/16 09:32, Sumit Bose wrote: > >On Thu, Feb 25, 2016 at 09:21:06AM +0000, lejeczek wrote: > >>On 25/02/16 08:21, Sumit Bose wrote: > >>>On Wed, Feb 24, 2016 at 05:20:30PM +0000, lejeczek wrote: > >>>>On 24/02/16 14:22, Sumit Bose wrote: > >>>>>On Wed, Feb 24, 2016 at 12:45:55PM +0000, lejeczek wrote: > >>>>>>On 24/02/16 11:26, Sumit Bose wrote: > >>>>>>>On Wed, Feb 24, 2016 at 11:21:13AM +0000, lejeczek wrote: > >>>>>>>>he everybody, > >>>>>>>>my first tampering with install gets me: > >>>>>>>> > >>>>>>>>Feb 24 11:04:22 my.host.fake sssd[be[host.fake]][17425]: Starting up > >>>>>>>>Feb 24 11:04:22 my.host.fake sssd[be[host.fake]][17425]: Failed to read > >>>>>>>>keytab [default]: Bad address > >>>>>>>>Feb 24 11:04:22 my.host.fake sssd[17406]: Exiting the SSSD. Could not > >>>>>>>>restart critical service [host.fake]. > >>>>>>>>Feb 24 11:04:22 my.host.fake systemd[1]: sssd.service: control process > >>>>>>>>exited, code=exited status=1 > >>>>>>>>Feb 24 11:04:22 my.host.fake systemd[1]: Failed to start System Security > >>>>>>>>Services Daemon. > >>>>>>>>Feb 24 11:04:22 my.host.fake systemd[1]: Unit sssd.service entered failed > >>>>>>>>state. > >>>>>>>>Feb 24 11:04:22 my.host.fake systemd[1]: sssd.service failed. > >>>>>>>> > >>>>>>>>And just after install process finishes I try: > >>>>>>>>$ kinit admin > >>>>>>>>kinit: Improper format of Kerberos configuration file while initializing > >>>>>>>>Kerberos 5 library > >>>>>>>I would recommend to check /etc/krb5.conf first. Since the library call > >>>>>>>SSSD uses the read the keytab will read /etc/krb5.conf as well, this > >>>>>>>might be the reason for the SSSD issue as well. > >>>>>>I said keytab, I meant config, which is below included. > >>>>>This is the SSSD config file /etc/sssd/sssd.conf, I really meant > >>>>>/etc/krb5.conf. > >>>>I wonder if it can be one use case where install script/process does not > >>>>realize it fails. I did run install on a virtually identical machine, > >>>>actually virtual kvm centos and it worked there, only exception is no sssd > >>>>there, not sure about 100% though. > >>>> > >>>>Most worryingly when I try to restart dirsrv@ I see this: > >>>> > >>>>[ 762.293817] ns-slapd[8772]: segfault at 8 ip 00007f3186a02b29 sp > >>>>00007ffe73055d60 error 4 in libipa_pwd_extop.so[7f31869f1000+2a000] > >>>>[ 779.072156] SELinux: initialized (dev tmpfs, type tmpfs), uses transition > >>>>SIDs > >>>>[ 801.098886] ns-slapd[8958]: segfault at 8 ip 00007fe875c5ab29 sp > >>>>00007ffc2c6c26e0 error 4 in libipa_pwd_extop.so[7fe875c49000+2a000] > >>>> > >>>>I'm not an expert, it looks pretty regular to me, here krb config: > >>>unfortunately it is broken, nearly every line with a '#' is wrong and > >>>causes libkrb5 to fail parsing the file. I think this is caused by an > >>>issue with authconfig > >>>(https://bugzilla.redhat.com/show_bug.cgi?id=1184639). Please try to > >>>upgrade to authconfig-6.2.8-10.el7 or higher. Nevertheless I think > >>>neither authconfig nor ipa-client-install will be able to fix the broken > >>>file completely and you have to delete the following lines manually. > >>yes, indeed it seems that when I used authconf (not tui) to disable ldap & > >>ssd configs were cleared of # char. I cannot only be sure 100% as I had a > >>look at configs after ipa install. > >>But I'll also say it would be nice to have kerberos smart and able to digest > >>these special cases, handle these chars regardless, no? > >no, because it is not about the '#' character, this is handled properly > >as a comment. This means there is a dangling '}' because the '{' was > >commented out before. The other '#' seems to do no harm but I suggested > >to remove them to be on the safe side. > > > >bye, > >Sumit > thanks Sumit, should I make it a bug report? no, I think the authconfig ticket is sufficient here. bye, Sumit > > > >>>>[logging] > >>>> default = FILE:/var/log/krb5libs.log > >>>> kdc = FILE:/var/log/krb5kdc.log > >>>> admin_server = FILE:/var/log/kadmind.log > >>>> > >>>>[libdefaults] > >>>> default_realm = # > >>> ^^^ delete ^^^ > >>>> dns_lookup_realm = false > >>>> dns_lookup_kdc = true > >>>> rdns = false > >>>> ticket_lifetime = 24h > >>>> forwardable = yes > >>>> udp_preference_limit = 0 > >>>> default_ccache_name = KEYRING:persistent:%{uid} > >>>> > >>>>[realms] > >>>> HOST.FAKE = { > >>>> kdc = my.host.fake:88 > >>>> master_kdc = my.host.fake:88 > >>>> admin_server = my.host.fake:749 > >>>> default_domain = host.fake > >>>> pkinit_anchors = FILE:/etc/ipa/ca.crt > >>>>} > >>>> > >>>> # = { > >>> ^^^ delete ^^^ > >>>> kdc = my.host.fake:88 > >>> ^^^ delete ^^^ > >>>> admin_server = my.host.fake:749 > >>> ^^^ delete ^^^ > >>>> } > >>> ^^^ delete ^^^ > >>>>[domain_realm] > >>>> .host.fake = HOST.FAKE > >>>> host.fake = HOST.FAKE > >>>> > >>>> # = # > >>> ^^^ delete ^^^ > >>>> .# = # > >>> ^^^ delete ^^^ > >>>>[dbmodules] > >>>> HOST.FAKE = { > >>>> db_library = ipadb.so > >>>> } > >>>> > >>>bye, > >>>Sumit > >>> > >>>>>bye, > >>>>>Sumit > >>>>> > >>>>>>>HTH > >>>>>>> > >>>>>>>bye, > >>>>>>>Sumit > >>>>>>> > >>>>>>>>here is keytab server installer created/amended: (one thing that I'm not > >>>>>>>>sure is the fact that my new "host.fake" domain is different from my > >>>>>>>>previously existing ldap search > >>>>>>>>"dc=xxx,dc=zzzzzzzz" - if it matters at all? Otherwise I have no clue. > >>>>>>>> > >>>>>>>>[domain/host.fake] > >>>>>>>> > >>>>>>>>cache_credentials = True > >>>>>>>>krb5_store_password_if_offline = True > >>>>>>>>ipa_domain = host.fake > >>>>>>>>id_provider = ipa > >>>>>>>>auth_provider = ipa > >>>>>>>>access_provider = ipa > >>>>>>>>ipa_hostname = my.host.fake > >>>>>>>>chpass_provider = ipa > >>>>>>>>ipa_server = my.host.fake > >>>>>>>>ipa_server_mode = True > >>>>>>>>ldap_tls_cacert = /etc/ipa/ca.crt > >>>>>>>>[domain/default] > >>>>>>>>autofs_provider = ldap > >>>>>>>>cache_credentials = True > >>>>>>>>krb5_realm = # > >>>>>>>>ldap_search_base = dc=xxx,dc=zzzzzzzz > >>>>>>>>id_provider = ldap > >>>>>>>>auth_provider = ldap > >>>>>>>>chpass_provider = ldap > >>>>>>>>ldap_uri = ldap://my.host.fake:1389/ > >>>>>>>>ldap_id_use_start_tls = True > >>>>>>>>ldap_tls_cacertdir = /etc/openldap/cacerts > >>>>>>>> > >>>>>>>>krb5_server = my.host.fake:88 > >>>>>>>>[sssd] > >>>>>>>>services = nss, sudo, pam, autofs, ssh > >>>>>>>>config_file_version = 2 > >>>>>>>> > >>>>>>>>domains = host.fake > >>>>>>>> > >>>>>>>>[nss] > >>>>>>>>memcache_timeout = 600 > >>>>>>>>homedir_substring = /home > >>>>>>>> > >>>>>>>> > >>>>>>>>regards. > >>>>>>>> > >>>>>>>>-- > >>>>>>>>Manage your subscription for the Freeipa-users mailing list: > >>>>>>>>https://www.redhat.com/mailman/listinfo/freeipa-users > >>>>>>>>Go to http://freeipa.org for more info on the project > >>>>>>-- > >>>>>>Manage your subscription for the Freeipa-users mailing list: > >>>>>>https://www.redhat.com/mailman/listinfo/freeipa-users > >>>>>>Go to http://freeipa.org for more info on the project > From harald.dunkel at aixigo.de Thu Feb 25 12:48:20 2016 From: harald.dunkel at aixigo.de (Harald Dunkel) Date: Thu, 25 Feb 2016 13:48:20 +0100 Subject: [Freeipa-users] sssd went away, failed to restart In-Reply-To: <20160224082447.GL3625@hendrix> References: <56CB16AF.9060303@aixigo.de> <20160222145152.GB3321@hendrix.arn.redhat.com> <56CC063E.7080900@aixigo.de> <20160223090003.GA3131@hendrix.redhat.com> <56CC2C86.8040109@aixigo.de> <20160223105825.GC2468@mail.corp.redhat.com> <56CC4A05.5040503@aixigo.de> <20160223124602.GH2468@mail.corp.redhat.com> <56CCE222.8010209@afaics.de> <20160224082447.GL3625@hendrix> Message-ID: <56CEF814.4000806@aixigo.de> Hi Jakub, On 02/24/2016 09:24 AM, Jakub Hrozek wrote: > > Do you have debug_level=N in the [domain] section? > I have set N=5. Is this OK to set global debugging for all modules? I am used to set something like debug_level = info but the man page doesn't tell. Regards Harri From jhrozek at redhat.com Thu Feb 25 12:55:45 2016 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 25 Feb 2016 13:55:45 +0100 Subject: [Freeipa-users] sssd went away, failed to restart In-Reply-To: <56CEF814.4000806@aixigo.de> References: <20160222145152.GB3321@hendrix.arn.redhat.com> <56CC063E.7080900@aixigo.de> <20160223090003.GA3131@hendrix.redhat.com> <56CC2C86.8040109@aixigo.de> <20160223105825.GC2468@mail.corp.redhat.com> <56CC4A05.5040503@aixigo.de> <20160223124602.GH2468@mail.corp.redhat.com> <56CCE222.8010209@afaics.de> <20160224082447.GL3625@hendrix> <56CEF814.4000806@aixigo.de> Message-ID: <20160225125545.GA20147@hendrix.redhat.com> On Thu, Feb 25, 2016 at 01:48:20PM +0100, Harald Dunkel wrote: > Hi Jakub, > > On 02/24/2016 09:24 AM, Jakub Hrozek wrote: > > > > Do you have debug_level=N in the [domain] section? > > > > I have set N=5. Is this OK to set global debugging for all > modules? Putting the option to the [domain] section would make the sssd_be process log more verbosely. Since the sssd process is the one that kills the non-responsive processes, it also makes sense to add the debug_level to the [sssd] section. 5 might be a good start. > I am used to set something like > > debug_level = info > > but the man page doesn't tell. man sssd.conf explains the format of the argument (decimal or hexadecimal number) From simo at redhat.com Thu Feb 25 14:35:47 2016 From: simo at redhat.com (Simo Sorce) Date: Thu, 25 Feb 2016 09:35:47 -0500 Subject: [Freeipa-users] PA Soalris client- Kerberos error In-Reply-To: <00d401d16f8b$52767fd0$f7637f70$@jithpl.com> References: <00d401d16f8b$52767fd0$f7637f70$@jithpl.com> Message-ID: <1456410947.6599.280.camel@redhat.com> On Thu, 2016-02-25 at 10:43 +0530, Supul Wickaramartna wrote: > > Hi, > > > > I have configured Solaris server ( 5.10 Generic_118833-33, sun4u sparc UNW, > Sun-Fire-V240) as IPA client. ldap is working, ldap user can login with 'su' > command and 'id' command displays ldap users identity information. But > Kerberos authentication failed with following error. > > > > Kinit at EXAMPLE.COM > > Segmentation Fault (core dumped) > > > > I have tested with Solaris 10 and 11 (x86) platforms, but I haven't seen > this error on Solaris 10 and 11 (x86) platforms. And I notice that > Segmentation Fault (core dumped) error only generates correct ldap user > names, because I tried with non-existing username it generates following > error "client not found in Kerberos database while getting initial > credentials" > > > > How to work around this issue ? I think this is something that can only be analyzed and fixed by Solaris support channels. A segfault is a bug in the client. Simo. -- Simo Sorce * Red Hat, Inc * New York From Terry.John at completeautomotivesolutions.co.uk Thu Feb 25 14:36:06 2016 From: Terry.John at completeautomotivesolutions.co.uk (Terry John) Date: Thu, 25 Feb 2016 14:36:06 +0000 Subject: [Freeipa-users] 14: No supported authentication methods available In-Reply-To: References: Message-ID: This turned out to be a setting in /etc/ssh/sshd_config which gets overridden by ipa-client-install. Needed to un-comment PasswordAuthentication yes Terry From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Terry John Sent: 18 February 2016 11:41 To: freeipa-users at redhat.com Subject: [Freeipa-users] 14: No supported authentication methods available I have an AWS instance running Centos 6.7 correctly configured for freeipa but I needed to make a backup machine which would remain live. I created a clone of the machine and changed the host name and the settings in /etc/hosts. When I tried to run ipa-client-install it told me to run the uninstall which I did. This had the worrying effect of not being able to log into my original live server but thankfully after a while it came good. I don't know why. Back on the new server I ran 'ipa-client-install --enable-dns-updates -mkhomedir' and it seemed to run ok. The host was created on the freeipa GUI and I added it to the same host group as the original server. But when I try to log in via SSH I get the error 'No supported authentication methods available'. I do have root access via the AWS Key file. As far as I can tell all the relevant settings seem the same between the two servers but one works and the other doesn't. I can kinit and klist using my freeipa account. 'getent netgroup my-servergroup' works fine. I can't seem to find anything relevant in the sssd logs and /var/log/secure just give me the same error of no supported authentication methods available I have noticed in /var/log/messages when I restart sssd and error which may be relevant but can't find anything useful so far sssd[be[my.domain.net]]: dereference processing failed : Input/output error Thanks Terry The Manheim group of companies within the UK comprises: Manheim Europe Limited (registered number: 03183918), Manheim Auctions Limited (registered number: 00448761), Manheim Retail Services Limited (registered number: 02838588), Motors.co.uk Limited (registered number: 05975777), Real Time Communications Limited (registered number: 04277845) and Complete Automotive Solutions Limited (registered number: 05302535). Each of these companies is registered in England and Wales with the registered office address of Central House, Leeds Road, Rothwell, Leeds LS26 0JE. The Manheim group of companies operates under various brand/trading names including Manheim Inspection Services, Manheim Auctions, Manheim Direct, Manheim De-fleet and Manheim Aftersales Solutions. V:0CF72C13B2AC -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Thu Feb 25 14:49:40 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 25 Feb 2016 09:49:40 -0500 Subject: [Freeipa-users] 14: No supported authentication methods available In-Reply-To: References: Message-ID: <56CF1484.6090807@redhat.com> Terry John wrote: > This turned out to be a setting in /etc/ssh/sshd_config which gets > overridden by ipa-client-install. Needed to un-comment > > > > PasswordAuthentication yes Glad you got it fixed but I don't think ipa-client-install was responsible for this change. It does make changes to sshd_config but not to this directive. rob > > > > Terry > > > > *From:*freeipa-users-bounces at redhat.com > [mailto:freeipa-users-bounces at redhat.com] *On Behalf Of *Terry John > *Sent:* 18 February 2016 11:41 > *To:* freeipa-users at redhat.com > *Subject:* [Freeipa-users] 14: No supported authentication methods available > > > > I have an AWS instance running Centos 6.7 correctly configured for > freeipa but I needed to make a backup machine which would remain live. > > > > I created a clone of the machine and changed the host name and the > settings in /etc/hosts. When I tried to run ipa-client-install it told > me to run the uninstall which I did. This had the worrying effect of not > being able to log into my original live server but thankfully after a > while it came good. I don?t know why. > > > > Back on the new server I ran ?ipa-client-install --enable-dns-updates > ?mkhomedir? and it seemed to run ok. The host was created on the freeipa > GUI and I added it to the same host group as the original server. But > when I try to log in via SSH I get the error ?No supported > authentication methods available?. I do have root access via the AWS Key > file. > > > > As far as I can tell all the relevant settings seem the same between the > two servers but one works and the other doesn?t. I can kinit and klist > using my freeipa account. ?getent netgroup my-servergroup? works fine. > > > > I can?t seem to find anything relevant in the sssd logs and > /var/log/secure just give me the same error of no supported > authentication methods available > > > > I have noticed in /var/log/messages when I restart sssd and error which > may be relevant but can?t find anything useful so far > > > > sssd[be[my.domain.net]]: dereference processing failed : Input/output error > > > > Thanks > > > > Terry > > > > The Manheim group of companies within the UK comprises: Manheim Europe > Limited (registered number: 03183918), Manheim Auctions Limited > (registered number: 00448761), Manheim Retail Services Limited > (registered number: 02838588), Motors.co.uk Limited (registered number: > 05975777), Real Time Communications Limited (registered number: > 04277845) and Complete Automotive Solutions Limited (registered number: > 05302535). Each of these companies is registered in England and Wales > with the registered office address of Central House, Leeds Road, > Rothwell, Leeds LS26 0JE. The Manheim group of companies operates under > various brand/trading names including Manheim Inspection Services, > Manheim Auctions, Manheim Direct, Manheim De-fleet and Manheim > Aftersales Solutions. > > V:0CF72C13B2AC > > > > > From simo at redhat.com Thu Feb 25 15:00:54 2016 From: simo at redhat.com (Simo Sorce) Date: Thu, 25 Feb 2016 10:00:54 -0500 Subject: [Freeipa-users] 14: No supported authentication methods available In-Reply-To: References: Message-ID: <1456412454.6599.282.camel@redhat.com> On Thu, 2016-02-25 at 14:36 +0000, Terry John wrote: > This turned out to be a setting in /etc/ssh/sshd_config which gets overridden by ipa-client-install. Needed to un-comment > > PasswordAuthentication yes This is disabled because we enable ChallengeResponseAuthentication which is a superset of PasswordAuthentication. PasswordAuthentication can't deal with PAM prompts, it is a oneshot only option (ie fails if PAM asks you to make a pasword change), while ChallengeResponseAuthentication is the more modern method that properly deals with PAM prompts. You should prefer ChallengeResponseAuthentication over PasswordAuthentication. HTH, Simo. > Terry > > From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Terry John > Sent: 18 February 2016 11:41 > To: freeipa-users at redhat.com > Subject: [Freeipa-users] 14: No supported authentication methods available > > I have an AWS instance running Centos 6.7 correctly configured for freeipa but I needed to make a backup machine which would remain live. > > I created a clone of the machine and changed the host name and the settings in /etc/hosts. When I tried to run ipa-client-install it told me to run the uninstall which I did. This had the worrying effect of not being able to log into my original live server but thankfully after a while it came good. I don't know why. > > Back on the new server I ran 'ipa-client-install --enable-dns-updates -mkhomedir' and it seemed to run ok. The host was created on the freeipa GUI and I added it to the same host group as the original server. But when I try to log in via SSH I get the error 'No supported authentication methods available'. I do have root access via the AWS Key file. > > As far as I can tell all the relevant settings seem the same between the two servers but one works and the other doesn't. I can kinit and klist using my freeipa account. 'getent netgroup my-servergroup' works fine. > > I can't seem to find anything relevant in the sssd logs and /var/log/secure just give me the same error of no supported authentication methods available > > I have noticed in /var/log/messages when I restart sssd and error which may be relevant but can't find anything useful so far > > sssd[be[my.domain.net]]: dereference processing failed : Input/output error > > Thanks > > Terry > > > > The Manheim group of companies within the UK comprises: Manheim Europe Limited (registered number: 03183918), Manheim Auctions Limited (registered number: 00448761), Manheim Retail Services Limited (registered number: 02838588), Motors.co.uk Limited (registered number: 05975777), Real Time Communications Limited (registered number: 04277845) and Complete Automotive Solutions Limited (registered number: 05302535). Each of these companies is registered in England and Wales with the registered office address of Central House, Leeds Road, Rothwell, Leeds LS26 0JE. The Manheim group of companies operates under various brand/trading names including Manheim Inspection Services, Manheim Auctions, Manheim Direct, Manheim De-fleet and Manheim Aftersales Solutions. > > V:0CF72C13B2AC > > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project -- Simo Sorce * Red Hat, Inc * New York From peljasz at yahoo.co.uk Thu Feb 25 15:35:22 2016 From: peljasz at yahoo.co.uk (lejeczek) Date: Thu, 25 Feb 2016 15:35:22 +0000 Subject: [Freeipa-users] installation of ipa-server successful but sssd fails.. In-Reply-To: <20160225122955.GQ7535@p.redhat.com> References: <56CD9229.2000406@yahoo.co.uk> <20160224112626.GY7535@p.redhat.com> <56CDA603.9060004@yahoo.co.uk> <20160224142238.GD7535@p.redhat.com> <56CDE65E.9050909@yahoo.co.uk> <20160225082126.GJ7535@p.redhat.com> <56CEC782.1060004@yahoo.co.uk> <20160225093242.GN7535@p.redhat.com> <56CEEC4C.7080002@yahoo.co.uk> <20160225122955.GQ7535@p.redhat.com> Message-ID: <56CF1F3A.505@yahoo.co.uk> On 25/02/16 12:29, Sumit Bose wrote: > On Thu, Feb 25, 2016 at 11:58:04AM +0000, lejeczek wrote: >> On 25/02/16 09:32, Sumit Bose wrote: >>> On Thu, Feb 25, 2016 at 09:21:06AM +0000, lejeczek wrote: >>>> On 25/02/16 08:21, Sumit Bose wrote: >>>>> On Wed, Feb 24, 2016 at 05:20:30PM +0000, lejeczek wrote: >>>>>> On 24/02/16 14:22, Sumit Bose wrote: >>>>>>> On Wed, Feb 24, 2016 at 12:45:55PM +0000, lejeczek wrote: >>>>>>>> On 24/02/16 11:26, Sumit Bose wrote: >>>>>>>>> On Wed, Feb 24, 2016 at 11:21:13AM +0000, lejeczek wrote: >>>>>>>>>> he everybody, >>>>>>>>>> my first tampering with install gets me: >>>>>>>>>> >>>>>>>>>> Feb 24 11:04:22 my.host.fake sssd[be[host.fake]][17425]: Starting up >>>>>>>>>> Feb 24 11:04:22 my.host.fake sssd[be[host.fake]][17425]: Failed to read >>>>>>>>>> keytab [default]: Bad address >>>>>>>>>> Feb 24 11:04:22 my.host.fake sssd[17406]: Exiting the SSSD. Could not >>>>>>>>>> restart critical service [host.fake]. >>>>>>>>>> Feb 24 11:04:22 my.host.fake systemd[1]: sssd.service: control process >>>>>>>>>> exited, code=exited status=1 >>>>>>>>>> Feb 24 11:04:22 my.host.fake systemd[1]: Failed to start System Security >>>>>>>>>> Services Daemon. >>>>>>>>>> Feb 24 11:04:22 my.host.fake systemd[1]: Unit sssd.service entered failed >>>>>>>>>> state. >>>>>>>>>> Feb 24 11:04:22 my.host.fake systemd[1]: sssd.service failed. >>>>>>>>>> >>>>>>>>>> And just after install process finishes I try: >>>>>>>>>> $ kinit admin >>>>>>>>>> kinit: Improper format of Kerberos configuration file while initializing >>>>>>>>>> Kerberos 5 library >>>>>>>>> I would recommend to check /etc/krb5.conf first. Since the library call >>>>>>>>> SSSD uses the read the keytab will read /etc/krb5.conf as well, this >>>>>>>>> might be the reason for the SSSD issue as well. >>>>>>>> I said keytab, I meant config, which is below included. >>>>>>> This is the SSSD config file /etc/sssd/sssd.conf, I really meant >>>>>>> /etc/krb5.conf. >>>>>> I wonder if it can be one use case where install script/process does not >>>>>> realize it fails. I did run install on a virtually identical machine, >>>>>> actually virtual kvm centos and it worked there, only exception is no sssd >>>>>> there, not sure about 100% though. >>>>>> >>>>>> Most worryingly when I try to restart dirsrv@ I see this: >>>>>> >>>>>> [ 762.293817] ns-slapd[8772]: segfault at 8 ip 00007f3186a02b29 sp >>>>>> 00007ffe73055d60 error 4 in libipa_pwd_extop.so[7f31869f1000+2a000] >>>>>> [ 779.072156] SELinux: initialized (dev tmpfs, type tmpfs), uses transition >>>>>> SIDs >>>>>> [ 801.098886] ns-slapd[8958]: segfault at 8 ip 00007fe875c5ab29 sp >>>>>> 00007ffc2c6c26e0 error 4 in libipa_pwd_extop.so[7fe875c49000+2a000] >>>>>> >>>>>> I'm not an expert, it looks pretty regular to me, here krb config: >>>>> unfortunately it is broken, nearly every line with a '#' is wrong and >>>>> causes libkrb5 to fail parsing the file. I think this is caused by an >>>>> issue with authconfig >>>>> (https://bugzilla.redhat.com/show_bug.cgi?id=1184639). Please try to >>>>> upgrade to authconfig-6.2.8-10.el7 or higher. Nevertheless I think >>>>> neither authconfig nor ipa-client-install will be able to fix the broken >>>>> file completely and you have to delete the following lines manually. >>>> yes, indeed it seems that when I used authconf (not tui) to disable ldap & >>>> ssd configs were cleared of # char. I cannot only be sure 100% as I had a >>>> look at configs after ipa install. >>>> But I'll also say it would be nice to have kerberos smart and able to digest >>>> these special cases, handle these chars regardless, no? >>> no, because it is not about the '#' character, this is handled properly >>> as a comment. This means there is a dangling '}' because the '{' was >>> commented out before. The other '#' seems to do no harm but I suggested >>> to remove them to be on the safe side. >>> >>> bye, >>> Sumit >> thanks Sumit, should I make it a bug report? > no, I think the authconfig ticket is sufficient here. I'll insist on the claim that installer could do better, especially when it completes without any errors nor warnings. I'm sure dev guys could easily resolve it in a number of ways, just to let them know. > bye, > Sumit > >>>>>> [logging] >>>>>> default = FILE:/var/log/krb5libs.log >>>>>> kdc = FILE:/var/log/krb5kdc.log >>>>>> admin_server = FILE:/var/log/kadmind.log >>>>>> >>>>>> [libdefaults] >>>>>> default_realm = # >>>>> ^^^ delete ^^^ >>>>>> dns_lookup_realm = false >>>>>> dns_lookup_kdc = true >>>>>> rdns = false >>>>>> ticket_lifetime = 24h >>>>>> forwardable = yes >>>>>> udp_preference_limit = 0 >>>>>> default_ccache_name = KEYRING:persistent:%{uid} >>>>>> >>>>>> [realms] >>>>>> HOST.FAKE = { >>>>>> kdc = my.host.fake:88 >>>>>> master_kdc = my.host.fake:88 >>>>>> admin_server = my.host.fake:749 >>>>>> default_domain = host.fake >>>>>> pkinit_anchors = FILE:/etc/ipa/ca.crt >>>>>> } >>>>>> >>>>>> # = { >>>>> ^^^ delete ^^^ >>>>>> kdc = my.host.fake:88 >>>>> ^^^ delete ^^^ >>>>>> admin_server = my.host.fake:749 >>>>> ^^^ delete ^^^ >>>>>> } >>>>> ^^^ delete ^^^ >>>>>> [domain_realm] >>>>>> .host.fake = HOST.FAKE >>>>>> host.fake = HOST.FAKE >>>>>> >>>>>> # = # >>>>> ^^^ delete ^^^ >>>>>> .# = # >>>>> ^^^ delete ^^^ >>>>>> [dbmodules] >>>>>> HOST.FAKE = { >>>>>> db_library = ipadb.so >>>>>> } >>>>>> >>>>> bye, >>>>> Sumit >>>>> >>>>>>> bye, >>>>>>> Sumit >>>>>>> >>>>>>>>> HTH >>>>>>>>> >>>>>>>>> bye, >>>>>>>>> Sumit >>>>>>>>> >>>>>>>>>> here is keytab server installer created/amended: (one thing that I'm not >>>>>>>>>> sure is the fact that my new "host.fake" domain is different from my >>>>>>>>>> previously existing ldap search >>>>>>>>>> "dc=xxx,dc=zzzzzzzz" - if it matters at all? Otherwise I have no clue. >>>>>>>>>> >>>>>>>>>> [domain/host.fake] >>>>>>>>>> >>>>>>>>>> cache_credentials = True >>>>>>>>>> krb5_store_password_if_offline = True >>>>>>>>>> ipa_domain = host.fake >>>>>>>>>> id_provider = ipa >>>>>>>>>> auth_provider = ipa >>>>>>>>>> access_provider = ipa >>>>>>>>>> ipa_hostname = my.host.fake >>>>>>>>>> chpass_provider = ipa >>>>>>>>>> ipa_server = my.host.fake >>>>>>>>>> ipa_server_mode = True >>>>>>>>>> ldap_tls_cacert = /etc/ipa/ca.crt >>>>>>>>>> [domain/default] >>>>>>>>>> autofs_provider = ldap >>>>>>>>>> cache_credentials = True >>>>>>>>>> krb5_realm = # >>>>>>>>>> ldap_search_base = dc=xxx,dc=zzzzzzzz >>>>>>>>>> id_provider = ldap >>>>>>>>>> auth_provider = ldap >>>>>>>>>> chpass_provider = ldap >>>>>>>>>> ldap_uri = ldap://my.host.fake:1389/ >>>>>>>>>> ldap_id_use_start_tls = True >>>>>>>>>> ldap_tls_cacertdir = /etc/openldap/cacerts >>>>>>>>>> >>>>>>>>>> krb5_server = my.host.fake:88 >>>>>>>>>> [sssd] >>>>>>>>>> services = nss, sudo, pam, autofs, ssh >>>>>>>>>> config_file_version = 2 >>>>>>>>>> >>>>>>>>>> domains = host.fake >>>>>>>>>> >>>>>>>>>> [nss] >>>>>>>>>> memcache_timeout = 600 >>>>>>>>>> homedir_substring = /home >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> regards. >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Manage your subscription for the Freeipa-users mailing list: >>>>>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>>>>>>> Go to http://freeipa.org for more info on the project >>>>>>>> -- >>>>>>>> Manage your subscription for the Freeipa-users mailing list: >>>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>>>>> Go to http://freeipa.org for more info on the project From Terry.John at completeautomotivesolutions.co.uk Thu Feb 25 16:56:22 2016 From: Terry.John at completeautomotivesolutions.co.uk (Terry John) Date: Thu, 25 Feb 2016 16:56:22 +0000 Subject: [Freeipa-users] 14: No supported authentication methods available In-Reply-To: <1456412454.6599.282.camel@redhat.com> References: <1456412454.6599.282.camel@redhat.com> Message-ID: Thanks for that. From what I've read there is no simple right answer. In 2013 RedHat itself says to leave ChallengeResponseAuthentication set to no "due to security reasons". https://access.redhat.com/solutions/336773 Setting PasswordAuthentication yes seems to leave all the other settings within thee sshd_config file like "PermitRootLogin without-password" which may be overridden elsewhere if ChallengeResponseAuthentication is set to yes Terry -----Original Message----- From: Simo Sorce [mailto:simo at redhat.com] Sent: 25 February 2016 15:01 To: Terry John Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] 14: No supported authentication methods available On Thu, 2016-02-25 at 14:36 +0000, Terry John wrote: > This turned out to be a setting in /etc/ssh/sshd_config which gets > overridden by ipa-client-install. Needed to un-comment > > PasswordAuthentication yes This is disabled because we enable ChallengeResponseAuthentication which is a superset of PasswordAuthentication. PasswordAuthentication can't deal with PAM prompts, it is a oneshot only option (ie fails if PAM asks you to make a pasword change), while ChallengeResponseAuthentication is the more modern method that properly deals with PAM prompts. You should prefer ChallengeResponseAuthentication over PasswordAuthentication. HTH, Simo. > Terry > > From: freeipa-users-bounces at redhat.com > [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Terry John > Sent: 18 February 2016 11:41 > To: freeipa-users at redhat.com > Subject: [Freeipa-users] 14: No supported authentication methods > available > > I have an AWS instance running Centos 6.7 correctly configured for freeipa but I needed to make a backup machine which would remain live. > > I created a clone of the machine and changed the host name and the settings in /etc/hosts. When I tried to run ipa-client-install it told me to run the uninstall which I did. This had the worrying effect of not being able to log into my original live server but thankfully after a while it came good. I don't know why. > > Back on the new server I ran 'ipa-client-install --enable-dns-updates -mkhomedir' and it seemed to run ok. The host was created on the freeipa GUI and I added it to the same host group as the original server. But when I try to log in via SSH I get the error 'No supported authentication methods available'. I do have root access via the AWS Key file. > > As far as I can tell all the relevant settings seem the same between the two servers but one works and the other doesn't. I can kinit and klist using my freeipa account. 'getent netgroup my-servergroup' works fine. > > I can't seem to find anything relevant in the sssd logs and > /var/log/secure just give me the same error of no supported > authentication methods available > > I have noticed in /var/log/messages when I restart sssd and error > which may be relevant but can't find anything useful so far > > sssd[be[my.domain.net]]: dereference processing failed : Input/output > error > > Thanks > > Terry > > > > The Manheim group of companies within the UK comprises: Manheim Europe Limited (registered number: 03183918), Manheim Auctions Limited (registered number: 00448761), Manheim Retail Services Limited (registered number: 02838588), Motors.co.uk Limited (registered number: 05975777), Real Time Communications Limited (registered number: 04277845) and Complete Automotive Solutions Limited (registered number: 05302535). Each of these companies is registered in England and Wales with the registered office address of Central House, Leeds Road, Rothwell, Leeds LS26 0JE. The Manheim group of companies operates under various brand/trading names including Manheim Inspection Services, Manheim Auctions, Manheim Direct, Manheim De-fleet and Manheim Aftersales Solutions. > > V:0CF72C13B2AC > > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Thu Feb 25 17:40:25 2016 From: simo at redhat.com (Simo Sorce) Date: Thu, 25 Feb 2016 12:40:25 -0500 Subject: [Freeipa-users] 14: No supported authentication methods available In-Reply-To: References: <1456412454.6599.282.camel@redhat.com> Message-ID: <1456422025.6599.315.camel@redhat.com> On Thu, 2016-02-25 at 16:56 +0000, Terry John wrote: > Thanks for that. From what I've read there is no simple right answer. In 2013 RedHat itself says to leave ChallengeResponseAuthentication set to no "due to security reasons". > > https://access.redhat.com/solutions/336773 We'll investigate to see if this is still a concern, given upstream has it defaulting to yes. The reason it should be preferred is that it will allow prompting for multiple factors, something we have in the works and would brek without this options set to true. Password changes (when the password is expiring PAM may ask to change it) also break badly if no ChallengResponseauthentication is used Simo. > Setting PasswordAuthentication yes seems to leave all the other settings within thee sshd_config file like "PermitRootLogin without-password" which may be overridden elsewhere if ChallengeResponseAuthentication is set to yes > > Terry > > -----Original Message----- > From: Simo Sorce [mailto:simo at redhat.com] > Sent: 25 February 2016 15:01 > To: Terry John > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] 14: No supported authentication methods available > > On Thu, 2016-02-25 at 14:36 +0000, Terry John wrote: > > This turned out to be a setting in /etc/ssh/sshd_config which gets > > > overridden by ipa-client-install. Needed to un-comment > > > > > > PasswordAuthentication yes > > > This is disabled because we enable ChallengeResponseAuthentication which is a superset of PasswordAuthentication. > > PasswordAuthentication can't deal with PAM prompts, it is a oneshot only option (ie fails if PAM asks you to make a pasword change), while ChallengeResponseAuthentication is the more modern method that properly deals with PAM prompts. > > You should prefer ChallengeResponseAuthentication over PasswordAuthentication. > > HTH, > Simo. > > > > Terry > > > > > > From: freeipa-users-bounces at redhat.com > > > [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Terry John > > > Sent: 18 February 2016 11:41 > > > To: freeipa-users at redhat.com > > > Subject: [Freeipa-users] 14: No supported authentication methods > > > available > > > > > > I have an AWS instance running Centos 6.7 correctly configured for freeipa but I needed to make a backup machine which would remain live. > > > > > > I created a clone of the machine and changed the host name and the settings in /etc/hosts. When I tried to run ipa-client-install it told me to run the uninstall which I did. This had the worrying effect of not being able to log into my original live server but thankfully after a while it came good. I don't know why. > > > > > > Back on the new server I ran 'ipa-client-install --enable-dns-updates -mkhomedir' and it seemed to run ok. The host was created on the freeipa GUI and I added it to the same host group as the original server. But when I try to log in via SSH I get the error 'No supported authentication methods available'. I do have root access via the AWS Key file. > > > > > > As far as I can tell all the relevant settings seem the same between the two servers but one works and the other doesn't. I can kinit and klist using my freeipa account. 'getent netgroup my-servergroup' works fine. > > > > > > I can't seem to find anything relevant in the sssd logs and > > > /var/log/secure just give me the same error of no supported > > > authentication methods available > > > > > > I have noticed in /var/log/messages when I restart sssd and error > > > which may be relevant but can't find anything useful so far > > > > > > sssd[be[my.domain.net]]: dereference processing failed : Input/output > > > error > > > > > > Thanks > > > > > > Terry > > > > > > > > > > > > The Manheim group of companies within the UK comprises: Manheim Europe Limited (registered number: 03183918), Manheim Auctions Limited (registered number: 00448761), Manheim Retail Services Limited (registered number: 02838588), Motors.co.uk Limited (registered number: 05975777), Real Time Communications Limited (registered number: 04277845) and Complete Automotive Solutions Limited (registered number: 05302535). Each of these companies is registered in England and Wales with the registered office address of Central House, Leeds Road, Rothwell, Leeds LS26 0JE. The Manheim group of companies operates under various brand/trading names including Manheim Inspection Services, Manheim Auctions, Manheim Direct, Manheim De-fleet and Manheim Aftersales Solutions. > > > > > > V:0CF72C13B2AC > > > > > > > > > -- > > > Manage your subscription for the Freeipa-users mailing list: > > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > Go to http://freeipa.org for more info on the project > > > > -- > Simo Sorce * Red Hat, Inc * New York > -- Simo Sorce * Red Hat, Inc * New York From Steven.Auerbach at flbog.edu Thu Feb 25 20:02:24 2016 From: Steven.Auerbach at flbog.edu (Auerbach, Steven) Date: Thu, 25 Feb 2016 20:02:24 +0000 Subject: [Freeipa-users] IPA Replicant Clean-up Needed? Message-ID: My IPA LDAP/CS Master logs errors regularly (every few minutes) that seem o be based upon an attempt to communicate with a replica that no longer exists. Feb 25 14:38:04 ipa01 named[2161]: LDAP query timed out. Try to adjust "timeout" parameter Feb 25 14:38:04 ipa01 named[2161]: LDAP query timed out. Try to adjust "timeout" parameter Feb 25 14:38:14 ipa01 named[2161]: LDAP query timed out. Try to adjust "timeout" parameter Feb 25 14:38:14 ipa01 named[2161]: LDAP query timed out. Try to adjust "timeout" parameter Feb 25 14:38:22 ipa01 ns-slapd: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Cannot contact any KDC for realm 'REALM.LOCAL') Feb 25 14:38:35 ipa01 named[2161]: LDAP query timed out. Try to adjust "timeout" parameter Feb 25 14:38:35 ipa01 named[2161]: LDAP query timed out. Try to adjust "timeout" parameter Feb 25 14:38:45 ipa01 named[2161]: LDAP query timed out. Try to adjust "timeout" parameter Feb 25 14:38:45 ipa01 named[2161]: LDAP query timed out. Try to adjust "timeout" parameter Feb 25 14:38:45 ipa01 ns-slapd: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Server ldap/ipa02.realm.local at REALM.LOCAL not found in Kerberos database) The only place I found any references to the server ipa02 is in dse.ldif files in the /etc/dirsrv/slapd-REALM-LOCAL/ folders Quote from dse.ldif: dn: cn=replica,cn=dc\3Drealm\2Cdc\3Dlocal,cn=mapping tree,cn=config cn: replica nsDS5Flags: 1 objectClass: top objectClass: nsds5replica objectClass: extensibleobject nsDS5ReplicaType: 3 nsDS5ReplicaRoot: dc=realm,dc=local nsds5ReplicaLegacyConsumer: off nsDS5ReplicaId: 4 nsDS5ReplicaBindDN: cn=replication manager,cn=config nsDS5ReplicaBindDN: krbprincipalname=ldap/ipa02.realm.local at REALM.LOCAL,cn=servi ces,cn=accounts,dc=fbog,dc=local nsDS5ReplicaBindDN: krbprincipalname=ldap/ipa-r02.realm.local at REALM.LOCAL,cn=ser vices,cn=accounts,dc=realm,dc=local creatorsName: cn=directory manager modifiersName: cn=Multimaster Replication Plugin,cn=plugins,cn=config createTimestamp: 20130924144354Z modifyTimestamp: 20160225194116Z nsState:: BAAAAAAAAADcWM9WAAAAAAEAAAAAAAAAZQAAAAAAAAADAAAAAAAAAA== nsDS5ReplicaName: a5641a0e-252711e3-96afcc83-6ff9b802 numSubordinates: 1 When I execute "ipa-replica-manage list" from either the master or replica server I get the same response: ipa01.realm.local: master ipa-r02.realm.local: master and when I execute "ipa-csreplica-manage list" from either the master or the replica server I get the same response: ipa01.fbog.local: master ipa-r02.fbog.local: CA not configured I know we are configured in "multi-master" mode and that the CA is only on the master. I would have expected one of these commands to include the "ipa02" server as well since it is in the dse.ldif file. >From an operating perspective, identity management operations (including signing on to the browser-based interface and updates made one server showing up on the other) from the replica (ipa-r02) are much faster than from the master (ipa01). I am intuiting that this is because any task executing on the replica has only a replica pointer to the master, whereas any operation on the master that tries to replicate has to timeout on the invalid pointer to "ipa02" before it can actually communicate with the replica (ipa-r02). Of course my intuition could be completely wrong and my actual understanding of how this process works is nil. I would like to clean up this environment, however, before I hand the reins over to the next person on my team. So my question is: What is the best way to remove the invalid pointer without having to disrupt services on the master? Steven Auerbach Systems Administrator State University System of Florida Board of Governors 325 West Gaines Street, Suite 1625C Tallahassee, Florida 32399 (850) 245-9592 steven.auerbach at flbog.edu | www.flbog.edu [BOG-wordmark-wideFOR EMAIL-color] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 4101 bytes Desc: image002.jpg URL: From thbeh at thbeh.com Fri Feb 26 01:22:15 2016 From: thbeh at thbeh.com (Teik Hooi Beh) Date: Fri, 26 Feb 2016 14:22:15 +1300 Subject: [Freeipa-users] Not able to get kerberos ticket from keytab Message-ID: Hi, I have manged to deployed 1 ipa master and 1 ipa client with success on centos 7.2 with freeipa v4.2. I also managed to create user and set sshd-rules to for ttester user and also successfully get krb ticket using *kinit ttester at EXAMPLE.MY*. I am trying to deploy password-less SSH login with kerberos using the following guide ( https://uz.sns.it/~enrico/wordpress/2014/03/password-less-ssh-login-with-kerberos/) - snippet - *$ ktutil ktutil: add_entry -password -p ttester at EXAMPLE.MY -k 1 -e aes256-cts-hmac-sha1-96 ktutil: write_kt keytab* When I tried *kinit -kt keytab ttester at EXAMPLE.MY*, I get *"**kinit: Password incorrect while getting initial credentials"* Doing a trace using KRB5_TRACE on both calls *1. KRB5_TRACE=/dev/stderr kinit ttester at EXAMPLE.MY* 27242] 1456447025.219676: Getting initial credentials for ttester at EXAMPLE.MY [27242] 1456447025.222070: Sending request (164 bytes) to EXAMPLE.MY [27242] 1456447025.222223: Resolving hostname node1.example.my [27242] 1456447035.238004: Initiating TCP connection to stream 192.168.38.2:88 [27242] 1456447035.238675: Sending TCP request to stream 192.168.38.2:88 [27242] 1456447035.241248: Received answer (337 bytes) from stream 192.168.38.2:88 [27242] 1456447035.241257: Terminating TCP connection to stream 192.168.38.2:88 [27242] 1456447035.241377: Response was from master KDC [27242] 1456447035.241437: Received error from KDC: -1765328359/Additional pre-authentication required [27242] 1456447035.241484: Processing preauth types: 136, 19, 2, 133 [27242] 1456447035.241499: Selected etype info: etype aes256-cts, salt "s`GD^,#=cA:Vr9hD", params "" [27242] 1456447035.241504: Received cookie: MIT Password for ttester at EXAMPLE.MY: [27242] 1456447062.215750: AS key obtained for encrypted timestamp: aes256-cts/73C6 [27242] 1456447062.215815: Encrypted timestamp (for 1456447062.215315): plain 301AA011180F32303136303232363030333734325AA1050203034913, encrypted F9A2E97E916FC14D141690E151A25DCC00168361179C7F0ACDA94C7F58F3D50429780A5608A6B8623E355F2A5BD676F6FA5272D38FD05C8B [27242] 1456447062.215942: Preauth module encrypted_timestamp (2) (real) returned: 0/Success [27242] 1456447062.215948: Produced preauth for next request: 133, 2 [27242] 1456447062.215965: Sending request (257 bytes) to EXAMPLE.MY [27242] 1456447062.216010: Resolving hostname node1.example.my [27242] 1456447072.229254: Initiating TCP connection to stream 192.168.38.2:88 [27242] 1456447072.229655: Sending TCP request to stream 192.168.38.2:88 [27242] 1456447072.236955: Received answer (722 bytes) from stream 192.168.38.2:88 [27242] 1456447072.236974: Terminating TCP connection to stream 192.168.38.2:88 [27242] 1456447072.237080: Response was from master KDC [27242] 1456447072.237117: Processing preauth types: 19 [27242] 1456447072.237125: Selected etype info: etype aes256-cts, salt "s`GD^,#=cA:Vr9hD", params "" [27242] 1456447072.237131: Produced preauth for next request: (empty) [27242] 1456447072.237140: AS key determined by preauth: aes256-cts/73C6 [27242] 1456447072.237199: Decrypted AS reply; session key is: aes256-cts/2A71 [27242] 1456447072.237216: FAST negotiation: available [27242] 1456447072.237236: Initializing KEYRING:persistent:1000:1000 with default princ ttester at EXAMPLE.MY [27242] 1456447072.237275: Storing ttester at EXAMPLE.MY -> krbtgt/EXAMPLE.MY at EXAMPLE.MY in KEYRING:persistent:1000:1000 [27242] 1456447072.237330: Storing config in KEYRING:persistent:1000:1000 for krbtgt/EXAMPLE.MY at EXAMPLE.MY: fast_avail: yes [27242] 1456447072.237345: Storing ttester at EXAMPLE.MY -> krb5_ccache_conf_data/fast_avail/krbtgt\/EXAMPLE.MY\@EXAMPLE.MY at X-CACHECONF: in KEYRING:persistent:1000:1000 [27242] 1456447072.237371: Storing config in KEYRING:persistent:1000:1000 for krbtgt/EXAMPLE.MY at EXAMPLE.MY: pa_type: 2 [27242] 1456447072.237380: Storing ttester at EXAMPLE.MY -> krb5_ccache_conf_data/pa_type/krbtgt\/EXAMPLE.MY\@EXAMPLE.MY at X-CACHECONF: in KEYRING:persistent:1000:1000 *2. KRB5_TRACE=/dev/stderr kinit -kt keytab ttester at EXAMPLE.MY* [27248] 1456447236.144685: Getting initial credentials for ttester at EXAMPLE.MY [27248] 1456447236.147107: Looked up etypes in keytab: aes256-cts [27248] 1456447236.147255: Sending request (164 bytes) to EXAMPLE.MY [27248] 1456447236.147381: Resolving hostname node1.example.my [27248] 1456447246.161528: Initiating TCP connection to stream 192.168.38.2:88 [27248] 1456447246.161970: Sending TCP request to stream 192.168.38.2:88 [27248] 1456447246.164772: Received answer (337 bytes) from stream 192.168.38.2:88 [27248] 1456447246.164791: Terminating TCP connection to stream 192.168.38.2:88 [27248] 1456447246.164904: Response was from master KDC [27248] 1456447246.164943: Received error from KDC: -1765328359/Additional pre-authentication required [27248] 1456447246.164987: Processing preauth types: 136, 19, 2, 133 [27248] 1456447246.164997: Selected etype info: etype aes256-cts, salt "s`GD^,#=cA:Vr9hD", params "" [27248] 1456447246.165001: Received cookie: MIT [27248] 1456447246.165142: Retrieving ttester at EXAMPLE.MY from FILE:keytab (vno 0, enctype aes256-cts) with result: 0/Success [27248] 1456447246.165166: AS key obtained for encrypted timestamp: aes256-cts/0A17 [27248] 1456447246.165210: Encrypted timestamp (for 1456447246.164647): plain 301AA011180F32303136303232363030343034365AA1050203028327, encrypted C092E6C29FC1CD794625CF12162D18767A68D1728E6C2ADC1F50492D6605E039B664213C29767715E04B3CA8D97EBD691BBF40B76370C9FA [27248] 1456447246.165224: Preauth module encrypted_timestamp (2) (real) returned: 0/Success [27248] 1456447246.165228: Produced preauth for next request: 133, 2 [27248] 1456447246.165239: Sending request (257 bytes) to EXAMPLE.MY [27248] 1456447246.165253: Resolving hostname node1.example.my [27248] 1456447256.178637: Initiating TCP connection to stream 192.168.38.2:88 [27248] 1456447256.179456: Sending TCP request to stream 192.168.38.2:88 [27248] 1456447256.184929: Received answer (167 bytes) from stream 192.168.38.2:88 [27248] 1456447256.184941: Terminating TCP connection to stream 192.168.38.2:88 [27248] 1456447256.185043: Response was from master KDC [27248] 1456447256.185065: Received error from KDC: -1765328353/Decrypt integrity check failed kinit: Password incorrect while getting initial credentials >From the 2 trace I notice the return bytes on return from calling using keytab is only 167 bytes compare to 722 bytes. Does anybody know the reasons or could point me to where I could debug further? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkupka at redhat.com Fri Feb 26 07:56:07 2016 From: dkupka at redhat.com (David Kupka) Date: Fri, 26 Feb 2016 08:56:07 +0100 Subject: [Freeipa-users] Not able to get kerberos ticket from keytab In-Reply-To: References: Message-ID: <56D00517.4070406@redhat.com> On 26/02/16 02:22, Teik Hooi Beh wrote: > Hi, > > I have manged to deployed 1 ipa master and 1 ipa client with success on > centos 7.2 with freeipa v4.2. I also managed to create user and set > sshd-rules to for ttester user and also successfully get krb ticket > using *kinit > ttester at EXAMPLE.MY*. I am trying to deploy password-less SSH login with > kerberos using the following guide ( > https://uz.sns.it/~enrico/wordpress/2014/03/password-less-ssh-login-with-kerberos/) > - > > snippet - > > > > *$ ktutil ktutil: add_entry -password -p ttester at EXAMPLE.MY -k 1 -e > aes256-cts-hmac-sha1-96 ktutil: write_kt keytab* > > When I tried *kinit -kt keytab ttester at EXAMPLE.MY*, I get *"**kinit: > Password incorrect while getting initial credentials"* > Doing a trace using KRB5_TRACE on both calls > > *1. KRB5_TRACE=/dev/stderr kinit ttester at EXAMPLE.MY* > 27242] 1456447025.219676: Getting initial credentials for ttester at EXAMPLE.MY > [27242] 1456447025.222070: Sending request (164 bytes) to EXAMPLE.MY > [27242] 1456447025.222223: Resolving hostname node1.example.my > [27242] 1456447035.238004: Initiating TCP connection to stream > 192.168.38.2:88 > [27242] 1456447035.238675: Sending TCP request to stream 192.168.38.2:88 > [27242] 1456447035.241248: Received answer (337 bytes) from stream > 192.168.38.2:88 > [27242] 1456447035.241257: Terminating TCP connection to stream > 192.168.38.2:88 > [27242] 1456447035.241377: Response was from master KDC > [27242] 1456447035.241437: Received error from KDC: -1765328359/Additional > pre-authentication required > [27242] 1456447035.241484: Processing preauth types: 136, 19, 2, 133 > [27242] 1456447035.241499: Selected etype info: etype aes256-cts, salt > "s`GD^,#=cA:Vr9hD", params "" > [27242] 1456447035.241504: Received cookie: MIT > Password for ttester at EXAMPLE.MY: > [27242] 1456447062.215750: AS key obtained for encrypted timestamp: > aes256-cts/73C6 > [27242] 1456447062.215815: Encrypted timestamp (for 1456447062.215315): > plain 301AA011180F32303136303232363030333734325AA1050203034913, encrypted > F9A2E97E916FC14D141690E151A25DCC00168361179C7F0ACDA94C7F58F3D50429780A5608A6B8623E355F2A5BD676F6FA5272D38FD05C8B > [27242] 1456447062.215942: Preauth module encrypted_timestamp (2) (real) > returned: 0/Success > [27242] 1456447062.215948: Produced preauth for next request: 133, 2 > [27242] 1456447062.215965: Sending request (257 bytes) to EXAMPLE.MY > [27242] 1456447062.216010: Resolving hostname node1.example.my > [27242] 1456447072.229254: Initiating TCP connection to stream > 192.168.38.2:88 > [27242] 1456447072.229655: Sending TCP request to stream 192.168.38.2:88 > [27242] 1456447072.236955: Received answer (722 bytes) from stream > 192.168.38.2:88 > [27242] 1456447072.236974: Terminating TCP connection to stream > 192.168.38.2:88 > [27242] 1456447072.237080: Response was from master KDC > [27242] 1456447072.237117: Processing preauth types: 19 > [27242] 1456447072.237125: Selected etype info: etype aes256-cts, salt > "s`GD^,#=cA:Vr9hD", params "" > [27242] 1456447072.237131: Produced preauth for next request: (empty) > [27242] 1456447072.237140: AS key determined by preauth: aes256-cts/73C6 > [27242] 1456447072.237199: Decrypted AS reply; session key is: > aes256-cts/2A71 > [27242] 1456447072.237216: FAST negotiation: available > [27242] 1456447072.237236: Initializing KEYRING:persistent:1000:1000 with > default princ ttester at EXAMPLE.MY > [27242] 1456447072.237275: Storing ttester at EXAMPLE.MY -> > krbtgt/EXAMPLE.MY at EXAMPLE.MY in KEYRING:persistent:1000:1000 > [27242] 1456447072.237330: Storing config in KEYRING:persistent:1000:1000 > for krbtgt/EXAMPLE.MY at EXAMPLE.MY: fast_avail: yes > [27242] 1456447072.237345: Storing ttester at EXAMPLE.MY -> > krb5_ccache_conf_data/fast_avail/krbtgt\/EXAMPLE.MY\@EXAMPLE.MY at X-CACHECONF: > in KEYRING:persistent:1000:1000 > [27242] 1456447072.237371: Storing config in KEYRING:persistent:1000:1000 > for krbtgt/EXAMPLE.MY at EXAMPLE.MY: pa_type: 2 > [27242] 1456447072.237380: Storing ttester at EXAMPLE.MY -> > krb5_ccache_conf_data/pa_type/krbtgt\/EXAMPLE.MY\@EXAMPLE.MY at X-CACHECONF: > in KEYRING:persistent:1000:1000 > > *2. KRB5_TRACE=/dev/stderr kinit -kt keytab ttester at EXAMPLE.MY* > [27248] 1456447236.144685: Getting initial credentials for > ttester at EXAMPLE.MY > [27248] 1456447236.147107: Looked up etypes in keytab: aes256-cts > [27248] 1456447236.147255: Sending request (164 bytes) to EXAMPLE.MY > [27248] 1456447236.147381: Resolving hostname node1.example.my > [27248] 1456447246.161528: Initiating TCP connection to stream > 192.168.38.2:88 > [27248] 1456447246.161970: Sending TCP request to stream 192.168.38.2:88 > [27248] 1456447246.164772: Received answer (337 bytes) from stream > 192.168.38.2:88 > [27248] 1456447246.164791: Terminating TCP connection to stream > 192.168.38.2:88 > [27248] 1456447246.164904: Response was from master KDC > [27248] 1456447246.164943: Received error from KDC: -1765328359/Additional > pre-authentication required > [27248] 1456447246.164987: Processing preauth types: 136, 19, 2, 133 > [27248] 1456447246.164997: Selected etype info: etype aes256-cts, salt > "s`GD^,#=cA:Vr9hD", params "" > [27248] 1456447246.165001: Received cookie: MIT > [27248] 1456447246.165142: Retrieving ttester at EXAMPLE.MY from FILE:keytab > (vno 0, enctype aes256-cts) with result: 0/Success > [27248] 1456447246.165166: AS key obtained for encrypted timestamp: > aes256-cts/0A17 > [27248] 1456447246.165210: Encrypted timestamp (for 1456447246.164647): > plain 301AA011180F32303136303232363030343034365AA1050203028327, encrypted > C092E6C29FC1CD794625CF12162D18767A68D1728E6C2ADC1F50492D6605E039B664213C29767715E04B3CA8D97EBD691BBF40B76370C9FA > [27248] 1456447246.165224: Preauth module encrypted_timestamp (2) (real) > returned: 0/Success > [27248] 1456447246.165228: Produced preauth for next request: 133, 2 > [27248] 1456447246.165239: Sending request (257 bytes) to EXAMPLE.MY > [27248] 1456447246.165253: Resolving hostname node1.example.my > [27248] 1456447256.178637: Initiating TCP connection to stream > 192.168.38.2:88 > [27248] 1456447256.179456: Sending TCP request to stream 192.168.38.2:88 > [27248] 1456447256.184929: Received answer (167 bytes) from stream > 192.168.38.2:88 > [27248] 1456447256.184941: Terminating TCP connection to stream > 192.168.38.2:88 > [27248] 1456447256.185043: Response was from master KDC > [27248] 1456447256.185065: Received error from KDC: -1765328353/Decrypt > integrity check failed > kinit: Password incorrect while getting initial credentials > >>From the 2 trace I notice the return bytes on return from calling using > keytab is only 167 bytes compare to 722 bytes. Does anybody know the > reasons or could point me to where I could debug further? > > Thanks > > > Hello! I don't know why it does not work with ktutil but I've find other way how to get keytab for a user: $ kinit ttester $ ipa-getkeytab -p ttester at EXAMPLE.TEST -k ttester.keytab -e aes256-cts-hmac-sha1-96 $ kdestroy ttester $ kinit ttester at EXAMPLE.TEST -kt ttester.keytab HTH, -- David Kupka From dkupka at redhat.com Fri Feb 26 08:15:17 2016 From: dkupka at redhat.com (David Kupka) Date: Fri, 26 Feb 2016 09:15:17 +0100 Subject: [Freeipa-users] Not able to get kerberos ticket from keytab In-Reply-To: <56D00517.4070406@redhat.com> References: <56D00517.4070406@redhat.com> Message-ID: <56D00995.1030201@redhat.com> On 26/02/16 08:56, David Kupka wrote: > On 26/02/16 02:22, Teik Hooi Beh wrote: >> Hi, >> >> I have manged to deployed 1 ipa master and 1 ipa client with success on >> centos 7.2 with freeipa v4.2. I also managed to create user and set >> sshd-rules to for ttester user and also successfully get krb ticket >> using *kinit >> ttester at EXAMPLE.MY*. I am trying to deploy password-less SSH login with >> kerberos using the following guide ( >> https://uz.sns.it/~enrico/wordpress/2014/03/password-less-ssh-login-with-kerberos/) >> >> - >> >> snippet - >> >> >> >> *$ ktutil ktutil: add_entry -password -p ttester at EXAMPLE.MY -k 1 -e >> aes256-cts-hmac-sha1-96 ktutil: write_kt keytab* >> >> When I tried *kinit -kt keytab ttester at EXAMPLE.MY*, I get *"**kinit: >> Password incorrect while getting initial credentials"* >> Doing a trace using KRB5_TRACE on both calls >> >> *1. KRB5_TRACE=/dev/stderr kinit ttester at EXAMPLE.MY* >> 27242] 1456447025.219676: Getting initial credentials for >> ttester at EXAMPLE.MY >> [27242] 1456447025.222070: Sending request (164 bytes) to EXAMPLE.MY >> [27242] 1456447025.222223: Resolving hostname node1.example.my >> [27242] 1456447035.238004: Initiating TCP connection to stream >> 192.168.38.2:88 >> [27242] 1456447035.238675: Sending TCP request to stream 192.168.38.2:88 >> [27242] 1456447035.241248: Received answer (337 bytes) from stream >> 192.168.38.2:88 >> [27242] 1456447035.241257: Terminating TCP connection to stream >> 192.168.38.2:88 >> [27242] 1456447035.241377: Response was from master KDC >> [27242] 1456447035.241437: Received error from KDC: >> -1765328359/Additional >> pre-authentication required >> [27242] 1456447035.241484: Processing preauth types: 136, 19, 2, 133 >> [27242] 1456447035.241499: Selected etype info: etype aes256-cts, salt >> "s`GD^,#=cA:Vr9hD", params "" >> [27242] 1456447035.241504: Received cookie: MIT >> Password for ttester at EXAMPLE.MY: >> [27242] 1456447062.215750: AS key obtained for encrypted timestamp: >> aes256-cts/73C6 >> [27242] 1456447062.215815: Encrypted timestamp (for 1456447062.215315): >> plain 301AA011180F32303136303232363030333734325AA1050203034913, encrypted >> F9A2E97E916FC14D141690E151A25DCC00168361179C7F0ACDA94C7F58F3D50429780A5608A6B8623E355F2A5BD676F6FA5272D38FD05C8B >> >> [27242] 1456447062.215942: Preauth module encrypted_timestamp (2) (real) >> returned: 0/Success >> [27242] 1456447062.215948: Produced preauth for next request: 133, 2 >> [27242] 1456447062.215965: Sending request (257 bytes) to EXAMPLE.MY >> [27242] 1456447062.216010: Resolving hostname node1.example.my >> [27242] 1456447072.229254: Initiating TCP connection to stream >> 192.168.38.2:88 >> [27242] 1456447072.229655: Sending TCP request to stream 192.168.38.2:88 >> [27242] 1456447072.236955: Received answer (722 bytes) from stream >> 192.168.38.2:88 >> [27242] 1456447072.236974: Terminating TCP connection to stream >> 192.168.38.2:88 >> [27242] 1456447072.237080: Response was from master KDC >> [27242] 1456447072.237117: Processing preauth types: 19 >> [27242] 1456447072.237125: Selected etype info: etype aes256-cts, salt >> "s`GD^,#=cA:Vr9hD", params "" >> [27242] 1456447072.237131: Produced preauth for next request: (empty) >> [27242] 1456447072.237140: AS key determined by preauth: aes256-cts/73C6 >> [27242] 1456447072.237199: Decrypted AS reply; session key is: >> aes256-cts/2A71 >> [27242] 1456447072.237216: FAST negotiation: available >> [27242] 1456447072.237236: Initializing KEYRING:persistent:1000:1000 with >> default princ ttester at EXAMPLE.MY >> [27242] 1456447072.237275: Storing ttester at EXAMPLE.MY -> >> krbtgt/EXAMPLE.MY at EXAMPLE.MY in KEYRING:persistent:1000:1000 >> [27242] 1456447072.237330: Storing config in KEYRING:persistent:1000:1000 >> for krbtgt/EXAMPLE.MY at EXAMPLE.MY: fast_avail: yes >> [27242] 1456447072.237345: Storing ttester at EXAMPLE.MY -> >> krb5_ccache_conf_data/fast_avail/krbtgt\/EXAMPLE.MY\@EXAMPLE.MY at X-CACHECONF: >> >> in KEYRING:persistent:1000:1000 >> [27242] 1456447072.237371: Storing config in KEYRING:persistent:1000:1000 >> for krbtgt/EXAMPLE.MY at EXAMPLE.MY: pa_type: 2 >> [27242] 1456447072.237380: Storing ttester at EXAMPLE.MY -> >> krb5_ccache_conf_data/pa_type/krbtgt\/EXAMPLE.MY\@EXAMPLE.MY at X-CACHECONF: >> in KEYRING:persistent:1000:1000 >> >> *2. KRB5_TRACE=/dev/stderr kinit -kt keytab ttester at EXAMPLE.MY* >> [27248] 1456447236.144685: Getting initial credentials for >> ttester at EXAMPLE.MY >> [27248] 1456447236.147107: Looked up etypes in keytab: aes256-cts >> [27248] 1456447236.147255: Sending request (164 bytes) to EXAMPLE.MY >> [27248] 1456447236.147381: Resolving hostname node1.example.my >> [27248] 1456447246.161528: Initiating TCP connection to stream >> 192.168.38.2:88 >> [27248] 1456447246.161970: Sending TCP request to stream 192.168.38.2:88 >> [27248] 1456447246.164772: Received answer (337 bytes) from stream >> 192.168.38.2:88 >> [27248] 1456447246.164791: Terminating TCP connection to stream >> 192.168.38.2:88 >> [27248] 1456447246.164904: Response was from master KDC >> [27248] 1456447246.164943: Received error from KDC: >> -1765328359/Additional >> pre-authentication required >> [27248] 1456447246.164987: Processing preauth types: 136, 19, 2, 133 >> [27248] 1456447246.164997: Selected etype info: etype aes256-cts, salt >> "s`GD^,#=cA:Vr9hD", params "" >> [27248] 1456447246.165001: Received cookie: MIT >> [27248] 1456447246.165142: Retrieving ttester at EXAMPLE.MY from FILE:keytab >> (vno 0, enctype aes256-cts) with result: 0/Success >> [27248] 1456447246.165166: AS key obtained for encrypted timestamp: >> aes256-cts/0A17 >> [27248] 1456447246.165210: Encrypted timestamp (for 1456447246.164647): >> plain 301AA011180F32303136303232363030343034365AA1050203028327, encrypted >> C092E6C29FC1CD794625CF12162D18767A68D1728E6C2ADC1F50492D6605E039B664213C29767715E04B3CA8D97EBD691BBF40B76370C9FA >> >> [27248] 1456447246.165224: Preauth module encrypted_timestamp (2) (real) >> returned: 0/Success >> [27248] 1456447246.165228: Produced preauth for next request: 133, 2 >> [27248] 1456447246.165239: Sending request (257 bytes) to EXAMPLE.MY >> [27248] 1456447246.165253: Resolving hostname node1.example.my >> [27248] 1456447256.178637: Initiating TCP connection to stream >> 192.168.38.2:88 >> [27248] 1456447256.179456: Sending TCP request to stream 192.168.38.2:88 >> [27248] 1456447256.184929: Received answer (167 bytes) from stream >> 192.168.38.2:88 >> [27248] 1456447256.184941: Terminating TCP connection to stream >> 192.168.38.2:88 >> [27248] 1456447256.185043: Response was from master KDC >> [27248] 1456447256.185065: Received error from KDC: -1765328353/Decrypt >> integrity check failed >> kinit: Password incorrect while getting initial credentials >> >>> From the 2 trace I notice the return bytes on return from calling using >> keytab is only 167 bytes compare to 722 bytes. Does anybody know the >> reasons or could point me to where I could debug further? >> >> Thanks >> >> >> > > Hello! > > I don't know why it does not work with ktutil but I've find other way > how to get keytab for a user: > > $ kinit ttester > $ ipa-getkeytab -p ttester at EXAMPLE.TEST -k ttester.keytab -e > aes256-cts-hmac-sha1-96 > $ kdestroy ttester > $ kinit ttester at EXAMPLE.TEST -kt ttester.keytab > > HTH, > Oh, I forget to mention that this also sets random krbPrincipalKey for the user so you can kinit only with the keytab. ipa-getkeytab has also option -r (--retrive) that should not change krbPrincipalKey but for some reason user is not allowed to retrieve it. You can of course add ACI to allow that but I would not do it because there's probably good reason why it's forbidden by default. -- David Kupka From thbeh at thbeh.com Fri Feb 26 09:29:44 2016 From: thbeh at thbeh.com (Teik Hooi Beh) Date: Fri, 26 Feb 2016 22:29:44 +1300 Subject: [Freeipa-users] Not able to get kerberos ticket from keytab In-Reply-To: <56D00995.1030201@redhat.com> References: <56D00517.4070406@redhat.com> <56D00995.1030201@redhat.com> Message-ID: Thanks. It's working now using ipa-getkeytab. Correct me if I am wrong (as I am new to freeipa), using ktutil I could add multiple user in a keytab file (correct???) but in this case using ipa-getkeytab can I do the same? On Fri, Feb 26, 2016 at 9:15 PM, David Kupka wrote: > On 26/02/16 08:56, David Kupka wrote: > >> On 26/02/16 02:22, Teik Hooi Beh wrote: >> >>> Hi, >>> >>> I have manged to deployed 1 ipa master and 1 ipa client with success on >>> centos 7.2 with freeipa v4.2. I also managed to create user and set >>> sshd-rules to for ttester user and also successfully get krb ticket >>> using *kinit >>> ttester at EXAMPLE.MY*. I am trying to deploy password-less SSH login with >>> kerberos using the following guide ( >>> >>> https://uz.sns.it/~enrico/wordpress/2014/03/password-less-ssh-login-with-kerberos/ >>> ) >>> >>> - >>> >>> snippet - >>> >>> >>> >>> *$ ktutil ktutil: add_entry -password -p ttester at EXAMPLE.MY -k 1 -e >>> aes256-cts-hmac-sha1-96 ktutil: write_kt keytab* >>> >>> When I tried *kinit -kt keytab ttester at EXAMPLE.MY*, I get *"**kinit: >>> Password incorrect while getting initial credentials"* >>> Doing a trace using KRB5_TRACE on both calls >>> >>> *1. KRB5_TRACE=/dev/stderr kinit ttester at EXAMPLE.MY* >>> 27242] 1456447025.219676: Getting initial credentials for >>> ttester at EXAMPLE.MY >>> [27242] 1456447025.222070: Sending request (164 bytes) to EXAMPLE.MY >>> [27242] 1456447025.222223: Resolving hostname node1.example.my >>> [27242] 1456447035.238004: Initiating TCP connection to stream >>> 192.168.38.2:88 >>> [27242] 1456447035.238675: Sending TCP request to stream 192.168.38.2:88 >>> [27242] 1456447035.241248: Received answer (337 bytes) from stream >>> 192.168.38.2:88 >>> [27242] 1456447035.241257: Terminating TCP connection to stream >>> 192.168.38.2:88 >>> [27242] 1456447035.241377: Response was from master KDC >>> [27242] 1456447035.241437: Received error from KDC: >>> -1765328359/Additional >>> pre-authentication required >>> [27242] 1456447035.241484: Processing preauth types: 136, 19, 2, 133 >>> [27242] 1456447035.241499: Selected etype info: etype aes256-cts, salt >>> "s`GD^,#=cA:Vr9hD", params "" >>> [27242] 1456447035.241504: Received cookie: MIT >>> Password for ttester at EXAMPLE.MY: >>> [27242] 1456447062.215750: AS key obtained for encrypted timestamp: >>> aes256-cts/73C6 >>> [27242] 1456447062.215815: Encrypted timestamp (for 1456447062.215315): >>> plain 301AA011180F32303136303232363030333734325AA1050203034913, encrypted >>> >>> F9A2E97E916FC14D141690E151A25DCC00168361179C7F0ACDA94C7F58F3D50429780A5608A6B8623E355F2A5BD676F6FA5272D38FD05C8B >>> >>> [27242] 1456447062.215942: Preauth module encrypted_timestamp (2) (real) >>> returned: 0/Success >>> [27242] 1456447062.215948: Produced preauth for next request: 133, 2 >>> [27242] 1456447062.215965: Sending request (257 bytes) to EXAMPLE.MY >>> [27242] 1456447062.216010: Resolving hostname node1.example.my >>> [27242] 1456447072.229254: Initiating TCP connection to stream >>> 192.168.38.2:88 >>> [27242] 1456447072.229655: Sending TCP request to stream 192.168.38.2:88 >>> [27242] 1456447072.236955: Received answer (722 bytes) from stream >>> 192.168.38.2:88 >>> [27242] 1456447072.236974: Terminating TCP connection to stream >>> 192.168.38.2:88 >>> [27242] 1456447072.237080: Response was from master KDC >>> [27242] 1456447072.237117: Processing preauth types: 19 >>> [27242] 1456447072.237125: Selected etype info: etype aes256-cts, salt >>> "s`GD^,#=cA:Vr9hD", params "" >>> [27242] 1456447072.237131: Produced preauth for next request: (empty) >>> [27242] 1456447072.237140: AS key determined by preauth: aes256-cts/73C6 >>> [27242] 1456447072.237199: Decrypted AS reply; session key is: >>> aes256-cts/2A71 >>> [27242] 1456447072.237216: FAST negotiation: available >>> [27242] 1456447072.237236: Initializing KEYRING:persistent:1000:1000 with >>> default princ ttester at EXAMPLE.MY >>> [27242] 1456447072.237275: Storing ttester at EXAMPLE.MY -> >>> krbtgt/EXAMPLE.MY at EXAMPLE.MY in KEYRING:persistent:1000:1000 >>> [27242] 1456447072.237330: Storing config in KEYRING:persistent:1000:1000 >>> for krbtgt/EXAMPLE.MY at EXAMPLE.MY: fast_avail: yes >>> [27242] 1456447072.237345: Storing ttester at EXAMPLE.MY -> >>> >>> krb5_ccache_conf_data/fast_avail/krbtgt\/EXAMPLE.MY\@EXAMPLE.MY at X-CACHECONF >>> : >>> >>> in KEYRING:persistent:1000:1000 >>> [27242] 1456447072.237371: Storing config in KEYRING:persistent:1000:1000 >>> for krbtgt/EXAMPLE.MY at EXAMPLE.MY: pa_type: 2 >>> [27242] 1456447072.237380: Storing ttester at EXAMPLE.MY -> >>> krb5_ccache_conf_data/pa_type/krbtgt\/EXAMPLE.MY\@EXAMPLE.MY at X-CACHECONF >>> : >>> in KEYRING:persistent:1000:1000 >>> >>> *2. KRB5_TRACE=/dev/stderr kinit -kt keytab ttester at EXAMPLE.MY* >>> [27248] 1456447236.144685: Getting initial credentials for >>> ttester at EXAMPLE.MY >>> [27248] 1456447236.147107: Looked up etypes in keytab: aes256-cts >>> [27248] 1456447236.147255: Sending request (164 bytes) to EXAMPLE.MY >>> [27248] 1456447236.147381: Resolving hostname node1.example.my >>> [27248] 1456447246.161528: Initiating TCP connection to stream >>> 192.168.38.2:88 >>> [27248] 1456447246.161970: Sending TCP request to stream 192.168.38.2:88 >>> [27248] 1456447246.164772: Received answer (337 bytes) from stream >>> 192.168.38.2:88 >>> [27248] 1456447246.164791: Terminating TCP connection to stream >>> 192.168.38.2:88 >>> [27248] 1456447246.164904: Response was from master KDC >>> [27248] 1456447246.164943: Received error from KDC: >>> -1765328359/Additional >>> pre-authentication required >>> [27248] 1456447246.164987: Processing preauth types: 136, 19, 2, 133 >>> [27248] 1456447246.164997: Selected etype info: etype aes256-cts, salt >>> "s`GD^,#=cA:Vr9hD", params "" >>> [27248] 1456447246.165001: Received cookie: MIT >>> [27248] 1456447246.165142: Retrieving ttester at EXAMPLE.MY from >>> FILE:keytab >>> (vno 0, enctype aes256-cts) with result: 0/Success >>> [27248] 1456447246.165166: AS key obtained for encrypted timestamp: >>> aes256-cts/0A17 >>> [27248] 1456447246.165210: Encrypted timestamp (for 1456447246.164647): >>> plain 301AA011180F32303136303232363030343034365AA1050203028327, encrypted >>> >>> C092E6C29FC1CD794625CF12162D18767A68D1728E6C2ADC1F50492D6605E039B664213C29767715E04B3CA8D97EBD691BBF40B76370C9FA >>> >>> [27248] 1456447246.165224: Preauth module encrypted_timestamp (2) (real) >>> returned: 0/Success >>> [27248] 1456447246.165228: Produced preauth for next request: 133, 2 >>> [27248] 1456447246.165239: Sending request (257 bytes) to EXAMPLE.MY >>> [27248] 1456447246.165253: Resolving hostname node1.example.my >>> [27248] 1456447256.178637: Initiating TCP connection to stream >>> 192.168.38.2:88 >>> [27248] 1456447256.179456: Sending TCP request to stream 192.168.38.2:88 >>> [27248] 1456447256.184929: Received answer (167 bytes) from stream >>> 192.168.38.2:88 >>> [27248] 1456447256.184941: Terminating TCP connection to stream >>> 192.168.38.2:88 >>> [27248] 1456447256.185043: Response was from master KDC >>> [27248] 1456447256.185065: Received error from KDC: -1765328353/Decrypt >>> integrity check failed >>> kinit: Password incorrect while getting initial credentials >>> >>> From the 2 trace I notice the return bytes on return from calling using >>>> >>> keytab is only 167 bytes compare to 722 bytes. Does anybody know the >>> reasons or could point me to where I could debug further? >>> >>> Thanks >>> >>> >>> >>> >> Hello! >> >> I don't know why it does not work with ktutil but I've find other way >> how to get keytab for a user: >> >> $ kinit ttester >> $ ipa-getkeytab -p ttester at EXAMPLE.TEST -k ttester.keytab -e >> aes256-cts-hmac-sha1-96 >> $ kdestroy ttester >> $ kinit ttester at EXAMPLE.TEST -kt ttester.keytab >> >> HTH, >> >> > Oh, I forget to mention that this also sets random krbPrincipalKey for the > user so you can kinit only with the keytab. ipa-getkeytab has also option > -r (--retrive) that should not change krbPrincipalKey but for some reason > user is not allowed to retrieve it. > You can of course add ACI to allow that but I would not do it because > there's probably good reason why it's forbidden by default. > > -- > David Kupka > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thbeh at thbeh.com Fri Feb 26 09:31:22 2016 From: thbeh at thbeh.com (Teik Hooi Beh) Date: Fri, 26 Feb 2016 22:31:22 +1300 Subject: [Freeipa-users] Not able to get kerberos ticket from keytab In-Reply-To: References: <56D00517.4070406@redhat.com> <56D00995.1030201@redhat.com> Message-ID: And yes, i also need to include -s ipaserver in the get-ipakeytab command, otherwise it kept giving wrong usage error.... On Fri, Feb 26, 2016 at 10:29 PM, Teik Hooi Beh wrote: > Thanks. It's working now using ipa-getkeytab. > > Correct me if I am wrong (as I am new to freeipa), using ktutil I could > add multiple user in a keytab file (correct???) but in this case using > ipa-getkeytab can I do the same? > > On Fri, Feb 26, 2016 at 9:15 PM, David Kupka wrote: > >> On 26/02/16 08:56, David Kupka wrote: >> >>> On 26/02/16 02:22, Teik Hooi Beh wrote: >>> >>>> Hi, >>>> >>>> I have manged to deployed 1 ipa master and 1 ipa client with success on >>>> centos 7.2 with freeipa v4.2. I also managed to create user and set >>>> sshd-rules to for ttester user and also successfully get krb ticket >>>> using *kinit >>>> ttester at EXAMPLE.MY*. I am trying to deploy password-less SSH login with >>>> kerberos using the following guide ( >>>> >>>> https://uz.sns.it/~enrico/wordpress/2014/03/password-less-ssh-login-with-kerberos/ >>>> ) >>>> >>>> - >>>> >>>> snippet - >>>> >>>> >>>> >>>> *$ ktutil ktutil: add_entry -password -p ttester at EXAMPLE.MY -k 1 -e >>>> aes256-cts-hmac-sha1-96 ktutil: write_kt keytab* >>>> >>>> When I tried *kinit -kt keytab ttester at EXAMPLE.MY*, I get *"**kinit: >>>> Password incorrect while getting initial credentials"* >>>> Doing a trace using KRB5_TRACE on both calls >>>> >>>> *1. KRB5_TRACE=/dev/stderr kinit ttester at EXAMPLE.MY* >>>> 27242] 1456447025.219676: Getting initial credentials for >>>> ttester at EXAMPLE.MY >>>> [27242] 1456447025.222070: Sending request (164 bytes) to EXAMPLE.MY >>>> [27242] 1456447025.222223: Resolving hostname node1.example.my >>>> [27242] 1456447035.238004: Initiating TCP connection to stream >>>> 192.168.38.2:88 >>>> [27242] 1456447035.238675: Sending TCP request to stream >>>> 192.168.38.2:88 >>>> [27242] 1456447035.241248: Received answer (337 bytes) from stream >>>> 192.168.38.2:88 >>>> [27242] 1456447035.241257: Terminating TCP connection to stream >>>> 192.168.38.2:88 >>>> [27242] 1456447035.241377: Response was from master KDC >>>> [27242] 1456447035.241437: Received error from KDC: >>>> -1765328359/Additional >>>> pre-authentication required >>>> [27242] 1456447035.241484: Processing preauth types: 136, 19, 2, 133 >>>> [27242] 1456447035.241499: Selected etype info: etype aes256-cts, salt >>>> "s`GD^,#=cA:Vr9hD", params "" >>>> [27242] 1456447035.241504: Received cookie: MIT >>>> Password for ttester at EXAMPLE.MY: >>>> [27242] 1456447062.215750: AS key obtained for encrypted timestamp: >>>> aes256-cts/73C6 >>>> [27242] 1456447062.215815: Encrypted timestamp (for 1456447062.215315): >>>> plain 301AA011180F32303136303232363030333734325AA1050203034913, >>>> encrypted >>>> >>>> F9A2E97E916FC14D141690E151A25DCC00168361179C7F0ACDA94C7F58F3D50429780A5608A6B8623E355F2A5BD676F6FA5272D38FD05C8B >>>> >>>> [27242] 1456447062.215942: Preauth module encrypted_timestamp (2) (real) >>>> returned: 0/Success >>>> [27242] 1456447062.215948: Produced preauth for next request: 133, 2 >>>> [27242] 1456447062.215965: Sending request (257 bytes) to EXAMPLE.MY >>>> [27242] 1456447062.216010: Resolving hostname node1.example.my >>>> [27242] 1456447072.229254: Initiating TCP connection to stream >>>> 192.168.38.2:88 >>>> [27242] 1456447072.229655: Sending TCP request to stream >>>> 192.168.38.2:88 >>>> [27242] 1456447072.236955: Received answer (722 bytes) from stream >>>> 192.168.38.2:88 >>>> [27242] 1456447072.236974: Terminating TCP connection to stream >>>> 192.168.38.2:88 >>>> [27242] 1456447072.237080: Response was from master KDC >>>> [27242] 1456447072.237117: Processing preauth types: 19 >>>> [27242] 1456447072.237125: Selected etype info: etype aes256-cts, salt >>>> "s`GD^,#=cA:Vr9hD", params "" >>>> [27242] 1456447072.237131: Produced preauth for next request: (empty) >>>> [27242] 1456447072.237140: AS key determined by preauth: aes256-cts/73C6 >>>> [27242] 1456447072.237199: Decrypted AS reply; session key is: >>>> aes256-cts/2A71 >>>> [27242] 1456447072.237216: FAST negotiation: available >>>> [27242] 1456447072.237236: Initializing KEYRING:persistent:1000:1000 >>>> with >>>> default princ ttester at EXAMPLE.MY >>>> [27242] 1456447072.237275: Storing ttester at EXAMPLE.MY -> >>>> krbtgt/EXAMPLE.MY at EXAMPLE.MY in KEYRING:persistent:1000:1000 >>>> [27242] 1456447072.237330: Storing config in >>>> KEYRING:persistent:1000:1000 >>>> for krbtgt/EXAMPLE.MY at EXAMPLE.MY: fast_avail: yes >>>> [27242] 1456447072.237345: Storing ttester at EXAMPLE.MY -> >>>> >>>> krb5_ccache_conf_data/fast_avail/krbtgt\/EXAMPLE.MY\@EXAMPLE.MY at X-CACHECONF >>>> : >>>> >>>> in KEYRING:persistent:1000:1000 >>>> [27242] 1456447072.237371: Storing config in >>>> KEYRING:persistent:1000:1000 >>>> for krbtgt/EXAMPLE.MY at EXAMPLE.MY: pa_type: 2 >>>> [27242] 1456447072.237380: Storing ttester at EXAMPLE.MY -> >>>> krb5_ccache_conf_data/pa_type/krbtgt\/EXAMPLE.MY\@EXAMPLE.MY at X-CACHECONF >>>> : >>>> in KEYRING:persistent:1000:1000 >>>> >>>> *2. KRB5_TRACE=/dev/stderr kinit -kt keytab ttester at EXAMPLE.MY* >>>> [27248] 1456447236.144685: Getting initial credentials for >>>> ttester at EXAMPLE.MY >>>> [27248] 1456447236.147107: Looked up etypes in keytab: aes256-cts >>>> [27248] 1456447236.147255: Sending request (164 bytes) to EXAMPLE.MY >>>> [27248] 1456447236.147381: Resolving hostname node1.example.my >>>> [27248] 1456447246.161528: Initiating TCP connection to stream >>>> 192.168.38.2:88 >>>> [27248] 1456447246.161970: Sending TCP request to stream >>>> 192.168.38.2:88 >>>> [27248] 1456447246.164772: Received answer (337 bytes) from stream >>>> 192.168.38.2:88 >>>> [27248] 1456447246.164791: Terminating TCP connection to stream >>>> 192.168.38.2:88 >>>> [27248] 1456447246.164904: Response was from master KDC >>>> [27248] 1456447246.164943: Received error from KDC: >>>> -1765328359/Additional >>>> pre-authentication required >>>> [27248] 1456447246.164987: Processing preauth types: 136, 19, 2, 133 >>>> [27248] 1456447246.164997: Selected etype info: etype aes256-cts, salt >>>> "s`GD^,#=cA:Vr9hD", params "" >>>> [27248] 1456447246.165001: Received cookie: MIT >>>> [27248] 1456447246.165142: Retrieving ttester at EXAMPLE.MY from >>>> FILE:keytab >>>> (vno 0, enctype aes256-cts) with result: 0/Success >>>> [27248] 1456447246.165166: AS key obtained for encrypted timestamp: >>>> aes256-cts/0A17 >>>> [27248] 1456447246.165210: Encrypted timestamp (for 1456447246.164647): >>>> plain 301AA011180F32303136303232363030343034365AA1050203028327, >>>> encrypted >>>> >>>> C092E6C29FC1CD794625CF12162D18767A68D1728E6C2ADC1F50492D6605E039B664213C29767715E04B3CA8D97EBD691BBF40B76370C9FA >>>> >>>> [27248] 1456447246.165224: Preauth module encrypted_timestamp (2) (real) >>>> returned: 0/Success >>>> [27248] 1456447246.165228: Produced preauth for next request: 133, 2 >>>> [27248] 1456447246.165239: Sending request (257 bytes) to EXAMPLE.MY >>>> [27248] 1456447246.165253: Resolving hostname node1.example.my >>>> [27248] 1456447256.178637: Initiating TCP connection to stream >>>> 192.168.38.2:88 >>>> [27248] 1456447256.179456: Sending TCP request to stream >>>> 192.168.38.2:88 >>>> [27248] 1456447256.184929: Received answer (167 bytes) from stream >>>> 192.168.38.2:88 >>>> [27248] 1456447256.184941: Terminating TCP connection to stream >>>> 192.168.38.2:88 >>>> [27248] 1456447256.185043: Response was from master KDC >>>> [27248] 1456447256.185065: Received error from KDC: -1765328353/Decrypt >>>> integrity check failed >>>> kinit: Password incorrect while getting initial credentials >>>> >>>> From the 2 trace I notice the return bytes on return from calling using >>>>> >>>> keytab is only 167 bytes compare to 722 bytes. Does anybody know the >>>> reasons or could point me to where I could debug further? >>>> >>>> Thanks >>>> >>>> >>>> >>>> >>> Hello! >>> >>> I don't know why it does not work with ktutil but I've find other way >>> how to get keytab for a user: >>> >>> $ kinit ttester >>> $ ipa-getkeytab -p ttester at EXAMPLE.TEST -k ttester.keytab -e >>> aes256-cts-hmac-sha1-96 >>> $ kdestroy ttester >>> $ kinit ttester at EXAMPLE.TEST -kt ttester.keytab >>> >>> HTH, >>> >>> >> Oh, I forget to mention that this also sets random krbPrincipalKey for >> the user so you can kinit only with the keytab. ipa-getkeytab has also >> option -r (--retrive) that should not change krbPrincipalKey but for some >> reason user is not allowed to retrieve it. >> You can of course add ACI to allow that but I would not do it because >> there's probably good reason why it's forbidden by default. >> >> -- >> David Kupka >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Fri Feb 26 12:05:46 2016 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 26 Feb 2016 13:05:46 +0100 Subject: [Freeipa-users] Not able to get kerberos ticket from keytab In-Reply-To: References: <56D00517.4070406@redhat.com> <56D00995.1030201@redhat.com> Message-ID: <56D03F9A.6070408@redhat.com> On 02/26/2016 10:31 AM, Teik Hooi Beh wrote: > And yes, i also need to include -s ipaserver in the get-ipakeytab command, > otherwise it kept giving wrong usage error.... Just for the record, this should no longer be needed from FreeIPA 4.3.0: https://fedorahosted.org/freeipa/ticket/2203 > On Fri, Feb 26, 2016 at 10:29 PM, Teik Hooi Beh wrote: > >> Thanks. It's working now using ipa-getkeytab. >> >> Correct me if I am wrong (as I am new to freeipa), using ktutil I could >> add multiple user in a keytab file (correct???) but in this case using >> ipa-getkeytab can I do the same? >> >> On Fri, Feb 26, 2016 at 9:15 PM, David Kupka wrote: >> >>> On 26/02/16 08:56, David Kupka wrote: >>> >>>> On 26/02/16 02:22, Teik Hooi Beh wrote: >>>> >>>>> Hi, >>>>> >>>>> I have manged to deployed 1 ipa master and 1 ipa client with success on >>>>> centos 7.2 with freeipa v4.2. I also managed to create user and set >>>>> sshd-rules to for ttester user and also successfully get krb ticket >>>>> using *kinit >>>>> ttester at EXAMPLE.MY*. I am trying to deploy password-less SSH login with >>>>> kerberos using the following guide ( >>>>> >>>>> https://uz.sns.it/~enrico/wordpress/2014/03/password-less-ssh-login-with-kerberos/ >>>>> ) >>>>> >>>>> - >>>>> >>>>> snippet - >>>>> >>>>> >>>>> >>>>> *$ ktutil ktutil: add_entry -password -p ttester at EXAMPLE.MY -k 1 -e >>>>> aes256-cts-hmac-sha1-96 ktutil: write_kt keytab* >>>>> >>>>> When I tried *kinit -kt keytab ttester at EXAMPLE.MY*, I get *"**kinit: >>>>> Password incorrect while getting initial credentials"* >>>>> Doing a trace using KRB5_TRACE on both calls >>>>> >>>>> *1. KRB5_TRACE=/dev/stderr kinit ttester at EXAMPLE.MY* >>>>> 27242] 1456447025.219676: Getting initial credentials for >>>>> ttester at EXAMPLE.MY >>>>> [27242] 1456447025.222070: Sending request (164 bytes) to EXAMPLE.MY >>>>> [27242] 1456447025.222223: Resolving hostname node1.example.my >>>>> [27242] 1456447035.238004: Initiating TCP connection to stream >>>>> 192.168.38.2:88 >>>>> [27242] 1456447035.238675: Sending TCP request to stream >>>>> 192.168.38.2:88 >>>>> [27242] 1456447035.241248: Received answer (337 bytes) from stream >>>>> 192.168.38.2:88 >>>>> [27242] 1456447035.241257: Terminating TCP connection to stream >>>>> 192.168.38.2:88 >>>>> [27242] 1456447035.241377: Response was from master KDC >>>>> [27242] 1456447035.241437: Received error from KDC: >>>>> -1765328359/Additional >>>>> pre-authentication required >>>>> [27242] 1456447035.241484: Processing preauth types: 136, 19, 2, 133 >>>>> [27242] 1456447035.241499: Selected etype info: etype aes256-cts, salt >>>>> "s`GD^,#=cA:Vr9hD", params "" >>>>> [27242] 1456447035.241504: Received cookie: MIT >>>>> Password for ttester at EXAMPLE.MY: >>>>> [27242] 1456447062.215750: AS key obtained for encrypted timestamp: >>>>> aes256-cts/73C6 >>>>> [27242] 1456447062.215815: Encrypted timestamp (for 1456447062.215315): >>>>> plain 301AA011180F32303136303232363030333734325AA1050203034913, >>>>> encrypted >>>>> >>>>> F9A2E97E916FC14D141690E151A25DCC00168361179C7F0ACDA94C7F58F3D50429780A5608A6B8623E355F2A5BD676F6FA5272D38FD05C8B >>>>> >>>>> [27242] 1456447062.215942: Preauth module encrypted_timestamp (2) (real) >>>>> returned: 0/Success >>>>> [27242] 1456447062.215948: Produced preauth for next request: 133, 2 >>>>> [27242] 1456447062.215965: Sending request (257 bytes) to EXAMPLE.MY >>>>> [27242] 1456447062.216010: Resolving hostname node1.example.my >>>>> [27242] 1456447072.229254: Initiating TCP connection to stream >>>>> 192.168.38.2:88 >>>>> [27242] 1456447072.229655: Sending TCP request to stream >>>>> 192.168.38.2:88 >>>>> [27242] 1456447072.236955: Received answer (722 bytes) from stream >>>>> 192.168.38.2:88 >>>>> [27242] 1456447072.236974: Terminating TCP connection to stream >>>>> 192.168.38.2:88 >>>>> [27242] 1456447072.237080: Response was from master KDC >>>>> [27242] 1456447072.237117: Processing preauth types: 19 >>>>> [27242] 1456447072.237125: Selected etype info: etype aes256-cts, salt >>>>> "s`GD^,#=cA:Vr9hD", params "" >>>>> [27242] 1456447072.237131: Produced preauth for next request: (empty) >>>>> [27242] 1456447072.237140: AS key determined by preauth: aes256-cts/73C6 >>>>> [27242] 1456447072.237199: Decrypted AS reply; session key is: >>>>> aes256-cts/2A71 >>>>> [27242] 1456447072.237216: FAST negotiation: available >>>>> [27242] 1456447072.237236: Initializing KEYRING:persistent:1000:1000 >>>>> with >>>>> default princ ttester at EXAMPLE.MY >>>>> [27242] 1456447072.237275: Storing ttester at EXAMPLE.MY -> >>>>> krbtgt/EXAMPLE.MY at EXAMPLE.MY in KEYRING:persistent:1000:1000 >>>>> [27242] 1456447072.237330: Storing config in >>>>> KEYRING:persistent:1000:1000 >>>>> for krbtgt/EXAMPLE.MY at EXAMPLE.MY: fast_avail: yes >>>>> [27242] 1456447072.237345: Storing ttester at EXAMPLE.MY -> >>>>> >>>>> krb5_ccache_conf_data/fast_avail/krbtgt\/EXAMPLE.MY\@EXAMPLE.MY at X-CACHECONF >>>>> : >>>>> >>>>> in KEYRING:persistent:1000:1000 >>>>> [27242] 1456447072.237371: Storing config in >>>>> KEYRING:persistent:1000:1000 >>>>> for krbtgt/EXAMPLE.MY at EXAMPLE.MY: pa_type: 2 >>>>> [27242] 1456447072.237380: Storing ttester at EXAMPLE.MY -> >>>>> krb5_ccache_conf_data/pa_type/krbtgt\/EXAMPLE.MY\@EXAMPLE.MY at X-CACHECONF >>>>> : >>>>> in KEYRING:persistent:1000:1000 >>>>> >>>>> *2. KRB5_TRACE=/dev/stderr kinit -kt keytab ttester at EXAMPLE.MY* >>>>> [27248] 1456447236.144685: Getting initial credentials for >>>>> ttester at EXAMPLE.MY >>>>> [27248] 1456447236.147107: Looked up etypes in keytab: aes256-cts >>>>> [27248] 1456447236.147255: Sending request (164 bytes) to EXAMPLE.MY >>>>> [27248] 1456447236.147381: Resolving hostname node1.example.my >>>>> [27248] 1456447246.161528: Initiating TCP connection to stream >>>>> 192.168.38.2:88 >>>>> [27248] 1456447246.161970: Sending TCP request to stream >>>>> 192.168.38.2:88 >>>>> [27248] 1456447246.164772: Received answer (337 bytes) from stream >>>>> 192.168.38.2:88 >>>>> [27248] 1456447246.164791: Terminating TCP connection to stream >>>>> 192.168.38.2:88 >>>>> [27248] 1456447246.164904: Response was from master KDC >>>>> [27248] 1456447246.164943: Received error from KDC: >>>>> -1765328359/Additional >>>>> pre-authentication required >>>>> [27248] 1456447246.164987: Processing preauth types: 136, 19, 2, 133 >>>>> [27248] 1456447246.164997: Selected etype info: etype aes256-cts, salt >>>>> "s`GD^,#=cA:Vr9hD", params "" >>>>> [27248] 1456447246.165001: Received cookie: MIT >>>>> [27248] 1456447246.165142: Retrieving ttester at EXAMPLE.MY from >>>>> FILE:keytab >>>>> (vno 0, enctype aes256-cts) with result: 0/Success >>>>> [27248] 1456447246.165166: AS key obtained for encrypted timestamp: >>>>> aes256-cts/0A17 >>>>> [27248] 1456447246.165210: Encrypted timestamp (for 1456447246.164647): >>>>> plain 301AA011180F32303136303232363030343034365AA1050203028327, >>>>> encrypted >>>>> >>>>> C092E6C29FC1CD794625CF12162D18767A68D1728E6C2ADC1F50492D6605E039B664213C29767715E04B3CA8D97EBD691BBF40B76370C9FA >>>>> >>>>> [27248] 1456447246.165224: Preauth module encrypted_timestamp (2) (real) >>>>> returned: 0/Success >>>>> [27248] 1456447246.165228: Produced preauth for next request: 133, 2 >>>>> [27248] 1456447246.165239: Sending request (257 bytes) to EXAMPLE.MY >>>>> [27248] 1456447246.165253: Resolving hostname node1.example.my >>>>> [27248] 1456447256.178637: Initiating TCP connection to stream >>>>> 192.168.38.2:88 >>>>> [27248] 1456447256.179456: Sending TCP request to stream >>>>> 192.168.38.2:88 >>>>> [27248] 1456447256.184929: Received answer (167 bytes) from stream >>>>> 192.168.38.2:88 >>>>> [27248] 1456447256.184941: Terminating TCP connection to stream >>>>> 192.168.38.2:88 >>>>> [27248] 1456447256.185043: Response was from master KDC >>>>> [27248] 1456447256.185065: Received error from KDC: -1765328353/Decrypt >>>>> integrity check failed >>>>> kinit: Password incorrect while getting initial credentials >>>>> >>>>> From the 2 trace I notice the return bytes on return from calling using >>>>>> >>>>> keytab is only 167 bytes compare to 722 bytes. Does anybody know the >>>>> reasons or could point me to where I could debug further? >>>>> >>>>> Thanks >>>>> >>>>> >>>>> >>>>> >>>> Hello! >>>> >>>> I don't know why it does not work with ktutil but I've find other way >>>> how to get keytab for a user: >>>> >>>> $ kinit ttester >>>> $ ipa-getkeytab -p ttester at EXAMPLE.TEST -k ttester.keytab -e >>>> aes256-cts-hmac-sha1-96 >>>> $ kdestroy ttester >>>> $ kinit ttester at EXAMPLE.TEST -kt ttester.keytab >>>> >>>> HTH, >>>> >>>> >>> Oh, I forget to mention that this also sets random krbPrincipalKey for >>> the user so you can kinit only with the keytab. ipa-getkeytab has also >>> option -r (--retrive) that should not change krbPrincipalKey but for some >>> reason user is not allowed to retrieve it. >>> You can of course add ACI to allow that but I would not do it because >>> there's probably good reason why it's forbidden by default. >>> >>> -- >>> David Kupka >>> >> >> > > > From rakesh.rajasekharan at gmail.com Fri Feb 26 16:23:12 2016 From: rakesh.rajasekharan at gmail.com (Rakesh Rajasekharan) Date: Fri, 26 Feb 2016 21:53:12 +0530 Subject: [Freeipa-users] version compatibility between server and client Message-ID: Hi!, I had successfully set up ipa in our qa environment, but since we are running cenots 6, i just got 3.0.25 version of IPA. I wanted to try out the latest 4.x version, for server by using a centos 7 OS. But have few questions regarding that Will there be compatibility issues, if I use a server at 4.x and clients at 3.0.25 Another question is, >From the documentation, I see that theres an option to manually configure a client where in we do not have to install freeipa-client using ipa-client-install https://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/linux-manual.html So that way , I can install the latest version of freeipa server and make my clients also be able to use the latest verison without actually installing it. But, are there any issues with this approach, and how does it differ from doing a ipa-client-install on the client machine. Thanks, Rakesh -------------- next part -------------- An HTML attachment was scrubbed... URL: From jbushey at inforelay.com Sat Feb 27 05:20:16 2016 From: jbushey at inforelay.com (Justin Bushey) Date: Sat, 27 Feb 2016 00:20:16 -0500 Subject: [Freeipa-users] Preserved users not replicated to new master (FreeIPA 4.2.0) Message-ID: Hello, I've noticed that when creating a new IPA master users that are set to be Preserved after deletion are not being replicated to the new master. I haven't been able to experiment much with this since I'm working in our production environment, but I did notice that if I restore them as active users and re-initialize the new master I can then move them to the 'Preserved' category. This change is replicated. I'm setting up the new master in the normal manner: On existing master: ipa-replica-prepare --ip-address x.x.x.x replica.domain.com And then using ipa-replica-install on the new master: ipa-replica-install --setup-dns --setup-ca --no-reverse --forwarder x.x.x.x --forwarder x.x.x.x --ip-address=x.x.x.x replica-info-replica.domain.com.gpg I'm just wondering if there's something I'm doing wrong, if this is by design, or if this is an actual bug. Thanks, Justin M. Bushey Systems Administrator InfoRelay Online Systems, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lslebodn at redhat.com Sat Feb 27 09:32:07 2016 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Sat, 27 Feb 2016 10:32:07 +0100 Subject: [Freeipa-users] Recovering from data-only backup doesn't recover Kerberos keys properly In-Reply-To: References: <56CDA23D.7050801@redhat.com> <56CDB907.20707@redhat.com> Message-ID: <20160227093206.GA21983@mail.corp.redhat.com> On (24/02/16 14:28), Marat Vyshegorodtsev wrote: >> Are you just toying with this or did something go horribly wrong and >you're trying to restore a production environment? > >This. :-( > >I have actually rebuilt the environment from scratch, then wrote a >perl script that just recreated all users from the ldif using ipa >user-add and reset password for everyone. > >After the fresh install the following command was used for each user: >ipa user-add --first='John' --last='Doe' --uid=1603600001 >--gid=1603600001 --email='john.doe at contoso.com' --sshpubkey='ssh-rsa >' --random john.doe > >I had to force uids/gids, so that users don't lose access to their home folders. > >I have regenerated keytabs on all client hosts, but now there is some >weird behavior is demonstrated by sssd: users intermittently fail to >login. This is a log from a client machine (Amazon Linux 2015.09): > >(Wed Feb 24 22:08:49 2016) [sssd[ssh]] [accept_fd_handler] (0x0400): >Client connected! >(Wed Feb 24 22:08:49 2016) [sssd[ssh]] [sss_cmd_get_version] (0x0200): >Received client version [0]. >(Wed Feb 24 22:08:49 2016) [sssd[ssh]] [sss_cmd_get_version] (0x0200): >Offered version [0]. >(Wed Feb 24 22:08:49 2016) [sssd[ssh]] [ssh_cmd_parse_request] >(0x0400): Requested domain [] >(Wed Feb 24 22:08:49 2016) [sssd[ssh]] [ssh_cmd_parse_request] >(0x0400): Parsing name [marat.vyshegorodtsev][] >(Wed Feb 24 22:08:49 2016) [sssd[ssh]] [sss_parse_name_for_domains] >(0x0200): name 'marat.vyshegorodtsev' matched without domain, user is >marat.vyshegorodtsev >(Wed Feb 24 22:08:49 2016) [sssd[ssh]] [sss_ssh_cmd_get_user_pubkeys] >(0x0400): Requesting SSH user public keys for [marat.vyshegorodtsev] >from [] >(Wed Feb 24 22:08:49 2016) [sssd[ssh]] [sss_dp_issue_request] >(0x0400): Issuing request for >[0x40b2d0:1:marat.vyshegorodtsev at contoso.com] >(Wed Feb 24 22:08:49 2016) [sssd[ssh]] [sss_dp_get_account_msg] >(0x0400): Creating request for >[contoso.com][1][1][name=marat.vyshegorodtsev] >(Wed Feb 24 22:08:49 2016) [sssd[ssh]] [sbus_add_timeout] (0x2000): 0xb99c10 >(Wed Feb 24 22:08:49 2016) [sssd[ssh]] [sss_dp_internal_get_send] >(0x0400): Entering request >[0x40b2d0:1:marat.vyshegorodtsev at contoso.com] >(Wed Feb 24 22:08:49 2016) [sssd[ssh]] [sbus_remove_timeout] (0x2000): 0xb99c10 >(Wed Feb 24 22:08:49 2016) [sssd[ssh]] [sss_dp_get_reply] (0x1000): >Got reply from Data Provider - DP error code: 1 errno: 11 error >message: Offline sssd works in offline mode. You can find reason/more details would be in different log files (sssd_$domain.log). You instaled server from scratch you it might be acertificate issue (just a wild guess). LS From mj at casalogic.dk Sat Feb 27 13:42:45 2016 From: mj at casalogic.dk (Martin Juhl) Date: Sat, 27 Feb 2016 14:42:45 +0100 (CET) Subject: [Freeipa-users] Error joining domain: tstream_npa_connect_recv to /run/samba/ncalrpc/np for pipe lsarpc Message-ID: <749057160.1682330.1456580565790.JavaMail.zimbra@casalogic.dk> Hi guys I have setup a NT4 Domain, using Freeipa as a ipasam backend... Normal user authentication and shares seems to work, but i'm getting an error when trying to join a Windows 7 machine to the domain (see below)... To me it seems to be the same error as here: https://bugzilla.samba.org/show_bug.cgi?id=11245.... Does anyone know if this patch have been implemented in the freeipa in CentOS??: [root at bart samba]# rpm -qa |grep ipa ipa-python-4.2.0-15.el7_2.6.x86_64 ipa-client-4.2.0-15.el7_2.6.x86_64 python-iniparse-0.4-9.el7.noarch libipa_hbac-1.13.0-40.el7_2.1.x86_64 python-libipa_hbac-1.13.0-40.el7_2.1.x86_64 sssd-ipa-1.13.0-40.el7_2.1.x86_64 Or is this another issue???? Regards Martin ==> /var/log/samba/log.nmbd <== [2016/02/27 14:35:48.662292, 3] ../source3/nmbd/nmbd_incomingrequests.c:220(process_name_registration_request) process_name_registration_request: Name registration for name __MSBROWSE__<01> IP 192.168.150.51 on subnet 192.168.150.51 [2016/02/27 14:35:48.662403, 3] ../source3/nmbd/nmbd_namelistdb.c:263(add_name_to_subnet) add_name_to_subnet: Added netbios name __MSBROWSE__<01> with first IP 192.168.150.51 ttl=0 nb_flags=80 to subnet 192.168.150.51 [2016/02/27 14:35:48.662411, 3] ../source3/nmbd/nmbd_become_lmb.c:453(become_local_master_stage1) become_local_master_stage1: go to stage 2: register the BOLLS<1d> name. [2016/02/27 14:35:48.662426, 3] ../source3/nmbd/nmbd_namelistdb.c:263(add_name_to_subnet) add_name_to_subnet: Added netbios name __MSBROWSE__<01> with first IP 192.168.150.51 ttl=0 nb_flags=80 to subnet UNICAST_SUBNET [2016/02/27 14:35:48.662481, 3] ../source3/nmbd/nmbd_incomingrequests.c:220(process_name_registration_request) process_name_registration_request: Name registration for name BOLLS<1d> IP 192.168.150.51 on subnet 192.168.150.51 [2016/02/27 14:35:49.087066, 3] ../source3/nmbd/nmbd_processlogon.c:542(process_logon_packet) process_logon_packet: processing delayed initial logon reply for client BOLLS-PC(192.168.150.204) [2016/02/27 14:35:49.187085, 3] ../source3/nmbd/nmbd_processlogon.c:542(process_logon_packet) process_logon_packet: processing delayed initial logon reply for client BOLLS-PC(192.168.150.204) [2016/02/27 14:35:49.187170, 3] ../source3/nmbd/nmbd_incomingrequests.c:220(process_name_registration_request) process_name_registration_request: Name registration for name BOLLS<1d> IP 192.168.150.51 on subnet 192.168.150.51 ==> /var/log/samba/log.bolls-pc <== [2016/02/27 14:35:50.694313, 2] ../source3/rpc_server/rpc_ncacn_np.c:773(make_external_rpc_pipe) tstream_npa_connect_recv to /run/samba/ncalrpc/np for pipe lsarpc and user bolls.lan\mj failed: No such file or directory ==> /var/log/samba/log.nmbd <== [2016/02/27 14:35:51.295850, 3] ../source3/nmbd/nmbd_incomingrequests.c:220(process_name_registration_request) process_name_registration_request: Name registration for name BOLLS<1d> IP 192.168.150.51 on subnet 192.168.150.51 [2016/02/27 14:35:51.295935, 3] ../source3/nmbd/nmbd_incomingrequests.c:220(process_name_registration_request) process_name_registration_request: Name registration for name BOLLS<1d> IP 192.168.150.51 on subnet 192.168.150.51 [2016/02/27 14:35:53.298112, 3] ../source3/nmbd/nmbd_namelistdb.c:263(add_name_to_subnet) add_name_to_subnet: Added netbios name BOLLS<1d> with first IP 192.168.150.51 ttl=0 nb_flags= 0 to subnet 192.168.150.51 [2016/02/27 14:35:53.298157, 3] ../source3/nmbd/nmbd_become_lmb.c:354(become_local_master_stage2) become_local_master_stage2: registered as master browser for workgroup BOLLS on subnet 192.168.150.51 [2016/02/27 14:35:53.298164, 3] ../source3/nmbd/nmbd_sendannounce.c:70(broadcast_announce_request) broadcast_announce_request: sending announce request for workgroup BOLLS to subnet 192.168.150.51 [2016/02/27 14:35:53.298205, 3] ../source3/nmbd/nmbd_namelistdb.c:263(add_name_to_subnet) add_name_to_subnet: Added netbios name BOLLS<1d> with first IP 192.168.150.51 ttl=0 nb_flags= 0 to subnet UNICAST_SUBNET [2016/02/27 14:35:53.298214, 0] ../source3/nmbd/nmbd_become_lmb.c:397(become_local_master_stage2) ***** Samba name server BART is now a local master browser for workgroup BOLLS on subnet 192.168.150.51 ***** [2016/02/27 14:35:53.298291, 3] ../source3/nmbd/nmbd_sendannounce.c:170(send_local_master_announcement) send_local_master_announcement: type 8c9b0b for name BART on subnet 192.168.150.51 for workgroup BOLLS [2016/02/27 14:35:53.298320, 3] ../source3/nmbd/nmbd_sendannounce.c:189(send_workgroup_announcement) send_workgroup_announcement: on subnet 192.168.150.51 for workgroup BOLLS From abokovoy at redhat.com Sat Feb 27 14:17:14 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sat, 27 Feb 2016 16:17:14 +0200 Subject: [Freeipa-users] Error joining domain: tstream_npa_connect_recv to /run/samba/ncalrpc/np for pipe lsarpc In-Reply-To: <749057160.1682330.1456580565790.JavaMail.zimbra@casalogic.dk> References: <749057160.1682330.1456580565790.JavaMail.zimbra@casalogic.dk> Message-ID: <20160227141714.GQ4492@redhat.com> On Sat, 27 Feb 2016, Martin Juhl wrote: >Hi guys > >I have setup a NT4 Domain, using Freeipa as a ipasam backend... > >Normal user authentication and shares seems to work, but i'm getting an >error when trying to join a Windows 7 machine to the domain (see >below)... > >To me it seems to be the same error as here: https://bugzilla.samba.org/show_bug.cgi?id=11245.... > >Does anyone know if this patch have been implemented in the freeipa in CentOS??: This should be fixed in RHEL 7 after rebase to 4.2.3, according to upstream git: $ git tag --contains 9a86ca9779c7be9cd6e2f6f7c18233d1c9883bef | head -1 samba-4.2.3 RHEL 7 had 4.2.3 coming as * Tue Jul 14 2015 Andreas Schneider - 4.2.3-1 - related: #1196140 - Rebase to version 4.2.3 - resolves: #1237036 - Fix DCERPC PDU calculation - resolves: #1237039 - Fix winbind request cancellation - resolves: #1223981 - Fix possible segfault with smbX protocol setting >Or is this another issue???? Most likely it is. We do not support using FreeIPA via ipasam as NT4 domain controller and this mode was never tested. I don't know how exactly you run ipasam configuration. -- / Alexander Bokovoy From alessandro.demaria at gmail.com Sat Feb 27 20:36:46 2016 From: alessandro.demaria at gmail.com (Alessandro De Maria) Date: Sat, 27 Feb 2016 20:36:46 +0000 Subject: [Freeipa-users] Unable to get new certificates after upgrade Message-ID: Hello list, I was running freeipa 4.1 on Centos 7.1. I wanted to upgrade to freeipa 4.2.x to make use of user certificates. Upgrade (through yum upgrade) went ok and I am now on version: Name : ipa-server Version : 4.2.0 Release : 15.el7_2.6 However I am unable to generate new certificates (this functionality was working perfectly before) When I use ipa-getcert request I get the following message (ipa-getcert list) *Failed request, will retry: 4001 (RPC failed at server. caIPAserviceCert: Certificate Profile not found* I read this blog: https://blog-ftweedal.rhcloud.com/2015/08/user-certificates-and-custom-profiles-with-freeipa-4-2/ I tried the following: $ ipa certprofile-show caIPAserviceCert ipa: ERROR: caIPAserviceCert: Certificate Profile not found So i tried to download *caIPAserviceCert* from this url and importing it: $ wget https://raw.githubusercontent.com/encukou/freeipa/master/install/share/profiles/caIPAserviceCert.cfg $ ipa certprofile-import caIPAserviceCert --file caIPAserviceCert.cfg --desc "Default certificates" --store TRUE ipa: ERROR: Non-2xx response from CA REST API: 400 Bad Request. Profile already exists So I imported it with another profile name (caIPAserviceCert_new) and that worked (I can see it from the web interface, but I cannot see caIPAserviceCert there) I tried to use: ipa-getcert request -T caIPAserviceCert_new ... ... ... and that still gives the the infamous message above: *Failed request, will retry: 4001 (RPC failed at server. caIPAserviceCert: Certificate Profile not found* Could someone help me out please? I noticed that 4.2.3 is out with important bug fixes, is there a repository out there with Centos rmps? Regards Alessandro -- Alessandro De Maria alessandro.demaria at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Sat Feb 27 21:25:16 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sat, 27 Feb 2016 23:25:16 +0200 Subject: [Freeipa-users] Unable to get new certificates after upgrade In-Reply-To: References: Message-ID: <20160227212516.GR4492@redhat.com> On Sat, 27 Feb 2016, Alessandro De Maria wrote: >Hello list, > >I was running freeipa 4.1 on Centos 7.1. >I wanted to upgrade to freeipa 4.2.x to make use of user certificates. > >Upgrade (through yum upgrade) went ok and I am now on version: >Name : ipa-server >Version : 4.2.0 >Release : 15.el7_2.6 > > >However I am unable to generate new certificates (this functionality was >working perfectly before) > >When I use ipa-getcert request I get the following message (ipa-getcert >list) > >*Failed request, will retry: 4001 (RPC failed at server. caIPAserviceCert: >Certificate Profile not found* >I read this blog: >https://blog-ftweedal.rhcloud.com/2015/08/user-certificates-and-custom-profiles-with-freeipa-4-2/ > >I tried the following: >$ ipa certprofile-show caIPAserviceCert >ipa: ERROR: caIPAserviceCert: Certificate Profile not found > > >So i tried to download *caIPAserviceCert* from this url and importing it: > >$ wget >https://raw.githubusercontent.com/encukou/freeipa/master/install/share/profiles/caIPAserviceCert.cfg > >$ ipa certprofile-import caIPAserviceCert --file caIPAserviceCert.cfg >--desc "Default certificates" --store TRUE >ipa: ERROR: Non-2xx response from CA REST API: 400 Bad Request. Profile >already exists > >So I imported it with another profile name (caIPAserviceCert_new) and that >worked (I can see it from the web interface, but I cannot see caIPAserviceCert >there) > >I tried to use: >ipa-getcert request -T caIPAserviceCert_new ... ... ... > >and that still gives the the infamous message above: >*Failed request, will retry: 4001 (RPC failed at server. caIPAserviceCert: >Certificate Profile not found* > >Could someone help me out please? I noticed that 4.2.3 is out with >important bug fixes, is there a repository out there with Centos rmps? I have no comments to your problem but wanted to comment on this specific thing: When certain software is packaged as part of Red Hat Enterprise Linux, there are rules its maintainers have to follow. One of these rules is to be more strict with rebases and package versions. When a rebase to newer version is not granted, any bugfixes/updates will be managed as patches to the base version. This means that if you see ipa-server-4.2.0-.el7_2 in RHEL 7.2, this does not mean that a particular package has only FreeIPA 4.2.0 version. It includes a number of patches on top of it which make it equal to a certain 4.2.x version at the time of a release of that package. These patches will have to be carried as separate files until next package rebase. For example ipa-4.2.0-15.el7.centos.3.src.rpm has 170 patches on top of 4.2.0 tarball. Some of these are downstream-specific like branding changes but the rest are patches on top of 4.2.0 upstream version that bring the package close to 4.2.3. This allows to be more explicit in what is added on top of a base version and some Red Hat customers actually depend on such information in their own software management processes. For maintainers this, of course, creates a bit of overhead but it is better to be more explicit here. The only inconvenience is that we have to explain the process sometimes to people like you who think 4.2.0-.el7_2 is older than 4.2.3 upstream release. In fact, out of those 170 patches, there are patches which went into upstream 4.3.0 release and weren't yet released in 4.2.x branch because there wasn't any 4.2.x release after 4.2.3 yet. So in the case of 4.2.0-.el7_2 you are actually getting more than FreeIPA 4.2.3. I hope this makes your hunt for '4.2.3' CentOS release less urgent. -- / Alexander Bokovoy From alessandro.demaria at gmail.com Sat Feb 27 21:30:10 2016 From: alessandro.demaria at gmail.com (Alessandro De Maria) Date: Sat, 27 Feb 2016 21:30:10 +0000 Subject: [Freeipa-users] Unable to get new certificates after upgrade In-Reply-To: <20160227212516.GR4492@redhat.com> References: <20160227212516.GR4492@redhat.com> Message-ID: great that explains a lot! Thank you. My hunt for > 4.2.0 was just because in the release note for 4.2.1 it had: - Various fixes for new Certificates Profiles feature So I immediately assumed the problem I might be experiencing could be fixed by an upgrade (I have tried everything else I know) But thank you this is already very helpful. I hope I can find some other pointed to understand my issue then. Regards Alessandro On 27 February 2016 at 21:25, Alexander Bokovoy wrote: > On Sat, 27 Feb 2016, Alessandro De Maria wrote: > >> Hello list, >> >> I was running freeipa 4.1 on Centos 7.1. >> I wanted to upgrade to freeipa 4.2.x to make use of user certificates. >> >> Upgrade (through yum upgrade) went ok and I am now on version: >> Name : ipa-server >> Version : 4.2.0 >> Release : 15.el7_2.6 >> >> >> However I am unable to generate new certificates (this functionality was >> working perfectly before) >> >> When I use ipa-getcert request I get the following message (ipa-getcert >> list) >> >> *Failed request, will retry: 4001 (RPC failed at server. caIPAserviceCert: >> Certificate Profile not found* >> I read this blog: >> >> https://blog-ftweedal.rhcloud.com/2015/08/user-certificates-and-custom-profiles-with-freeipa-4-2/ >> >> I tried the following: >> $ ipa certprofile-show caIPAserviceCert >> ipa: ERROR: caIPAserviceCert: Certificate Profile not found >> >> >> So i tried to download *caIPAserviceCert* from this url and importing it: >> >> $ wget >> >> https://raw.githubusercontent.com/encukou/freeipa/master/install/share/profiles/caIPAserviceCert.cfg >> >> $ ipa certprofile-import caIPAserviceCert --file caIPAserviceCert.cfg >> --desc "Default certificates" --store TRUE >> ipa: ERROR: Non-2xx response from CA REST API: 400 Bad Request. Profile >> already exists >> >> So I imported it with another profile name (caIPAserviceCert_new) and that >> worked (I can see it from the web interface, but I cannot see >> caIPAserviceCert >> there) >> >> I tried to use: >> ipa-getcert request -T caIPAserviceCert_new ... ... ... >> >> and that still gives the the infamous message above: >> *Failed request, will retry: 4001 (RPC failed at server. caIPAserviceCert: >> Certificate Profile not found* >> >> Could someone help me out please? I noticed that 4.2.3 is out with >> important bug fixes, is there a repository out there with Centos rmps? >> > I have no comments to your problem but wanted to comment on this > specific thing: > > When certain software is packaged as part of Red Hat Enterprise Linux, > there are rules its maintainers have to follow. One of these rules is to > be more strict with rebases and package versions. > When a rebase to newer version is not granted, any bugfixes/updates will > be managed as patches to the base version. This means that if you see > ipa-server-4.2.0-.el7_2 in RHEL 7.2, this does not mean that > a particular package has only FreeIPA 4.2.0 version. It includes a > number of patches on top of it which make it equal to a certain 4.2.x > version at the time of a release of that package. These patches will > have to be carried as separate files until next package rebase. > > For example ipa-4.2.0-15.el7.centos.3.src.rpm has 170 patches on top of > 4.2.0 tarball. Some of these are downstream-specific like branding > changes but the rest are patches on top of 4.2.0 upstream version that > bring the package close to 4.2.3. > > This allows to be more explicit in what is added on top of a base > version and some Red Hat customers actually depend on such information > in their own software management processes. For maintainers this, of > course, creates a bit of overhead but it is better to be more explicit > here. The only inconvenience is that we have to explain the process > sometimes to people like you who think 4.2.0-.el7_2 is older > than 4.2.3 upstream release. > > In fact, out of those 170 patches, there are patches which went into > upstream 4.3.0 release and weren't yet released in 4.2.x branch because > there wasn't any 4.2.x release after 4.2.3 yet. So in the case of > 4.2.0-.el7_2 you are actually getting more than FreeIPA > 4.2.3. > > I hope this makes your hunt for '4.2.3' CentOS release less urgent. > > > -- > / Alexander Bokovoy > -- Alessandro De Maria alessandro.demaria at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Sat Feb 27 21:40:08 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sat, 27 Feb 2016 23:40:08 +0200 Subject: [Freeipa-users] Unable to get new certificates after upgrade In-Reply-To: References: <20160227212516.GR4492@redhat.com> Message-ID: <20160227214008.GS4492@redhat.com> On Sat, 27 Feb 2016, Alessandro De Maria wrote: >great that explains a lot! Thank you. > >My hunt for > 4.2.0 was just because in the release note for 4.2.1 it had: > > - Various fixes for new Certificates Profiles feature > > >So I immediately assumed the problem I might be experiencing could be fixed >by an upgrade (I have tried everything else I know) > >But thank you this is already very helpful. > >I hope I can find some other pointed to understand my issue then. I think you are hitting https://fedorahosted.org/freeipa/ticket/5682 commit 704319c3eaf74e0531dd2aa1e5880db7b6ab830c Author: Martin Babinsky Date: Mon Feb 22 13:35:41 2016 +0100 upgrade: unconditional import of certificate profiles into LDAP During IPA server upgrade, the migration of Dogtag profiles into LDAP backend was bound to the update of CS.cfg which enabled the LDAP profile subsystem. If the subsequent profile migration failed, the subsequent upgrades were not executing the migration code leaving CA subsystem in broken state. Therefore the migration code path should be executed regardless of the status of the main Dogtag config file. https://fedorahosted.org/freeipa/ticket/5682 Reviewed-By: Fraser Tweedale Reviewed-By: Jan Cholasta This should be part of 4.2.4 release and will eventually make into RHEL/CentOS updates. -- / Alexander Bokovoy From alessandro.demaria at gmail.com Sat Feb 27 21:46:08 2016 From: alessandro.demaria at gmail.com (Alessandro De Maria) Date: Sat, 27 Feb 2016 21:46:08 +0000 Subject: [Freeipa-users] Unable to get new certificates after upgrade In-Reply-To: <20160227214008.GS4492@redhat.com> References: <20160227212516.GR4492@redhat.com> <20160227214008.GS4492@redhat.com> Message-ID: Yes that looks exactly like it, thank you. Are you aware of a workaround available? Like changing manually the CS.cfg? On 27 February 2016 at 21:40, Alexander Bokovoy wrote: > On Sat, 27 Feb 2016, Alessandro De Maria wrote: > >> great that explains a lot! Thank you. >> >> My hunt for > 4.2.0 was just because in the release note for 4.2.1 it had: >> >> - Various fixes for new Certificates Profiles feature >> >> >> So I immediately assumed the problem I might be experiencing could be >> fixed >> by an upgrade (I have tried everything else I know) >> >> But thank you this is already very helpful. >> >> I hope I can find some other pointed to understand my issue then. >> > I think you are hitting https://fedorahosted.org/freeipa/ticket/5682 > > commit 704319c3eaf74e0531dd2aa1e5880db7b6ab830c > Author: Martin Babinsky > Date: Mon Feb 22 13:35:41 2016 +0100 > > upgrade: unconditional import of certificate profiles into LDAP > During IPA server upgrade, the migration of Dogtag profiles into LDAP > backend was bound to the update of CS.cfg which enabled the LDAP profile > subsystem. If the subsequent profile migration failed, the subsequent > upgrades were not executing the migration code leaving CA subsystem in > broken state. Therefore the migration code path should be executed > regardless of the status of the main Dogtag config file. > https://fedorahosted.org/freeipa/ticket/5682 > Reviewed-By: Fraser Tweedale > Reviewed-By: Jan Cholasta > > This should be part of 4.2.4 release and will eventually make into > RHEL/CentOS updates. > > -- > / Alexander Bokovoy > -- Alessandro De Maria alessandro.demaria at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From alessandro.demaria at gmail.com Sat Feb 27 22:08:09 2016 From: alessandro.demaria at gmail.com (Alessandro De Maria) Date: Sat, 27 Feb 2016 22:08:09 +0000 Subject: [Freeipa-users] Unable to get new certificates after upgrade In-Reply-To: References: <20160227212516.GR4492@redhat.com> <20160227214008.GS4492@redhat.com> Message-ID: I re-run the upgrade script and that fixed it. Thank you very much Alexander! On 27 February 2016 at 21:46, Alessandro De Maria < alessandro.demaria at gmail.com> wrote: > Yes that looks exactly like it, thank you. > Are you aware of a workaround available? Like changing manually the CS.cfg? > > > On 27 February 2016 at 21:40, Alexander Bokovoy > wrote: > >> On Sat, 27 Feb 2016, Alessandro De Maria wrote: >> >>> great that explains a lot! Thank you. >>> >>> My hunt for > 4.2.0 was just because in the release note for 4.2.1 it >>> had: >>> >>> - Various fixes for new Certificates Profiles feature >>> >>> >>> So I immediately assumed the problem I might be experiencing could be >>> fixed >>> by an upgrade (I have tried everything else I know) >>> >>> But thank you this is already very helpful. >>> >>> I hope I can find some other pointed to understand my issue then. >>> >> I think you are hitting https://fedorahosted.org/freeipa/ticket/5682 >> >> commit 704319c3eaf74e0531dd2aa1e5880db7b6ab830c >> Author: Martin Babinsky >> Date: Mon Feb 22 13:35:41 2016 +0100 >> >> upgrade: unconditional import of certificate profiles into LDAP >> During IPA server upgrade, the migration of Dogtag profiles into >> LDAP >> backend was bound to the update of CS.cfg which enabled the LDAP >> profile >> subsystem. If the subsequent profile migration failed, the subsequent >> upgrades were not executing the migration code leaving CA subsystem in >> broken state. Therefore the migration code path should be executed >> regardless of the status of the main Dogtag config file. >> https://fedorahosted.org/freeipa/ticket/5682 >> Reviewed-By: Fraser Tweedale >> Reviewed-By: Jan Cholasta >> >> This should be part of 4.2.4 release and will eventually make into >> RHEL/CentOS updates. >> >> -- >> / Alexander Bokovoy >> > > > > -- > Alessandro De Maria > alessandro.demaria at gmail.com > -- Alessandro De Maria alessandro.demaria at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From tgeier at accertify.com Sun Feb 28 07:15:34 2016 From: tgeier at accertify.com (Timothy Geier) Date: Sun, 28 Feb 2016 07:15:34 +0000 Subject: [Freeipa-users] IPA 4.2: pki-tomcatd in terrible shape In-Reply-To: <56CC3300.9060608@redhat.com> References: <56B86DE0.4070909@redhat.com> <7F0EB8FC-8F2F-49D1-A124-562B5B0A55A2@accertify.com> <56B9AA53.1000400@redhat.com> <56BAFC6E.6030605@redhat.com> <56BE04AD.2020700@redhat.com> <1455951442.25282.2.camel@accertify.com> <56CB277F.2000309@redhat.com> <56CC3300.9060608@redhat.com> Message-ID: On Feb 23, 2016, at 4:22 AM, Ludwig Krispenz > wrote: On 02/22/2016 11:51 PM, Timothy Geier wrote: What?s the established procedure to start a 389 instance without any replication agreements enabled? The only thing that seemed close on google (http://directory.fedoraproject.org/docs/389ds/howto/howto-fix-and-reset-time-skew.html) seems risky and couldn?t be done trivially in a production environment. no, this is about how to get out of problems when replication could no longer synchronize its csn time generation, either by too many accumulate time drifts o playing with system time, hope you don't have to go thru this. Enabling disabling a replication agreement can be done by setting the configuration parameter: look for replication agreements (entries with objectclass=nsDS5ReplicationAgreement) and set nsds5ReplicaEnabled: off you can do this with an ldapmodify when the server is running or by editing /etc/dirsrv/slapd-/dse.ldif when teh server is stopped Thanks for the procedure..the good news is this worked quite well in making sure that 389 didn?t crash immediately after startup. The bad news is that the certificates still didn?t renew due to Server at "http://master_server:8080/ca/ee/ca/profileSubmit" replied: Profile caServerCert Not Found which was the same error in getcert list I saw that one time 389 didn?t crash right away. At least now this can be further troubleshooted without worrying about 389. "This message and any attachments may contain confidential information. If you have received this message in error, any use or distribution is prohibited. Please notify us by reply e-mail if you have mistakenly received this message, and immediately and permanently delete it and any attachments. Thank you." -------------- next part -------------- An HTML attachment was scrubbed... URL: From mj at casalogic.dk Sun Feb 28 07:24:43 2016 From: mj at casalogic.dk (Martin Juhl) Date: Sun, 28 Feb 2016 08:24:43 +0100 (CET) Subject: [Freeipa-users] Error joining domain: tstream_npa_connect_recv to /run/samba/ncalrpc/np for pipe lsarpc In-Reply-To: <20160227141714.GQ4492@redhat.com> References: <749057160.1682330.1456580565790.JavaMail.zimbra@casalogic.dk> <20160227141714.GQ4492@redhat.com> Message-ID: <1782201489.1690311.1456644283940.JavaMail.zimbra@casalogic.dk> Hi Alexander Thanks for your reply... The problem here was apparently SELinux, after setting: setsebool -P samba_load_libgfapi 1 setsebool -P samba_portmapper 1 The lsasd deamon was able to startup correctly... Now I'm faced with another issue: ACCESS DENIED (granted: 0x00000201; required: 0x00000010) i'm trying to use the user "mj" to do the join: [root at bart ~]# id mj uid=1935800001(mj) gid=1935800001(mj) grupper=1935800001(mj),1935800004(vpn),1935800000(admins),1935800008(ntadmins) [root at bart ~]# net groupmap list Domain Users (S-1-5-21-3189138339-1730592290-4215248117-513) -> ntusers Domain Admins (S-1-5-21-3189138339-1730592290-4215248117-512) -> ntadmins Domain Guests (S-1-5-21-3189138339-1730592290-4215248117-514) -> nobody Any thoughts??? You say that freeipa with ipasam is not supported with NT4 domain... Is there a supported way to do this?? (Sambav4 AD??? Couldn't get it to work)... My configuration is below... Regards Martin [global] workgroup = BOLLS netbios name = BART realm = BOLLS.LAN kerberos method = dedicated keytab dedicated keytab file = FILE:/etc/samba/samba.keytab create krb5 conf = no security = user domain master = yes domain logons = yes log level = 3 max log size = 100000 log file = /var/log/samba/log.%m passdb backend = ipasam:ldaps://lisa.bolls.lan disable spoolss = yes ldapsam:trusted = yes ldap ssl = off ldap suffix = dc=bolls,dc=lan ldap user suffix = cn=users,cn=accounts ldap group suffix = cn=groups,cn=accounts ldap machine suffix = cn=computers,cn=accounts rpc_server:epmapper = external rpc_server:lsarpc = external rpc_server:lsass = external rpc_server:lsasd = external rpc_server:samr = external rpc_server:netlogon = external rpc_server:tcpip = yes rpc_daemon:epmd = fork rpc_daemon:lsasd = fork logon path = \\%L\Profiles\%U logon drive = H: logon home = \\%L\%U [homes] comment = Home Directories valid users = %S read only = No browseable = No [printers] comment = All Printers path = /var/spool/samba printer admin = root, mj create mask = 0600 guest ok = Yes printable = Yes browseable = No [print$] comment = Printer Drivers Share path = /var/lib/samba/drivers write list = mj, root printer admin = mj, root [netlogon] comment = Network Logon Service path = /var/lib/samba/netlogon admin users = root, mj guest ok = Yes browseable = No # For profiles to work, create a user directory under the path # shown. i.e., mkdir -p /var/lib/samba/profiles/mj [Profiles] comment = Roaming Profile Share path = /var/lib/samba/profiles read only = No profile acls = Yes ----- Original meddelelse ----- Fra: "Alexander Bokovoy" Til: "mj" Cc: "freeipa-users" Sendt: l?rdag, 27. februar 2016 15:17:14 Emne: Re: [Freeipa-users] Error joining domain: tstream_npa_connect_recv to /run/samba/ncalrpc/np for pipe lsarpc On Sat, 27 Feb 2016, Martin Juhl wrote: >Hi guys > >I have setup a NT4 Domain, using Freeipa as a ipasam backend... > >Normal user authentication and shares seems to work, but i'm getting an >error when trying to join a Windows 7 machine to the domain (see >below)... > >To me it seems to be the same error as here: https://bugzilla.samba.org/show_bug.cgi?id=11245.... > >Does anyone know if this patch have been implemented in the freeipa in CentOS??: This should be fixed in RHEL 7 after rebase to 4.2.3, according to upstream git: $ git tag --contains 9a86ca9779c7be9cd6e2f6f7c18233d1c9883bef | head -1 samba-4.2.3 RHEL 7 had 4.2.3 coming as * Tue Jul 14 2015 Andreas Schneider - 4.2.3-1 - related: #1196140 - Rebase to version 4.2.3 - resolves: #1237036 - Fix DCERPC PDU calculation - resolves: #1237039 - Fix winbind request cancellation - resolves: #1223981 - Fix possible segfault with smbX protocol setting >Or is this another issue???? Most likely it is. We do not support using FreeIPA via ipasam as NT4 domain controller and this mode was never tested. I don't know how exactly you run ipasam configuration. -- / Alexander Bokovoy From abokovoy at redhat.com Sun Feb 28 09:03:24 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sun, 28 Feb 2016 04:03:24 -0500 (EST) Subject: [Freeipa-users] Error joining domain: tstream_npa_connect_recv to /run/samba/ncalrpc/np for pipe lsarpc In-Reply-To: <1782201489.1690311.1456644283940.JavaMail.zimbra@casalogic.dk> References: <749057160.1682330.1456580565790.JavaMail.zimbra@casalogic.dk> <20160227141714.GQ4492@redhat.com> <1782201489.1690311.1456644283940.JavaMail.zimbra@casalogic.dk> Message-ID: <1056802684.37120578.1456650204035.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Hi Alexander > > Thanks for your reply... > > The problem here was apparently SELinux, after setting: > > setsebool -P samba_load_libgfapi 1 > setsebool -P samba_portmapper 1 On IPA master these should be enabled by ipa-adtrust-install. On a client you are on your own. You can look at ipaserver/install/adtrustinstance.py to see what is being done there. This also affects your cifs/bart.bolls.lan at BOLLS.LAN principal which Samba uses to authenticate against LDAP and perform changes in LDAP. It is this principal that will be used to judge what can be created/modified in LDAP. > The lsasd deamon was able to startup correctly... > > Now I'm faced with another issue: > > ACCESS DENIED (granted: 0x00000201; required: 0x00000010) 'mj' user lacks SeMachineAccountPrivilege --------------------------- # net sam rights grant mj SeMachineAccountPrivilege Granted SeMachineAccountPrivilege to BOLLS\mj --------------------------- However, as I said, this might not be enough because it would only allow smbd to come to ipasam and ask creating a machine account. To do so, ipasam would connect to LDAP with cifs/bart.bolls.lan at BOLLS.LAN principal and any operation which is denied to cifs/bart, will not pass. > You say that freeipa with ipasam is not supported with NT4 domain... Is there > a supported way to do this?? (Sambav4 AD??? Couldn't get it to work)... Our envisioned way of doing it is eventually have Samba AD as your AD environment and then use cross-forest trust to IPA to establish relationship between the two. NT4 domains are not really supported well by Windows 7+ either (see https://wiki.samba.org/index.php/Required_settings_for_NT4-style_domains for gory details). > > My configuration is below... > > Regards > > Martin > > [global] > workgroup = BOLLS > netbios name = BART > realm = BOLLS.LAN > kerberos method = dedicated keytab > dedicated keytab file = FILE:/etc/samba/samba.keytab > create krb5 conf = no > security = user > domain master = yes > domain logons = yes > log level = 3 > max log size = 100000 > log file = /var/log/samba/log.%m > passdb backend = ipasam:ldaps://lisa.bolls.lan > disable spoolss = yes > ldapsam:trusted = yes > ldap ssl = off > ldap suffix = dc=bolls,dc=lan > ldap user suffix = cn=users,cn=accounts > ldap group suffix = cn=groups,cn=accounts > ldap machine suffix = cn=computers,cn=accounts > rpc_server:epmapper = external > rpc_server:lsarpc = external > rpc_server:lsass = external > rpc_server:lsasd = external > rpc_server:samr = external > rpc_server:netlogon = external > rpc_server:tcpip = yes > rpc_daemon:epmd = fork > rpc_daemon:lsasd = fork > logon path = \\%L\Profiles\%U > logon drive = H: > logon home = \\%L\%U > > [homes] > comment = Home Directories > valid users = %S > read only = No > browseable = No > [printers] > comment = All Printers > path = /var/spool/samba > printer admin = root, mj > create mask = 0600 > guest ok = Yes > printable = Yes > browseable = No > [print$] > comment = Printer Drivers Share > path = /var/lib/samba/drivers > write list = mj, root > printer admin = mj, root > [netlogon] > comment = Network Logon Service > path = /var/lib/samba/netlogon > admin users = root, mj > guest ok = Yes > browseable = No > # For profiles to work, create a user directory under the path > # shown. i.e., mkdir -p /var/lib/samba/profiles/mj > [Profiles] > comment = Roaming Profile Share > path = /var/lib/samba/profiles > read only = No > profile acls = Yes > > > ----- Original meddelelse ----- > Fra: "Alexander Bokovoy" > Til: "mj" > Cc: "freeipa-users" > Sendt: l?rdag, 27. februar 2016 15:17:14 > Emne: Re: [Freeipa-users] Error joining domain: tstream_npa_connect_recv to > /run/samba/ncalrpc/np for pipe lsarpc > > On Sat, 27 Feb 2016, Martin Juhl wrote: > >Hi guys > > > >I have setup a NT4 Domain, using Freeipa as a ipasam backend... > > > >Normal user authentication and shares seems to work, but i'm getting an > >error when trying to join a Windows 7 machine to the domain (see > >below)... > > > >To me it seems to be the same error as here: > >https://bugzilla.samba.org/show_bug.cgi?id=11245.... > > > >Does anyone know if this patch have been implemented in the freeipa in > >CentOS??: > This should be fixed in RHEL 7 after rebase to 4.2.3, according to > upstream git: > > $ git tag --contains 9a86ca9779c7be9cd6e2f6f7c18233d1c9883bef | head -1 > samba-4.2.3 > > RHEL 7 had 4.2.3 coming as > * Tue Jul 14 2015 Andreas Schneider - 4.2.3-1 > - related: #1196140 - Rebase to version 4.2.3 > - resolves: #1237036 - Fix DCERPC PDU calculation > - resolves: #1237039 - Fix winbind request cancellation > - resolves: #1223981 - Fix possible segfault with smbX protocol setting > > >Or is this another issue???? > Most likely it is. We do not support using FreeIPA via ipasam as NT4 > domain controller and this mode was never tested. I don't know how > exactly you run ipasam configuration. > > -- > / Alexander Bokovoy > > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project -- / Alexander Bokovoy From freeipa at 0xc0dedbad.com Sun Feb 28 13:51:47 2016 From: freeipa at 0xc0dedbad.com (Peter Fern) Date: Mon, 29 Feb 2016 00:51:47 +1100 Subject: [Freeipa-users] DNSSEC KSK rollover Message-ID: <56D2FB73.3000003@0xc0dedbad.com> Hi all, A new KSK has been auto-generated, and it's transitioned through 'published' and is now sitting in the 'ready' state, but does not appear as a DNSKEY record on the zone. I can see that ods-enforcerd has picked up the state change correctly and logged a DSChanged event with the correct output for the new DNSKEY record, and it appears as expected in localhsm, but is not published on the zone. Running FreeIPA 4.3.0-1.fc23, anyone got pointers on how to proceed with the rollover? Cheers, Pete Konsole output -------------- next part -------------- An HTML attachment was scrubbed... URL: From alessandro.demaria at gmail.com Sun Feb 28 23:17:42 2016 From: alessandro.demaria at gmail.com (Alessandro De Maria) Date: Sun, 28 Feb 2016 23:17:42 +0000 Subject: [Freeipa-users] OTP not working since upgrade Message-ID: Hello, since I upgraded to 4.2.0 on Centos, OTPs do not seem to work anymore. Name : ipa-server Version : 4.2.0 Release : 15.el7_2.6 The error I see in the Feb 28 23:01:40 id1 krb5kdc[2894](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 10.0.1.10: NEEDED_PREAUTH: alessandro at XX.COM for krbtgt/XX.COM at XX.COM, Additional pre-authentication required Feb 28 23:01:41 id1.XX.com krb5kdc[2896](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 10.0.1.10: PREAUTH_FAILED: alessandro at XX.COM for krbtgt/ XX.COM at XX.COM, Incorrect password in encrypted challenge I tried syncing the OTP and also creating a new one. Strangely enough I can connect OK with the VPN supplying password + OTP, but OTP is not working on both freeipa gui and when issuing sudo. Could someone help me understand what is going on? Regards Alessandro -- Alessandro De Maria alessandro.demaria at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From alessandro.demaria at gmail.com Mon Feb 29 00:11:36 2016 From: alessandro.demaria at gmail.com (Alessandro De Maria) Date: Mon, 29 Feb 2016 00:11:36 +0000 Subject: [Freeipa-users] OTP not working since upgrade In-Reply-To: References: Message-ID: Solved. This turned out to be the ipa-otp process stuck on one of the 2 servers. The VPN requests where being sent to the other server which was working fine a simple restart of ipa fixed it. Regards On 28 February 2016 at 23:17, Alessandro De Maria < alessandro.demaria at gmail.com> wrote: > Hello, > > since I upgraded to 4.2.0 on Centos, OTPs do not seem to work anymore. > Name : ipa-server > Version : 4.2.0 > Release : 15.el7_2.6 > > The error I see in the > Feb 28 23:01:40 id1 krb5kdc[2894](info): AS_REQ (6 etypes {18 17 16 23 25 > 26}) 10.0.1.10: NEEDED_PREAUTH: alessandro at XX.COM for krbtgt/XX.COM at XX.COM, > Additional pre-authentication required > Feb 28 23:01:41 id1.XX.com krb5kdc[2896](info): AS_REQ (6 etypes {18 17 > 16 23 25 26}) 10.0.1.10: PREAUTH_FAILED: alessandro at XX.COM for krbtgt/ > XX.COM at XX.COM, Incorrect password in encrypted challenge > > I tried syncing the OTP and also creating a new one. > Strangely enough I can connect OK with the VPN supplying password + OTP, > but OTP is not working on both freeipa gui and when issuing sudo. > > Could someone help me understand what is going on? > > Regards > Alessandro > > > -- > Alessandro De Maria > alessandro.demaria at gmail.com > -- Alessandro De Maria alessandro.demaria at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Mon Feb 29 05:44:56 2016 From: simo at redhat.com (Simo Sorce) Date: Mon, 29 Feb 2016 00:44:56 -0500 Subject: [Freeipa-users] OTP not working since upgrade In-Reply-To: References: Message-ID: <1456724696.6599.486.camel@redhat.com> On Mon, 2016-02-29 at 00:11 +0000, Alessandro De Maria wrote: > Solved. > This turned out to be the ipa-otp process stuck on one of the 2 servers. > The VPN requests where being sent to the other server which was working fine > > a simple restart of ipa fixed it. Do you have any logs that show any error from the ipa-otpd process It would be nice to fix any issue it may have. Simo. > Regards > > On 28 February 2016 at 23:17, Alessandro De Maria < > alessandro.demaria at gmail.com> wrote: > > > Hello, > > > > since I upgraded to 4.2.0 on Centos, OTPs do not seem to work anymore. > > Name : ipa-server > > Version : 4.2.0 > > Release : 15.el7_2.6 > > > > The error I see in the > > Feb 28 23:01:40 id1 krb5kdc[2894](info): AS_REQ (6 etypes {18 17 16 23 25 > > 26}) 10.0.1.10: NEEDED_PREAUTH: alessandro at XX.COM for krbtgt/XX.COM at XX.COM, > > Additional pre-authentication required > > Feb 28 23:01:41 id1.XX.com krb5kdc[2896](info): AS_REQ (6 etypes {18 17 > > 16 23 25 26}) 10.0.1.10: PREAUTH_FAILED: alessandro at XX.COM for krbtgt/ > > XX.COM at XX.COM, Incorrect password in encrypted challenge > > > > I tried syncing the OTP and also creating a new one. > > Strangely enough I can connect OK with the VPN supplying password + OTP, > > but OTP is not working on both freeipa gui and when issuing sudo. > > > > Could someone help me understand what is going on? > > > > Regards > > Alessandro > > > > > > -- > > Alessandro De Maria > > alessandro.demaria at gmail.com > > > > > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project -- Simo Sorce * Red Hat, Inc * New York From mbabinsk at redhat.com Mon Feb 29 08:34:01 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 29 Feb 2016 09:34:01 +0100 Subject: [Freeipa-users] Unable to get new certificates after upgrade In-Reply-To: References: Message-ID: <56D40279.6010302@redhat.com> On 02/27/2016 09:36 PM, Alessandro De Maria wrote: > Hello list, > > I was running freeipa 4.1 on Centos 7.1. > I wanted to upgrade to freeipa 4.2.x to make use of user certificates. > > Upgrade (through yum upgrade) went ok and I am now on version: > Name : ipa-server > Version : 4.2.0 > Release : 15.el7_2.6 > > > However I am unable to generate new certificates (this functionality was > working perfectly before) > > When I use ipa-getcert request I get the following message (ipa-getcert > list) > /*Failed request, will retry: 4001 (RPC failed at server. > caIPAserviceCert: Certificate Profile not found > */ > I read this blog: > https://blog-ftweedal.rhcloud.com/2015/08/user-certificates-and-custom-profiles-with-freeipa-4-2/ > > I tried the following: > $ ipa certprofile-show caIPAserviceCert > ipa: ERROR: caIPAserviceCert: Certificate Profile not found > > > So i tried to download /*caIPAserviceCert*/ from this url and importing it: > > $ wget > https://raw.githubusercontent.com/encukou/freeipa/master/install/share/profiles/caIPAserviceCert.cfg > > $ ipa certprofile-import caIPAserviceCert --file caIPAserviceCert.cfg > --desc "Default certificates" --store TRUE > ipa: ERROR: Non-2xx response from CA REST API: 400 Bad Request. Profile > already exists > > So I imported it with another profile name (caIPAserviceCert_new) and > that worked (I can see it from the web interface, but I cannot see > caIPAserviceCert there) > > I tried to use: > ipa-getcert request -T caIPAserviceCert_new ... ... ... > > and that still gives the the infamous message above: > /*Failed request, will retry: 4001 (RPC failed at server. > caIPAserviceCert: Certificate Profile not found*/ > /* > */ > Could someone help me out please? I noticed that 4.2.3 is out with > important bug fixes, is there a repository out there with Centos rmps? > > Regards > Alessandro > -- > > > Alessandro De Maria > alessandro.demaria at gmail.com > > Hi Alessandro, you probably hit https://fedorahosted.org/freeipa/ticket/5682: a fix for this issue is underway to the downstream. Meanwhile you can try the following workaround: 1.) open /etc/pki/pki-tomcat/conf/ca/CS.cfg file and locate a line similar to the following: "subsystem.1.class=com.netscape.cmscore.profile.LDAPProfileSubsystem" 2.) Replace the "LDAPProfileSubsystem" part of the directive with "ProfileSubsystem". 3.) Run "ipa-server-upgrade" to trigger the addition of profiles to LDAP manually 4.) As directory manager, run """ ldapsearch -D 'cn=Directory Manager' -W -b 'ou=CertificateProfiles,ou=ca,o=ipaca' '(objectclass=certProfile)' """ You should get a list of profiles with base64-encoded configurations and the certificate requests should work as usual. -- Martin^3 Babinsky From pspacek at redhat.com Mon Feb 29 10:22:53 2016 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 29 Feb 2016 11:22:53 +0100 Subject: [Freeipa-users] DNSSEC KSK rollover In-Reply-To: <56D2FB73.3000003@0xc0dedbad.com> References: <56D2FB73.3000003@0xc0dedbad.com> Message-ID: <56D41BFD.9010709@redhat.com> On 28.2.2016 14:51, Peter Fern wrote: > Hi all, > A new KSK has been auto-generated, and it's transitioned through > 'published' and is now sitting in the 'ready' state, but does not appear > as a DNSKEY record on the zone. I can see that ods-enforcerd has picked > up the state change correctly and logged a DSChanged event with the > correct output for the new DNSKEY record, and it appears as expected in > localhsm, but is not published on the zone. > > Running FreeIPA 4.3.0-1.fc23, anyone got pointers on how to proceed with > the rollover? Hi, I would recommend you to wait until fix https://fedorahosted.org/freeipa/ticket/5334 is released in 4.3.1 or so. After that you can use procedure described on page http://www.freeipa.org/page/Howto/DNSSEC to run ds-seen command. I hope this helps. -- Petr^2 Spacek From freeipa at 0xc0dedbad.com Mon Feb 29 10:54:27 2016 From: freeipa at 0xc0dedbad.com (Peter Fern) Date: Mon, 29 Feb 2016 21:54:27 +1100 Subject: [Freeipa-users] DNSSEC KSK rollover In-Reply-To: <56D41BFD.9010709@redhat.com> References: <56D2FB73.3000003@0xc0dedbad.com> <56D41BFD.9010709@redhat.com> Message-ID: <56D42363.4080806@0xc0dedbad.com> On 02/29/2016 21:22, Petr Spacek wrote: > On 28.2.2016 14:51, Peter Fern wrote: >> Hi all, >> A new KSK has been auto-generated, and it's transitioned through >> 'published' and is now sitting in the 'ready' state, but does not appear >> as a DNSKEY record on the zone. I can see that ods-enforcerd has picked >> up the state change correctly and logged a DSChanged event with the >> correct output for the new DNSKEY record, and it appears as expected in >> localhsm, but is not published on the zone. >> >> Running FreeIPA 4.3.0-1.fc23, anyone got pointers on how to proceed with >> the rollover? > Hi, > > I would recommend you to wait until fix > https://fedorahosted.org/freeipa/ticket/5334 > is released in 4.3.1 or so. > > After that you can use procedure described on page > http://www.freeipa.org/page/Howto/DNSSEC > to run ds-seen command. > > I hope this helps. That ticket was reported by me ;-) The issue here is that the new KSK did not appear as a DNSKEY record, so running ds-seen would have been a bad idea, since the zone would be entirely invalid if the old key was rotated out before the new key was published, and the new DS record would be invalid without the corresponding KSK anyway. I did also have some more rotated keys get stuck per #5334, and had cleared them prior to this issue, but I was having trouble getting the zone resigned correctly, and I was hoping to roll all the keys to deal with that. In the end, I had to un-sign the domain and re-sign it to recover. I was wondering if there were possibly some known issues/tricks with KSK rollover, but wasn't certain if my #5334 issues may have thrown a spanner in the works at some key point in the lifecycle. I've got some more KSKs due to roll in a couple of months, so hopefully I can get 4.3.1 deployed before then, and I'll be able to see if the process goes smoothly without the extraneous issues. I've also discovered the replication ACI issues in 4.3.0 (#5575 and friends), which are causing me some grief. Is there a feel for how close we are to a 4.3.1 release? From mkosek at redhat.com Mon Feb 29 11:53:31 2016 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 29 Feb 2016 12:53:31 +0100 Subject: [Freeipa-users] version compatibility between server and client In-Reply-To: References: Message-ID: <56D4313B.9030105@redhat.com> On 02/26/2016 05:23 PM, Rakesh Rajasekharan wrote: > Hi!, > > I had successfully set up ipa in our qa environment, but since we are > running cenots 6, i just got 3.0.25 version of IPA. > > I wanted to try out the latest 4.x version, for server by using a centos 7 > OS. But have few questions regarding that > > Will there be compatibility issues, if I use a server at 4.x and clients at > 3.0.25 Please see http://www.freeipa.org/page/Client#Compatibility There are plans for FreeIPA 4.4 to improve the "ipa" tool/API compatibility too. > Another question is, >>From the documentation, I see that theres an option to manually configure a > client where in we do not have to install freeipa-client using > ipa-client-install > > https://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/linux-manual.html Please note that this is a quite old documentation, see here for other options: http://www.freeipa.org/page/Upstream_User_Guide > So that way , I can install the latest version of freeipa server and make > my clients also be able to use the latest verison without actually > installing it. > > But, are there any issues with this approach, and how does it differ from > doing a ipa-client-install on the client machine. I can hardly imagine when manually configuring a FreeIPA client would be a good idea. In vast majority of cases, ipa-client-install is what you want, to configure a client against newer or older FreeIPA server version. Martin From tbordaz at redhat.com Mon Feb 29 12:43:11 2016 From: tbordaz at redhat.com (thierry bordaz) Date: Mon, 29 Feb 2016 13:43:11 +0100 Subject: [Freeipa-users] Preserved users not replicated to new master (FreeIPA 4.2.0) In-Reply-To: References: Message-ID: <56D43CDF.20406@redhat.com> Hi Justin, I was trying to reproduce this but I think I am missing some steps. Do you mind reviewing my testcase to check what is missing ? The test case is : install master M, prepare replica (+copy of gpg), install replica (new master) R. On R: * Authenticate as 'admin' * 'ipa user-add ' * ipa user-del --preserve On M: * Authenticate as 'admin' * ipa user-find --preserved=true <--- here the preserved is found Is it similar to what you tested ? thanks theirry On 02/27/2016 06:20 AM, Justin Bushey wrote: > Hello, > > I've noticed that when creating a new IPA master users that are set to > be Preserved after deletion are not being replicated to the new > master. I haven't been able to experiment much with this since I'm > working in our production environment, but I did notice that if I > restore them as active users and re-initialize the new master I can > then move them to the 'Preserved' category. This change is replicated. > > I'm setting up the new master in the normal manner: > > On existing master: > ipa-replica-prepare --ip-address x.x.x.x replica.domain.com > > > And then using ipa-replica-install on the new master: > > ipa-replica-install --setup-dns --setup-ca --no-reverse --forwarder > x.x.x.x --forwarder x.x.x.x --ip-address=x.x.x.x > replica-info-replica.domain.com.gpg > > I'm just wondering if there's something I'm doing wrong, if this is by > design, or if this is an actual bug. > > Thanks, > > Justin M. Bushey > Systems Administrator > InfoRelay Online Systems, Inc. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alessandro.demaria at gmail.com Mon Feb 29 16:49:51 2016 From: alessandro.demaria at gmail.com (Alessandro De Maria) Date: Mon, 29 Feb 2016 16:49:51 +0000 Subject: [Freeipa-users] OTP not working since upgrade In-Reply-To: <1456724696.6599.486.camel@redhat.com> References: <1456724696.6599.486.camel@redhat.com> Message-ID: Of course, could you point me to the logs you would be interested in? Regards Alessandro On 29 February 2016 at 05:44, Simo Sorce wrote: > On Mon, 2016-02-29 at 00:11 +0000, Alessandro De Maria wrote: > > Solved. > > This turned out to be the ipa-otp process stuck on one of the 2 servers. > > The VPN requests where being sent to the other server which was working > fine > > > > a simple restart of ipa fixed it. > > Do you have any logs that show any error from the ipa-otpd process > It would be nice to fix any issue it may have. > > Simo. > > > Regards > > > > On 28 February 2016 at 23:17, Alessandro De Maria < > > alessandro.demaria at gmail.com> wrote: > > > > > Hello, > > > > > > since I upgraded to 4.2.0 on Centos, OTPs do not seem to work anymore. > > > Name : ipa-server > > > Version : 4.2.0 > > > Release : 15.el7_2.6 > > > > > > The error I see in the > > > Feb 28 23:01:40 id1 krb5kdc[2894](info): AS_REQ (6 etypes {18 17 16 23 > 25 > > > 26}) 10.0.1.10: NEEDED_PREAUTH: alessandro at XX.COM for krbtgt/ > XX.COM at XX.COM, > > > Additional pre-authentication required > > > Feb 28 23:01:41 id1.XX.com krb5kdc[2896](info): AS_REQ (6 etypes {18 > 17 > > > 16 23 25 26}) 10.0.1.10: PREAUTH_FAILED: alessandro at XX.COM for krbtgt/ > > > XX.COM at XX.COM, Incorrect password in encrypted challenge > > > > > > I tried syncing the OTP and also creating a new one. > > > Strangely enough I can connect OK with the VPN supplying password + > OTP, > > > but OTP is not working on both freeipa gui and when issuing sudo. > > > > > > Could someone help me understand what is going on? > > > > > > Regards > > > Alessandro > > > > > > > > > -- > > > Alessandro De Maria > > > alessandro.demaria at gmail.com > > > > > > > > > > > -- > > Manage your subscription for the Freeipa-users mailing list: > > https://www.redhat.com/mailman/listinfo/freeipa-users > > Go to http://freeipa.org for more info on the project > > > -- > Simo Sorce * Red Hat, Inc * New York > > -- Alessandro De Maria alessandro.demaria at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From rakesh.rajasekharan at gmail.com Mon Feb 29 18:03:34 2016 From: rakesh.rajasekharan at gmail.com (Rakesh Rajasekharan) Date: Mon, 29 Feb 2016 23:33:34 +0530 Subject: [Freeipa-users] version compatibility between server and client In-Reply-To: <56D4313B.9030105@redhat.com> References: <56D4313B.9030105@redhat.com> Message-ID: the only reason for me to avoid ipa-client-install was few of our machines are Amazon Linux and I was having a tough time setting up ipa over there as the yum does not get the repo even with epel enabled. Otherwise, I was able to get this working on all of the other systems , which are centos 6.3 Are there any documentations on setting IPA on an Amazon Linux, if not, the only option would to try compiling this. Thanks, Rakesh On Mon, Feb 29, 2016 at 5:23 PM, Martin Kosek wrote: > On 02/26/2016 05:23 PM, Rakesh Rajasekharan wrote: > > Hi!, > > > > I had successfully set up ipa in our qa environment, but since we are > > running cenots 6, i just got 3.0.25 version of IPA. > > > > I wanted to try out the latest 4.x version, for server by using a centos > 7 > > OS. But have few questions regarding that > > > > Will there be compatibility issues, if I use a server at 4.x and clients > at > > 3.0.25 > > Please see > http://www.freeipa.org/page/Client#Compatibility > There are plans for FreeIPA 4.4 to improve the "ipa" tool/API > compatibility too. > > > Another question is, > >>From the documentation, I see that theres an option to manually > configure a > > client where in we do not have to install freeipa-client using > > ipa-client-install > > > > > https://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/linux-manual.html > > Please note that this is a quite old documentation, see here for other > options: > http://www.freeipa.org/page/Upstream_User_Guide > > > So that way , I can install the latest version of freeipa server and make > > my clients also be able to use the latest verison without actually > > installing it. > > > > But, are there any issues with this approach, and how does it differ from > > doing a ipa-client-install on the client machine. > > I can hardly imagine when manually configuring a FreeIPA client would be a > good > idea. In vast majority of cases, ipa-client-install is what you want, to > configure a client against newer or older FreeIPA server version. > > Martin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Mon Feb 29 18:12:25 2016 From: simo at redhat.com (Simo Sorce) Date: Mon, 29 Feb 2016 13:12:25 -0500 Subject: [Freeipa-users] OTP not working since upgrade In-Reply-To: References: <1456724696.6599.486.camel@redhat.com> Message-ID: <1456769545.6599.493.camel@redhat.com> On Mon, 2016-02-29 at 16:49 +0000, Alessandro De Maria wrote: > Of course, > > could you point me to the logs you would be interested in? Probably the kdc logs, I am not sure we directly log from ipa-otpd, but you could take a look at the journal/syslog too ? Simo. > Regards > Alessandro > > On 29 February 2016 at 05:44, Simo Sorce wrote: > > > On Mon, 2016-02-29 at 00:11 +0000, Alessandro De Maria wrote: > > > Solved. > > > This turned out to be the ipa-otp process stuck on one of the 2 servers. > > > The VPN requests where being sent to the other server which was working > > fine > > > > > > a simple restart of ipa fixed it. > > > > Do you have any logs that show any error from the ipa-otpd process > > It would be nice to fix any issue it may have. > > > > Simo. > > > > > Regards > > > > > > On 28 February 2016 at 23:17, Alessandro De Maria < > > > alessandro.demaria at gmail.com> wrote: > > > > > > > Hello, > > > > > > > > since I upgraded to 4.2.0 on Centos, OTPs do not seem to work anymore. > > > > Name : ipa-server > > > > Version : 4.2.0 > > > > Release : 15.el7_2.6 > > > > > > > > The error I see in the > > > > Feb 28 23:01:40 id1 krb5kdc[2894](info): AS_REQ (6 etypes {18 17 16 23 > > 25 > > > > 26}) 10.0.1.10: NEEDED_PREAUTH: alessandro at XX.COM for krbtgt/ > > XX.COM at XX.COM, > > > > Additional pre-authentication required > > > > Feb 28 23:01:41 id1.XX.com krb5kdc[2896](info): AS_REQ (6 etypes {18 > > 17 > > > > 16 23 25 26}) 10.0.1.10: PREAUTH_FAILED: alessandro at XX.COM for krbtgt/ > > > > XX.COM at XX.COM, Incorrect password in encrypted challenge > > > > > > > > I tried syncing the OTP and also creating a new one. > > > > Strangely enough I can connect OK with the VPN supplying password + > > OTP, > > > > but OTP is not working on both freeipa gui and when issuing sudo. > > > > > > > > Could someone help me understand what is going on? > > > > > > > > Regards > > > > Alessandro > > > > > > > > > > > > -- > > > > Alessandro De Maria > > > > alessandro.demaria at gmail.com > > > > > > > > > > > > > > > > -- > > > Manage your subscription for the Freeipa-users mailing list: > > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > Go to http://freeipa.org for more info on the project > > > > > > -- > > Simo Sorce * Red Hat, Inc * New York > > > > > > -- Simo Sorce * Red Hat, Inc * New York