Search Results

Search found 4 results on 1 pages for '84104'.

Page 1/1 | 1 

  • CentOS openLDAP cert trust issues

    - by 84104
    # LDAPTLS_CACERTDIR=/etc/ssl/certs/ ldapwhoami -x -ZZ -H ldaps://ldap.domain.tld ldap_start_tls: Can't contact LDAP server (-1) additional info: TLS error -8172:Peer's certificate issuer has been marked as not trusted by the user. # openssl s_client -connect ldap.domain.tld:636 -CApath /etc/ssl/certs <... successful tls negotiation stuff ...> Compression: 1 (zlib compression) Start Time: 1349994779 Timeout : 300 (sec) Verify return code: 0 (ok) --- openssl seems to think the certificate is fine, but openldap's libraries (pam_ldap exhibits similar behavior, which is how I got on to this mess) disagree. What am I doing wrong?

    Read the article

  • How does one remove an encryption type from a kerberos principal?

    - by 84104
    I would like to remove all of the des keys from the principal below, but have no idea how to do so without someone inputting the password. kadmin: getprinc user Principal: [email protected] Expiration date: [never] Last password change: Thu May 26 08:52:51 PDT 2013 Password expiration date: [none] Maximum ticket life: 0 days 12:00:00 Maximum renewable life: 7 days 00:00:00 Last modified: Tue Jul 16 15:17:18 PDT 2013 (administrator/[email protected]) Last successful authentication: Wed Jul 24 14:40:53 PDT 2013 Last failed authentication: [never] Failed password attempts: 0 Number of keys: 8 Key: vno 3, aes256-cts-hmac-sha1-96, no salt Key: vno 3, arcfour-hmac, no salt Key: vno 3, des3-cbc-sha1, no salt Key: vno 3, des-cbc-crc, no salt Key: vno 3, des-cbc-md5, no salt Key: vno 3, des-cbc-md5, Version 5 - No Realm Key: vno 3, des-cbc-md5, Version 5 - Realm Only Key: vno 3, des-cbc-md5, AFS version 3 MKey: vno 2 Attributes: REQUIRES_PRE_AUTH Policy: [none] Also, the the kdc is using an OpenLDAP backend.

    Read the article

  • Can nginx be an mail proxy for a backend server that does not accept cleartext logins?

    - by 84104
    Can Nginx be an mail proxy for a backend server that does not accept cleartext logins? Preferably I'd like to know what directive to include so that it will invoke STARTTLS/STLS, but communication via IMAPS or POP3S is sufficient. relevant(?) section of nginx.conf mail { auth_http localhost:80/mailproxy/auth.php; proxy on; ssl_prefer_server_ciphers on; ssl_protocols TLSv1 SSLv3; ssl_ciphers HIGH:!ADH:!MD5:@STRENGTH; ssl_session_cache shared:TLSSL:16m; ssl_session_timeout 10m; ssl_certificate /etc/ssl/private/hostname.crt; ssl_certificate_key /etc/ssl/private/hostname.key; imap_capabilities "IMAP4rev1" "UIDPLUS"; server { protocol imap; listen 143; starttls on; } server { protocol imap; listen 993; ssl on; } pop3_capabilities "TOP" "USER"; server { protocol pop3; listen 110; starttls on; pop3_auth plain; } server { protocol pop3; listen 995; ssl on; pop3_auth plain; } }

    Read the article

  • Openldap startup problems after upgrade

    - by Craig Efrein
    I am trying to syncrhonize a ldap slave and master server. The master server is using openldap 2.3.43-12 and the slave server is using openldap 2.4.23. I copied over the files in /var/lib/ldap, started the server and got this error: Oct 22 16:16:41 xe-ldap-slave1 slapd[12111]: bdb(dc=myserver,dc=fr): Program version 4.7 doesn't match environment version 4.4 Oct 22 16:16:41 xe-ldap-slave1 slapd[12111]: bdb_db_open: database "dc=myserver,dc=fr" cannot be opened, err -30971. Restore from backup! Oct 22 16:16:41 xe-ldap-slave1 slapd[12111]: bdb(dc=myserver,dc=fr): txn_checkpoint interface requires an environment configured for the transaction subsystem Oct 22 16:16:41 xe-ldap-slave1 slapd[12111]: bdb_db_close: database "dc=myserver,dc=fr": txn_checkpoint failed: Invalid argument (22). Oct 22 16:16:41 xe-ldap-slave1 slapd[12111]: backend_startup_one (type=bdb, suffix="dc=myserver,dc=fr"): bi_db_open failed! (-30971) Oct 22 16:16:41 xe-ldap-slave1 slapd[12111]: bdb_db_close: database "dc=myserver,dc=fr": alock_close failed I have used the db_upgrade command to upgrade the database files on the new slave server, but I still get the same error when starting slapd. The master server is Centos 5.5 32bit & openldap 2.3.43-12 The slave server is Centos 6.3 64 bit & openldap 2.4.23 Everything was installed using yum. What is the proper method to synchronize database files from an ldap master server and slave server when the slave server is more recent then the master? I have followed the suggestion from 84104, but I am getting an error on the slave Here is the error on the slave: Oct 23 18:28:30 xe-ldap-slave1 slapd[1415]: slap_client_connect: URI=ldaps://ldap0.lan.myserver.com:636 DN="cn=syncuser,dc=myserver,dc=fr" ldap_sasl_bind_s failed (-1) Oct 23 18:28:30 xe-ldap-slave1 slapd[1415]: do_syncrepl: rid=003 rc -1 retrying Here is the error on the master: Oct 23 18:29:30 ldap0 slapd[15265]: conn=201 fd=35 ACCEPT from IP=192.168.150.100:47690 (IP=0.0.0.0:636) Oct 23 18:29:30 ldap0 slapd[15265]: conn=201 fd=35 closed (TLS negotiation failure) I can do an ldap search on the master just fine with the user configured for synchronization from the new slave server. ldapsearch -LLL -x -H ldaps://192.168.150.99:636 -x -W -b dc=myserver,dc=fr-D"cn=syncuser,dc=myserver,dc=fr"

    Read the article

1