Re: [Freeipa-users] ipa spamming radius with otp token?
On 05/13/2015 03:01 PM, Bahmer, Eric Vaughn wrote: I¹ll have to look into the the ports on the idm server then, I¹m not overly familiar with firewalld, I tried to install iptables and use the rules I had before I rebuilt the box as RHEL7.1 from RHEL6.6 to test. But it wouldn¹t take, so I ended up turning firewalld off during testing since it was behind the other firewall/gateway server. It probably is using UDP for the connections then, I know you can set an option in kerberos to use tcp depending on the packet size, but it still falls back to udp if the attempt fails. The hardware token radius varies on response time depending on which configuration I¹m using on the firewall/gateway machine. If I had them unblock me at the institutional side I can proxy my radius off their radius and the config is identical to another sub-network that works fairly quick, couple seconds at most. The other config uses ldap and takes several seconds since it has to first open the connection, start tls, pass the root certificate, authenticate as the top level for the realm, fetch user information, then rebind as the user with the token. I have not yet tried to use ldap just for the accounting section in my radius with kerberos as the auth mechanism on their side since I¹d probably have to request a radius principal for the firewall/gateway server since I don¹t own the intranet realm, but I expect it to be nearly as slow having to take so many extra steps. I will give setting up firewalld a go then to restrict udp. Since you mentioned that a cross-realm trust is probably better in this case (I could always go back to using ipa-3.x on RHEL6), assuming the following: Some names changed to protect the guilty. Vlans 4-windows, 5-nfs (though I can use for some general traffic as well), 6-management This is to keep certain types of traffic isolated by vlan and restrict user access. Internal networks mostly use 10.vlan.switch.x and are not registered with the institutional kdc. Intranet realm: example.gov (in lowercase unfortunately) My firewall server: mon-gate1.example.gov ‹ external network, internal vlans 5/6 My internal idm: idm2.manage.monitor.net ‹ vlans 4,5,6 full ipa-server realm is MANAGE.MONITOR.NET owns domain manage.monitor.net on vlan 6 and also serves dns for monitor.net on vlan5, I needed a bare-metal dns on the management vlan for vm host machines. My windows ad: mon-ad.windows.monitor.net ‹ vlans 4,5,6, owns domain windows.monitor.net on vlan4 and is a vm. I already have a trust between manage.monitor.net and windows.monitor.net, but not the groups or account mapping since I need consistent uid/gid. I¹m assuming I need to set up a kdc on the firewall/gateway mon-gate1.example.gov, and have idm trust that, or both idm and the ad trust it, but have the kdc on the firewall/gateway trust the example.gov intranet realm. The only place I¹m confused is how to set up the kdc on the gateway as it¹s multi-homed, I¹m assuming it needs to use it¹s own intranet resolvable fqdn but with a different realm name like BRIDGE.MONITOR.NET or something and make sure that krb5.conf indicates that mon-gate1.example.gov is part of the realm. How I get it done isn¹t quite as important is that I can use our hardware token behind the gateway as I¹m required, for security reasons. There is a bit too much complexity to digest in one mail. It would be beneficial to have a diagram and comments around it to try to understand your environment and goals. The only other comment I would make is that trust is not supported in RHEL6.x it is in tech preview and it is done differently in RHEL7 where it is supported. Using 7.1 is recommended. On 5/13/15, 12:00 PM, Nathaniel McCallum npmccal...@redhat.com wrote: On Wed, 2015-05-13 at 14:44 +, Bahmer, Eric Vaughn wrote: Institutionally we have a hardware token set up, you use a pin to unlock the device and it spits out a passcode. The passcode allows access through kerberos, radius, or ldap binds to linux servers, or with a custom apache module to websites. I have an out-of-band private network set up that attaches to our intranet using a firewall/gateway server which does some port forwarding for various things like SSH, RDP. I¹m attempting to set up RADIUS on this firewall/gateway to be used as a proxy for freeipa to our token system which I¹d like to be able to use behind the firewall. However I seem to be getting nearly a dozen requests into the radius server, about half are dropped as duplicate, but usually 3-6 get through and since it¹s a single use token the first attempt succeeds, but the rest fail and cause the hardware token to be blacklisted. Is there a way to specify that the user radius login is a one-time token or is this something that sssd or pam is causing? Or does the OTP support just not work in the way I need it to? I have this issue with both the inbox 4.1.0 in RHEL7.1 or the upstream 4.1.4 rpms. My only alternative is probably to set up a KDC on the
Re: [Freeipa-users] ipa spamming radius with otp token?
I¹ll have to look into the the ports on the idm server then, I¹m not overly familiar with firewalld, I tried to install iptables and use the rules I had before I rebuilt the box as RHEL7.1 from RHEL6.6 to test. But it wouldn¹t take, so I ended up turning firewalld off during testing since it was behind the other firewall/gateway server. It probably is using UDP for the connections then, I know you can set an option in kerberos to use tcp depending on the packet size, but it still falls back to udp if the attempt fails. The hardware token radius varies on response time depending on which configuration I¹m using on the firewall/gateway machine. If I had them unblock me at the institutional side I can proxy my radius off their radius and the config is identical to another sub-network that works fairly quick, couple seconds at most. The other config uses ldap and takes several seconds since it has to first open the connection, start tls, pass the root certificate, authenticate as the top level for the realm, fetch user information, then rebind as the user with the token. I have not yet tried to use ldap just for the accounting section in my radius with kerberos as the auth mechanism on their side since I¹d probably have to request a radius principal for the firewall/gateway server since I don¹t own the intranet realm, but I expect it to be nearly as slow having to take so many extra steps. I will give setting up firewalld a go then to restrict udp. Since you mentioned that a cross-realm trust is probably better in this case (I could always go back to using ipa-3.x on RHEL6), assuming the following: Some names changed to protect the guilty. Vlans 4-windows, 5-nfs (though I can use for some general traffic as well), 6-management This is to keep certain types of traffic isolated by vlan and restrict user access. Internal networks mostly use 10.vlan.switch.x and are not registered with the institutional kdc. Intranet realm: example.gov (in lowercase unfortunately) My firewall server: mon-gate1.example.gov ‹ external network, internal vlans 5/6 My internal idm: idm2.manage.monitor.net ‹ vlans 4,5,6 full ipa-server realm is MANAGE.MONITOR.NET owns domain manage.monitor.net on vlan 6 and also serves dns for monitor.net on vlan5, I needed a bare-metal dns on the management vlan for vm host machines. My windows ad: mon-ad.windows.monitor.net ‹ vlans 4,5,6, owns domain windows.monitor.net on vlan4 and is a vm. I already have a trust between manage.monitor.net and windows.monitor.net, but not the groups or account mapping since I need consistent uid/gid. I¹m assuming I need to set up a kdc on the firewall/gateway mon-gate1.example.gov, and have idm trust that, or both idm and the ad trust it, but have the kdc on the firewall/gateway trust the example.gov intranet realm. The only place I¹m confused is how to set up the kdc on the gateway as it¹s multi-homed, I¹m assuming it needs to use it¹s own intranet resolvable fqdn but with a different realm name like BRIDGE.MONITOR.NET or something and make sure that krb5.conf indicates that mon-gate1.example.gov is part of the realm. How I get it done isn¹t quite as important is that I can use our hardware token behind the gateway as I¹m required, for security reasons. On 5/13/15, 12:00 PM, Nathaniel McCallum npmccal...@redhat.com wrote: On Wed, 2015-05-13 at 14:44 +, Bahmer, Eric Vaughn wrote: Institutionally we have a hardware token set up, you use a pin to unlock the device and it spits out a passcode. The passcode allows access through kerberos, radius, or ldap binds to linux servers, or with a custom apache module to websites. I have an out-of-band private network set up that attaches to our intranet using a firewall/gateway server which does some port forwarding for various things like SSH, RDP. I¹m attempting to set up RADIUS on this firewall/gateway to be used as a proxy for freeipa to our token system which I¹d like to be able to use behind the firewall. However I seem to be getting nearly a dozen requests into the radius server, about half are dropped as duplicate, but usually 3-6 get through and since it¹s a single use token the first attempt succeeds, but the rest fail and cause the hardware token to be blacklisted. Is there a way to specify that the user radius login is a one-time token or is this something that sssd or pam is causing? Or does the OTP support just not work in the way I need it to? I have this issue with both the inbox 4.1.0 in RHEL7.1 or the upstream 4.1.4 rpms. My only alternative is probably to set up a KDC on the firewall to trust the institutional realm and have the IdM kerberos realm trust that. This is also a mixed linux/windows environment behind the firewall, I¹ve enabled unix attributes in my AD and I¹m using a script to sync uid/gid with the external ldap. I do think a cross realm trust is the right way to set this up. However, let's look more closely at the RADIUS issue. First, I want
[Freeipa-users] Replacing HTTP certs with public CA signed wildcard cert
Hi there, I was reading this document regarding using 3rd party certificates in FreeIPA: https://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP Which includes the information The certificate in mysite.crt must be signed by the CA used when installing FreeIPA. Also this thread: http://www.redhat.com/archives/freeipa-users/2014-August/msg00338.html Which says at the end I'm wondering if it's because of this from the doc The certificate in mysite.crt must be signed by the CA used when installing FreeIPA. but it might not either... In this case you should get a file.p12 is not signed by /etc/ipa/ca.crt, or the full certificate chain is not present in the PKCS#12 file error in ipa-server-certinstall. This brings me to my question... If I have an existing multi-server FreeIPA setup with multiple IPA client installations, using a self-signed CA certificate for /etc/ipa/ca.crt, would I need to start over the FreeIPA installation from scratch using the public root CA, which signed the wildcard certificate? Thanks, Dave -- 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] trusted user groups
I've noticed that trusted users supplementary ad groups don't show up until after the users login to the box at least once. Is there a chance that information will be dropped again at any point going forward? The reason I ask is that on our sftp boxes we chroot users based on group membership. I set that up as an external group in freeIPA and the first time the user logs in to the sftp box, they are dropped in their normal home directory as opposed to the chroot environment. If there is a chance the group membership will not show up correctly again in the future, I'm inclined to change the chroot stanzas to match on user as opposed to group. Is that by design? Running sssd-ipa-1.11.6-30.el6_6.4.x86_64 ipa-client-3.0.0-42.el6.x86_64 on RHEL6x clients against a RHEL7 4.1 ipa server thanks -andy *** This communication may contain privileged and/or confidential information. It is intended solely for the use of the addressee. If you are not the intended recipient, you are strictly prohibited from disclosing, copying, distributing or using any of this information. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. *** -- 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] Configuration of CA failed
On 14/05/15 13:54, Remigio Moncayo Serrano wrote: I fail to see the problem in the logs so I’m attaching the file here *De:*Martin Basti [mailto:mba...@redhat.com] *Enviado el:* jueves, 14 de mayo de 2015 13:05 *Para:* Remigio Moncayo Serrano; freeipa-users@redhat.com *Asunto:* Re: [Freeipa-users] Configuration of CA failed On 14/05/15 11:58, Remigio Moncayo Serrano wrote: Hello, I’ve been put in charge of implementing a solution that uses LDAP and kerberos authentication. At first thought I should use openLDAP and Kerberos but found freeIPA and looks really cool, however, when trying to install I keep getting this error about configuration of CA: The following operations may take some minutes to complete. Please wait until the prompt is returned. Configuring NTP daemon (ntpd) [1/4]: stopping ntpd [2/4]: writing configuration [3/4]: configuring ntpd to start on boot [4/4]: starting ntpd Done configuring NTP daemon (ntpd). Configuring directory server for the CA (pkids): Estimated time 30 seconds [1/3]: creating directory server user [2/3]: creating directory server instance [3/3]: restarting directory server ipa : CRITICAL Failed to restart the directory server. See the installation log for details. Done configuring directory server for the CA (pkids). Configuring certificate server (pki-cad): Estimated time 3 minutes 30 seconds [1/20]: creating certificate server user [2/20]: configuring certificate server instance ipa : CRITICAL failed to configure ca instance Command '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname ipatest.ingenia.local -cs_port 9445 -client_certdb_dir /tmp/tmp-ARezzO -client_certdb_pwd -preop_pin f0dLhx9bLX5qWHYx50h6 -domain_name IPA -admin_user admin -admin_email root@localhost -admin_password -agent_name ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa -agent_cert_subject CN=ipa-ca-agent,O=INGENIA.LOCAL -ldap_host ipatest.ingenia.local -ldap_port 7389 -bind_dn cn=Directory Manager -bind_password -base_dn o=ipaca -db_name ipaca -key_size 2048 -key_type rsa -key_algorithm SHA256withRSA -save_p12 true -backup_pwd -subsystem_name pki-cad -token_name internal -ca_subsystem_cert_subject_name CN=CA Subsystem,O=INGENIA.LOCAL -ca_subsystem_cert_subject_name CN=CA Subsystem,O=INGENIA.LOCAL -ca_ocsp_cert_subject_name CN=OCSP Subsystem,O=INGENIA.LOCAL -ca_server_cert_subject_name CN=ipatest.ingenia.local,O=INGENIA.LOCAL -ca_audit_signing_cert_subject_name CN=CA Audit,O=INGENIA.LOCAL -ca_sign_cert_subject_name CN=Certificate Authority,O=INGENIA.LOCAL -external false -clone false' returned non-zero exit status 255 Configuration of CA failed I’m including two install logs, one with dns-setup and the other without it. Don’t really know what I’m doing wrong, thought maybe I should allow connections to certain ports in ip tables or something but have no clue really and I’m quite new to this, help please.. Regards, Remigio Hello, can you please check error logs of DS? /var/log/dirsrv/slapd-*/errors And please post here an error why DS restart failed. Martin -- Martin Basti indeed, log looks good. There is some issue that IPA cannot verify DS on port 7389. Can you answer the questions asked by Martin Kosek, please? Martin -- Martin Basti -- 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] trusted user groups
On Thu, May 14, 2015 at 03:33:28PM +, Andy Thompson wrote: I've noticed that trusted users supplementary ad groups don't show up until after the users login to the box at least once. That's expected with the versions you're running. Prior to 6.7, we could only read the trusted users' group membership from the PAC blob attached to the Kerberos ticket. Is there a chance that information will be dropped again at any point going forward? No, otherwise it's a bug. The reason I ask is that on our sftp boxes we chroot users based on group membership. I set that up as an external group in freeIPA and the first time the user logs in to the sftp box, they are dropped in their normal home directory as opposed to the chroot environment. If there is a chance the group membership will not show up correctly again in the future, I'm inclined to change the chroot stanzas to match on user as opposed to group. Is that by design? If you can't see the correct group memberships after a login, then something is fishy. However, we're rebasing to sssd 1.12.x in 6.7 and there's so many fixes and enhancements in this area..is there a chance you could try out 6.7 beta or some custom packages? Running sssd-ipa-1.11.6-30.el6_6.4.x86_64 ipa-client-3.0.0-42.el6.x86_64 on RHEL6x clients against a RHEL7 4.1 ipa server thanks -andy *** This communication may contain privileged and/or confidential information. It is intended solely for the use of the addressee. If you are not the intended recipient, you are strictly prohibited from disclosing, copying, distributing or using any of this information. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. *** -- 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] trusted user groups
-Original Message- From: freeipa-users-boun...@redhat.com [mailto:freeipa-users- boun...@redhat.com] On Behalf Of Jakub Hrozek Sent: Thursday, May 14, 2015 11:46 AM To: freeipa-users@redhat.com Subject: Re: [Freeipa-users] trusted user groups On Thu, May 14, 2015 at 03:33:28PM +, Andy Thompson wrote: I've noticed that trusted users supplementary ad groups don't show up until after the users login to the box at least once. That's expected with the versions you're running. Prior to 6.7, we could only read the trusted users' group membership from the PAC blob attached to the Kerberos ticket. Is there a chance that information will be dropped again at any point going forward? No, otherwise it's a bug. The reason I ask is that on our sftp boxes we chroot users based on group membership. I set that up as an external group in freeIPA and the first time the user logs in to the sftp box, they are dropped in their normal home directory as opposed to the chroot environment. If there is a chance the group membership will not show up correctly again in the future, I'm inclined to change the chroot stanzas to match on user as opposed to group. Is that by design? If you can't see the correct group memberships after a login, then something is fishy. However, we're rebasing to sssd 1.12.x in 6.7 and there's so many fixes and enhancements in this area..is there a chance you could try out 6.7 beta or some custom packages? Group memberships show up fine after the first login so it is working as expected then. The accounts are very controlled so it shouldn't be a huge sticking point. I could try out some custom packages on this box but I can't move to 6.7 until we upgrade the entire environment. Thanks much -andy -- 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] Replication Update in progress : FALSE LDAP ERROR
On 05/14/2015 04:58 AM, nat...@nathanpeters.com wrote:
I have tried to setup synchronization between a FreeIPA domain and an AD
domain. The certificates are in the right place.
[root@ipadc1 ~]# ipa-replica-manage connect --winsync --binddn cn=sync
user,cn=Users,dc=datacenter,dc=addomain,dc=net --bindpw secretpassword
--passsync secretpassword --cacert
/etc/openldap/cacerts/addc1-datacenter.cer addc1.datacenter.addomain.net
-v
Directory Manager password:
Added CA certificate /etc/openldap/cacerts/addc1-datacenter.cer to
certificate database for ipadc1.ipadomain.net
ipa: INFO: AD Suffix is: DC=datacenter,DC=addomain,DC=net
The user for the Windows PassSync service is
uid=passsync,cn=sysaccounts,cn=etc,dc=ipadomain,dc=net
Windows PassSync system account exists, not resetting password
ipa: INFO: Added new sync agreement, waiting for it to become ready . .
.
ipa: INFO: Replication Update in progress: FALSE: status: -11 - LDAP
error: Connect error: start: 0: end: 0
ipa: INFO: Agreement is ready, starting replication . . .
Starting replication, please wait until this has completed.
[ipadc1.ipadomain.net] reports: Update failed! Status: [-11 - LDAP
error:
Connect error]
Failed to start replication
This is the system journal while the failure is happening
May 14 02:50:39 ipadc1.ipadomain.net systemd[1]: Stopping 389 Directory
Server IPADOMAIN-NET
May 14 02:50:41 ipadc1.ipadomain.net named-pkcs11[5594]: LDAP error:
Can't
contact LDAP server: ldap_sync_poll() failed
May 14 02:50:41 ipadc1.ipadomain.net named-pkcs11[5594]: ldap_syncrepl
will reconnect in 60 seconds
May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: ipa
:
ERRORsyncrepl_poll: LDAP error ({'desc': Can't contact LDAP
server})
May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: Traceback
(most recent call last):
May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: File
/usr/libexec/ipa/ipa-dnskeysyncd, line 106, in module
May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: while
ldap_connection.syncrepl_poll(all=1, msgid=ldap_search):
May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: File
/usr/lib64/python2.7/site-packages/ldap/syncrepl.py, line 349, in
syncrepl_poll
May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]:
add_intermediates=1, add_ctrls=1, all = 0
May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: File
/usr/lib64/python2.7/site-packages/ldap/ldapobject.py, line 483, in
result4
May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: ldap_result
=
self._ldap_call(self._l.result4,msgid,all,timeout,add_ctrls,add_intermediates,add_extop)
May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: File
/usr/lib64/python2.7/site-packages/ldap/ldapobject.py, line 106, in
_ldap_call
May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: result =
func(*args,**kwargs)
May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: SERVER_DOWN:
{'desc': Can't contact LDAP server}
May 14 02:50:41 ipadc1.ipadomain.net systemd[1]:
ipa-dnskeysyncd.service:
main process exited, code=exited, status=1/FAILURE
May 14 02:50:41 ipadc1.ipadomain.net systemd[1]: Unit
ipa-dnskeysyncd.service entered failed state.
May 14 02:50:41 ipadc1.ipadomain.net systemd[1]: Stopped 389 Directory
Server IPADOMAIN-NET..
May 14 02:50:41 ipadc1.ipadomain.net systemd[1]: Starting 389 Directory
Server IPADOMAIN-NET
May 14 02:50:41 ipadc1.ipadomain.net systemd[1]: Started 389 Directory
Server IPADOMAIN-NET..
May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]:
[14/May/2015:02:50:41
+] SSL Initialization - Configured SSL version range: min: TLS1.0,
max: TLS1.2
May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]:
[14/May/2015:02:50:41
+] - SSL alert: Configured NSS Ciphers
May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]:
[14/May/2015:02:50:41
+] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256:
enabled
May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]:
[14/May/2015:02:50:41
+] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256:
enabled
May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]:
[14/May/2015:02:50:41
+] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA:
enabled
May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]:
[14/May/2015:02:50:41
+] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA:
enabled
May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]:
[14/May/2015:02:50:41
+] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA: enabled
May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]:
[14/May/2015:02:50:41
+] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256:
enabled
May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]:
[14/May/2015:02:50:41
+] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256:
enabled
May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]:
[14/May/2015:02:50:41
+] - SSL
Re: [Freeipa-users] External Self Help Suggestions.
Hi Dmitri, No I am sticking to the 90 day, gotta start the change in the right direction somewhere :). So I am trying out LBT Self service password, and I am wondering if there is documentation anywhere on how to create a service style account that has the ability to change a password without forcing the user to reset thier password on next login. This would be for if a user forgets thier password and uses a mail token style auth. Thanks, Bill On 5/13/15 5:28 PM, Dmitri Pal wrote: On 05/13/2015 08:18 PM, William Graboyes wrote: Hi Dmitri, That is quite a bucket of stuff... On the CA-less install, basically I don't want to have my users change their passwords again (they are complaining about the every 90 day password rotation policy), we do not have an internal CA, most of our desk top support folks don't even have access to all of the desktops in the place. Like I said this place is mind bending when it comes to standard practices. The CA-less would be good if it were possible to make that change in place, or make the change by standing up a new IPA server and having the ability to import the current data set. I was looking at PWM, and may try to get that implemented. Another option is to reset expiration time in the user entry and set it some date close to 2038 which is the end of the 32-bit time. If the problem is 90 day policy you can just change the policy to be 5000 days and then next time people change password they would not be bother for another 5000 days or so (make sure it does not roll over). For people that already have 90 days in their entry you can run a script once and move the date into the future. People have done it for the same reason and in the same way. Thanks, Bill On 5/13/15 5:00 PM, Dmitri Pal wrote: On 05/13/2015 07:40 PM, William Graboyes wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi List, I am trying to figure out a method of allowing users who do not have shell access to change their own passwords. The GUI that comes with FreeIPA is out of the question due to the untrusted CA (yes I know we are a strange shop, there is nothing I can do about it, and you would want to gouge you eyes out if I told you the full story) becoming a Bad habit forming method of changing one's password. I have been looking around for about a week now, and am somewhat lost and perplexed. The old documentation for FreeIPA basically says that it is not a good idea to manipulate the password directly in LDAP (and even then finding what hash is being used has been next to impossible). So the question is this, does anyone know of any tools out there that can happily, or even with some modification, allow me to set up a trusted external ssl site that allows users to change their passwords. There is no external password reset self service in IPA yet. We will be starting to look into this effort during summer. Take a look at the bucket of tickets in the FreeIPA Community Portal Release here https://fedorahosted.org/freeipa/report/3. What prevents you from making IPA trusted? You can chain IPA to your CA or use it CA-less with certs from your own CA. Then UI would be an option I assume. Other option is https://code.google.com/p/pwm/ Thanks, Bill -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVU+DdAAoJEJFMz73A1+zryTIP/1dLBYfMwSNkvICW8PToUkD6 MCQQt+yGblI2gqZiVm2NCHD4Lto4sDUJSdnQF++kcuCTd0u4P5twFR/LejIAa/Jc bKCO7XSmfBEh/+ArVeUBSsoBec2V0h6x3i98mChD55DzuRJj4HiIxGgM1KdeAgaV UdwI9wQEKOUCyHZyDVdEk/g+X1QMnNBPUXhdEiHtAkbqkxSan01iw2k1mGjfIOWU NfOThdj7K9vE18YIKuJ7L/uztvNyAaj+ZsR1uKayYxlpgMalUJDHW1u3gX2MPELm zpDWVj7mR0iZ78AJlSG0J7+ughBMq5jarlzdCYTHmFqe0dszmafDAdxIBKmWw+IW /BXIMDTR/CjoPW4D65fewEcqIVrODDft6GNDg7aYa0dF8eiOjQM3wNUVjmgBESBK ztcGuFID+bl96+GABuSo9OFS36/dKskhGK125gvpEgU8pWM4+POQDtWlHjFHw5Ml 1ZCZHxrQOp/drolh50uMTl6QrZSKt0U3Kikw+zzj5itAEtbhVrnfw7nvJHlhPsy/ 7CG2WMv/iwXzif+ogSN6ClkOxSTqHftS2BW9uMP7meLNK0tRiCtTVSXSXIizTR96 ZbCb9zbETfHYj2KE3nLeKAeycaN15+8NK1YgVYEh+ZqbsgdFgD6src6X/NP3v3dX kzyr3+tqYdDbgibcYyhd =5KCr -END PGP SIGNATURE- -- 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] Replication Update in progress : FALSE LDAP ERROR
On 05/14/2015 05:43 PM, nat...@nathanpeters.com wrote:
On 05/14/2015 04:58 AM, nat...@nathanpeters.com wrote:
I have tried to setup synchronization between a FreeIPA domain and an AD
domain. The certificates are in the right place.
[root@ipadc1 ~]# ipa-replica-manage connect --winsync --binddn cn=sync
user,cn=Users,dc=datacenter,dc=addomain,dc=net --bindpw secretpassword
--passsync secretpassword --cacert
/etc/openldap/cacerts/addc1-datacenter.cer addc1.datacenter.addomain.net
-v
Directory Manager password:
Added CA certificate /etc/openldap/cacerts/addc1-datacenter.cer to
certificate database for ipadc1.ipadomain.net
ipa: INFO: AD Suffix is: DC=datacenter,DC=addomain,DC=net
The user for the Windows PassSync service is
uid=passsync,cn=sysaccounts,cn=etc,dc=ipadomain,dc=net
Windows PassSync system account exists, not resetting password
ipa: INFO: Added new sync agreement, waiting for it to become ready . .
.
ipa: INFO: Replication Update in progress: FALSE: status: -11 - LDAP
error: Connect error: start: 0: end: 0
ipa: INFO: Agreement is ready, starting replication . . .
Starting replication, please wait until this has completed.
[ipadc1.ipadomain.net] reports: Update failed! Status: [-11 - LDAP
error:
Connect error]
Failed to start replication
This is the system journal while the failure is happening
May 14 02:50:39 ipadc1.ipadomain.net systemd[1]: Stopping 389 Directory
Server IPADOMAIN-NET
May 14 02:50:41 ipadc1.ipadomain.net named-pkcs11[5594]: LDAP error:
Can't
contact LDAP server: ldap_sync_poll() failed
May 14 02:50:41 ipadc1.ipadomain.net named-pkcs11[5594]: ldap_syncrepl
will reconnect in 60 seconds
May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: ipa
:
ERRORsyncrepl_poll: LDAP error ({'desc': Can't contact LDAP
server})
May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: Traceback
(most recent call last):
May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: File
/usr/libexec/ipa/ipa-dnskeysyncd, line 106, in module
May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: while
ldap_connection.syncrepl_poll(all=1, msgid=ldap_search):
May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: File
/usr/lib64/python2.7/site-packages/ldap/syncrepl.py, line 349, in
syncrepl_poll
May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]:
add_intermediates=1, add_ctrls=1, all = 0
May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: File
/usr/lib64/python2.7/site-packages/ldap/ldapobject.py, line 483, in
result4
May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: ldap_result
=
self._ldap_call(self._l.result4,msgid,all,timeout,add_ctrls,add_intermediates,add_extop)
May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: File
/usr/lib64/python2.7/site-packages/ldap/ldapobject.py, line 106, in
_ldap_call
May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: result =
func(*args,**kwargs)
May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: SERVER_DOWN:
{'desc': Can't contact LDAP server}
May 14 02:50:41 ipadc1.ipadomain.net systemd[1]:
ipa-dnskeysyncd.service:
main process exited, code=exited, status=1/FAILURE
May 14 02:50:41 ipadc1.ipadomain.net systemd[1]: Unit
ipa-dnskeysyncd.service entered failed state.
May 14 02:50:41 ipadc1.ipadomain.net systemd[1]: Stopped 389 Directory
Server IPADOMAIN-NET..
May 14 02:50:41 ipadc1.ipadomain.net systemd[1]: Starting 389 Directory
Server IPADOMAIN-NET
May 14 02:50:41 ipadc1.ipadomain.net systemd[1]: Started 389 Directory
Server IPADOMAIN-NET..
May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]:
[14/May/2015:02:50:41
+] SSL Initialization - Configured SSL version range: min: TLS1.0,
max: TLS1.2
May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]:
[14/May/2015:02:50:41
+] - SSL alert: Configured NSS Ciphers
May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]:
[14/May/2015:02:50:41
+] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256:
enabled
May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]:
[14/May/2015:02:50:41
+] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256:
enabled
May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]:
[14/May/2015:02:50:41
+] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA:
enabled
May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]:
[14/May/2015:02:50:41
+] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA:
enabled
May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]:
[14/May/2015:02:50:41
+] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA: enabled
May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]:
[14/May/2015:02:50:41
+] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256:
enabled
May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]:
[14/May/2015:02:50:41
+] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256:
enabled
May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]:
[14/May/2015:02:50:41
+] - SSL alert: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA:
Re: [Freeipa-users] Replication Update in progress : FALSE LDAP ERROR
On 05/14/2015 04:58 AM, nat...@nathanpeters.com wrote:
I have tried to setup synchronization between a FreeIPA domain and an AD
domain. The certificates are in the right place.
[root@ipadc1 ~]# ipa-replica-manage connect --winsync --binddn cn=sync
user,cn=Users,dc=datacenter,dc=addomain,dc=net --bindpw secretpassword
--passsync secretpassword --cacert
/etc/openldap/cacerts/addc1-datacenter.cer addc1.datacenter.addomain.net
-v
Directory Manager password:
Added CA certificate /etc/openldap/cacerts/addc1-datacenter.cer to
certificate database for ipadc1.ipadomain.net
ipa: INFO: AD Suffix is: DC=datacenter,DC=addomain,DC=net
The user for the Windows PassSync service is
uid=passsync,cn=sysaccounts,cn=etc,dc=ipadomain,dc=net
Windows PassSync system account exists, not resetting password
ipa: INFO: Added new sync agreement, waiting for it to become ready . .
.
ipa: INFO: Replication Update in progress: FALSE: status: -11 - LDAP
error: Connect error: start: 0: end: 0
ipa: INFO: Agreement is ready, starting replication . . .
Starting replication, please wait until this has completed.
[ipadc1.ipadomain.net] reports: Update failed! Status: [-11 - LDAP
error:
Connect error]
Failed to start replication
This is the system journal while the failure is happening
May 14 02:50:39 ipadc1.ipadomain.net systemd[1]: Stopping 389 Directory
Server IPADOMAIN-NET
May 14 02:50:41 ipadc1.ipadomain.net named-pkcs11[5594]: LDAP error:
Can't
contact LDAP server: ldap_sync_poll() failed
May 14 02:50:41 ipadc1.ipadomain.net named-pkcs11[5594]: ldap_syncrepl
will reconnect in 60 seconds
May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: ipa
:
ERRORsyncrepl_poll: LDAP error ({'desc': Can't contact LDAP
server})
May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: Traceback
(most recent call last):
May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: File
/usr/libexec/ipa/ipa-dnskeysyncd, line 106, in module
May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: while
ldap_connection.syncrepl_poll(all=1, msgid=ldap_search):
May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: File
/usr/lib64/python2.7/site-packages/ldap/syncrepl.py, line 349, in
syncrepl_poll
May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]:
add_intermediates=1, add_ctrls=1, all = 0
May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: File
/usr/lib64/python2.7/site-packages/ldap/ldapobject.py, line 483, in
result4
May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: ldap_result
=
self._ldap_call(self._l.result4,msgid,all,timeout,add_ctrls,add_intermediates,add_extop)
May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: File
/usr/lib64/python2.7/site-packages/ldap/ldapobject.py, line 106, in
_ldap_call
May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: result =
func(*args,**kwargs)
May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: SERVER_DOWN:
{'desc': Can't contact LDAP server}
May 14 02:50:41 ipadc1.ipadomain.net systemd[1]:
ipa-dnskeysyncd.service:
main process exited, code=exited, status=1/FAILURE
May 14 02:50:41 ipadc1.ipadomain.net systemd[1]: Unit
ipa-dnskeysyncd.service entered failed state.
May 14 02:50:41 ipadc1.ipadomain.net systemd[1]: Stopped 389 Directory
Server IPADOMAIN-NET..
May 14 02:50:41 ipadc1.ipadomain.net systemd[1]: Starting 389 Directory
Server IPADOMAIN-NET
May 14 02:50:41 ipadc1.ipadomain.net systemd[1]: Started 389 Directory
Server IPADOMAIN-NET..
May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]:
[14/May/2015:02:50:41
+] SSL Initialization - Configured SSL version range: min: TLS1.0,
max: TLS1.2
May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]:
[14/May/2015:02:50:41
+] - SSL alert: Configured NSS Ciphers
May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]:
[14/May/2015:02:50:41
+] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256:
enabled
May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]:
[14/May/2015:02:50:41
+] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256:
enabled
May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]:
[14/May/2015:02:50:41
+] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA:
enabled
May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]:
[14/May/2015:02:50:41
+] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA:
enabled
May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]:
[14/May/2015:02:50:41
+] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA: enabled
May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]:
[14/May/2015:02:50:41
+] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256:
enabled
May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]:
[14/May/2015:02:50:41
+] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256:
enabled
May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]:
[14/May/2015:02:50:41
+] - SSL
Re: [Freeipa-users] Configuration of CA failed
On 14/05/15 11:58, Remigio Moncayo Serrano wrote: Hello, I’ve been put in charge of implementing a solution that uses LDAP and kerberos authentication. At first thought I should use openLDAP and Kerberos but found freeIPA and looks really cool, however, when trying to install I keep getting this error about configuration of CA: The following operations may take some minutes to complete. Please wait until the prompt is returned. Configuring NTP daemon (ntpd) [1/4]: stopping ntpd [2/4]: writing configuration [3/4]: configuring ntpd to start on boot [4/4]: starting ntpd Done configuring NTP daemon (ntpd). Configuring directory server for the CA (pkids): Estimated time 30 seconds [1/3]: creating directory server user [2/3]: creating directory server instance [3/3]: restarting directory server ipa : CRITICAL Failed to restart the directory server. See the installation log for details. Done configuring directory server for the CA (pkids). Configuring certificate server (pki-cad): Estimated time 3 minutes 30 seconds [1/20]: creating certificate server user [2/20]: configuring certificate server instance ipa : CRITICAL failed to configure ca instance Command '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname ipatest.ingenia.local -cs_port 9445 -client_certdb_dir /tmp/tmp-ARezzO -client_certdb_pwd -preop_pin f0dLhx9bLX5qWHYx50h6 -domain_name IPA -admin_user admin -admin_email root@localhost -admin_password -agent_name ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa -agent_cert_subject CN=ipa-ca-agent,O=INGENIA.LOCAL -ldap_host ipatest.ingenia.local -ldap_port 7389 -bind_dn cn=Directory Manager -bind_password -base_dn o=ipaca -db_name ipaca -key_size 2048 -key_type rsa -key_algorithm SHA256withRSA -save_p12 true -backup_pwd -subsystem_name pki-cad -token_name internal -ca_subsystem_cert_subject_name CN=CA Subsystem,O=INGENIA.LOCAL -ca_subsystem_cert_subject_name CN=CA Subsystem,O=INGENIA.LOCAL -ca_ocsp_cert_subject_name CN=OCSP Subsystem,O=INGENIA.LOCAL -ca_server_cert_subject_name CN=ipatest.ingenia.local,O=INGENIA.LOCAL -ca_audit_signing_cert_subject_name CN=CA Audit,O=INGENIA.LOCAL -ca_sign_cert_subject_name CN=Certificate Authority,O=INGENIA.LOCAL -external false -clone false' returned non-zero exit status 255 Configuration of CA failed I’m including two install logs, one with dns-setup and the other without it. Don’t really know what I’m doing wrong, thought maybe I should allow connections to certain ports in ip tables or something but have no clue really and I’m quite new to this, help please.. Regards, Remigio Hello, can you please check error logs of DS? /var/log/dirsrv/slapd-*/errors And please post here an error why DS restart failed. Martin -- Martin Basti -- 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] Replication Update in progress : FALSE LDAP ERROR
[root@ipadc1 cacerts]# ipa-replica-manage connect --winsync --binddn cn=ad sync,cn=Users,dc=test,dc=mycompany,dc=net --bindpw supersecretpassword --passsync supersecretpassword --cacert /etc/openldap/cacerts/addc2-test.cer addc2.test.mycompany.net -v Directory Manager password: Added CA certificate /etc/openldap/cacerts/addc2-test.cer to certificate database for ipadc1.ipadomain.net ipa: INFO: AD Suffix is: DC=test,DC=mycompany,DC=net The user for the Windows PassSync service is uid=passsync,cn=sysaccounts,cn=etc,dc=ipadomain,dc=net Windows PassSync system account exists, not resetting password ipa: INFO: Added new sync agreement, waiting for it to become ready . . . ipa: INFO: Replication Update in progress: FALSE: status: -11 - LDAP error: Connect error: start: 0: end: 0 ipa: INFO: Agreement is ready, starting replication . . . Starting replication, please wait until this has completed. [ipadc1.ipadomain.net] reports: Update failed! Status: [-11 - LDAP error: Connect error] Have you tried using ldapsearch to verify the connection? # LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-DOMAIN-COM ldapsearch -xLLL -ZZ -h addc2.test.mycompany.net -D cn=ad sync,cn=Users,dc=test,dc=mycompany,dc=net -w supersecretpassword -s base -b cn=Users,dc=test,dc=mycompany,dc=net objectclass=* and/or # LDAPTLS_CACERT=/etc/openldap/cacerts/addc2-test.cer ldapsearch -xLLL -ZZ -h addc2.test.mycompany.net -D cn=ad sync,cn=Users,dc=test,dc=mycompany,dc=net -w supersecretpassword -s base -b cn=Users,dc=test,dc=mycompany,dc=net objectclass=* Both commands give the same successful result. I don't think it's a problem with the credentials because I was able to generate different error messages during the attempted sync setup if I intentionally gave a bad password or username. Here is what happens when I run the above commands : [root@ipadc1 cacerts]# LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-DOMAIN-COM ldapsearch -xLLL -ZZ -h addc2.test.mycompany.net -D cn=ad sync,cn=Users,dc=test,dc=mycompany,dc=net -w supersecretpassword -s base -b cn=Users,dc=test,dc=mycompany,dc=net objectclass=* dn: cn=Users,dc=test,dc=mycompany,dc=net objectClass: top objectClass: container cn: Users description: Default container for upgraded user accounts distinguishedName: CN=Users,DC=test,DC=mycompany,DC=net instanceType: 4 whenCreated: 20150515024307.0Z whenChanged: 20150515024307.0Z uSNCreated: 5696 uSNChanged: 5696 showInAdvancedViewOnly: FALSE name: Users objectGUID:: V9KaoufynkWbJpSo2PjxiA== systemFlags: -1946157056 objectCategory: CN=Container,CN=Schema,CN=Configuration,DC=test,DC=mycompany,DC=net isCriticalSystemObject: TRUE dSCorePropagationData: 20150515025646.0Z dSCorePropagationData: 1601010101.0Z [root@ipadc1 cacerts]# LDAPTLS_CACERT=/etc/openldap/cacerts/addc2-test.cer ldapsearch -xLLL -ZZ -h addc2.test.mycompany.net -D cn=ad sync,cn=Users,dc=test,dc=mycompany,dc=net -w supersecretpassword -s base -b cn=Users,dc=test,dc=mycompany,dc=net objectclass=* dn: cn=Users,dc=test,dc=mycompany,dc=net objectClass: top objectClass: container cn: Users description: Default container for upgraded user accounts distinguishedName: CN=Users,DC=test,DC=mycompany,DC=net instanceType: 4 whenCreated: 20150515024307.0Z whenChanged: 20150515024307.0Z uSNCreated: 5696 uSNChanged: 5696 showInAdvancedViewOnly: FALSE name: Users objectGUID:: V9KaoufynkWbJpSo2PjxiA== systemFlags: -1946157056 objectCategory: CN=Container,CN=Schema,CN=Configuration,DC=test,DC=mycompany,DC=net isCriticalSystemObject: TRUE dSCorePropagationData: 20150515025646.0Z dSCorePropagationData: 1601010101.0Z -- 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] FreeIPA server in Docker container improved
On Wed, Apr 08, 2015 at 02:42:38PM +0200, Jan Pazdziora wrote: The ability to run FreeIPA server in a container was recently improved by adding support for storing the server configuration and data in a volume, making it easier to backup the server, upgrade it to newer versions, as well as adding the ability to start a container as a replica of existing (containerized or non-containerized) IPA server. Using IPA in a container can be an easy way to try IPA or test things on different OSes (there are multiple per-OS branches in the GitHub repo and multiple images built), as well as running IPA on a machine where it would otherwise clash with other software. It it still an unsupported release but working in multiple tests on our side, so we encourage our community members to try it out. We will welcome your comments about your experience with the code at https://github.com/adelton/docker-freeipa I gave presentation on EurOpen conference yesterday about the FreeIPA containerization work: http://www.adelton.com/docs/docker/nontrivial-application-in-container It explains the approach and the reasons for the layout of the image. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] Problems with failed upgrade: groups are not created
On 14/05/15 01:50, Will Sheldon wrote: Hello everyone :) We are seeing some strange behavior (created groups don't exist) and I really hope someone can lend some advice... We installed v 3.0 some time ago, and tried an upgrade to 3.3 which was aborted before completion, however I believe the schema was updated. Recently we attempted to upgrade to 4.1, but encountered some issues with the upgrade; replication failed : from the install log (before schema update, so server was running 3.3 schema): === Done configuring ipa-otpd. Applying LDAP updates ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERRORAdd failure attribute cn not allowed === After that we tried updating the schema, and we now get this error (we have log file captures for this): === [24/35]: setting up initial replication Starting replication, please wait until this has completed. Update in progress, 131 seconds elapsed Update in progress yet not in progress [vanipa.foo.com http://vanipa.foo.com] reports: Update failed! Status: [10 Total update abortedLDAP error: Referral] [error] RuntimeError: Failed to start replication Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. which seems to be referring to this bit of the log: === 2015-04-21T19:18:48Z DEBUG Traceback (most recent call last): File /usr/lib/python2.7/site-packages/ipaserver/install/service.py, line 382, in start_creation run_step(full_msg, method) === Since then we have a somewhat strange issue where new groups that are added using the web interface and ipa CLI command interface are created in the compat tree, but not in the cn=hostgroups,cn=accounts tree, even though ADD operations appear to complete successfully (slapd log output below) === [13/May/2015:23:13:58 +] conn=7120402 op=4 ADD dn=cn=p-test-100,cn=hostgroups,cn=accounts,dc=foo,dc=com [13/May/2015:23:13:58 +] conn=2616653 op=3660217 SRCH base=idnsName=net,idnsname=bar.net http://bar.net,cn=dns,dc=foo,dc=com scope=0 filter=(objectClass=idnsRecord) attrs=ALL [13/May/2015:23:13:58 +] conn=2616653 op=3660217 RESULT err=32 tag=101 nentries=0 etime=0 [13/May/2015:23:13:58 +] conn=2616653 op=3660218 SRCH base=idnsName=bar.net http://bar.net,idnsname=bar.net http://bar.net,cn=dns,dc=foo,dc=com scope=0 filter=(objectClass=idnsRecord) attrs=ALL [13/May/2015:23:13:58 +] conn=2616653 op=3660218 RESULT err=32 tag=101 nentries=0 etime=0 [13/May/2015:23:13:58 +] conn=2616653 op=3660219 SRCH base=idnsName=vanzbx.bar.net http://vanzbx.bar.net,idnsname=bar.net http://bar.net,cn=dns,dc=foo,dc=com scope=0 filter=(objectClass=idnsRecord) attrs=ALL [13/May/2015:23:13:58 +] conn=2616653 op=3660219 RESULT err=32 tag=101 nentries=0 etime=0 [13/May/2015:23:13:58 +] conn=2616653 op=3660220 SRCH base=idnsName=net,idnsname=bar.net http://bar.net,cn=dns,dc=foo,dc=com scope=0 filter=(objectClass=idnsRecord) attrs=ALL [13/May/2015:23:13:58 +] conn=2616653 op=3660220 RESULT err=32 tag=101 nentries=0 etime=0 [13/May/2015:23:13:58 +] conn=2616653 op=3660221 SRCH base=idnsName=bar.net http://bar.net,idnsname=bar.net http://bar.net,cn=dns,dc=foo,dc=com scope=0 filter=(objectClass=idnsRecord) attrs=ALL [13/May/2015:23:13:58 +] conn=2616653 op=3660221 RESULT err=32 tag=101 nentries=0 etime=0 [13/May/2015:23:13:58 +] conn=2616653 op=3660222 SRCH base=idnsName=vanzbx.bar.net http://vanzbx.bar.net,idnsname=bar.net http://bar.net,cn=dns,dc=foo,dc=com scope=0 filter=(objectClass=idnsRecord) attrs=ALL [13/May/2015:23:13:58 +] conn=2616653 op=3660222 RESULT err=32 tag=101 nentries=0 etime=0 [13/May/2015:23:13:58 +] conn=7120402 op=4 RESULT err=0 tag=105 nentries=0 etime=0 csn=5553e3f800010004 === Which is consistent with the slapd log during the upgrade: [21/Apr/2015:19:18:43 +] NSACLPlugin - The ACL target cn=hr,cn=groups,cn=accounts,dc=foo,dc=com does not exist -- Kind regards, Will Sheldon Hello, can you find in ipaserver-install.log more details about this error? ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERRORAdd failure attribute cn not allowed Martin -- Martin Basti -- 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] Replication Update in progress : FALSE LDAP ERROR
On 05/14/2015 04:58 AM, nat...@nathanpeters.com wrote:
I have tried to setup synchronization between a FreeIPA domain and an AD
domain. The certificates are in the right place.
[root@ipadc1 ~]# ipa-replica-manage connect --winsync --binddn cn=sync
user,cn=Users,dc=datacenter,dc=addomain,dc=net --bindpw secretpassword
--passsync secretpassword --cacert
/etc/openldap/cacerts/addc1-datacenter.cer addc1.datacenter.addomain.net
-v
Directory Manager password:
Added CA certificate /etc/openldap/cacerts/addc1-datacenter.cer to
certificate database for ipadc1.ipadomain.net
ipa: INFO: AD Suffix is: DC=datacenter,DC=addomain,DC=net
The user for the Windows PassSync service is
uid=passsync,cn=sysaccounts,cn=etc,dc=ipadomain,dc=net
Windows PassSync system account exists, not resetting password
ipa: INFO: Added new sync agreement, waiting for it to become ready . . .
ipa: INFO: Replication Update in progress: FALSE: status: -11 - LDAP
error: Connect error: start: 0: end: 0
ipa: INFO: Agreement is ready, starting replication . . .
Starting replication, please wait until this has completed.
[ipadc1.ipadomain.net] reports: Update failed! Status: [-11 - LDAP error:
Connect error]
Failed to start replication
This is the system journal while the failure is happening
May 14 02:50:39 ipadc1.ipadomain.net systemd[1]: Stopping 389 Directory
Server IPADOMAIN-NET
May 14 02:50:41 ipadc1.ipadomain.net named-pkcs11[5594]: LDAP error: Can't
contact LDAP server: ldap_sync_poll() failed
May 14 02:50:41 ipadc1.ipadomain.net named-pkcs11[5594]: ldap_syncrepl
will reconnect in 60 seconds
May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: ipa :
ERRORsyncrepl_poll: LDAP error ({'desc': Can't contact LDAP server})
May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: Traceback
(most recent call last):
May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: File
/usr/libexec/ipa/ipa-dnskeysyncd, line 106, in module
May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: while
ldap_connection.syncrepl_poll(all=1, msgid=ldap_search):
May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: File
/usr/lib64/python2.7/site-packages/ldap/syncrepl.py, line 349, in
syncrepl_poll
May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]:
add_intermediates=1, add_ctrls=1, all = 0
May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: File
/usr/lib64/python2.7/site-packages/ldap/ldapobject.py, line 483, in
result4
May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: ldap_result =
self._ldap_call(self._l.result4,msgid,all,timeout,add_ctrls,add_intermediates,add_extop)
May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: File
/usr/lib64/python2.7/site-packages/ldap/ldapobject.py, line 106, in
_ldap_call
May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: result =
func(*args,**kwargs)
May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: SERVER_DOWN:
{'desc': Can't contact LDAP server}
May 14 02:50:41 ipadc1.ipadomain.net systemd[1]: ipa-dnskeysyncd.service:
main process exited, code=exited, status=1/FAILURE
May 14 02:50:41 ipadc1.ipadomain.net systemd[1]: Unit
ipa-dnskeysyncd.service entered failed state.
May 14 02:50:41 ipadc1.ipadomain.net systemd[1]: Stopped 389 Directory
Server IPADOMAIN-NET..
May 14 02:50:41 ipadc1.ipadomain.net systemd[1]: Starting 389 Directory
Server IPADOMAIN-NET
May 14 02:50:41 ipadc1.ipadomain.net systemd[1]: Started 389 Directory
Server IPADOMAIN-NET..
May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41
+] SSL Initialization - Configured SSL version range: min: TLS1.0,
max: TLS1.2
May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41
+] - SSL alert: Configured NSS Ciphers
May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41
+] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256:
enabled
May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41
+] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256: enabled
May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41
+] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA: enabled
May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41
+] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA: enabled
May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41
+] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA: enabled
May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41
+] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256:
enabled
May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41
+] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256: enabled
May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]: [14/May/2015:02:50:41
+] - SSL alert:
[Freeipa-users] Configuration of CA failed
Hello, I've been put in charge of implementing a solution that uses LDAP and kerberos authentication. At first thought I should use openLDAP and Kerberos but found freeIPA and looks really cool, however, when trying to install I keep getting this error about configuration of CA: The following operations may take some minutes to complete. Please wait until the prompt is returned. Configuring NTP daemon (ntpd) [1/4]: stopping ntpd [2/4]: writing configuration [3/4]: configuring ntpd to start on boot [4/4]: starting ntpd Done configuring NTP daemon (ntpd). Configuring directory server for the CA (pkids): Estimated time 30 seconds [1/3]: creating directory server user [2/3]: creating directory server instance [3/3]: restarting directory server ipa : CRITICAL Failed to restart the directory server. See the installation log for details. Done configuring directory server for the CA (pkids). Configuring certificate server (pki-cad): Estimated time 3 minutes 30 seconds [1/20]: creating certificate server user [2/20]: configuring certificate server instance ipa : CRITICAL failed to configure ca instance Command '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname ipatest.ingenia.local -cs_port 9445 -client_certdb_dir /tmp/tmp-ARezzO -client_certdb_pwd -preop_pin f0dLhx9bLX5qWHYx50h6 -domain_name IPA -admin_user admin -admin_email root@localhost -admin_password -agent_name ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa -agent_cert_subject CN=ipa-ca-agent,O=INGENIA.LOCAL -ldap_host ipatest.ingenia.local -ldap_port 7389 -bind_dn cn=Directory Manager -bind_password -base_dn o=ipaca -db_name ipaca -key_size 2048 -key_type rsa -key_algorithm SHA256withRSA -save_p12 true -backup_pwd -subsystem_name pki-cad -token_name internal -ca_subsystem_cert_subject_name CN=CA Subsystem,O=INGENIA.LOCAL -ca_subsystem_cert_subject_name CN=CA Subsystem,O=INGENIA.LOCAL -ca_ocsp_cert_subject_name CN=OCSP Subsystem,O=INGENIA.LOCAL -ca_server_cert_subject_name CN=ipatest.ingenia.local,O=INGENIA.LOCAL -ca_audit_signing_cert_subject_name CN=CA Audit,O=INGENIA.LOCAL -ca_sign_cert_subject_name CN=Certificate Authority,O=INGENIA.LOCAL -external false -clone false' returned non-zero exit status 255 Configuration of CA failed I'm including two install logs, one with dns-setup and the other without it. Don't really know what I'm doing wrong, thought maybe I should allow connections to certain ports in ip tables or something but have no clue really and I'm quite new to this, help please.. Regards, Remigio ipaserver-install.log Description: ipaserver-install.log ipaserver-install1.log Description: ipaserver-install1.log -- 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
