Tag Info

New answers tagged

0

The bug that causes this specific issue has been in the libpam-ldap source for a long time, but it's effect was only seen after a separate bug was fixed in the gnutls library that libldap-2.4-2 uses. The specifics can be found in an enlightening email from Ryan Tandy in the Debian bug page for this issue. ( Debian Bug 790488 ). I had already known that ...


1

OpenSSL supports starttls for a number of protocols with s_client: -starttls protocol send the protocol-specific message(s) to switch to TLS for communication. protocol is a keyword for the intended protocol. Currently, the only supported keywords are "smtp", "pop3", "imap", and "ftp". which would allow you to easily retrieve the ...


-2

In a traditional LDAP deployment 389 doesn't use SSL/TLS which greatly speeds things up. Port 636 is the port typically secured with SSL/TLS. If your deployment uses SSL/TLS over port 389 understand that it isn't a typical deployment. After a quick search I found a similar question here.


0

The documentation for the AuthLDAPUrl option doesn't say anything about appending TLS after the URL. Instead, you should replace ldap:// with ldaps:// to use secure LDAP.


0

Stop using the directory's RootDN as the dn for the local system's root account. The directory's rootdn is not subject to access controls. Use (create if necessary) a dn entry with the appropriate permissions with your LDAP server to modify passwords correctly.


0

This one worked for me: Get a copy of your data on the old server by running the following command: ldapsearch -z max -LLL -Wx -D "cn=admin,dc=your,dc=domain" -b "dc=your,dc=base" > save.ldif Move the file to the new server and import it by running: ldapmodify -c -Wx -D "cn=admin,dc=your,dc=domain" -a -f save.ldif


1

After lots and lots of searching, I finally found a solution by myself in the deep internet. In case someone has the same problem in the future, I'm gonna post the answer here. Actually, it's pretty simple. On the new server, you need to install LDAP and GOsa normally. To transfer the LDAP-database, there only two commands you need to execute. In many ...


0

If your system is using PAM as the underlying authentication provider according to the documentation the options you specified with authconfig will modify the required PAM files(similar to using pam-config) which should be located in /etc/pam.d(at least on openSUSE, where there is no auth). It also appears that it will modify /etc/nsswitch.conf. You ...


0

PAM use for user authentication https://wiki.debian.org/LDAP/PAM When user logs into different servers, they have different homes? Yes. How is LDAP acls talk to client acls? If I have www:www on some of the client machines, how do I allow certain users to access them? You need to read about ACL (setfacl, getfacl) Also you need to read about ...


2

Your LDAP database only holds metadata about your users. The path name of the user's home directory will be in there (because that's metadata), but the home directory itself will not (because that's data). Shared/non-shared home directories is a problem entirely orthogonal from where user metadata is stored. You can have shared home directories (via NFS, AFS ...


1

Take a look at this answer but ultimately it seems like there is no way to make users part of multiple ou's


-2

To be sure, the cert is the problem you can make a test: Install a Webserver and configure https. Use your cert and bind it to the https port. Add a line to the hosts-file of one Win7Client that matches the name of the cert and the ip of the webserver Use IE and open your new webpage. IE shows you if the cert is trusted and you can open the properies of the ...


1

Well I don't know if this is a solution or just a workaround, but I managed to get it working. I first stopped the slapd with: service slapd stop Then I started it in debug mode: slapd -h ldapi:/// -u openldap -g openldap -d 65 -F /etc/ldap/slapd.d/ -d 65 Important is to start it ONLY with ldapi:/// URL. After it started I executed the ldapmodify ...


0

It's unfortunate that Spring Security won't allow you to set an appropriate search base. Depending on your environment you may be able to get away with setting a default search base to the frontend config. $ ldapmodify -f <<EOF dn: olcDatabase={-1}frontend,cn=config add: olcDefaultSearchBase olcDefaultSearchBase: dc=example,dc=com


1

An empty base is a special case for retrieving information about the OpenLDAP server that can host several databases (or "namingContexts" or "bases"). E.g.: ldapsearch -x -LLL -b '' -s base 'objectClass=*' + There really should be some way of specifying the base to use for searches


0

Looks like various code changes between 1.2 and 1.6 led to the problem that I was seeing. To fix the problem, I did the following: Added the kadmin/admin principal to /etc/krb5.keytab Appended --keytab=/etc/krb5.keytab to the kadmind arguments in /etc/inetd.conf This tells kadmind to explicitly look in /etc/krb5.keytab (instead of "HDBGET:") for the ...


0

I'm not sure whether you're asking about generally how to have a Debian server do authentication/authorization against Active Directory...or how to make sure the existing authentication/authorization is highly available. I'm going to assume the latter in this answer. The short answer is that setting up OpenLDAP as a cacheing layer for an Active Directory ...


0

A local OpenLDAP server is probably not the best way to handle the situation described. I think you should take a good long look at sssd. It should have everything you need.


0

I faced same problem like you, when i read your post i didn't have a clue to solve that, but now i solve my problem. Here's my solution's : Install nss-pam-ldapd if you didn't install it previously : [root@www ~]# yum -y install nss-pam-ldapd Disable selinux and reboot : [root@ldap ~]# vi /etc/selinux/config Change this line : selinux=disabled ...


0

The ordering of the ACL lines matters. olcaccess: {0}to dn.subtree="ou=subtree,dc=domain,dc=tld" by self write by dn="cn=subadmin,dc=domain,dc=tld" write by users read by anonymous none olcaccess: {1}to attrs=userPassword,shadowLastChange by self write by anonymous auth by dn="cn=admin,dc=mpbteam,dc=de" write by * none olcaccess: ...


2

Your .ldif file is formatted incorrectly. After you have gotten the password you need to put it in a correctly formatted .ldif: dn: <DN TO EDIT> changetype: modify userPassword: <NEW PASSWORD> If you have the file like this then look for whitespace, LDAP really doesn't like it. If not then, edit the script you have put above to include the ...


0

You didn't really say what your LDAP server was or how a user in your LDAP directory looks like, but I'll try answer as best as I can. At the moment, SSSD serves only POSIX accounts. That means the the user object on the server side either has to have name and numerical IDs or the numerical IDs must be inferred from Windows SID. The actual objectClass ...


1

inetOrgPerson depends on both core and cosine. It looks like you already have core. Add in cosine, then inetorgperson. Cosine should be at /etc/openldap/schema/cosine.ldif.


0

The following is taken from a working CentOS7 ldap server, and should cover the key aspects of SASL/EXTERNAL(TLS) authentication. Minors notes: - The server is also acting as the client in this example. - This example makes use of ~/.ldaprc rather than /etc/openldap/ldap.conf - This example uses olcTLSVerifyClient: verify rather than hard because the server ...


1

Even deleting the base entry will not remove a naming context. You'll have to remove it from your configuration.


2

If you want to use an existing working OpenLDAP server on your network under Debian Jessie then you should be using the following packages : libnss-ldap libpam-ldap rather than libnss-ldapd libpam-ldapd



Top 50 recent answers are included