Re: [Freeipa-users] bind-dyndb-ldap: using keytabs for auth to ldap
On 1.4.2014 21:51, Brendan Kearney wrote: No, it is not. http://port389.org/wiki/History ok then. still, i am trying to learn the individual pieces and get them working together. Okay then. I'm attaching SASL mapping configuration we use in FreeIPA. You can read all the gory details on https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/SASL.html Please let us know what configuration works for your with OpenLDAP so we can add this information to bind-dyndb-ldap docs or wiki. Have a nice day! -- Petr^2 Spacek version: 1 dn: cn=mapping,cn=sasl,cn=config objectClass: nsContainer objectClass: top cn: mapping dn: cn=Full Principal,cn=mapping,cn=sasl,cn=config objectClass: nsSaslMapping objectClass: top cn: Full Principal nsSaslMapBaseDNTemplate: dc=ipa,dc=example nsSaslMapFilterTemplate: (krbPrincipalName=\1@\2) nsSaslMapRegexString: \(.*\)@\(.*\) nsSaslMapPriority: 10 dn: cn=Name Only,cn=mapping,cn=sasl,cn=config objectClass: nsSaslMapping objectClass: top cn: Name Only nsSaslMapBaseDNTemplate: dc=ipa,dc=example nsSaslMapFilterTemplate: (krbPrincipalName=@IPA.EXAMPLE) nsSaslMapRegexString: ^[^:@]+$ nsSaslMapPriority: 10 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] IPA Replica Issues (Total update abortedLDAP error: Can't contact LDAP server)
Rich Megginson wrote: On 04/02/2014 09:20 AM, Nevada Sanchez wrote: Okay, we might be on to something: ipa - ipa2 $ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-EXAMPLE-COM ldapsearch -xLLLZZ -h ipa2.example.com http://ipa2.example.com -s base -b 'objectclass=*' vendorVersion dn: vendorVersion: 389-Directory/1.3.1.22.a1 B2014.073.1751 ipa2 - ipa $ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-EXAMPLE-COM ldapsearch -xLLLZZ -h ipa.example.com http://ipa.example.com -s base -b 'objectclass=*' vendorVersion ldap_start_tls: Connect error (-11) additional info: TLS error -8172:Peer's certificate issuer has been marked as not trusted by the user. The original IPA trusts the replica (since it signed the cert, I assume), but the replica doesn't trust the main IPA server. I guess the ZZ option would have shown me the failure that I missed in my initial ldapsearch tests. -Z[Z] Issue StartTLS (Transport Layer Security) extended operation. If you use -ZZ, the command will require the operation to be suc- cessful. i.e. use SSL, and force a successful handshake Anyway, what's the best way to remedy this in a way that makes IPA happy? (I've found that LDAP can have different requirements on which certs go where). I'm not sure. ipa-server-install/ipa-replica-prepare/ipa-replica-install is supposed to take care of installing the CA cert properly for you. If you try to hack it and install the CA cert manually, you will probably miss something else that ipa install did not do. I think the only way to ensure that you have a properly configured ipa server + replicas is to get all of the ipa commands completing successfully. Which means going back to the drawing board and starting over from scratch. You can compare the certs that each side is using with: # certutil -L -d /etc/dirsrv/slapd-EXAMPLE-COM Did you by chance replace the SSL server certs that IPA uses on your working master? rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] force uninstall from Ubunutu 12.04
Thank you that was it!!! -Original Message- From: Rob Crittenden [mailto:rcrit...@redhat.com] Sent: Tuesday, April 01, 2014 6:11 PM To: Todd Maugh; freeipa-users@redhat.com Subject: Re: [Freeipa-users] force uninstall from Ubunutu 12.04 Todd Maugh wrote: Has any one been able to successfully uninstall a client from Ubuntu 12.04 I have the install down for these boxes. But I need to transfer an ubunutu client from our old ipa server to the new The error I get during uninstall is Failed to remove krb5/LDAP Configuration Even if I remove the /etc/ipa/default.conf When I go to renenroll client it says IPA client is already configured on this system. Run the uninstall blah blah blah Any suggestions? Does any one know the magic file to remove? The files in /var/lib/ipa/sysrestore rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] IPA Replica Issues (Total update abortedLDAP error: Can't contact LDAP server)
On 04/02/2014 11:45 AM, Nevada Sanchez wrote: My apologies. I mistakenly ran the failing ldapsearch from an unpriviliged user (couldn't read slapd-EXAMPLE-COM directory). Running as root, it now works just fine (same result as the one that worked). SSL seems to not be the issue. Also, I haven't change the SSL certs since I first set up the master. I have been doing the replica side things from scratch (even so far as starting with a new machine). For the master side, I have just been re-preparing the replica. I hope I don't have to start from scratch with the master replica. I guess the next step would be to do the ipa-replica-install using -ddd and review the extra debug information that comes out. On Wed, Apr 2, 2014 at 11:45 AM, Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com wrote: Rich Megginson wrote: On 04/02/2014 09:20 AM, Nevada Sanchez wrote: Okay, we might be on to something: ipa - ipa2 $ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-EXAMPLE-COM ldapsearch -xLLLZZ -h ipa2.example.com http://ipa2.example.com http://ipa2.example.com -s base -b 'objectclass=*' vendorVersion dn: vendorVersion: 389-Directory/1.3.1.22.a1 B2014.073.1751 ipa2 - ipa $ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-EXAMPLE-COM ldapsearch -xLLLZZ -h ipa.example.com http://ipa.example.com http://ipa.example.com -s base -b 'objectclass=*' vendorVersion ldap_start_tls: Connect error (-11) additional info: TLS error -8172:Peer's certificate issuer has been marked as not trusted by the user. The original IPA trusts the replica (since it signed the cert, I assume), but the replica doesn't trust the main IPA server. I guess the ZZ option would have shown me the failure that I missed in my initial ldapsearch tests. -Z[Z] Issue StartTLS (Transport Layer Security) extended operation. If you use -ZZ, the command will require the operation to be suc- cessful. i.e. use SSL, and force a successful handshake Anyway, what's the best way to remedy this in a way that makes IPA happy? (I've found that LDAP can have different requirements on which certs go where). I'm not sure. ipa-server-install/ipa-replica-prepare/ipa-replica-install is supposed to take care of installing the CA cert properly for you. If you try to hack it and install the CA cert manually, you will probably miss something else that ipa install did not do. I think the only way to ensure that you have a properly configured ipa server + replicas is to get all of the ipa commands completing successfully. Which means going back to the drawing board and starting over from scratch. You can compare the certs that each side is using with: # certutil -L -d /etc/dirsrv/slapd-EXAMPLE-COM Did you by chance replace the SSL server certs that IPA uses on your working master? rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] IPA Replica Issues (Total update abortedLDAP error: Can't contact LDAP server)
My apologies. I mistakenly ran the failing ldapsearch from an unpriviliged user (couldn't read slapd-EXAMPLE-COM directory). Running as root, it now works just fine (same result as the one that worked). SSL seems to not be the issue. Also, I haven't change the SSL certs since I first set up the master. I have been doing the replica side things from scratch (even so far as starting with a new machine). For the master side, I have just been re-preparing the replica. I hope I don't have to start from scratch with the master replica. On Wed, Apr 2, 2014 at 11:45 AM, Rob Crittenden rcrit...@redhat.com wrote: Rich Megginson wrote: On 04/02/2014 09:20 AM, Nevada Sanchez wrote: Okay, we might be on to something: ipa - ipa2 $ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-EXAMPLE-COM ldapsearch -xLLLZZ -h ipa2.example.com http://ipa2.example.com -s base -b 'objectclass=*' vendorVersion dn: vendorVersion: 389-Directory/1.3.1.22.a1 B2014.073.1751 ipa2 - ipa $ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-EXAMPLE-COM ldapsearch -xLLLZZ -h ipa.example.com http://ipa.example.com -s base -b 'objectclass=*' vendorVersion ldap_start_tls: Connect error (-11) additional info: TLS error -8172:Peer's certificate issuer has been marked as not trusted by the user. The original IPA trusts the replica (since it signed the cert, I assume), but the replica doesn't trust the main IPA server. I guess the ZZ option would have shown me the failure that I missed in my initial ldapsearch tests. -Z[Z] Issue StartTLS (Transport Layer Security) extended operation. If you use -ZZ, the command will require the operation to be suc- cessful. i.e. use SSL, and force a successful handshake Anyway, what's the best way to remedy this in a way that makes IPA happy? (I've found that LDAP can have different requirements on which certs go where). I'm not sure. ipa-server-install/ipa-replica-prepare/ipa-replica-install is supposed to take care of installing the CA cert properly for you. If you try to hack it and install the CA cert manually, you will probably miss something else that ipa install did not do. I think the only way to ensure that you have a properly configured ipa server + replicas is to get all of the ipa commands completing successfully. Which means going back to the drawing board and starting over from scratch. You can compare the certs that each side is using with: # certutil -L -d /etc/dirsrv/slapd-EXAMPLE-COM Did you by chance replace the SSL server certs that IPA uses on your working master? rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] IPA Replica Issues (Total update abortedLDAP error: Can't contact LDAP server)
On 04/02/2014 03:01 PM, Nevada Sanchez wrote: Okay, I ran it with debug on. The output is quite large. I'm not sure what the etiquette is for posting large logs, so I threw it on gist here: https://gist.githubusercontent.com/nevsan/8b6f78d7396963dc5f70/raw/b76b3c3acce4f12d292d680f4c1dab39c05888d5/gistfile1.txt http://gist.githubusercontent.com/nevsan/8b6f78d7396963dc5f70/raw/b76b3c3acce4f12d292d680f4c1dab39c05888d5/gistfile1.txt Let me know if I should copy it into the thread instead. Ok. Now can you post excerpts from the dirsrv errors log from both the master replica and the replica from around the time of the failure? On Wed, Apr 2, 2014 at 1:49 PM, Rich Megginson rmegg...@redhat.com mailto:rmegg...@redhat.com wrote: On 04/02/2014 11:45 AM, Nevada Sanchez wrote: My apologies. I mistakenly ran the failing ldapsearch from an unpriviliged user (couldn't read slapd-EXAMPLE-COM directory). Running as root, it now works just fine (same result as the one that worked). SSL seems to not be the issue. Also, I haven't change the SSL certs since I first set up the master. I have been doing the replica side things from scratch (even so far as starting with a new machine). For the master side, I have just been re-preparing the replica. I hope I don't have to start from scratch with the master replica. I guess the next step would be to do the ipa-replica-install using -ddd and review the extra debug information that comes out. On Wed, Apr 2, 2014 at 11:45 AM, Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com wrote: Rich Megginson wrote: On 04/02/2014 09:20 AM, Nevada Sanchez wrote: Okay, we might be on to something: ipa - ipa2 $ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-EXAMPLE-COM ldapsearch -xLLLZZ -h ipa2.example.com http://ipa2.example.com http://ipa2.example.com -s base -b 'objectclass=*' vendorVersion dn: vendorVersion: 389-Directory/1.3.1.22.a1 B2014.073.1751 ipa2 - ipa $ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-EXAMPLE-COM ldapsearch -xLLLZZ -h ipa.example.com http://ipa.example.com http://ipa.example.com -s base -b 'objectclass=*' vendorVersion ldap_start_tls: Connect error (-11) additional info: TLS error -8172:Peer's certificate issuer has been marked as not trusted by the user. The original IPA trusts the replica (since it signed the cert, I assume), but the replica doesn't trust the main IPA server. I guess the ZZ option would have shown me the failure that I missed in my initial ldapsearch tests. -Z[Z] Issue StartTLS (Transport Layer Security) extended operation. If you use -ZZ, the command will require the operation to be suc- cessful. i.e. use SSL, and force a successful handshake Anyway, what's the best way to remedy this in a way that makes IPA happy? (I've found that LDAP can have different requirements on which certs go where). I'm not sure. ipa-server-install/ipa-replica-prepare/ipa-replica-install is supposed to take care of installing the CA cert properly for you. If you try to hack it and install the CA cert manually, you will probably miss something else that ipa install did not do. I think the only way to ensure that you have a properly configured ipa server + replicas is to get all of the ipa commands completing successfully. Which means going back to the drawing board and starting over from scratch. You can compare the certs that each side is using with: # certutil -L -d /etc/dirsrv/slapd-EXAMPLE-COM Did you by chance replace the SSL server certs that IPA uses on your working master? rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Problem using IPA for Apache LDAP Auth
Hi All, I'm having some issues with setting up ldap auth for an apache webserver. In short I have an IPA server that seems to be working correctly, it is currently acting and a central authentication server for our Linux server environment. What I'm trying to do is get LDAP Auth up for our web based services. The test environment is all CentOS 6.5 with the following config IPA server with an LDAP bind user set up as per http://www.freeipa.org/page/Apache_Group_Based_Authorization without the kerberos component. There is a single web directory /var/www/html/webtest with a single index.htlm file and a .htaccess file with the following contents. # Make sure you're using HTTPS, or anyone can read your LDAP password. # SSLRequireSSL Order deny,allow Deny from All AuthName Example Authorisation AuthType Basic AuthBasicProvider ldap AuthzLDAPAuthoritative on AuthLDAPUrl ldaps://ipa.example.com:636/dc=example,dc=com?uid AuthLDAPBindDN uid=webapps,cn=sysaccounts,cn=etc, dc=example,dc=com AuthLDAPBindPassword password removed Require valid-user Satisfy any --- When I try to access the web page I get a basic auth prompt and in the ipa server logs I get the following [03/Apr/2014:12:26:22 +1100] conn=1689 fd=83 slot=83 SSL connection from 10.0.0.11 to 10.0.0.3 [03/Apr/2014:12:26:22 +1100] conn=1689 SSL 256-bit AES [03/Apr/2014:12:26:22 +1100] conn=1689 op=0 BIND dn=uid=webapps,cn=sysaccounts,cn=etc,dc=example,dc=com method=128 version=3 [03/Apr/2014:12:26:22 +1100] conn=1689 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn=uid=webapps,cn=sysaccounts,cn=etc, dc=example,dc=com [03/Apr/2014:12:26:22 +1100] conn=1689 op=1 SRCH base= dc=example,dc=com scope=2 filter=((objectClass=*)(uid=dtaylor)) attrs=uid [03/Apr/2014:12:26:22 +1100] conn=1689 op=1 RESULT err=0 tag=101 nentries=1 etime=0 notes=U --- Any help is greatly appreciated. Best regards David Taylor ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Server Ports
I'm having some trouble determining which ports my servers need open to communicate and what ports client servers and users will need. The last documentation that I was able to find was included in Fedora 15 (http://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/installing-ipa.html). I opened those ports with firewalld, but I encountered errors when joining my replica server. (I retried the replica install with firewalld, and it succeeded, so it's clearly a problem with the firewall settings.) I'm joining the wave of the future, so please excuse the firewalld XML, but it should be pretty obvsious. All of the services are built into firewalld, except dogtag, which I made myself and is defined at the end. rule family=ipv4 source address=192.168.0.0/16/ service name=http/ accept/ /rule rule family=ipv4 source address=192.168.0.0/16/ service name=https/ accept/ /rule rule family=ipv4 source address=192.168.0.0/16/ service name=dogtag/ accept/ /rule rule family=ipv4 source address=192.168.0.0/16/ service name=dns/ accept/ /rule rule family=ipv4 source address=192.168.0.0/16/ service name=kerberos/ accept/ /rule rule family=ipv4 source address=192.168.0.0/16/ service name=kpasswd/ accept/ /rule rule family=ipv4 source address=192.168.0.0/16/ service name=ldap/ accept/ /rule rule family=ipv4 source address=192.168.0.0/16/ service name=ldaps/ accept/ /rule rule family=ipv4 source address=192.168.0.0/16/ service name=ntp/ accept/ /rule rule family=ipv4 source address=192.168.0.0/16/ service name=ssh/ accept/ /rule Services dns, kerberos, and kpasswd are TCP+UDP. Service ntp is UDP only. The others are TCP only. = services/dogtag.xml: ?xml version=1.0 encoding=utf-8? service port protocol=tcp port=9180/ port protocol=tcp port=9443/ port protocol=tcp port=9444/ port protocol=tcp port=9445/ port protocol=tcp port=9446/ port protocol=tcp port=9701/ port protocol=tcp port=7389/ /service = On a side note, it would be nice if the firewalld packagers included a freeipa-server service (nudge nudge). Thanks, Justin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
