Re: [Freeipa-users] A crazy idea maybe, migration to Free-IPA 4.1.
Awesome, it worked!
Just one final question: how to make that script search not only in
ipa1.example.com's LDAP database, but also in ipa2.example.com's LDAP in
case ipa1 is inaccessible? It's vital for a production environment!
I tried copying the whole section of code from ldapsearch ... to ...
done
and putting it after a new instance of if [ ! -s $tmpf ]; then ,
but it didn't work (I'm not a programmer...).
My current cron script is like this:
https://cloud.mail.ru/public/fdf2e60c5df8%2Fsudo.sh
Programmers, please take a glance at the file - logically it shouldn't
be difficult to make necessary modifications,
but I don't know how...
23-Oct-14 21:40, Alexander Bokovoy пишет:
try adding something like this:
old_krb5_ccache=${KRB5_CCACHE}
KRB5_CCACHE=/tmp/_hostgroups_access.ccache.$$
export KRB5_CCACHE
kinit -k -t /etc/krb5.keytab host/`hostname`
# perform actual search
ldapsearch -Y GSSAPI .
# end of script
kdestroy
KRB5_CCACHE=${old_krb5_ccache}
export KRB5_CCACHE
--
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] Errors upgrading 4.0.1 to 4.1
On 10/24/2014 05:17 AM, Michael Lasevich wrote: While upgrading from 4.0.1. to 4.1 on fedora 20 got following on one of the two boxes: Upgrade failed with attribute allowWeakCipher not allowed IPA upgrade failed. Unexpected error DuplicateEntry: This entry already exists It seems the ipa no longer starts up after this. The replica server seems to have had same error,but it runs just fine. From digging around, it appears that there are a number of GSS errors in dirsrv and bind fails with something like: named-pkcs11[2212]: ObjectStore.cpp(74): Failed to open token e919db16-6329-406c-6ae4-120ad68508c4 named-pkcs11[2212]: sha1.c:92: fatal error: named-pkcs11[2212]: RUNTIME_CHECK(pk11_get_session(ctx, OP_DIGEST, isc_boolean_true, isc_boolean_false, isc_boolean_false, ((void *)0), 0) == 0) failed Any help would be appreciated -M What Directory Server version do you use? This is an attribute introduced in 389-ds-base 1.3.3+ which should be included in the FreeIPA Copr (DS 1.3.3 is native to F21+). CCing Ludwig to advise further. Thanks, 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] A crazy idea maybe, migration to Free-IPA 4.1.
On Fri, 24 Oct 2014, Orkhan Gasimov wrote:
Awesome, it worked!
Just one final question: how to make that script search not only in
ipa1.example.com's LDAP database, but also in ipa2.example.com's LDAP
in case ipa1 is inaccessible? It's vital for a production environment!
There are two things here:
- ldapsearch should use DNS SRV records to discover servers
- ldapsearch call should rotate over all servers in case of an error
First is achieved with -H option if you don't specify a host but rather
use DN: dc=example,dc=com, encoded in a way of RFC 2396:
dc%3Dexample%2Cdc%3Dcom
where %3D is escape sequence for '=' and %2C is escape sequence for ','
ldapsearch -H ldap://dc%3Dexample%2Cdc%3Dcom
would request ldapsearch to first go and resolve DNS SRV record
_ldap._tcp.example.com and then connect to the list of servers returned.
All tools from OpenLDAP client side use this technique and rotate over
list of servers. You can specify multiple servers yourself too as
-H ldap://ipa1.example.com ldap://ipa2.example.com ldap://ipa3.example.com;
but using DNS SRV records is more reliable because you don't need to
change your script when you decommission the servers.
I tried copying the whole section of code from ldapsearch ... to
... done
and putting it after a new instance of if [ ! -s $tmpf ]; then ,
but it didn't work (I'm not a programmer...).
My current cron script is like this:
https://cloud.mail.ru/public/fdf2e60c5df8%2Fsudo.sh
Programmers, please take a glance at the file - logically it shouldn't
be difficult to make necessary modifications,
but I don't know how...
23-Oct-14 21:40, Alexander Bokovoy пишет:
try adding something like this:
old_krb5_ccache=${KRB5_CCACHE}
KRB5_CCACHE=/tmp/_hostgroups_access.ccache.$$
export KRB5_CCACHE
kinit -k -t /etc/krb5.keytab host/`hostname`
# perform actual search
ldapsearch -Y GSSAPI .
# end of script
kdestroy
KRB5_CCACHE=${old_krb5_ccache}
export KRB5_CCACHE
--
/ Alexander Bokovoy
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Inconsistent group memberships in sssd
On Thu, Oct 23, 2014 at 05:19:38PM -0700, Michael Lasevich wrote: Small update, it appears that once I run getent group groupname - my user shows up in the group groupname. Odd. (and yes, I have ran sss_cache -UG many a time) -M One particular change in IPA 4.x that might be giving old clients headache is the new permission system. Only clean installs or replicas of 6.6 (or newer) servers are guaranteed to work with old clients. How was your IPA 4.0.3 server installed? What is the 389-ds-base version you're running? Any chance you can try a newer SSSD on your CentOS6 client? I have a COPR repo with the latest 1.11 branch here: http://copr-fe.cloud.fedoraproject.org/coprs/jhrozek/SSSD-1.11-RHEL6/ -- 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] Inconsistent group memberships in sssd
It was a clean install of 4.0.1(not 4.0.3, I was wrong). I have upgraded to 4.1 and have not yet seen the problem recur - though I have not tested it much yet. On Oct 24, 2014 12:53 AM, Jakub Hrozek jhro...@redhat.com wrote: On Thu, Oct 23, 2014 at 05:19:38PM -0700, Michael Lasevich wrote: Small update, it appears that once I run getent group groupname - my user shows up in the group groupname. Odd. (and yes, I have ran sss_cache -UG many a time) -M One particular change in IPA 4.x that might be giving old clients headache is the new permission system. Only clean installs or replicas of 6.6 (or newer) servers are guaranteed to work with old clients. How was your IPA 4.0.3 server installed? What is the 389-ds-base version you're running? Any chance you can try a newer SSSD on your CentOS6 client? I have a COPR repo with the latest 1.11 branch here: http://copr-fe.cloud.fedoraproject.org/coprs/jhrozek/SSSD-1.11-RHEL6/ -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] A crazy idea maybe, migration to Free-IPA 4.1.
Thanks, this option worked in that script! 24-Oct-14 12:43, Alexander Bokovoy пишет: You can specify multiple servers yourself too as -H ldap://ipa1.example.com ldap://ipa2.example.com ldap://ipa3.example.com; -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
[Freeipa-users] Radius schema addition to default user objectclasses in FreeIPA 4.1
New task: I want to add an additional schema (radius schema) to default user object classes. I prepared the ldif-file for the schema: https://cloud.mail.ru/public/40edc9a6c9bb%2Fradiusschema.ldif , then followed instructions in https://www.redhat.com/archives/freeipa-users/2014-February/msg00050.html At step #2 of the instructions, ldapmodify command was run; as I'm using FreeIPA 4.1 in a multi-master replication scenario with 2 servers, the command was run on both servers and produced this output on both: modifying entry cn=schema Then I switched to GUI and added radiusprofile objectclass. After hitting the Update button I got the message: IPA Error 4001: NotFound objectclass radiusprofile not found Restarting ipactl didn't help. Command ldapsearch -Y GSSAPI | grep schema gives no output besides informational SASL messages. There is a MUST cn part in the objectclass definition in the ldif-file, but even after removing it the situation doesn't change. Please help me to understand where is the problem, and is it generally possible to use radius.schema with FreeIPA? The original schema was taken from: http://open.rhx.it/phamm/schema/radius.schema Thanks in advance! -- Орхан Касумов-- 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] Third party SSL certificate renewal
Hi,
Dne 24.10.2014 v 04:36 Dragan Prostran napsal(a):
Hello,
This is my first time posting to this list, so if I've made a faux pas
or mistake, please do correct me.
Can anyone please point me to the correct method to renewing 3rd party
SSL certificates used by FreeIPA 3.0? I suspect I've not done this
correctly.
Here is what has worked correctly so far:
1. FreeIPA is installed and configured to work correctly. It uses 3rd
party SSL certificates. I have access to the CSR, the certificate, the
private key, and the new CA bundle.
2. I have successfully followed these instructions to update the SSL
certificates used by Apache to serve the FreeIPA web interface:
http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP.
Of note is that there are 2 IPA servers, and the procedure has been
followed on both.
3. Upon visiting the FreeIPA web interface, I can see that the
certificate is valid, and expires in the future. Login to FreeIPA and
modifying (for example) an LDAP password, work correctly.
4. 3rd party services that take advantage of LDAP work correctly. I
can login and authenticate via LDAP.
Here is what does not work correctly:
1. A distinct, 3rd party webservice that takes advantage of LDAP *via
SSL* no longer is able to authenticate. Prior to certificate update
mentioned, this did work correctly. I must admit I'm unfamiliar with
LDAP (via SSL), and so instead of troubleshooting that service, I had
a closer look at the FreeIPA instance.
The 3rd party webservice needs to trust the CA certificate of the LDAP
server certificate in order for this to work.
2. When connected to the FreeIPA instance, and issuing 'ipa
user-status username', the following error is returned:
ipa: ERROR: cert validation failed for CN=CERT_CN_REDACTED,OU=Domain
Control Validated ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate
issuer has been marked as not trusted by the user.)
ipa: ERROR: cert validation failed for CN=CERT_CN_REDACTED,OU=Domain
Control Validated ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate
issuer has been marked as not trusted by the user.)
ipa: ERROR: cannot connect to Gettext('any of the configured servers',
domain='ipa', localedir=None): https://IPA1_FQDN_REDACTED/ipa/xml,
https://IPA2_FQDN_REDACTED/ipa/xml
Note that, CERT_CN_REDACTED is the *.domain.tld cert that has been
renewed. Of note is that, prior to the certificate update noted above,
this did work correctly, and would return the status of the user.
This means that the CA certificate of the HTTP server certificate is
missing from the NSS database at /etc/pki/nssdb.
Further, when issuing 'ipa service restart' on the IPA instance, the
following is returned:
# service ipa restart
Restarting Directory Service
Shutting down dirsrv:
DIRSRV_REDACTED... [ OK ]
Starting dirsrv:
DIRSRV_REDACTED...[21/Oct/2014:19:07:22 -0700] - SSL alert:
CERT_VerifyCertificateNow: verify certificate failed for cert
CERT_CN_REDACTED - GoDaddy.com, Inc. of family
cn=RSA,cn=encryption,cn=config (Netscape Portable Runtime error -8172
- Peer's certificate issuer has been marked as not trusted by the
user.)
[ OK ]
Restarting KDC Service
Stopping Kerberos 5 KDC: [ OK ]
Starting Kerberos 5 KDC: [ OK ]
Restarting KPASSWD Service
Stopping Kerberos 5 Admin Server: [ OK ]
Starting Kerberos 5 Admin Server: [ OK ]
Restarting MEMCACHE Service
Stopping ipa_memcached:[ OK ]
Starting ipa_memcached:[ OK ]
Restarting HTTP Service
Stopping httpd:[ OK ]
Starting httpd:[ OK ]
#
This means that the CA certificate of the LDAP server certificate is
missing from the NSS database at /etc/dirsrv/slapd-DIRSRV_REDACTED.
Can anyone instruct me as to what may be misconfigured? I assume this
is the root cause of LDAP via SSL not working correctly, but I'm not
quite sure how to verify that.
It is of note to say that the CA bundle (a chain of public keys
leading to a root, 3rd party CA) issued with the new certificate is
different from the previous certificate bundle. I know this as I have
records of the original certificate, key, bundle, and CSR. The CA
bundle issued with this new certificate is *different* from the CA
bundle used with the original certificate. As I have not provided, or
otherwise used, this new CA bundle when renewing the certificates in
FreeIPA, I suspect this is the root cause of the error, and so I ask
for help here.
You are right this is the root cause. To fix IPA, you need to import the
CA certificate to NSS databases at /etc/dirsrv/slapd-DIRSRV_REDACTED,
/etc/httpd/alias and /etc/pki/nssdb, copy it to /etc/ipa/ca.crt and
Re: [Freeipa-users] Third party SSL certificate renewal
Hi Jan,
I'm grateful for your help. I've researched how to follow your
recommendations above, but I'm not having a lot of luck. According to
old posts in this mailing list,
https://www.redhat.com/archives/freeipa-users/2013-May/msg00199.html,
the command ipa-server-certinstall is the way to go. That said, I
found an issue you've filed to allow for this, and it was implemented
in FreeIPA 3.3: https://fedorahosted.org/freeipa/ticket/3641
Unfortunately, this system is running FreeIPA 3.0:
# rpm -qa | grep -P ipa[_-]
ipa-pki-common-theme-9.0.3-7.el6.noarch
ipa-server-selinux-3.0.0-26.el6_4.4.x86_64
ipa-pki-ca-theme-9.0.3-7.el6.noarch
ipa-client-3.0.0-26.el6_4.4.x86_64
ipa-admintools-3.0.0-26.el6_4.4.x86_64
libipa_hbac-1.9.2-82.10.el6_4.x86_64
libipa_hbac-python-1.9.2-82.10.el6_4.x86_64
ipa-python-3.0.0-26.el6_4.4.x86_64
ipa-server-3.0.0-26.el6_4.4.x86_64
#
I've found these instructions:
http://www.freeipa.org/page/Howto/CA_Certificate_Renewal. I've read
those instructions, and I believe I may have a misconception about
this process. The procedure calls to:
# cp /root/ipa.crt /usr/share/ipa/html/ca.crt
# cp /root/ipa.crt /etc/ipa/ca.crt
Can you clear up what /root/ipa.crt ought to contain? I assume it
ought to contain *only* the root CA certificate which is the *first*
key in the bundle provided by the 3rd party Certificate Authority. Is
that correct?
The files /etc/ip/ca.crt already exists, but it is a single
certificate. The file I have, issued alongside with the certificate by
GoDaddy, is a CA bundle. It contains 3 public keys in sequence in a
single file. Could you please be more detailed as to how to accomplish
this: you need to import the CA certificate to NSS databases at
/etc/dirsrv/slapd-DIRSRV_REDACTED, /etc/httpd/alias and
/etc/pki/nssdb, copy it to /etc/ipa/ca.crt and
/usr/share/ipa/html/ca.crt and update
cn=CAcert,cn=ipa,cn=etc,dc=example,dc=com in LDAP with it.
I certainly hope these are not inappropriate questions: I'd just like
to ensure this is done correctly. Thank you.
---
Dragan Prostran
On Fri, Oct 24, 2014 at 6:12 AM, Jan Cholasta jchol...@redhat.com wrote:
Hi,
Dne 24.10.2014 v 04:36 Dragan Prostran napsal(a):
Hello,
This is my first time posting to this list, so if I've made a faux pas
or mistake, please do correct me.
Can anyone please point me to the correct method to renewing 3rd party
SSL certificates used by FreeIPA 3.0? I suspect I've not done this
correctly.
Here is what has worked correctly so far:
1. FreeIPA is installed and configured to work correctly. It uses 3rd
party SSL certificates. I have access to the CSR, the certificate, the
private key, and the new CA bundle.
2. I have successfully followed these instructions to update the SSL
certificates used by Apache to serve the FreeIPA web interface:
http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP.
Of note is that there are 2 IPA servers, and the procedure has been
followed on both.
3. Upon visiting the FreeIPA web interface, I can see that the
certificate is valid, and expires in the future. Login to FreeIPA and
modifying (for example) an LDAP password, work correctly.
4. 3rd party services that take advantage of LDAP work correctly. I
can login and authenticate via LDAP.
Here is what does not work correctly:
1. A distinct, 3rd party webservice that takes advantage of LDAP *via
SSL* no longer is able to authenticate. Prior to certificate update
mentioned, this did work correctly. I must admit I'm unfamiliar with
LDAP (via SSL), and so instead of troubleshooting that service, I had
a closer look at the FreeIPA instance.
The 3rd party webservice needs to trust the CA certificate of the LDAP
server certificate in order for this to work.
2. When connected to the FreeIPA instance, and issuing 'ipa
user-status username', the following error is returned:
ipa: ERROR: cert validation failed for CN=CERT_CN_REDACTED,OU=Domain
Control Validated ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate
issuer has been marked as not trusted by the user.)
ipa: ERROR: cert validation failed for CN=CERT_CN_REDACTED,OU=Domain
Control Validated ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate
issuer has been marked as not trusted by the user.)
ipa: ERROR: cannot connect to Gettext('any of the configured servers',
domain='ipa', localedir=None): https://IPA1_FQDN_REDACTED/ipa/xml,
https://IPA2_FQDN_REDACTED/ipa/xml
Note that, CERT_CN_REDACTED is the *.domain.tld cert that has been
renewed. Of note is that, prior to the certificate update noted above,
this did work correctly, and would return the status of the user.
This means that the CA certificate of the HTTP server certificate is missing
from the NSS database at /etc/pki/nssdb.
Further, when issuing 'ipa service restart' on the IPA instance, the
following is returned:
# service ipa restart
Restarting Directory Service
Shutting down dirsrv:
DIRSRV_REDACTED... [ OK
Re: [Freeipa-users] Radius schema addition to default user objectclasses in FreeIPA 4.1
On 10/24/2014 06:27 AM, Орхан Касумов wrote: New task: I want to add an additional schema (radius schema) to default user object classes. I prepared the ldif-file for the schema: https://cloud.mail.ru/public/40edc9a6c9bb%2Fradiusschema.ldif , then followed instructions in https://www.redhat.com/archives/freeipa-users/2014-February/msg00050.html At step #2 of the instructions, ldapmodify command was run; as I'm using FreeIPA 4.1 in a multi-master replication scenario with 2 servers, the command was run on both servers and produced this output on both: modifying entry cn=schema Then I switched to GUI and added radiusprofile objectclass. After hitting the Update button I got the message: IPA Error 4001: NotFound objectclass radiusprofile not found Restarting ipactl didn't help. Command ldapsearch -Y GSSAPI | grep schema gives no output besides informational SASL messages. Are you trying to list the schema over LDAP? Where did you get the above instructions? They are wrong. Use ldapsearch -o ldif-wrap=no -Y GSSAPI -s base -b cn=schema attributeTypes objectClasses If you are using an older version of ldapsearch that doesn't support ldif-wrap, see http://richmegginson.livejournal.com/18726.html There is a MUST cn part in the objectclass definition in the ldif-file, but even after removing it the situation doesn't change. Please help me to understand where is the problem, and is it generally possible to use radius.schema with FreeIPA? The original schema was taken from: http://open.rhx.it/phamm/schema/radius.schema Thanks in advance! -- Орхан Касумов -- 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] multi-master replication
I would have thought that changes go from replica to master and not just master to replica. Is there something I have to do to make the changes bi-directional? Craig White System Administrator O 623-201-8179 M 602-377-9752 [cid:image001.png@01CF86FE.42D51630] SkyTouch Technology 4225 E. Windrose Dr. Phoenix, AZ 85032 -- 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] multi-master replication
From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Craig White Sent: Friday, October 24, 2014 4:02 PM To: freeipa-users@redhat.com Subject: [Freeipa-users] multi-master replication I would have thought that changes go from replica to master and not just master to replica. Is there something I have to do to make the changes bi-directional? Replying to my own post... Logs are my friend ;-) [24/Oct/2014:23:08:17 +] NSMMReplicationPlugin - agmt=cn=meToipa001.domain.local (ipa001:389): Replication bind with GSSAPI auth resumed [24/Oct/2014:23:08:17 +] NSMMReplicationPlugin - agmt=cn=meToipa001.domain.local (ipa001:389): Warning: unable to replicate schema: rc=2 [24/Oct/2014:23:08:17 +] NSMMReplicationPlugin - agmt=cn=meToipa001.domain.local (ipa001:389): Failed to send update operation to consumer (uniqueid e018060f-5bb011e4-81078979-dc802980, CSN 544aa3460003): Can't contact LDAP server. Will retry later. [24/Oct/2014:23:08:17 +] NSMMReplicationPlugin - agmt=cn=meToipa001.domain.local (ipa001:389): Consumer failed to replay change (uniqueid (null), CSN (null)): Can't contact LDAP server(-1). Will retry later. [24/Oct/2014:23:08:17 +] NSMMReplicationPlugin - agmt=cn=meToipa001.domain.local (ipa001:389): Warning: unable to send endReplication extended operation (Can't contact LDAP server) And on the master, I see a bunch of... sasl_io_recv failed to decode packet for connection 4113 but dirsrv is running on both machines and firewalls aren't in the way because I managed to set up the initial replication from master to replica without a problem and the firewall rules are the same for both machines. # rpm -qa | grep ipa ipa-admintools-3.0.0-42.el6.x86_64 libipa_hbac-python-1.11.6-30.el6.x86_64 python-iniparse-0.3.1-2.1.el6.noarch ipa-client-3.0.0-42.el6.x86_64 ipa-server-selinux-3.0.0-42.el6.x86_64 ipa-pki-common-theme-9.0.3-7.el6.noarch ipa-pki-ca-theme-9.0.3-7.el6.noarch sssd-ipa-1.11.6-30.el6.x86_64 ipa-python-3.0.0-42.el6.x86_64 ipa-server-3.0.0-42.el6.x86_64 libipa_hbac-1.11.6-30.el6.x86_64 RHEL 6.5 -- 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
