[Freeipa-users] A couple of quick questions about FreeIPA
Hello I'm trying to figure out if free IPA is a good solution for my environment or if i should just construct a custom infrastructure with 389 server and i just have a couple of quick questions. I have a long history working with LDAPv3 and I'm currently planing a new infrastructure for my current employer. I've worked with OpenLDAP 389 server and even 389 servers original incarnation when Netscape was still around 1) Can the Kerberos server be on an other box. I'm not a python programer so I haven't been able to test it my self but many of the Kerberos calls look like wrappers to the C libraries. if so than it might be possible 2) Can I configure it not to store the Kerberos data in the LDAP server. I don't like the chicken and the egg authentication conundrum this can cause, and I have no intention of allowing users to use LDAPv2 so I actually don't want the password field in the database or at least blocked by an ACL so it cant be used. I personally find the fact that applications still use this field for authentication appalling because it essentially turned back the clock to before shadow password files. 3) This is the most important question, there has been a lot of talk about fixing the issues with MIT Kerberos. Is there someplace I can look To see what the status of these fixes are other than pouring through the change logs for MIT Kerberos. I don't want to get in to a Kerberos holy war but most of these are really old bugs in MIT Kerberos that made me abandon the Idea of ever using the MIT server in production over a decade ago. I know exactly the issues that lead to the Samba group choose to code only to Heimdal all too well because I first remember hitting them and reporting them back 2001 to the Samba group via usenet. The big thing for me is the thread safety because this often caused the MIT Kerberos server to crash then Samba was running in domain mode on the same box, Honestly I still don't trust MIT's implementation in a mission critical environment, ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] A couple of quick questions about FreeIPA
On 04/26/2012 12:57 PM, Paul Robert Marino wrote: Hello I'm trying to figure out if free IPA is a good solution for my environment or if i should just construct a custom infrastructure with 389 server and i just have a couple of quick questions. I have a long history working with LDAPv3 and I'm currently planing a new infrastructure for my current employer. I've worked with OpenLDAP 389 server and even 389 servers original incarnation when Netscape was still around 1) Can the Kerberos server be on an other box. I'm not a python programer so I haven't been able to test it my self but many of the Kerberos calls look like wrappers to the C libraries. if so than it might be possible Currently no, since KDC uses local LDAP calls over ldapi. Can you please explain why KDC on a separate box is a requirement in your case? 2) Can I configure it not to store the Kerberos data in the LDAP server. This defeats the purpose of the solution. The whole point is to make them integrated. If you do not want this you can get any LDAP server and Kerberos and do it yourself. I don't like the chicken and the egg authentication conundrum this can cause, and I have no intention of allowing users to use LDAPv2 so I actually don't want the password field in the database or at least blocked by an ACL so it cant be used. This is all taken care for you in IPA. It is unclear what problem you are trying to solve. LDAP will store userPassword with different strong hashes that can be used for Kerberos auth and for LDAP auth. You can close anonymous bind that we recommend. You can require TLS for simple bind. I personally find the fact that applications still use this field for authentication appalling because it essentially turned back the clock to before shadow password files. There are all sorts of ways to control what kind of authentication is allowed and not expose weaker authentication methods if you do not want to. 3) This is the most important question, there has been a lot of talk about fixing the issues with MIT Kerberos. Is there someplace I can look To see what the status of these fixes are other than pouring through the change logs for MIT Kerberos. Which bugs in particular? I don't want to get in to a Kerberos holy war but most of these are really old bugs in MIT Kerberos that made me abandon the Idea of ever using the MIT server in production over a decade ago. I know exactly the issues that lead to the Samba group choose to code only to Heimdal all too well because I first remember hitting them and reporting them back 2001 to the Samba group via usenet. The big thing for me is the thread safety because this often caused the MIT Kerberos server to crash then Samba was running in domain mode on the same box, Honestly I still don't trust MIT's implementation in a mission critical environment, Are you talking libkrb5? I do not think it is used inside IPA server. KDC is not threaded but LDAP driver (KDC glue to LDAP) is capable of working with multithreaded DS. So far we have not seen any issues there in the whole lifetime of the IPA which is more than 4 years. Generally we have been actively working with MIT and if there are any specific issues that you think are still there and worth solving we would like to hear about them. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] A couple of quick questions about FreeIPA
On Thu, 2012-04-26 at 12:57 -0400, Paul Robert Marino wrote: Hello I'm trying to figure out if free IPA is a good solution for my environment or if i should just construct a custom infrastructure with 389 server and i just have a couple of quick questions. I have a long history working with LDAPv3 and I'm currently planing a new infrastructure for my current employer. I've worked with OpenLDAP 389 server and even 389 servers original incarnation when Netscape was still around 1) Can the Kerberos server be on an other box. I'm not a python programer so I haven't been able to test it my self but many of the Kerberos calls look like wrappers to the C libraries. if so than it might be possible No. Our install scripts support setting up the KDC only locally on the same box for various reasons of simplicity and performance. 2) Can I configure it not to store the Kerberos data in the LDAP server. I don't like the chicken and the egg authentication conundrum this can cause, and I have no intention of allowing users to use LDAPv2 so I actually don't want the password field in the database or at least blocked by an ACL so it cant be used. I personally find the fact that applications still use this field for authentication appalling because it essentially turned back the clock to before shadow password files. No, KDC data is in LDAP, but there is no chicken/egg issue, plus we do not expose userPassword nor any of the krb5 keys to users (keys are exposed to the KDC process of course). You have to use LDAP simple binds or SASL/GSSAPI binds to authenticate when you use IPA. 3) This is the most important question, there has been a lot of talk about fixing the issues with MIT Kerberos. Is there someplace I can look To see what the status of these fixes are other than pouring through the change logs for MIT Kerberos. Plans for what goes in various MIT Kerberos releases are generally available on http://k5wiki.kerberos.org/, but the changelog is the authoritative source of info for what is fixed in current releases. I don't want to get in to a Kerberos holy war but most of these are really old bugs in MIT Kerberos that made me abandon the Idea of ever using the MIT server in production over a decade ago. I know exactly the issues that lead to the Samba group choose to code only to Heimdal all too well because I first remember hitting them and reporting them back 2001 to the Samba group via usenet. The big thing for me is the thread safety because this often caused the MIT Kerberos server to crash then Samba was running in domain mode on the same box, Honestly I still don't trust MIT's implementation in a mission critical environment, MIT Kerberos libraries are thread safe, this has been the case for a long while now. If you have specific questions or doubts feel free to ask. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] What are the main purposes of Dogtag certificate system inside IPA
Hi folks, When evaluating migration from existing seperate LDAP/Kerberos solution to integrated IPA, I got confused on the purposes of Dogtag Certificate system inside IPA. What are the main purposes of it? or what value it brings in to IPA? I can see the points of KDC and 389 Directory server parts, even NTP and DNS, but not for Dogtag. Frankly, I am not sure where I should put it. Say, For Kerberos authentication, I need only /etc/krb5.conf and /etc/krb5.keytab locally on client and then krb5 tools/libs will do their work happily. Then why should I authenticate a machine with certificate, or certificate+keytab -- either way the certificate part is a MUST -- see document http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/hosts.html ( at the very bottom). A close question is: what are the main points/benefits of machine authentication? because of with traditional keytab based kerberos setup, the users, machines and services can authenticate no problem, then why we need an extra authentication with machine certificate as a must? Please help me clarify the question of why the statement 'pkinit_anchors = FILE:/etc/ipa/ca.crt' is put inside krb5.conf after running ipa-client-install script? what is its purposes? Last problem is: after I following the steps at http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/linux-manual.html to setup my Linux client manually, I still can not run 'ipa user-find' command on the client; when another same type linux client installed with 'ipa-client-install' has no problem to run it. Does there are any difference between manual and automatic installations? Sorry I got too many questions and probably more, as I read though the Redhat IPA document serveral times, and every time more questions pop up. :) Thanks a lot. --Robinson ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] A couple of quick questions about FreeIPA
Thank You every one for answering so quickly On Thu, Apr 26, 2012 at 1:20 PM, Simo Sorce s...@redhat.com wrote: On Thu, 2012-04-26 at 12:57 -0400, Paul Robert Marino wrote: Hello I'm trying to figure out if free IPA is a good solution for my environment or if i should just construct a custom infrastructure with 389 server and i just have a couple of quick questions. I have a long history working with LDAPv3 and I'm currently planing a new infrastructure for my current employer. I've worked with OpenLDAP 389 server and even 389 servers original incarnation when Netscape was still around 1) Can the Kerberos server be on an other box. I'm not a python programer so I haven't been able to test it my self but many of the Kerberos calls look like wrappers to the C libraries. if so than it might be possible No. Our install scripts support setting up the KDC only locally on the same box for various reasons of simplicity and performance. I understand the reasoning I just don't like sub components to be too dependent on each other, especially when talking about distributed authentication infrastructures. Ive had instances where a bug in a piece of software (or just a poorly written piece of software) has opened a ridiculous number of connections and caused cascading failures of LDAP servers due to exceeding the max file handle limit on the boxes usually its web apps that do it. In those instances the only thing that bought me enough time to deal with the issues before it caused a serious outage was the fact that my Kerberos servers were not effected and the fact that I had properly tuned nscd on the boxes. I know ssd and pam_nss are planed to completely replace it but I still find nscd very useful, and every place I've seen it cause problems it was because it was never properly tuned e.g. if you have a web server that accepts 1000 or more connections the maximum number of threads being limited to default of 32 is obviously far too low and results in the Apache processes DOSing it. that's how it winds up in states where it eats an entire cpu core and never seems to answer any queries essentially its still working through its backlog of expired queries, and eventually crashes if the problem persists. I also tend to double the deceptively named suggested size for passwd, group, and hosts as i find it significantly improves the hit rate and max number of cached values. 2) Can I configure it not to store the Kerberos data in the LDAP server. I don't like the chicken and the egg authentication conundrum this can cause, and I have no intention of allowing users to use LDAPv2 so I actually don't want the password field in the database or at least blocked by an ACL so it cant be used. I personally find the fact that applications still use this field for authentication appalling because it essentially turned back the clock to before shadow password files. No, KDC data is in LDAP, but there is no chicken/egg issue, plus we do not expose userPassword nor any of the krb5 keys to users (keys are exposed to the KDC process of course). You have to use LDAP simple binds or SASL/GSSAPI binds to authenticate when you use IPA. glad to hear the userPassword is not exposed however many poorly written applications expect to login as a user that can see the field and than do the authentication themselves rather than doing a bind for each user who logs in. even Apaches LDAP auth modules do this, personally I think the idea behind Auth MemCache Cookie sounds close to the ideal way web apps should handle authentication for this kind of thing even for non LDAP auth because it avoids doing a full login for every file downloaded although admittedly I haven't tried that module yet. 3) This is the most important question, there has been a lot of talk about fixing the issues with MIT Kerberos. Is there someplace I can look To see what the status of these fixes are other than pouring through the change logs for MIT Kerberos. Plans for what goes in various MIT Kerberos releases are generally available on http://k5wiki.kerberos.org/, but the changelog is the authoritative source of info for what is fixed in current releases. I don't want to get in to a Kerberos holy war but most of these are really old bugs in MIT Kerberos that made me abandon the Idea of ever using the MIT server in production over a decade ago. I know exactly the issues that lead to the Samba group choose to code only to Heimdal all too well because I first remember hitting them and reporting them back 2001 to the Samba group via usenet. The big thing for me is the thread safety because this often caused the MIT Kerberos server to crash then Samba was running in domain mode on the same box, Honestly I still don't trust MIT's implementation in a mission critical environment, MIT Kerberos libraries are thread safe, this has been the case for a long while now. If you have specific questions or doubts feel free to ask.
[Freeipa-users] IPv6
Hi, FYI, I shutdown IPv6 as we dont do IPv6 and found that IPA wouldnt workslight oops there... 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
Re: [Freeipa-users] A couple of quick questions about FreeIPA
On Thu, 2012-04-26 at 16:52 -0400, Paul Robert Marino wrote: Thank You every one for answering so quickly I understand the reasoning I just don't like sub components to be too dependent on each other, especially when talking about distributed authentication infrastructures. Ive had instances where a bug in a piece of software (or just a poorly written piece of software) has opened a ridiculous number of connections and caused cascading failures of LDAP servers due to exceeding the max file handle limit on the boxes usually its web apps that do it. In those instances the only thing that bought me enough time to deal with the issues before it caused a serious outage was the fact that my Kerberos servers were not effected and the fact that I had properly tuned nscd on the boxes. Use replicas with forntend servers, that way you will at most bring down a replica but not the core infrastructure. I know ssd and pam_nss are planed to completely replace it but I still find nscd very useful, and every place I've seen it cause problems it was because it was never properly tuned e.g. if you have a web server that accepts 1000 or more connections the maximum number of threads being limited to default of 32 is obviously far too low and results in the Apache processes DOSing it. that's how it winds up in states where it eats an entire cpu core and never seems to answer any queries essentially its still working through its backlog of expired queries, and eventually crashes if the problem persists. I also tend to double the deceptively named suggested size for passwd, group, and hosts as i find it significantly improves the hit rate and max number of cached values. Yes, tuning is always important when dealing with network facing services, you will be required to tune your installations in all cases. With sssd we replace nscd simply because it knows better when it make sense to make a query, how to pool queries, and when servers are not reachable and it can immediately answer back. Also we added a shmem bases cache to pam_sss in master that brings performance on par with nscd for the cases where it matters most. glad to hear the userPassword is not exposed however many poorly written applications expect to login as a user that can see the field and than do the authentication themselves rather than doing a bind for each user who logs in. Well we have no magic wand here do we :-) If you have those applications you will have to decide if it is a good idea to relax permissions on userPassword or if it is possible to modify the application or use alternatives. even Apaches LDAP auth modules do this, personally I think the idea behind Auth MemCache Cookie sounds close to the ideal way web apps should handle authentication for this kind of thing even for non LDAP auth because it avoids doing a full login for every file downloaded although admittedly I haven't tried that module yet. Yes, we are planning to eventually extend this method to a usable method for third party apps on other servers through standard APIs, but we are not there yet. Glad to hear that the thread safety was fixed it has been a few years since i looked to that.it use to be quite a serious problem and not just for Samba, FWIW all of samba except libsmbclient is not multi-threaded and is largely non multi-thread safe, so I am not really sure why that would have been an issue there, but it is fixed, and we are all happy now :) for those of you who were familiar with it. it was a libkrb5 issue that was caused usually when a multi-threaded app would try to simultaneously via local socket instead of the network. These condition usually resulted the Kerberos server crashing. A few other samba libraries cough*nss_winbindd*cough were also not thread safe until relatively recently ... this things happen, and they get fixed. I still have to think about it because there are still a few separation things I would like to do that I would still be prohibited from doing on one set of servers like have a second realm and OU just for my network gear. but ill definitely do some experiments before i make my final decision. We are working on cross realm trust as the next big feature, that will allow you to have a separate infrastructure for network gear if you like and still be able to authenticate from one realm to the other. IPA-IPA cross realm is not fully tabled yet, it will come after our first stab at AD-IPA cross realm trust support. 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] IPv6
On Thu, 2012-04-26 at 21:18 +, Steven Jones wrote: Hi, FYI, I shutdown IPv6 as we dont do IPv6 and found that IPA wouldnt workslight oops there... Hi Steve, can you be more explicit on how you 'shutdown' IPv6 ? And can you please tell exactly how IPA breaks in that case ? Is this after IPA is fully installed ? Or does the installer fail ? Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] IPA Bug??: IPA replica installation problem on IPV4-only nodes
IPA Replica installation fails on IPV4 Linux box, The exception/messages on screen are: ... error: [Errno 97] Address family not supported by protocol ... After looking into the python code, it is found out that the IPA program tried to test both IPV4 and IPv6 address families, and it failed there when IPV6 is turned off. So I turn on IPV6 again, try ipa-conncheck again and it works this time. --David From: hshhs caca cao2...@yahoo.com To: freeipa-users@redhat.com freeipa-users@redhat.com Sent: Thursday, April 26, 2012 1:51 PM Subject: [Freeipa-users] What are the main purposes of Dogtag certificate system inside IPA Hi folks, When evaluating migration from existing seperate LDAP/Kerberos solution to integrated IPA, I got confused on the purposes of Dogtag Certificate system inside IPA. What are the main purposes of it? or what value it brings in to IPA? I can see the points of KDC and 389 Directory server parts, even NTP and DNS, but not for Dogtag. Frankly, I am not sure where I should put it. Say, For Kerberos authentication, I need only /etc/krb5.conf and /etc/krb5.keytab locally on client and then krb5 tools/libs will do their work happily. Then why should I authenticate a machine with certificate, or certificate+keytab -- either way the certificate part is a MUST -- see document http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/hosts.html ( at the very bottom). A close question is: what are the main points/benefits of machine authentication? because of with traditional keytab based kerberos setup, the users, machines and services can authenticate no problem, then why we need an extra authentication with machine certificate as a must? Please help me clarify the question of why the statement 'pkinit_anchors = FILE:/etc/ipa/ca.crt' is put inside krb5.conf after running ipa-client-install script? what is its purposes? Last problem is: after I following the steps at http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/linux-manual.html to setup my Linux client manually, I still can not run 'ipa user-find' command on the client; when another same type linux client installed with 'ipa-client-install' has no problem to run it. Does there are any difference between manual and automatic installations? Sorry I got too many questions and probably more, as I read though the Redhat IPA document serveral times, and every time more questions pop up. :) Thanks a lot. --Robinson ___ 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] Manually installed IPA clients failes to run 'ipa user-find', 'ipa host-find', etc.
On Thu, Apr 26, 2012 at 3:51 PM, hshhs caca cao2...@yahoo.com wrote:
Hi folks,
I'm pretty new to freeIPA. And here is a freeIPA installation problem
encountered in my work. For company policies reasons we can not use
ipa-client-install on Linux clients, instead manual installation method is
in use and most of the freeIPA client config files are pushed out with
cfengine. The problem details/steps are listed below:
1, following the steps at
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/linux-manual.html,
we registered all clients in IPA master, created and downloaded into
subversion the keytab files for all clients, then use 'ipa-client-install'
on one clients and save the config files into subversion too.
2, when a new Linux node is newly deployed, we deploy the files below onto
the nodes: /etc/{krb5.conf, krb5.keytab,nsswitch.conf}, /etc/sssd/sssd.conf,
/etc/pam.d/{fingerprint-auth-ac, password-auth-ac, system-auth-ac,
smartcard-auth-ac}, with permissions and ownership setup correctly.
3, then we tested kerberos commands kinit/kdestroy/klist and they were all
working; we tested 'getent passwd ipaAccount', 'getent group ipausers' and
they were working too, at last we tried ssh/login and they were working as
expected as well.
4, at this step I could claim that IPA authentication and authorization
worked successfully. Then I continued to try IPA admin command but
unexpected them failed.
[root@ipaclient04 ~]# ipa
ipa: ERROR: Client is not configured. Run ipa-client-install.
[root@ipaclient04 ~]# ipa user-find
ipa: ERROR: Client is not configured. Run ipa-client-install.
[root@ipaclient04 ~]#
5, so I copied the files /etc/ca.crt and /etc/default.conf from a client
installed with 'ipa-client-install' to this manual client, and tried the
above command again and them stopped whiling and showed help screen as
expected; but real IPA administration commands failed with the following
error prompts:
[root@ipaclient04 ~]# ipa user-find
ipa: ERROR: cert validation failed for
CN=ipamaster.pegaclouds.com,O=PEGACLOUDS.COM ((SEC_ERROR_UNTRUSTED_ISSUER)
Peer's certificate issuer has been marked as not trusted by the user.)
ipa: ERROR: cannot connect to u'https://ipamaster.pegaclouds.com/ipa/xml':
[Errno -8172] (SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has
been marked as not trusted by the user.
6, So it looks like there are some kinds of new authentication steps I have
missed somewhere -- could not find any clue on the Redhat IPA document for
further steps -- I tried several times but results are not fruitful. Could
anyone please shed a light at here? Thanks a lot.
David-
It looks like you didn't import the CA into the host certificate store
in /etc/pki/nssdb. I believe those commands require that you trust
your IPA CA. You can import the CA with:
certutil -A -d /etc/pki/nssdb -n 'IPA CA' -t CT,C,C -a -i /etc/ipa/ca.crt
Also, make sure and generate a host cert for the machine (also in
/etc/pki/nssdb) and have IPA sign it.
Steve
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Manually installed IPA clients failes to run 'ipa user-find', 'ipa host-find', etc.
Hi, Stephen,
Thanks for your reply, and it works great, though I still have one question
around the host cert -- what are the typical usage senarios of host cert for
IPA clients?
On 4/26/12 6:01 PM, Stephen Ingram sbing...@gmail.com wrote:
On Thu, Apr 26, 2012 at 3:51 PM, hshhs caca cao2...@yahoo.com wrote:
Hi folks,
I'm pretty new to freeIPA. And here is a freeIPA installation problem
encountered in my work. For company policies reasons we can not use
ipa-client-install on Linux clients, instead manual installation method is
in use and most of the freeIPA client config files are pushed out with
cfengine. The problem details/steps are listed below:
1, following the steps at
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/linux-manual.html,
we registered all clients in IPA master, created and downloaded into
subversion the keytab files for all clients, then use 'ipa-client-install'
on one clients and save the config files into subversion too.
2, when a new Linux node is newly deployed, we deploy the files below onto
the nodes: /etc/{krb5.conf, krb5.keytab,nsswitch.conf}, /etc/sssd/sssd.conf,
/etc/pam.d/{fingerprint-auth-ac, password-auth-ac, system-auth-ac,
smartcard-auth-ac}, with permissions and ownership setup correctly.
3, then we tested kerberos commands kinit/kdestroy/klist and they were all
working; we tested 'getent passwd ipaAccount', 'getent group ipausers'
and
they were working too, at last we tried ssh/login and they were working as
expected as well.
4, at this step I could claim that IPA authentication and authorization
worked successfully. Then I continued to try IPA admin command but
unexpected them failed.
[root@ipaclient04 ~]# ipa
ipa: ERROR: Client is not configured. Run ipa-client-install.
[root@ipaclient04 ~]# ipa user-find
ipa: ERROR: Client is not configured. Run ipa-client-install.
[root@ipaclient04 ~]#
[root@ipaclient04 ~]# ipa user-find
ipa: ERROR: cert validation failed for
CN=ipamaster.pegaclouds.com,O=PEGACLOUDS.COM ((SEC_ERROR_UNTRUSTED_ISSUER)
Peer's certificate issuer has been marked as not trusted by the user.)
ipa: ERROR: cannot connect to u'https://ipamaster.pegaclouds.com/ipa/xml':
[Errno -8172] (SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has
been marked as not trusted by the user.
6, So it looks like there are some kinds of new authentication steps I have
missed somewhere -- could not find any clue on the Redhat IPA document for
further steps -- I tried several times but results are not fruitful. Could
anyone please shed a light at here? Thanks a lot.
David-
It looks like you didn't import the CA into the host certificate store
in /etc/pki/nssdb. I believe those commands require that you trust
your IPA CA. You can import the CA with:
certutil -A -d /etc/pki/nssdb -n 'IPA CA' -t CT,C,C -a -i /etc/ipa/ca.crt
That is the magic finger!! and the IPA commands 'ipa user-find', 'ipa
host-add', etc
works without a glitch.
Also, make sure and generate a host cert for the machine (also in
/etc/pki/nssdb) and have IPA sign it.
I have to fire up service messagebus, certmonger, and then run 'ipa-getcert
request'
command to generate a CSR, send it to IPA Master to sign it, save certificate
at IPA master,
and save the host private key / certificate locally inder /etc/pki/nssdb.
So what are the benefits of host certificates? bascically what are the usage
senarios to allure
users to go though these efforts to register and renew a host certicate? I am
new to host certificate
(not httpd SSL certificate) and really not sure where they can be helpful.
Thanks.
--David
5, so I copied the files /etc/ca.crt and /etc/default.conf from a client
installed with 'ipa-client-install' to this manual client, and tried the
above command again and them stopped whiling and showed help screen as
expected; but real IPA administration commands failed with the following
error prompts:
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Problem: How to download the keytab from IPA without resetting/regenerating a new one??
Hi, Just have a silly case where I've to download the existing version keytab for a service principal. It is download only -- not recreate a new version and download the new version which ipa-getkeytab does. -- ipa-getkeytab command name seems a little bit misleading because it does both 'set' and 'get' operations. I've overheard that there is way to get it from underlying 389 directory server but not sure how to do it. Any one please shed a light on this? Similarly, how to download a host certificate form Dogtag because 'ipa-getcert request' also resetting it -- I may be wrong and so please feel free to correct me :); or how about a user principal's keytab from 389 too? Thanks a lot. --David ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
