Re: [Freeipa-users] ipa-getkeytab and mandatory password change
On 06/19/2012 07:12 PM, Stephen Ingram wrote: On Tue, Jun 19, 2012 at 9:55 AM, Simo Sorce s...@redhat.com wrote: On Tue, 2012-06-19 at 09:15 -0700, Stephen Ingram wrote: On Tue, Jun 19, 2012 at 2:54 AM, Dmitri Pal d...@redhat.com wrote: On 06/18/2012 11:58 AM, Darran Lofthouse wrote: Just experienced some weird behaviour on my Fedora 17 installation, just wanted to check if this was expected. I have the default config that requires a user to change their password the first time they run kinit. However I created a user and immediately used ipa-getkeytab as this user will be a non-interactive process, despite the ipa-getkeytab resetting the secret for the user the first attempt at authentication failed as the user was still told to change their password. I do not think we have anticipated this use. The ipa-getkeytab is designed for the host and services keytabs not for users. I suggest that use a service principal rather than a user principal to run those jobs. You can also file an RFE to allow keytabs for users if you think that services would not work for you. My expectation would have been that any update to the secret should meet the requirement for the user to change their password. Darren- I'm not sure if you went further with this, but if you do change the password through other means, you then will be able to get a copy of the keytab for the user with ipa-getkeytab. I tried it out because the thought of not being able to get a keytab for a user was concerning. I agree that the service keytabs make more sense for these instances (I was also told this by Simo in another thread), but I keep being told by the application people that I need to use a user principal, which, thankfully works. Ask them why, I am curious about the requirement. What I was trying to achieve was a single Java process obtaining it's own ticket before it connected to a service that was identified by a service principal mapping. In this scenario the client process is just as non-interactive as the server process so both sides were being configured with a keytab. Obtaining the keytab works fine and the client can use it - the only part that was a surprise was that the requirement for the client to change their password remained even though it was now redundant as a keytab had been generated. I'm still waiting for responses. The only thing I've been told thus far is that since there are multiple processes authenticating to their respective servers, it might be difficult to direct each to the proper credential cache. If you use one user to auth to each server process then there is only one credential cache. Steve ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Request for comments - Apache SNI via IPA with kerberos authentication
I'll try and replicate the blog findings in the course of the next couple of days if it works I'll add it to the wiki ... Set up a test this morning using Centos 6: nss-3.13.1-7.el6_2.x86_64 mod_nss-1.0.8-14.el6_2.x86_64 The behaviour was... odd SNI itself must have been working as the contents differed depending on the domain which matched the expectation from the two virtual hosts however there appears to remain certificate selection issues and/or issues with respect to the the behaviour of the NSS options - only the last NSSCertificateDatabase seemed to apply rather than be local to a given VirtualHost (if separating certificate databases) and if in a common database although Apache reported different nicknamed certificates in error_log only the first NSSNickname seemed to be used to obtain the correct certificate... Set up a similar test on Fedora 17: nss-3.13.4-3.fc17.x86_64 mod_nss-1.0.8-17.fc17.x86_64 Same behaviour occurred (not that surprising given the versions) So the short of it is ignore that blog and Rob is right - mod_nss is not ready yet... if you want SNI you need mod_ssl (or mod_gnutls)... if you have FIPS etc requirements or other reasons to use mod_nss then SNI is not at this time possible if you want valid certificates in place... James ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa-getkeytab and mandatory password change
On Wed, 2012-06-20 at 10:01 +0100, Darran Lofthouse wrote: On 06/19/2012 07:12 PM, Stephen Ingram wrote: On Tue, Jun 19, 2012 at 9:55 AM, Simo Sorce s...@redhat.com wrote: On Tue, 2012-06-19 at 09:15 -0700, Stephen Ingram wrote: On Tue, Jun 19, 2012 at 2:54 AM, Dmitri Pal d...@redhat.com wrote: On 06/18/2012 11:58 AM, Darran Lofthouse wrote: Just experienced some weird behaviour on my Fedora 17 installation, just wanted to check if this was expected. I have the default config that requires a user to change their password the first time they run kinit. However I created a user and immediately used ipa-getkeytab as this user will be a non-interactive process, despite the ipa-getkeytab resetting the secret for the user the first attempt at authentication failed as the user was still told to change their password. I do not think we have anticipated this use. The ipa-getkeytab is designed for the host and services keytabs not for users. I suggest that use a service principal rather than a user principal to run those jobs. You can also file an RFE to allow keytabs for users if you think that services would not work for you. My expectation would have been that any update to the secret should meet the requirement for the user to change their password. Darren- I'm not sure if you went further with this, but if you do change the password through other means, you then will be able to get a copy of the keytab for the user with ipa-getkeytab. I tried it out because the thought of not being able to get a keytab for a user was concerning. I agree that the service keytabs make more sense for these instances (I was also told this by Simo in another thread), but I keep being told by the application people that I need to use a user principal, which, thankfully works. Ask them why, I am curious about the requirement. What I was trying to achieve was a single Java process obtaining it's own ticket before it connected to a service that was identified by a service principal mapping. In this scenario the client process is just as non-interactive as the server process so both sides were being configured with a keytab. Obtaining the keytab works fine and the client can use it - the only part that was a surprise was that the requirement for the client to change their password remained even though it was now redundant as a keytab had been generated. Users must obey password policies, that's why I suggest people to use real service keytabs. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Request for comments - Apache SNI via IPA with kerberos authentication
James Hogarth wrote: I'll try and replicate the blog findings in the course of the next couple of days if it works I'll add it to the wiki ... Set up a test this morning using Centos 6: nss-3.13.1-7.el6_2.x86_64 mod_nss-1.0.8-14.el6_2.x86_64 The behaviour was... odd SNI itself must have been working as the contents differed depending on the domain which matched the expectation from the two virtual hosts however there appears to remain certificate selection issues and/or issues with respect to the the behaviour of the NSS options - only the last NSSCertificateDatabase seemed to apply rather than be local to a given VirtualHost (if separating certificate databases) and if in a common database although Apache reported different nicknamed certificates in error_log only the first NSSNickname seemed to be used to obtain the correct certificate... Set up a similar test on Fedora 17: nss-3.13.4-3.fc17.x86_64 mod_nss-1.0.8-17.fc17.x86_64 Same behaviour occurred (not that surprising given the versions) So the short of it is ignore that blog and Rob is right - mod_nss is not ready yet... if you want SNI you need mod_ssl (or mod_gnutls)... if you have FIPS etc requirements or other reasons to use mod_nss then SNI is not at this time possible if you want valid certificates in place... Only one nss database may be opened at a time. mod_nss should probably error out if multiple are defined to prevent confusion. I'd think a nickname should be unique to a given VirtualServer. If not then it's a bug. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Request for comments - Apache SNI via IPA with kerberos authentication
Only one nss database may be opened at a time. mod_nss should probably error out if multiple are defined to prevent confusion. I'd think a nickname should be unique to a given VirtualServer. If not then it's a bug. That makes sense - and yeah it should probably error out rather than just open the last without notice. Pretty sure the NSSNickname issue is a bug - but at this time not sure where that lies exactly given that mod_nss doesn't claim SNI support currently anyway I'm going to let this lie for now to get on with other bits and will probably pick it up again in a weke or so to dig a little deeper (ie use multiple IPs and compare behaviour versus on a single IP etc)... If I can find anything relevant I'll open appropriate tickets with the appropriate parties then. For now (and in the context of this thread) I'll not mention mod_nss and leave the wiki page as is. James ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Updated 389-ds-base released
An update of 389-ds-base has been released which should resolve the
problems that IPA was having. 389-ds-base-1.2.11.5-1.fc17 corrects the
problems we were seeing with managed entries.
Don't forget to remove 389-ds-base from excludes in your yum.conf and/or
use yum versionlock delete 389-ds-base{,-devel,-libs}
regards
rob
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] IPA client ldapsearch
Hi: This is a best practices question. I am really impressed with FreeIPA and I want to make sure that I follow the recommended usage paradigms. What is the best way to do a ldapsearch operation on a FreeIPA client? One approach would be to install LDAP utilities on the client and run ldapsearch. Another approach might be to install the ipa-admintools package on the client. Since all I want to do is a simple query (like ipa user-find on the ipa-server), I wasn't sure whether the ipa-admintools made sense. Thanks, Joe ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] IPA client ldapsearch
Joe Linoff wrote: Hi: This is a best practices question. I am really impressed with FreeIPA and I want to make sure that I follow the recommended usage paradigms. What is the best way to do a ldapsearch operation on a FreeIPA client? One approach would be to install LDAP utilities on the client and run ldapsearch. Another approach might be to install the ipa-admintools package on the client. Since all I want to do is a simple query (like “ipa user-find” on the ipa-server), I wasn’t sure whether the ipa-admintools made sense. Your best bet is to use the ipa-admintools package. This way you don't have to work about the LDAP internals. If you have some need for something the tools can't provide you can always fall back to using ldapsearch. You probably don't to install this on every client. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Do clients have to be in teh same DNS zone / FQDN as the IPA servers / Kerberos Realm?
I assume with no reply, now one knows? regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 From: freeipa-users-boun...@redhat.com [freeipa-users-boun...@redhat.com] on behalf of Steven Jones [steven.jo...@vuw.ac.nz] Sent: Wednesday, 20 June 2012 2:17 p.m. To: freeipa-users@redhat.com Subject: [Freeipa-users] Do clients have to be in teh same DNS zone / FQDN as the IPA servers / Kerberos Realm? My IPA servers are say ipa1 and 2.ipa.example.com I have existing linux servers that I would rather not change the FQDN on, say server1.example.com Do I actually have to make the client server1.ipa.example.com or can I leave it as is at server1.example.com? Would that give any IPA problems? or is it just poor practice? regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Do clients have to be in teh same DNS zone / FQDN as the IPA servers / Kerberos Realm?
Steven Jones wrote: I assume with no reply, now one knows? That's not really fair, it hasn't even been 24 hours. My IPA servers are say ipa1 and 2.ipa.example.com I have existing linux servers that I would rather not change the FQDN on, say server1.example.com Do I actually have to make the client server1.ipa.example.com or can I leave it as is at server1.example.com? Would that give any IPA problems? or is it just poor practice? Yes, you should be able to enroll server1.example.com into the ipa.example.com realm. You'll need a v2.2+ client for this to work. A patch was added (contributed by a user, actually) that will add a domain mapping to krb5.conf so this should work. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Do clients have to be in teh same DNS zone / FQDN as the IPA servers / Kerberos Realm?
Hi, Sorry. but Im getting hammered by my management for instant answers...they asked last night and expect an answer this morning.and I'm expected to catch up and deploy several important solutions/projects all hinging on IPA ASAP... 2.2 isnt in RHEL6.3 though? Anyway I will leave it longer, but Qs seem to drop off the list pretty quickly... regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 From: Rob Crittenden [rcrit...@redhat.com] Sent: Thursday, 21 June 2012 8:31 a.m. To: Steven Jones Cc: freeipa-users@redhat.com Subject: Re: [Freeipa-users] Do clients have to be in teh same DNS zone / FQDN as the IPA servers / Kerberos Realm? Steven Jones wrote: I assume with no reply, now one knows? That's not really fair, it hasn't even been 24 hours. My IPA servers are say ipa1 and 2.ipa.example.com I have existing linux servers that I would rather not change the FQDN on, say server1.example.com Do I actually have to make the client server1.ipa.example.com or can I leave it as is at server1.example.com? Would that give any IPA problems? or is it just poor practice? Yes, you should be able to enroll server1.example.com into the ipa.example.com realm. You'll need a v2.2+ client for this to work. A patch was added (contributed by a user, actually) that will add a domain mapping to krb5.conf so this should work. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] IPA client ldapsearch
Hi Rob: Your best bet is to use the ipa-admintools package. Thank you, I appreciate the help. As you suggested, I will use the ipa-admintools package. You probably don't to install this on every client. That makes sense. Regards, Joe -Original Message- From: Rob Crittenden [mailto:rcrit...@redhat.com] Sent: Wednesday, June 20, 2012 11:26 AM To: Joe Linoff Cc: freeipa-users@redhat.com Subject: Re: [Freeipa-users] IPA client ldapsearch Joe Linoff wrote: Hi: This is a best practices question. I am really impressed with FreeIPA and I want to make sure that I follow the recommended usage paradigms. What is the best way to do a ldapsearch operation on a FreeIPA client? One approach would be to install LDAP utilities on the client and run ldapsearch. Another approach might be to install the ipa-admintools package on the client. Since all I want to do is a simple query (like ipa user-find on the ipa-server), I wasn't sure whether the ipa-admintools made sense. Your best bet is to use the ipa-admintools package. This way you don't have to work about the LDAP internals. If you have some need for something the tools can't provide you can always fall back to using ldapsearch. You probably don't to install this on every client. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] IPA client ldapsearch
Hi, I export an ldif and use jexplorer regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 From: freeipa-users-boun...@redhat.com [freeipa-users-boun...@redhat.com] on behalf of Joe Linoff [jlin...@tabula.com] Sent: Thursday, 21 June 2012 9:24 a.m. To: Rob Crittenden Cc: Joe Linoff; freeipa-users@redhat.com Subject: Re: [Freeipa-users] IPA client ldapsearch Hi Rob: Your best bet is to use the ipa-admintools package. Thank you, I appreciate the help. As you suggested, I will use the ipa-admintools package. You probably don't to install this on every client. That makes sense. Regards, Joe -Original Message- From: Rob Crittenden [mailto:rcrit...@redhat.com] Sent: Wednesday, June 20, 2012 11:26 AM To: Joe Linoff Cc: freeipa-users@redhat.com Subject: Re: [Freeipa-users] IPA client ldapsearch Joe Linoff wrote: Hi: This is a best practices question. I am really impressed with FreeIPA and I want to make sure that I follow the recommended usage paradigms. What is the best way to do a ldapsearch operation on a FreeIPA client? One approach would be to install LDAP utilities on the client and run ldapsearch. Another approach might be to install the ipa-admintools package on the client. Since all I want to do is a simple query (like ipa user-find on the ipa-server), I wasn't sure whether the ipa-admintools made sense. Your best bet is to use the ipa-admintools package. This way you don't have to work about the LDAP internals. If you have some need for something the tools can't provide you can always fall back to using ldapsearch. You probably don't to install this on every client. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa installation problem -- 2
Hi Rob, Client configuration complete. but it says Failed to upload host SSH public keys. Hope it's OK. Thanks a lot, George From: Rob Crittenden rcrit...@redhat.com To: george he george_...@yahoo.com Cc: freeipa-users@redhat.com freeipa-users@redhat.com Sent: Wednesday, June 20, 2012 4:24 PM Subject: Re: [Freeipa-users] ipa installation problem -- 2 george he wrote: Hello all, My first problem was related to firewall, the command iptables -A INPUT -p tcp --dport 80 -j ACCEPT opened port 80 after this line in iptables thus the problem I had. REJECT all -- anywhere anywhere reject-with icmp-host-prohibited Now I have another problem when I run ipa-client-install on the client (after it asked for admin password): Joining realm failed: HTTP response code is 400, not 200 Here are the related lines in /var/log/ipaclient-install.log 2012-06-20T19:46:53Z DEBUG args=/usr/sbin/ipa-join -s cns2.psych.yale.edu -b dc=psych,dc=yale,dc=edu 2012-06-20T19:46:53Z DEBUG stdout= 2012-06-20T19:46:53Z DEBUG stderr=HTTP response code is 400, not 200 Try updating mod_nss to mod_nss.x86_64 0:1.0.8-17.fc17. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
