Re: [Freeipa-users] AD Trust - Cannot resolve servers for KDC after reboot
On 19.9.2014 23:15, Genadi Postrilko wrote: The DNS server service of AD is running. I am able to resolve with nslookup command. I have just restarted the named service and i am able to kinit again. It looks like the named deamon, cannot recognize that the forwarder is back online. Is there some caching mechanism implemented for the forwarders? 'IPA forwarders' are exactly the same as normal 'BIND forward zone' so they involve normal DNS cache. Which type of forwarder do you have configured? Is your 'forwarding policy' set to 'first' (default) or 'only'? Forwarding policy 'first' (combined with cache) could be the cause of your problem. 'First' policy instructs BIND to contact the configured server and if it fails (because of timeout) BIND will re-try the same query using normal recursion. Depending on your network configuration, the normal DNS recursion can return different results than forwarding(^1). In this case BIND can cache e.g. NXDOMAIN answer from some other server and this answer will stay in cache for TTL value in the given answer. As a result, IPA could get cached NXDOMAIN instead of correct SRV records for AD until the TTL in cache expires. This is of course a wild guess. Detailed logs from named (log level 5 or higher+querylog) could tell us what exactly happened. Have a nice day! (^1) I would argue that this points to a flaw in network configuration... Petr^2 Spacek 2014-09-19 23:40 GMT+03:00 Alexander Bokovoy aboko...@redhat.com: On Fri, 19 Sep 2014, Genadi Postrilko wrote: I have recreated the problem. Rebooted the AD and now cannot kinit with AD users. [root@ipaserver1 ~]# KRB5_TRACE=/dev/stdout kinit y...@blue.com [22865] 1411157693.26121: Resolving unique ccache of type KEYRING [22865] 1411157693.26167: Getting initial credentials for y...@blue.com [22865] 1411157693.28577: Sending request (156 bytes) to BLUE.COM kinit: Cannot resolve servers for KDC in realm BLUE.COM while getting initial credentials The AD configured as forwarder: [root@ipaserver1 ~]# ipa dnsconfig-show Global forwarders: 192.168.227.60 i can ping the AD machine. If you rebooted AD DC, it takes time to start up its services. If Kerberos library cannot resolve SRV records for BLUE.COM, it means DNS service on AD DC didn't start up yet and cannot respond to DNS queries. 2014-09-16 10:28 GMT+03:00 Sumit Bose sb...@redhat.com: On Tue, Sep 16, 2014 at 01:39:41AM +0300, Genadi Postrilko wrote: Hello all ! I have deployed test environment for AD trust feature, the environment contains : Windows Server 2008 - AD Server. RHEL 7 - IPA 3.3 Server. RHEL 6.2 - IPA Client. I have established the trust as IPA in the sub domain of AD. AD DNS domain - blue.com IPA DNS domain - linux.blue.com All was working fine as i was able to kinit with AD users: [root@ipaserver1 ~]# kinit y...@blue.com Password for y...@blue.com: [root@ipaserver1 ~]# klist Ticket cache: KEYRING:persistent:0:krb_ccache_oi15FrE Default principal: y...@blue.com Valid starting Expires Service principal 09/16/2014 01:00:25 09/16/2014 11:00:25 krbtgt/blue@blue.com renew until 09/17/2014 01:00:20 But after i rebooted the Windows Server Machine, i could not kinit with AD users anymore: [root@ipaserver1 ~]# kinit y...@blue.com kinit: Cannot resolve servers for KDC in realm BLUE.COM while getting initial The only IPA component used for kinit is the DNS server. How did you configure DNS (glue records? forwarder?). To get more details about what is failing you can call: KRB5_TRACE=/dev/stdout kinit y...@blue.com HTH bye, Sumit I have checked if all the IPA services where UP: [root@ipaserver1 ~]# ipactl status Directory Service: RUNNING krb5kdc Service: RUNNING kadmin Service: RUNNING named Service: RUNNING ipa_memcached Service: RUNNING httpd Service: RUNNING pki-tomcatd Service: RUNNING smb Service: RUNNING winbind Service: RUNNING ipa-otpd Service: RUNNING ipa: INFO: The ipactl command was successful After i restarted IPA services (ipactl restart), i was able to to kinit again. Restarting smb service would do the job as well (?). Just wanted to know if it is a know issue, or the AD should be re discovered if it reboots. I think i seen an issue about it in the mailing list some time ago (not sure). I did not increase the debug level and got the logs. But i can share the ipa and sssd version: rpm -qa | grep ipa ipa-server-3.3.3-28.el7_0.1.x86_64 python-iniparse-0.4-9.el7.noarch libipa_hbac-1.11.2-68.el7_0.5.x86_64 ipa-admintools-3.3.3-28.el7_0.1.x86_64 ipa-server-trust-ad-3.3.3-28.el7_0.1.x86_64 ipa-python-3.3.3-28.el7_0.1.x86_64 sssd-ipa-1.11.2-68.el7_0.5.x86_64 iniparser-3.1-5.el7.x86_64 libipa_hbac-python-1.11.2-68.el7_0.5.x86_64 ipa-client-3.3.3-28.el7_0.1.x86_64 rpm -qa | grep sssd sssd-krb5-common-1.11.2-68.el7_0.5.x86_64 sssd-ldap-1.11.2-68.el7_0.5.x86_64 sssd-common-1.11.2-68.el7_0.5.x86_64 sssd-common-pac-1.11.2-68.el7_0.5.x86_64
Re: [Freeipa-users] PKI-CA fails to start (broken config after update?)
On 09/20/2014 01:02 AM, swartz wrote:
Hello,
Encountered same issue as described here:
https://www.redhat.com/archives/freeipa-users/2013-July/msg00133.html
https://www.redhat.com/archives/freeipa-users/2014-August/msg00224.html
Plain vanilla IPA setup. No changes, no customizations.
Recently IPA fails to start. Error happened right after a 'yum update' and
reboot.
---
Starting pki-ca: [ OK ]
Usage: grep [OPTION]... PATTERN [FILE]...
Try `grep --help' for more information.
Usage: grep [OPTION]... PATTERN [FILE]...
Try `grep --help' for more information.
Usage: grep [OPTION]... PATTERN [FILE]...
Try `grep --help' for more information.
...
Failed to start CA Service
Shutting down
Digging into the matter further...
The line that causes the error above is in /usr/share/pki/scripts/functions
(which is loaded by pki-ca init script):
netstat -antl | grep ${port} /dev/null
The $port variable is blank so call to grep is without a search parameter.
Hence invalid call to grep and subsequent error msg I'm seeing as above.
$port is defined just a few lines above as
port=`grep '^pkicreate.unsecure_port=' ${pki_instance_configuration_file} |
cut
-b25- -`
BUT! For whatever reason there is no line that starts with
pkicreate.unsecure_port in $pki_instance_configuration_file
(/var/lib/pki-ca/conf/CS.cfg). Thus no port info is ever obtained for use in
grep.
Why there is no such line in config file where one is expected is unknown to
me...
Versions currently installed
ipa-server-3.0.0-37.el6.x86_64
pki-ca-9.0.3-32.el6.noarch
Did updates to pki packages clobber the configs? What got broken? How do I
resolve it?
Thank you.
Also please see another PKI crash on EL6 reported on freeipa-users:
https://www.redhat.com/archives/freeipa-users/2014-September/msg00331.html
This is not the first time this issue was reported, but we got no response from
PKI team, even though I CCed several members (maybe that was actually the root
case).
The PKI installation errors are piling up (7.1 too), I would like to resolve
that very soon so that we are not seen as too unstable software.
Thanks for help,
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
[Freeipa-users] weak and null ciphers detected on ldap ports
Security scan of FreeIPA server ports uncovered weak, medium and null ciphers on port 389 and 636. We are running ‘ipa-server-3.0.0-37.el6.i686’. How can I disable/remove these ciphers in my existing setup? Ciphers Discovered - TLSv1 EXP-RC2-CBC-MD5 Kx=RSA(512)Au=RSA Enc=RC2-CBC(40) Mac=MD5export EXP-RC4-MD5 Kx=RSA(512)Au=RSA Enc=RC4(40) Mac=MD5export TLSv1 EXP1024-DES-CBC-SHA Kx=RSA(1024) Au=RSA Enc=DES-CBC(56) Mac=SHA1 export EXP1024-RC4-SHA Kx=RSA(1024) Au=RSA Enc=RC4(56) Mac=SHA1 export DES-CBC-SHA Kx=RSA Au=RSA Enc=DES-CBC(56) Mac=SHA1 TLSv1 NULL-SHA Kx=RSA Au=RSA Enc=None Mac=SHA1 Thanks, Amb. This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and any disclosure, copying, or distribution of this message, or the taking of any action based on it, by you is strictly prohibited. v.E.1 -- 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
Re: [Freeipa-users] PKI-CA fails to start (broken config after update?)
On Mon, 2014-09-22 at 10:50 +0200, Martin Kosek wrote:
On 09/20/2014 01:02 AM, swartz wrote:
Hello,
Encountered same issue as described here:
https://www.redhat.com/archives/freeipa-users/2013-July/msg00133.html
https://www.redhat.com/archives/freeipa-users/2014-August/msg00224.html
Plain vanilla IPA setup. No changes, no customizations.
Recently IPA fails to start. Error happened right after a 'yum update' and
reboot.
---
Starting pki-ca: [ OK ]
Usage: grep [OPTION]... PATTERN [FILE]...
Try `grep --help' for more information.
Usage: grep [OPTION]... PATTERN [FILE]...
Try `grep --help' for more information.
Usage: grep [OPTION]... PATTERN [FILE]...
Try `grep --help' for more information.
...
Failed to start CA Service
Shutting down
Digging into the matter further...
The line that causes the error above is in /usr/share/pki/scripts/functions
(which is loaded by pki-ca init script):
netstat -antl | grep ${port} /dev/null
The $port variable is blank so call to grep is without a search parameter.
Hence invalid call to grep and subsequent error msg I'm seeing as above.
$port is defined just a few lines above as
port=`grep '^pkicreate.unsecure_port=' ${pki_instance_configuration_file} |
cut
-b25- -`
BUT! For whatever reason there is no line that starts with
pkicreate.unsecure_port in $pki_instance_configuration_file
(/var/lib/pki-ca/conf/CS.cfg). Thus no port info is ever obtained for use
in grep.
Why there is no such line in config file where one is expected is unknown
to me...
Versions currently installed
ipa-server-3.0.0-37.el6.x86_64
pki-ca-9.0.3-32.el6.noarch
Did updates to pki packages clobber the configs? What got broken? How do I
resolve it?
There have been no updates recently on rhel 6 to the pki packages.
There has, however, been an update to tomcat - which broke dogtag
startups.
What version of tomcat6 is on your system?
Thank you.
Also please see another PKI crash on EL6 reported on freeipa-users:
https://www.redhat.com/archives/freeipa-users/2014-September/msg00331.html
This is not the first time this issue was reported, but we got no response
from
PKI team, even though I CCed several members (maybe that was actually the root
case).
The PKI installation errors are piling up (7.1 too), I would like to resolve
that very soon so that we are not seen as too unstable software.
The issues on 7.1 are tomcat related too. Builds were completed last
week to address these.
Thanks for help,
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
Re: [Freeipa-users] PKI-CA fails to start (broken config after update?)
On Mon, 2014-09-22 at 10:43 -0400, Ade Lee wrote:
On Mon, 2014-09-22 at 10:50 +0200, Martin Kosek wrote:
On 09/20/2014 01:02 AM, swartz wrote:
Hello,
Encountered same issue as described here:
https://www.redhat.com/archives/freeipa-users/2013-July/msg00133.html
https://www.redhat.com/archives/freeipa-users/2014-August/msg00224.html
Plain vanilla IPA setup. No changes, no customizations.
Recently IPA fails to start. Error happened right after a 'yum update'
and reboot.
---
Starting pki-ca: [ OK ]
Usage: grep [OPTION]... PATTERN [FILE]...
Try `grep --help' for more information.
Usage: grep [OPTION]... PATTERN [FILE]...
Try `grep --help' for more information.
Usage: grep [OPTION]... PATTERN [FILE]...
Try `grep --help' for more information.
...
Failed to start CA Service
Shutting down
Digging into the matter further...
The line that causes the error above is in
/usr/share/pki/scripts/functions
(which is loaded by pki-ca init script):
netstat -antl | grep ${port} /dev/null
The $port variable is blank so call to grep is without a search parameter.
Hence invalid call to grep and subsequent error msg I'm seeing as above.
$port is defined just a few lines above as
port=`grep '^pkicreate.unsecure_port=' ${pki_instance_configuration_file}
| cut
-b25- -`
BUT! For whatever reason there is no line that starts with
pkicreate.unsecure_port in $pki_instance_configuration_file
(/var/lib/pki-ca/conf/CS.cfg). Thus no port info is ever obtained for use
in grep.
Why there is no such line in config file where one is expected is unknown
to me...
Versions currently installed
ipa-server-3.0.0-37.el6.x86_64
pki-ca-9.0.3-32.el6.noarch
Did updates to pki packages clobber the configs? What got broken? How do I
resolve it?
Another question - what is the output of ls -l /etc/pki-ca/CS.cfg ?
There have been no updates recently on rhel 6 to the pki packages.
There has, however, been an update to tomcat - which broke dogtag
startups.
What version of tomcat6 is on your system?
Thank you.
Also please see another PKI crash on EL6 reported on freeipa-users:
https://www.redhat.com/archives/freeipa-users/2014-September/msg00331.html
This is not the first time this issue was reported, but we got no response
from
PKI team, even though I CCed several members (maybe that was actually the
root
case).
The PKI installation errors are piling up (7.1 too), I would like to resolve
that very soon so that we are not seen as too unstable software.
The issues on 7.1 are tomcat related too. Builds were completed last
week to address these.
Thanks for help,
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
[Freeipa-users] copy encrypted password into IPA?
We would like to add some users that are currently in the password/shadow files on some servers into IPA. Is there any way to copy (preferably via a script) the encrypted password into IPA so that we do not have to have them reset their passwords? Our idea is to use the IPA user-add command to create the user then insert their encrypted password into their IPA entry. Regards, Ron -- 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
Re: [Freeipa-users] copy encrypted password into IPA?
On 09/22/2014 02:23 PM, Ron wrote: We would like to add some users that are currently in the password/shadow files on some servers into IPA. Is there any way to copy (preferably via a script) the encrypted password into IPA so that we do not have to have them reset their passwords? Our idea is to use the IPA user-add command to create the user then insert their encrypted password into their IPA entry. Regards, Ron The most probably answer is no since the hash types would not match between what you have in the files and what LDAP server expects. If you by any chance configured your files to use other hashes than default it might match. You can go the other way and reconfigure the LDAP server but AFAIR it is not recommended. The user-add command would not work anyways as it does not accept hash as an input. Or I should say it would allow you to add users without passwords in a script. You can set a random password, send it to account owner in a script and make account owners to change passwords (default) on the first use. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- 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
Re: [Freeipa-users] apache kerberized nfs4 /var/www/html access denied for apache user
On 09/20/2014 05:19 PM, Simo Sorce wrote: On Sat, 20 Sep 2014 19:44:28 +0200 Rob Verduijn rob.verdu...@gmail.com wrote: Hi again, Thank you for the quick response. I've removed the credstore entries that are not necessary for the nfs access. Now the users no longer go through gssproxy, but apache does. I've googled around quite a bit and and it seems that your presentation on youtube and the gssproxy page together with a bit on the fedora site are about it concerning documentation. We do not have a lot of docs yet, indeed. Is there any chance we can publish this setup somewhere as a HOWTO? May be on GSS proxy or IPA wiki? That would help others coming after you. If you have a fedora account you can add content to FreeIPA wiki. The below gssproxy.conf works fine for apache accessing a kerberized nfs share without having to authenticate against ipa. If I were to create another share for say an tftp directory do I need to create another entry like the one below or can I simply say : euid = 48,1,2,3,4 Nope, euid is singlevalued. Should we open RFE for it? ding-libs can return you a list of numbers. Or maybe this if you won't mind that any service with a keytab gets nfs access. euid = %U Setting %U in euid does not work, that's why we have allow_any_uid. Thanx for the quick help. Glad you got it working to your liking, and feel free to ask questions directly on the gss-proxy mailing list if you want. Btw in the conf below you can also remove completely the allow_any_uid (no is the default) and the trusted options (you should not really trust apache to impersonate any user, w/o trusted it will just be itself). Simo. [gssproxy] [service/nfs-client] mechs = krb5 cred_store = client_keytab:/etc/gssproxy/%U.keytab cred_usage = initiate allow_any_uid = no trusted = yes euid = 48 2014-09-20 18:15 GMT+02:00 Simo Sorce s...@redhat.com: On Sat, 20 Sep 2014 16:53:48 +0200 Rob Verduijn rob.verdu...@gmail.com wrote: Hello all, I've managed to get the gssproxy to work on my installation. I can now mount my apache document root using sec=krb5p and apache automagically mounts the share when needed. However I noticed that now all nfs credentials are going through gssproxy. Is there a way to disable this for regular users (or only enable it for apache) Below is the gssproxy.conf I used I assume you mean that gssproxy is used for all users when rpc.gssd is used ? You cannot pick and choose this way, but gss-proxy can be configured to user regular user's caches so that it preserve proper authorization for access. Cheers Rob [gssproxy] [service/nfs-client] mechs = krb5 cred_store = keytab:/etc/krb5.keytab cred_store = ccache:FILE:/var/lib/gssproxy/clients/krb5cc_%U cred_store = client_keytab:/etc/gssproxy/%U.keytab cred_usage = initiate allow_any_uid = yes trusted = yes euid = 0 You do not need allow_any_uid in your case as rpc.gssd always runs as root. You can also remove the keytab:/etc/krb5.keytab option as you are only going to initiate with explicit client keytabs. If you only have the apache keytab in /etc/gssproxy then for any other user will fall back to local resolution. You may also experiment with setting ccache to the default for your system so that gss-proxy can find actual user's ccaches, though that may comport some minor risk and will force you to run gss-proxy as root. HTH, Simo. -- Simo Sorce * Red Hat, Inc * New York -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- 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
Re: [Freeipa-users] copy encrypted password into IPA?
Dmitri Pal wrote:
On 09/22/2014 02:23 PM, Ron wrote:
We would like to add some users that are currently in the
password/shadow files on some servers into IPA.
Is there any way to copy (preferably via a script) the encrypted
password into IPA so that we do not have to have them reset their
passwords?
Our idea is to use the IPA user-add command to create the user then
insert their encrypted password into their IPA entry.
Regards,
Ron
The most probably answer is no since the hash types would not match
between what you have in the files and what LDAP server expects.
If you by any chance configured your files to use other hashes than
default it might match. You can go the other way and reconfigure the
LDAP server but AFAIR it is not recommended.
The user-add command would not work anyways as it does not accept hash
as an input. Or I should say it would allow you to add users without
passwords in a script.
You can set a random password, send it to account owner in a script and
make account owners to change passwords (default) on the first use.
If you put IPA into migration mode then you can set a password on
user-add via --setattr userPassword=hash . Note that it is important
to do it in one step and not add user, then set password. You'll then
need to migrate the password to create Kerberos credentials either by
authenticating via SSSD or on the IPA web page.
The trick is having the hash in a format acceptable to 389-ds. I know it
works with crypt, you just need to prefix it with {crypt}hash. For
other formats, I don't know.
rob
--
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
Re: [Freeipa-users] PKI-CA fails to start (broken config after update?)
On 9/22/2014 9:14 AM, Ade Lee wrote: Another question - what is the output of ls -l /etc/pki-ca/CS.cfg ? ls -l /etc/pki-ca/CS.cfg -rw-r-. 1 pkiuser pkiuser 49196 Sep 19 11:29 /etc/pki-ca/CS.cfg I know that I did NOT change the configs myself. But something certainly did during 'yum update'. There are no .rpmsave or .rpmnew files that would typically be created if configs are properly marked in RPM spec file. There are two other files that exist though: -rw-r-. 1 pkiuser pkiuser 65869 Sep 19 11:30 CS.cfg.in.p21 -rw-rw. 1 pkiuser pkiuser 65955 Sep 5 2013 CS.cfg.in.p33 However, they are not usable either in place of current CS.cfg. There have been no updates recently on rhel 6 to the pki packages. There has, however, been an update to tomcat - which broke dogtag startups. What version of tomcat6 is on your system? rpm -qa tomcat6 tomcat6-6.0.24-78.el6_5.noarch -- 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
Re: [Freeipa-users] apache kerberized nfs4 /var/www/html access denied for apache user
On Mon, 22 Sep 2014 15:09:42 -0400 Dmitri Pal d...@redhat.com wrote: On 09/20/2014 05:19 PM, Simo Sorce wrote: On Sat, 20 Sep 2014 19:44:28 +0200 Rob Verduijn rob.verdu...@gmail.com wrote: Hi again, Thank you for the quick response. I've removed the credstore entries that are not necessary for the nfs access. Now the users no longer go through gssproxy, but apache does. I've googled around quite a bit and and it seems that your presentation on youtube and the gssproxy page together with a bit on the fedora site are about it concerning documentation. We do not have a lot of docs yet, indeed. Is there any chance we can publish this setup somewhere as a HOWTO? May be on GSS proxy or IPA wiki? That would help others coming after you. If you have a fedora account you can add content to FreeIPA wiki. With a Fedora account you can also write to the GSS-Proxy wiki which may be more appropriate. The below gssproxy.conf works fine for apache accessing a kerberized nfs share without having to authenticate against ipa. If I were to create another share for say an tftp directory do I need to create another entry like the one below or can I simply say : euid = 48,1,2,3,4 Nope, euid is singlevalued. Should we open RFE for it? ding-libs can return you a list of numbers. No, it rarely if ever would make sense to do so, And we want to move the conf to have multiple conf snippets instead of a single file, in that case you'll want to have multiple snippets one per user. Simo. -- Simo Sorce * Red Hat, Inc * New York -- 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
Re: [Freeipa-users] weak and null ciphers detected on ldap ports
On 09/22/2014 05:03 AM, Murty, Ajeet (US - Arlington) wrote: Security scan of FreeIPA server ports uncovered weak, medium and null ciphers on port 389 and 636. We are running ‘ipa-server-3.0.0-37.el6.i686’. How can I disable/remove these ciphers in my existing setup? This has recently been worked on in this 389-ds-base ticket: https://fedorahosted.org/389/ticket/47838 As mentioned in the initial description of that ticket, you can configure the allowed ciphers in the cn=config entry in 389-ds-base. You can edit this over LDAP, or by stopping 389-ds-base and editing /etc/dirsrv/slapd-REALM/dse.ldif. Thanks, -NGK Ciphers Discovered - TLSv1 EXP-RC2-CBC-MD5 Kx=RSA(512)Au=RSA Enc=RC2-CBC(40) Mac=MD5export EXP-RC4-MD5 Kx=RSA(512)Au=RSA Enc=RC4(40) Mac=MD5export TLSv1 EXP1024-DES-CBC-SHA Kx=RSA(1024) Au=RSA Enc=DES-CBC(56) Mac=SHA1 export EXP1024-RC4-SHA Kx=RSA(1024) Au=RSA Enc=RC4(56) Mac=SHA1 export DES-CBC-SHA Kx=RSA Au=RSA Enc=DES-CBC(56) Mac=SHA1 TLSv1 NULL-SHA Kx=RSA Au=RSA Enc=None Mac=SHA1 Thanks, Amb. This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and any disclosure, copying, or distribution of this message, or the taking of any action based on it, by you is strictly prohibited. v.E.1 -- 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
Re: [Freeipa-users] copy encrypted password into IPA?
2014-09-22 21:31 GMT+02:00 Rob Crittenden rcrit...@redhat.com:
The trick is having the hash in a format acceptable to 389-ds. I know it
works with crypt, you just need to prefix it with {crypt}hash. For
other formats, I don't know.
{SHA}hash works as well
- Jitse
--
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
Re: [Freeipa-users] PKI-CA fails to start (broken config after update?)
On Mon, 2014-09-22 at 13:39 -0600, swartz wrote: On 9/22/2014 9:14 AM, Ade Lee wrote: Another question - what is the output of ls -l /etc/pki-ca/CS.cfg ? ls -l /etc/pki-ca/CS.cfg -rw-r-. 1 pkiuser pkiuser 49196 Sep 19 11:29 /etc/pki-ca/CS.cfg In very rare cases, I've seen cases where the CS.cfg becomes truncated during an update. Unfortunately, we have not been able to reproduce the event. In later versions of dogtag, we make sure to save the CS.cfg just in case. Your instance sounds like a truncated CS.cfg instance, but the size is a lot larger than cases I've seen before, so I don't want to jump to that conclusion yet. If you scroll to the end of the CS.cfg, does it look like it has been truncated? If you have backups of the CS.cfg, that will help. Also, you could look for backups that we have created: find /var/lib/pki-ca -name CS.cfg* find /var/log -name CS.cfg* Also, do you have a replica CA? Ade I know that I did NOT change the configs myself. But something certainly did during 'yum update'. There are no .rpmsave or .rpmnew files that would typically be created if configs are properly marked in RPM spec file. There are two other files that exist though: -rw-r-. 1 pkiuser pkiuser 65869 Sep 19 11:30 CS.cfg.in.p21 -rw-rw. 1 pkiuser pkiuser 65955 Sep 5 2013 CS.cfg.in.p33 However, they are not usable either in place of current CS.cfg. The above files are templates only. They are modified during instance configuration. There have been no updates recently on rhel 6 to the pki packages. There has, however, been an update to tomcat - which broke dogtag startups. What version of tomcat6 is on your system? rpm -qa tomcat6 tomcat6-6.0.24-78.el6_5.noarch This tomcat version should still be a working one. The tomcat6 then broke things has not made it out yet, having been discovered in QE testing. -- 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
