[Freeipa-users] Unable to start IPA server after server reboot
Hi list,
I have a problem with my IPA server:
Symptoms:
[root@polaris etc]# /etc/init.d/ipa start
Starting Directory Service
Starting dirsrv:
EXAMPLE-COM... [ OK ]
PKI-IPA... [ OK ]
Failed to read data from Directory Service: Unknown error when retrieving list of services from LDAP: {'matched':
'cn=masters,cn=ipa,cn=etc,dc=example,dc=com', 'desc': 'No such object'}
Shutting down
Shutting down dirsrv:
EXAMPLE-COM... [ OK ]
PKI-IPA... [ OK ]
I am able to start the services (dirsrv, named, krb5kdc) separately though and
then read the configuration fine:
[root@polaris log]# kinit admin
Password for ad...@example.com:
[root@polaris etc]# ldapsearch -Y GSSAPI -h localhost -b
cn=masters,cn=ipa,cn=etc,dc=example,dc=com
SASL/GSSAPI authentication started
SASL username: ad...@example.com
SASL SSF: 56
SASL data security layer installed.
# extended LDIF
#
# LDAPv3
# base with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
# masters, ipa, etc, example.com
dn: cn=masters,cn=ipa,cn=etc,dc=example,dc=com
objectClass: nsContainer
objectClass: top
cn: masters
# polaris.example.com, masters, ipa, etc, example.com
dn: cn=polaris.example.com,cn=masters,cn=ipa,cn=etc,dc=example,dc=com
objectClass: top
objectClass: nsContainer
cn: polaris.example.com
# CA, polaris.example.com, masters, ipa, etc, example.com
dn: cn=CA,cn=polaris.example.com,cn=masters,cn=ipa,cn=etc,dc=example,dc=com
objectClass: nsContainer
objectClass: ipaConfigObject
objectClass: top
ipaConfigString: enabledService
ipaConfigString: startOrder 50
cn: CA
.
Does it ring any bell to you?
Note that the IPA server was running fine right after the installation
Thanks!
Ondrej
The information contained in this e-mail and in any attachments is confidential
and is designated solely for the attention of the intended recipient(s). If you
are not an intended recipient, you must not use, disclose, copy, distribute or
retain this e-mail or any part thereof. If you have received this e-mail in
error, please notify the sender by return e-mail and delete all copies of this
e-mail from your computer system(s).
Please direct any additional queries to: communicati...@s3group.com.
Thank You.
Silicon and Software Systems Limited (S3 Group). Registered in Ireland no.
378073.
Registered Office: South County Business Park, Leopardstown, Dublin 18___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] FreeIPA for Linux desktop deployment
Robert M. Albrecht wrote: Hi, any ideas ? Something I can help with ? Your best bet is to add yourself as a cc onto bug https://bugzilla.redhat.com/show_bug.cgi?id=725577 and include information on your crash. regards rob cu romal Am 28.07.11 07:11, schrieb Robert M. Albrecht: Hi, my IPA is still dying. Strange thing is,it's very random. Most times is stops after some minutes, but yesterday named worked for several hours. If it helps, I can provide shell access to the system. cu romal Am 26.07.11 19:26, schrieb nasir nasir: Hi all, After applying the patches and restarting the service, everything was fine for about couple of hours. But again it crashed and gave core dump. I have updated the latest /var/log/messages and core dump with the bugzilla report. Please help. Regards, Nidal --- On Tue, 7/26/11, Adam Tkac wrote: From: Adam Tkac Subject: Re: [Freeipa-users] FreeIPA for Linux desktop deployment To: "nasir nasir" Cc: freeipa-users@redhat.com, "Robert M. Albrecht" Date: Tuesday, July 26, 2011, 7:58 AM On 07/26/2011 04:51 PM, nasir nasir wrote: Hi All, Thanks a ton for every one who helped to have such a quick fix for this issue. I truly appreciate it. I have applied the patch (generated from the source rpm and applied with rpm -Uvh ***) and restarted IPA service. Had a preliminary test of the services and everything seems to be fine. Will keep watching and update the list in due course. Adam, Do you want me to update the bugzilla now or wait for a couple of days to observe ? Thanks for your feedback, you don't have to update bugzilla, update it only in case if named crashes again, please. For now I will consider the patch as correct. Regards, Adam ___ 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 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Unable to start IPA server after server reboot
Ondrej Valousek wrote:
Hi list,
I have a problem with my IPA server:
Symptoms:
[root@polaris etc]# /etc/init.d/ipa start
Starting Directory Service
Starting dirsrv:
EXAMPLE-COM... [ OK ]
PKI-IPA... [ OK ]
Failed to read data from Directory Service: Unknown error when
retrieving list of services from LDAP: {'matched':
'cn=masters,cn=ipa,cn=etc,dc=example,dc=com', 'desc': 'No such object'}
Shutting down
Shutting down dirsrv:
EXAMPLE-COM... [ OK ]
PKI-IPA... [ OK ]
I am able to start the services (dirsrv, named, krb5kdc) separately
though and then read the configuration fine:
[root@polaris log]# kinit admin
Password for ad...@example.com:
[root@polaris etc]# ldapsearch -Y GSSAPI -h localhost -b
cn=masters,cn=ipa,cn=etc,dc=example,dc=com
SASL/GSSAPI authentication started
SASL username: ad...@example.com
SASL SSF: 56
SASL data security layer installed.
# extended LDIF
#
# LDAPv3
# base with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
# masters, ipa, etc, example.com
dn: cn=masters,cn=ipa,cn=etc,dc=example,dc=com
objectClass: nsContainer
objectClass: top
cn: masters
# polaris.example.com, masters, ipa, etc, example.com
dn: cn=polaris.example.com,cn=masters,cn=ipa,cn=etc,dc=example,dc=com
objectClass: top
objectClass: nsContainer
cn: polaris.example.com
# CA, polaris.example.com, masters, ipa, etc, example.com
dn: cn=CA,cn=polaris.example.com,cn=masters,cn=ipa,cn=etc,dc=example,dc=com
objectClass: nsContainer
objectClass: ipaConfigObject
objectClass: top
ipaConfigString: enabledService
ipaConfigString: startOrder 50
cn: CA
.
Does it ring any bell to you?
Note that the IPA server was running fine right after the installation
Is your hostname set to polaris.example.com or polaris (check
/etc/sysconfig/network).
What we search for is cn=$FQDN,cn=masters,cn=etc
That explains the matched part. It matched everything except the hostname.
rob
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Unable to start IPA server after server reboot
Hi Rob, It was just "polaris" - so I tried: [root@polaris etc]# hostname polaris.example.com and it started working - Magic! That means that we rely on the fact that hostname is set to FQDN, right? Isn't it too strong requirement? Maybe we should guess FQDN using reverse lookups I do not know. The bottom line is that at least the IPA installation script should warn about the incorrect hostname. And the error message was bit confusing as well, because from that one none can even guess what went wrong, I even tried to add 'ipactl -d start' to print more debugging, but it did not help either. Just trying to bring some ideas, otherwise I am happy that it is working again for me :-) Thanks! Ondrej On 02.08.2011 15:18, Rob Crittenden wrote: Is your hostname set to polaris.example.com or polaris (check /etc/sysconfig/network). What we search for is cn=$FQDN,cn=masters,cn=etc That explains the matched part. It matched everything except the hostname. rob The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communicati...@s3group.com. Thank You. Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] version mismatch while joining a client ?
Steven Jones wrote: Yesenrolement now fails, previous messages I attached show that I think, it used to work. History, I had to remove all my working IPA clients due to a disk space problem on our SAN (we didnt have any). So I managed to keep the working IPA server and 2 x RHEL5 64 bit servers and the one un-configured template of RHEL6.1 64bit client I had. This I used to make client side clones off previously and connected them to IPA server and they worked. So lastweek I went back and with a running ipa server, I cloned in the old client/template and got the mis-match, so I put them on the production network and patched, same mismatch problem. I can do a sosreport of the old template I think and the client to look at the differences if that helps. I'm having a hard time following exactly what you are doing, on what machine. I think we need to be more systematic. Can you choose a machine to act as the client and provide the following: - distro and architecture (e.g. RHEL 6.1 on x86_64) - rpm -q curl libcurl - rpm -q ipa-client On the IPA server: - rpm -q ipa-server Start with a client that is not enrolled. If it has previously been enrolled run: ipa-client-install --uninstall -U Now run ipa-client-install and answer the questions as appropriate for your install. If it fails please provide the following: - any stdout you get from the client install - attach the full /var/log/ipaclient-install.log - attach the last 100 lines from /var/log/httpd/error_log from the IPA server rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Unable to start IPA server after server reboot
On 08/02/2011 09:42 AM, Ondrej Valousek wrote: Hi Rob, It was just "polaris" - so I tried: [root@polaris etc]# hostname polaris.example.com and it started working - Magic! That means that we rely on the fact that hostname is set to FQDN, right? Isn't it too strong requirement? Maybe we should guess FQDN using reverse lookups I do not know. The bottom line is that at least the IPA installation script should warn about the incorrect hostname. This actually brought a chucklewe've been through a few iterations of how to deal with this. The approach did do Reverse at one point, but that brought in a few other issues. Needless to say, we've felt your pain on numerous occasions. Kerberos depends on the hostname being right, and none of the auth works without Kerberos. This is an issue that seems to mess people up in testing and evaluation mode, but people want and need it to resolve correctly in live environments. And the error message was bit confusing as well, because from that one none can even guess what went wrong, I even tried to add 'ipactl -d start' to print more debugging, but it did not help either. Just trying to bring some ideas, otherwise I am happy that it is working again for me :-) Thanks! Ondrej On 02.08.2011 15:18, Rob Crittenden wrote: Is your hostname set to polaris.example.com or polaris (check /etc/sysconfig/network). What we search for is cn=$FQDN,cn=masters,cn=etc That explains the matched part. It matched everything except the hostname. rob The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communicati...@s3group.com. Thank You. Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18 ___ Freeipa-users mailing list Freeipa-users@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] Unable to start IPA server after server reboot
On 08/02/2011 08:04 AM, Adam Young wrote: On 08/02/2011 09:42 AM, Ondrej Valousek wrote: Hi Rob, It was just "polaris" - so I tried: [root@polaris etc]# hostname polaris.example.com and it started working - Magic! That means that we rely on the fact that hostname is set to FQDN, right? Isn't it too strong requirement? Maybe we should guess FQDN using reverse lookups I do not know. The bottom line is that at least the IPA installation script should warn about the incorrect hostname. This actually brought a chucklewe've been through a few iterations of how to deal with this. The approach did do Reverse at one point, but that brought in a few other issues. Needless to say, we've felt your pain on numerous occasions. Kerberos depends on the hostname being right, and none of the auth works without Kerberos. This is an issue that seems to mess people up in testing and evaluation mode, but people want and need it to resolve correctly in live environments. Most TLS/SSL implementations want to use the fqdn as well e.g. server certs will have cn=fqdn,something... as the Subject: in the cert. And the error message was bit confusing as well, because from that one none can even guess what went wrong, I even tried to add 'ipactl -d start' to print more debugging, but it did not help either. Just trying to bring some ideas, otherwise I am happy that it is working again for me :-) Thanks! Ondrej On 02.08.2011 15:18, Rob Crittenden wrote: Is your hostname set to polaris.example.com or polaris (check /etc/sysconfig/network). What we search for is cn=$FQDN,cn=masters,cn=etc That explains the matched part. It matched everything except the hostname. rob The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communicati...@s3group.com. Thank You. Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18 ___ Freeipa-users mailing list Freeipa-users@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 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Unable to start IPA server after server reboot
Ondrej Valousek wrote: Hi Rob, It was just "polaris" - so I tried: [root@polaris etc]# hostname polaris.example.com and it started working - Magic! That means that we rely on the fact that hostname is set to FQDN, right? Isn't it too strong requirement? Maybe we should guess FQDN using reverse lookups I do not know. The bottom line is that at least the IPA installation script should warn about the incorrect hostname. And the error message was bit confusing as well, because from that one none can even guess what went wrong, I even tried to add 'ipactl -d start' to print more debugging, but it did not help either. Just trying to bring some ideas, otherwise I am happy that it is working again for me :-) Thanks! Ondrej Kerberos and SSL really want fully-qualified names. We've done some upstream work to address detecting when the hostname is not a fqdn. I filed a new ticket for the poor error message. thanks for the suggestions. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Unknown user pkisrv
Hi, from /var/log/messages Aug 2 18:03:14 zerberus systemd-tmpfiles[2148]: [/etc/tmpfiles.d/dirsrv-PKI-IPA.conf:1] Unknown user 'pkisrv'. Aug 2 18:03:14 zerberus systemd-tmpfiles[2148]: [/etc/tmpfiles.d/dirsrv-PKI-IPA.conf:2] Unknown user 'pkisrv'. Aug 2 18:03:14 zerberus systemd-tmpfiles[2148]: [/etc/tmpfiles.d/dirsrv-PKI-IPA.conf:3] Unknown user 'pkisrv'. Aug 2 18:03:14 zerberus systemd-tmpfiles[2148]: Two or more conflicting lines for /var/run/dirsrv configured, ignoring. Aug 2 18:03:14 zerberus systemd-tmpfiles[2148]: Two or more conflicting lines for /var/lock/dirsrv configured, ignoring. Aug 2 18:03:14 zerberus systemd[1]: systemd-tmpfiles-clean.service: main process exited, code=exited, status=1 Aug 2 18:03:14 zerberus systemd[1]: Unit systemd-tmpfiles-clean.service entered failed state. Is this normal ? cu romal ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Use of FreeIPA or FreeIPA LDAP server to hold private keys
Is there some mechanism to store private keys (e.g. ssh, pgp, gpg, X.509) in FreeIPA, tied to a user account, so only the user (via kerb token or with password prompt) can fetch the token? If FreeIPA doesn't make this possible, can anyone suggest a good mechanism to have, effectively, a user keystore that would sync passwords with FreeIPA nicely. I am thinking, in particular, of the scenario where users forget their password -- we'd strongly prefer to just reset it for them (24 hours, one login) in a way that didn't mean also re-issuing all passphrase-secured identity tokens. Thanks, Ian <>___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Unknown user pkisrv
On 08/02/2011 10:20 AM, Robert M. Albrecht wrote: Hi, from /var/log/messages Aug 2 18:03:14 zerberus systemd-tmpfiles[2148]: [/etc/tmpfiles.d/dirsrv-PKI-IPA.conf:1] Unknown user 'pkisrv'. Aug 2 18:03:14 zerberus systemd-tmpfiles[2148]: [/etc/tmpfiles.d/dirsrv-PKI-IPA.conf:2] Unknown user 'pkisrv'. Aug 2 18:03:14 zerberus systemd-tmpfiles[2148]: [/etc/tmpfiles.d/dirsrv-PKI-IPA.conf:3] Unknown user 'pkisrv'. Aug 2 18:03:14 zerberus systemd-tmpfiles[2148]: Two or more conflicting lines for /var/run/dirsrv configured, ignoring. Aug 2 18:03:14 zerberus systemd-tmpfiles[2148]: Two or more conflicting lines for /var/lock/dirsrv configured, ignoring. Aug 2 18:03:14 zerberus systemd[1]: systemd-tmpfiles-clean.service: main process exited, code=exited, status=1 Aug 2 18:03:14 zerberus systemd[1]: Unit systemd-tmpfiles-clean.service entered failed state. Is this normal ? No. Did you use any sort of ipa-remove or ipa-delete command that would have removed or deleted ipa components? Beginning with Fedora 15, 389 has support for tmpfiles.d - running setup-ds.pl will create the necessary files, and running remove-ds.pl will remove them. I don't think ipa uses remove-ds.pl so it might have left these files around. If /etc/dirsrv/slapd-PKI-IPA does not exist, you can remove /etc/tmpfiles.d/dirsrv-PKI-IPA* cu romal ___ 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] Use of FreeIPA or FreeIPA LDAP server to hold private keys
On 08/02/2011 02:15 PM, Ian Stokes-Rees wrote: > Is there some mechanism to store private keys (e.g. ssh, pgp, gpg, > X.509) in FreeIPA, tied to a user account, so only the user (via kerb > token or with password prompt) can fetch the token? > > If FreeIPA doesn't make this possible, can anyone suggest a good > mechanism to have, effectively, a user keystore that would sync > passwords with FreeIPA nicely. I am thinking, in particular, of the > scenario where users forget their password -- we'd strongly prefer to > just reset it for them (24 hours, one login) in a way that didn't mean > also re-issuing all passphrase-secured identity tokens. > Not now however: https://fedorahosted.org/freeipa/ticket/754 https://fedorahosted.org/freeipa/ticket/237 https://fedorahosted.org/freeipa/ticket/521 There are also some thoughts and ideas about IPA as a secure vault for other credentials in other systems which is not logged as a ticket. Would you mind sharing with us your ideas about this functionality actually should work? Use cases, examples and design ideas are very welcome. > Thanks, > > Ian > > > ___ > 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] Use of FreeIPA or FreeIPA LDAP server to hold private keys
On Tue, 2011-08-02 at 16:27 -0400, Dmitri Pal wrote: > On 08/02/2011 02:15 PM, Ian Stokes-Rees wrote: > > Is there some mechanism to store private keys (e.g. ssh, pgp, gpg, > > X.509) in FreeIPA, tied to a user account, so only the user (via > > kerb token or with password prompt) can fetch the token? > > > > If FreeIPA doesn't make this possible, can anyone suggest a good > > mechanism to have, effectively, a user keystore that would sync > > passwords with FreeIPA nicely. I am thinking, in particular, of the > > scenario where users forget their password -- we'd strongly prefer > > to just reset it for them (24 hours, one login) in a way that didn't > > mean also re-issuing all passphrase-secured identity tokens. > > > > Not now however: > https://fedorahosted.org/freeipa/ticket/754 > https://fedorahosted.org/freeipa/ticket/237 > https://fedorahosted.org/freeipa/ticket/521 Replaced the last one with: https://fedorahosted.org/freeipa/ticket/1560 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] version mismatch while joining a client ?
Hi,
Client
==
rhel61-64cl04.unix.vuw.ac.nz
Linux rhel61-64cl04.unix.vuw.ac.nz 2.6.32-131.6.1.el6.x86_64 #1 SMP Mon Jun 20
14:15:38 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux
ipa-client-2.0.0-23.el6_1.1.x86_64
libcurl-7.19.7-26.el6.x86_64
Red Hat Enterprise Linux Client release 6.1 (Santiago)
==
Server
==
Linux vuwunicoipamt01 2.6.32-131.6.1.el6.x86_64 #1 SMP Mon Jun 20 14:15:38 EDT
2011 x86_64 x86_64 x86_64 GNU/Linux
libcurl-7.19.7-26.el6_1.1.x86_64
ipa-client-2.0.0-23.el6_1.1.x86_64
ipa-server-2.0.0-23.el6_1.1.x86_64
Red Hat Enterprise Linux Server release 6.1 (Santiago)
==
install output
==
[root@rhel61-64cl04 ~]# ipa-client-install --mkhomedir --server
vuwunicoipamt01.unix.vuw.ac.nz --domain unix.vuw.ac.nz -d
root: DEBUG/usr/sbin/ipa-client-install was invoked with options:
{'conf_ntp': True, 'domain': 'unix.vuw.ac.nz', 'uninstall': False, 'force':
False, 'sssd': True, 'hostname': None, 'permit': False, 'server':
'vuwunicoipamt01.unix.vuw.ac.nz', 'prompt_password': False, 'realm_name': None,
'dns_updates': False, 'debug': True, 'on_master': False, 'ntp_server': None,
'mkhomedir': True, 'unattended': None, 'principal': None}
root: DEBUGmissing options might be asked for interactively later
root: DEBUGLoading Index file from
'/var/lib/ipa-client/sysrestore/sysrestore.index'
root: DEBUG[ipacheckldap]
root: DEBUGargs=/usr/bin/wget -O /tmp/tmpaaTaqF/ca.crt
http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt
root: DEBUGstdout=
root: DEBUGstderr=--2011-08-03 09:01:14--
http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt
Resolving vuwunicoipamt01.unix.vuw.ac.nz... 130.195.87.236
Connecting to vuwunicoipamt01.unix.vuw.ac.nz|130.195.87.236|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 779 [application/x-x509-ca-cert]
Saving to: `/tmp/tmpaaTaqF/ca.crt'
0K 100% 132M=0s
2011-08-03 09:01:14 (132 MB/s) - `/tmp/tmpaaTaqF/ca.crt' saved [779/779]
root: DEBUGInit ldap with: ldap://vuwunicoipamt01.unix.vuw.ac.nz:389
root: DEBUGSearch rootdse
root: DEBUGSearch for (info=*) in dc=unix,dc=vuw,dc=ac,dc=nz(base)
root: DEBUGFound: [('dc=unix,dc=vuw,dc=ac,dc=nz', {'objectClass':
['top', 'domain', 'pilotObject', 'nisDomainObject', 'domainRelatedObject'],
'info': ['IPA V2.0'], 'associatedDomain': ['unix.vuw.ac.nz'], 'dc': ['unix'],
'nisDomain': ['unix.vuw.ac.nz']})]
root: DEBUGSearch for (objectClass=krbRealmContainer) in
dc=unix,dc=vuw,dc=ac,dc=nz(sub)
root: DEBUGFound:
[('cn=UNIX.VUW.AC.NZ,cn=kerberos,dc=unix,dc=vuw,dc=ac,dc=nz', {'krbSubTrees':
['dc=unix,dc=vuw,dc=ac,dc=nz'], 'cn': ['UNIX.VUW.AC.NZ'],
'krbDefaultEncSaltTypes': ['aes256-cts:special', 'aes128-cts:special',
'des3-hmac-sha1:special', 'arcfour-hmac:special'], 'objectClass': ['top',
'krbrealmcontainer', 'krbticketpolicyaux'], 'krbSearchScope': ['2'],
'krbSupportedEncSaltTypes': ['aes256-cts:normal', 'aes256-cts:special',
'aes128-cts:normal', 'aes128-cts:special', 'des3-hmac-sha1:normal',
'des3-hmac-sha1:special', 'arcfour-hmac:normal', 'arcfour-hmac:special',
'des-hmac-sha1:normal', 'des-cbc-md5:normal', 'des-cbc-crc:normal',
'des-cbc-crc:v4', 'des-cbc-crc:afs3'], 'krbMaxTicketLife': ['86400'],
'krbMaxRenewableAge': ['604800']})]
root: DEBUGwill use domain: unix.vuw.ac.nz
root: DEBUGwill use server: vuwunicoipamt01.unix.vuw.ac.nz
Discovery was successful!
root: DEBUGwill use cli_realm: UNIX.VUW.AC.NZ
root: DEBUGwill use cli_basedn: dc=unix,dc=vuw,dc=ac,dc=nz
Hostname: rhel61-64cl04.unix.vuw.ac.nz
Realm: UNIX.VUW.AC.NZ
DNS Domain: unix.vuw.ac.nz
IPA Server: vuwunicoipamt01.unix.vuw.ac.nz
BaseDN: dc=unix,dc=vuw,dc=ac,dc=nz
Continue to configure the system with these values? [no]: yes
Enrollment principal: admin
root: DEBUGwill use principal: admin
root: DEBUGargs=/usr/bin/wget -O /etc/ipa/ca.crt
http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt
root: DEBUGstdout=
root: DEBUGstderr=--2011-08-03 09:01:22--
http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt
Resolving vuwunicoipamt01.unix.vuw.ac.nz... 130.195.87.236
Connecting to vuwunicoipamt01.unix.vuw.ac.nz|130.195.87.236|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 779 [application/x-x509-ca-cert]
Saving to: `/etc/ipa/ca.crt'
0K 100% 96.5M=0s
2011-08-03 09:01:22 (96.5 MB/s) - `/etc/ipa/ca.crt' saved [779/779]
Password for ad...@unix.vuw.ac.nz:
root: DEBUGargs=kinit ad...@unix.vuw.ac.nz
root: DEBUGstdout=Password for ad...@unix.vuw.ac.nz:
root: DEBUGstderr=
root: DEBUGargs=/usr/sbin/ipa-join -s
vuwunicoipamt01.unix.vuw.ac.nz -d
root: DEBUG
Re: [Freeipa-users] Use of FreeIPA or FreeIPA LDAP server to hold private keys
On 8/2/11 4:27 PM, Dmitri Pal wrote: > On 08/02/2011 02:15 PM, Ian Stokes-Rees wrote: >> Is there some mechanism to store private keys (e.g. ssh, pgp, gpg, >> X.509) in FreeIPA, tied to a user account, so only the user (via kerb >> token or with password prompt) can fetch the token? >> >> If FreeIPA doesn't make this possible, can anyone suggest a good >> mechanism to have, effectively, a user keystore that would sync >> passwords with FreeIPA nicely. I am thinking, in particular, of the >> scenario where users forget their password -- we'd strongly prefer to >> just reset it for them (24 hours, one login) in a way that didn't >> mean also re-issuing all passphrase-secured identity tokens. >> > > Not now however: > https://fedorahosted.org/freeipa/ticket/754 > https://fedorahosted.org/freeipa/ticket/237 > https://fedorahosted.org/freeipa/ticket/521 > > There are also some thoughts and ideas about IPA as a secure vault for > other credentials in other systems which is not logged as a ticket. > > > Would you mind sharing with us your ideas about this functionality > actually should work? > Use cases, examples and design ideas are very welcome. Is there any standard to keystores? It would be great if Linux, Mac, Windows could all be pointed at an FreeIPA to fetch credentials, usernames, passwords. Authentication could use kerberos tickets if available, otherwise prompt for username/password, or have configurable authentication policies. Users and administrators could set ACL policies on the keystores (I know very little about LDAP, but I believe LDAP already provides this kind of thing), and they could be hierarchical, with access policy inheritance. It could act as a password safe like http://kedpm.sourceforge.net/. Imagine storing SSH private keys in IPA. The user then wants to fetch these into ssh-agent, or to provide them for some other in-memory process that requires access to the unencrypted private-key. Another scenario is X.509 PKI where the private key is usually passphrase encrypted. If the user forgets their passphrase, the PKI token needs to be revoked and a new one issued. Much better (IMO) to hold it in a trusted authentication system and to provide the unencrypted key to applications on demand. User-passphrase can then be linked to FreeIPA system. Here is a quick idea of a command line to fetch credentials from an IPA keystore: ipa-keystore-fetch [-k keystore] [-u username] [-p password] [-P] [-o output_dir_or_file] \ [/path/to/token/]token_name[#attribute] \ [[/path/to/token/]token_name[#attribute]] [ ... ] Usual kind of thing: the user would have a default keystore, and their kerberos tokens (if available) would be used to authenticate for access to the keystore (based on username, I guess). Users could just dump tokens in the "root" space, or arrange the tokens hierarchically. Tokens could have attributes associated with them, with a "primary" or "default" token if none is specified. Tokens could be dumped to screen, routed to an application (pipe, IPC, socket, PID), or written to file. You could pretty easily imagine commands: chmod # acl changes add edit rm backup ls Ian <>___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Use of FreeIPA or FreeIPA LDAP server to hold private keys
On 08/02/2011 05:51 PM, Ian Stokes-Rees wrote: > > > On 8/2/11 4:27 PM, Dmitri Pal wrote: >> On 08/02/2011 02:15 PM, Ian Stokes-Rees wrote: >>> Is there some mechanism to store private keys (e.g. ssh, pgp, gpg, >>> X.509) in FreeIPA, tied to a user account, so only the user (via >>> kerb token or with password prompt) can fetch the token? >>> >>> If FreeIPA doesn't make this possible, can anyone suggest a good >>> mechanism to have, effectively, a user keystore that would sync >>> passwords with FreeIPA nicely. I am thinking, in particular, of the >>> scenario where users forget their password -- we'd strongly prefer >>> to just reset it for them (24 hours, one login) in a way that didn't >>> mean also re-issuing all passphrase-secured identity tokens. >>> >> >> Not now however: >> https://fedorahosted.org/freeipa/ticket/754 >> https://fedorahosted.org/freeipa/ticket/237 >> https://fedorahosted.org/freeipa/ticket/521 >> >> There are also some thoughts and ideas about IPA as a secure vault >> for other credentials in other systems which is not logged as a ticket. >> >> >> Would you mind sharing with us your ideas about this functionality >> actually should work? >> Use cases, examples and design ideas are very welcome. > > Is there any standard to keystores? It would be great if Linux, Mac, > Windows could all be pointed at an FreeIPA to fetch credentials, > usernames, passwords. Authentication could use kerberos tickets if > available, otherwise prompt for username/password, or have > configurable authentication policies. > > Users and administrators could set ACL policies on the keystores (I > know very little about LDAP, but I believe LDAP already provides this > kind of thing), and they could be hierarchical, with access policy > inheritance. It could act as a password safe like > http://kedpm.sourceforge.net/. > > Imagine storing SSH private keys in IPA. The user then wants to fetch > these into ssh-agent, or to provide them for some other in-memory > process that requires access to the unencrypted private-key. > > Another scenario is X.509 PKI where the private key is usually > passphrase encrypted. If the user forgets their passphrase, the PKI > token needs to be revoked and a new one issued. Much better (IMO) to > hold it in a trusted authentication system and to provide the > unencrypted key to applications on demand. User-passphrase can then > be linked to FreeIPA system. > > Here is a quick idea of a command line to fetch credentials from an > IPA keystore: > > ipa-keystore-fetch [-k keystore] [-u username] [-p password] [-P] > [-o output_dir_or_file] \ > [/path/to/token/]token_name[#attribute] \ > [[/path/to/token/]token_name[#attribute]] [ ... ] > > Usual kind of thing: the user would have a default keystore, and their > kerberos tokens (if available) would be used to authenticate for > access to the keystore (based on username, I guess). Users could just > dump tokens in the "root" space, or arrange the tokens > hierarchically. Tokens could have attributes associated with them, > with a "primary" or "default" token if none is specified. Tokens > could be dumped to screen, routed to an application (pipe, IPC, > socket, PID), or written to file. You could pretty easily imagine > commands: > > chmod # acl changes > add > edit > rm > backup > ls > > Ian > First, security specialist would probably rebel about providing the password or keys in clear. The best practice says do not reveal the keys/passwords but rather encrypt them with some other "transport" secret that would be known to the user or destination host and would protect the password/key while in transit. Second, yes I was thinking about hierarchical storage too but then every user would have to turn into a container. That would have some implications that need to be researched. It might be easier to keep the key(s) in user entry and have ACLs attached to the key(s). And then have a separate vault storage in a form of a database for a quick and simple lookup. Needs investigation. Third there is a standard and protocol http://www.oasis-open.org/committees/kmip/ but last time I looked there were no open source implementations that we can take advantage of. Starting a whole new kmip related project is something that we can't afford... So: It can be solved and can be solved generically and more or less securely but it will take a lot of time before we would get there. I am sure we would though but not as soon as you might want. Our current plan is to focus on the storage and make sure we can address the use cases we need to address like keys for disk encryption, SSH etc. Serving them out is whole different story and I doubt it will be done soon. Design work in this area would hopefully start in the fall. -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/
