Re: query across ou
Chuck Theobald wrote: Is there a way to perform a single query an LDAP database such that I can retrieve the group name (cn) from a user's full name (cn). My structure holds user accounts in ou=People and groups in ou=Group. I know I can ask for gidNumber from the People tree, then reference the group in the Group tree, but with an SQL background, I would like a single query. Not feasible in general. The LDAP functional model is much simpler than SQL. Depending on the group schema used in your deployment you could configure the server with slapo-memberof. Then slapd maintains a back-link to the group entries from the member entry. By default it's attribute 'memberOf' (configurable) and always contains the full DN of all group entries. This only works if using RFC 2307bis style posixGroup entries with attribute 'member' pointing to member entries (not 'memberUID'). If you have to provide also 'memberUID' group relation attribute to some legacy clients you can define a hybrid groupOfNames/posixGroup object class like described herein: http://www.ietf.org/mail-archive/web/ldapext/current/msg02112.html Ciao, Michael. smime.p7s Description: S/MIME Cryptographic Signature
Re: query across ou
On 29/04/2015 07:59, Michael Ströder wrote: Chuck Theobald wrote: Is there a way to perform a single query an LDAP database such that I can retrieve the group name (cn) from a user's full name (cn). My structure holds user accounts in ou=People and groups in ou=Group. I know I can ask for gidNumber from the People tree, then reference the group in the Group tree, but with an SQL background, I would like a single query. Not feasible in general. The LDAP functional model is much simpler than SQL. Depending on the group schema used in your deployment you could configure the server with slapo-memberof. Then slapd maintains a back-link to the group entries from the member entry. By default it's attribute 'memberOf' (configurable) and always contains the full DN of all group entries. This only works if using RFC 2307bis style posixGroup entries with attribute 'member' pointing to member entries (not 'memberUID'). I think what Chuck wants to do is dereference a user's primary group ID from their gidNumber attribute to get the group name. The primary group does not appear in the memberOf list with slapo-memberof as the user won't be in the list of members for that group. Only way is indeed to do two lookups: get the user's gidNumber, then the group name associated with the gidNumber. -- Liam Grettonliam.gret...@le.ac.uk Systems Specialist http://www.le.ac.uk/its/ IT Services Tel: +44 (0)116 2522254 University Of Leicester, University Road Leicestershire LE1 7RH, United Kingdom
Re: getent passwd only catch local user passwd
On Tue, Apr 28, 2015 at 07:49:07PM +, Yingbo Li wrote: I am new to LDAP. The company’s IT own LDAP server, I tried to configure openldap client but failed. My OS is CentOS 7, openldap is 2.4.39. I configured ldap and ldaps. I can use ldapsearch to find out full ldap info of my LDAP account. I configured with authconfig-tui. I also modified /etc/pam.d/ system-auth and password-auth, change pam_sss.so to pam_ldap.so. While when I tried getent passwd, I can only find local users. I cannot su to my LDAP account. Why? You have probably messed up the config by making those changes. CentOS 7 expects to use SSSD to access LDAP: it provides useful services and isolates system processes from the LDAP service so you should not try to bypass it. Lots of useful information here: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html-single/Deployment_Guide/index.html#SSSD-Introduction Rather than editing config files directly, try to get a basic system running by using the authconfig command. This should make sure that you have a consistent setup. Better still, select LDAP authentication when you install the system and let the install wizard help you through the process. If your LDAP service places size limits or restrictive access-control on the data you may need to create an account for SSSD to bind with so that it can bypass the limits. This is not really an OpenLDAP problem, so you are likely to get more detailed help on a Red Hat or CentOS mailing list or forum. Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: Ldap challenge
Thanks, I will read over this and see if I can make it work. Daniel From: Andrew Findlay andrew.find...@skills-1st.co.uk Sent: Monday, April 27, 2015 3:06 PM To: Ross, Daniel B. Cc: openldap-technical@openldap.org Subject: Re: Ldap challenge On Mon, Apr 27, 2015 at 06:27:39PM +, Ross, Daniel B. wrote: ismemberof does not exist we have to use memberof Memberof is fairly common. I don't think I have ever found a system that used 'ismemberof'. Note that maintaining memberof takes some work so it is not enabled on all LDAP servers by default. nsUniqueId we have to use objectGUID What do you use nsUniqueId for? Probably not a problem anyway as you may be able to use other similar attributes as you mention above. no uniqueMember again can only use memberof. uniqueMember and memberOf have completely different use-cases: uniqueMember is used just like 'member' in most cases, to indicate which entries are members of the group that it appears in. memberOf indicates which groups the entry that it appears in is a member of (i.e. it is the inverse mapping). while there is a guarantee of person there is not the same for Posixaccount or shadowaccount. Ah - if you lack those attributes then AD is certainly not going to do the job on its own. While I have been able to get linux with SSSD to work, to some extent, with this its rather hit and miss and the Solaris systems just wont work at all. This is why I was hoping to be able to use the campus for the username and password, and then provide the rest from a local ldap server. It doesnt sound like this is really possible. Yes - it should be possible but it will take a bit more work. saslauthd did not work at all with the MS LDS. Did you try following the instructions here?: http://www.openldap.org/doc/admin24/security.html#Pass-Through%20authentication Note that you will need the DN and password of an existing AD user to allow saslauthd to do LDAP searches on AD. You can try the ldapsearch commands from section 14.5.3 without any other setup to test that you have a good user account. In principle it may be better to do Kerberos authentication against AD rather than LDAP, but I didn't have a Kerberos server handy when I wrote that bit. What is a parallel or overlay directory service? Parallel would be where you replicate some subset of data from AD into a local LDAP server, which then operates as a self-contained system. You could have the replication process create or look up Unix-specific attributes like UID and GID for new accounts. Overlay would be where you use what you can get from AD, and put a translucent overlay on top containing Unix-specific data that you administer locally. In either case you need to decide how to handle password checking and account locking. All of my customers so far have chosen the parallel approach, as that allows the Unix LDAP to continue working if it loses access to AD. Ideally this includes installing a module on the AD Domain Controllers that detects password changes and forwards them immediately to the Unix LDAP. I have generally used Microsoft's SFU password-capture module for this as AD admins seem happier to install Microsoft code than things from other sources. It does have its problems though, and the code quality of the Unix end that they provide leaves a lot to be desired. I believe newer AD versions come with an updated version of this built in, but I have not tested it. Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
RE: getent passwd only catch local user passwd
Findlay, Thanks for your help! But the problem is not addressed. On centOS 6 and 7 I test getent passwd yli28. The same result, no ouput. On my own ldap client server env, both cnetos 6.6, it works. I started sssd on client. It did not work. Then I start nscd. It still not work. I would like to list all my configurations here: /etc/hosts 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 10.91.96.141LVD-LDAP-C6IT hostname 10.91.96.142LDV-LDAP-CENT6 /etc/openldap/ldap.conf # # LDAP Defaults # # See ldap.conf(5) for details # This file should be world readable but not world writable. BASE ou=people,dc=ra-int,dc=com #URIldap://ldap.example.com ldap://ldap-master.example.com:666 URI ldap://usmkemsi107.ra-int.com #URI10.91.96.142 #SIZELIMIT 12 #TIMELIMIT 15 #DEREF never TLS_CACERTDIR /etc/openldap/cacerts /etc/nsswitch.conf (All sss were replaced by ldap. Both did not work) passwd: files ldap shadow: files ldap group: files ldap #hosts: db files nisplus nis dns hosts: files dns # Example - obey only what nisplus tells us... #services: nisplus [NOTFOUND=return] files #networks: nisplus [NOTFOUND=return] files #protocols: nisplus [NOTFOUND=return] files #rpc:nisplus [NOTFOUND=return] files #ethers: nisplus [NOTFOUND=return] files #netmasks: nisplus [NOTFOUND=return] files bootparams: nisplus [NOTFOUND=return] files ethers: files netmasks: files networks: files protocols: files rpc:files services: files ldap netgroup: files ldap publickey: nisplus automount: files ldap aliases:files nisplus /etc/sssd/sssd.conf [domain/default] autofs_provider = ldap cache_credentials = True ldap_search_base = ou=people,dc=ra-int,dc=com krb5_realm = EXAMPLE.COM krb5_server = kerberos.example.com id_provider = ldap auth_provider = ldap chpass_provider = ldap ldap_uri = ldap://usmkemsi107.ra-int.com ldap_id_use_start_tls = False ldap_tls_cacertdir = /etc/openldap/cacerts [sssd] services = nss, pam, autofs config_file_version = 2 enumerate = true domains = default [nss] homedir_substring = /home [pam] [sudo] [autofs] [ssh] [pac] [ifp] /etc/pam.d/system-auth #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. authrequired pam_env.so authsufficientpam_unix.so nullok try_first_pass authrequisite pam_succeed_if.so uid = 500 quiet authsufficientpam_sss.so use_first_pass authrequired pam_deny.so account required pam_unix.so broken_shadow account sufficientpam_localuser.so account sufficientpam_succeed_if.so uid 500 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so passwordrequisite pam_cracklib.so try_first_pass retry=3 type= passwordsufficientpam_unix.so sha512 shadow nullok try_first_pass use_authtok passwordsufficientpam_sss.so use_authtok passwordrequired pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_sss.so /etc/pam.d/password-auth #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. authrequired pam_env.so authsufficientpam_unix.so nullok try_first_pass authrequisite pam_succeed_if.so uid = 500 quiet authsufficientpam_sss.so use_first_pass authrequired pam_deny.so account required pam_unix.so broken_shadow account sufficientpam_localuser.so account sufficientpam_succeed_if.so uid 500 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so passwordrequisite pam_cracklib.so try_first_pass retry=3 type= passwordsufficientpam_unix.so sha512 shadow nullok try_first_pass use_authtok passwordsufficientpam_sss.so use_authtok passwordrequired pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_sss.so Yesterday, I configured LDAP authentication on Artifactory (a repository software) on centos 7. It works. I use ldapsearch -x -D binddn_username -w password samaccount=yli28. It works. I really do not know what else can I do to make getent work. Then I can su yli28. If you find anything wrong, please let me know. I can only configure the client side, the LDAP server controlled by IT. Thank you! Yingbo
Re: modifying cn=config with ldapmodify
Hi, In your ssl.ldif file there is a *blank* line too after changetype: modify This is not reported in your first post but it apear in seconde one. I have reproduced the same symptoms with this empty line More details bellow Cheers. Le 29/04/2015 12:56, Robert Munn a écrit : My replies inline... On Apr 26, 2015, at 2:28 AM, Abdelhamid MEDDEB abdelha...@meddeb.net mailto:abdelha...@meddeb.net wrote: Hi, Le 25/04/2015 15:10, Robert Munn a écrit : I have been trying to replace the SSL cert settings on my OpenLDAP instance running on Ubuntu using ldapmodify. I followed directions on the Ubuntu wiki: https://help.ubuntu.com/lts/serverguide/openldap-server.html#openldap-tls using a modified ldif file for the replace: |dn: cn=config changetype: modify replace: olcTLSCACertificateFile olcTLSCACertificateFile: /etc/ssl/certs/cacert.pem - replace: olcTLSCertificateFile olcTLSCertificateFile: /etc/ssl/certs/ldap01_slapd_cert.pem - replace: olcTLSCertificateKeyFile olcTLSCertificateKeyFile: /etc/ssl/private/ldap01_slapd_key.pem| |All right| Empty line is not reported here. When it didn’t work on my existing instance I built a new instance in a new Ubuntu VM (14.04) and tried the original directions from Ubuntu. That did not work either. May be you've missed some settings at build time like --with-tls I installed OpenLDAP using apt. The .deb package must include TLS because I added the certificates manually. The ldapmodify command executes correctly but it seems that the change is not registered by the server. This is the case in both the new instance and the old instance of OpenLDAP. No error message like Insufficient access (50) ? and you should check the write (manage)rights to cn=config database. The command I ran (as sudo) and the message: ldapmodify -Y EXTERNAL -H ldapi:/// -f ssl.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry cn=config” and ssl.ldif : dn: cn=config changetype:modify replace: olcTLSCACertificateFile olcTLSCACertificateFile: /etc/ssl/certs/CAcert - replace: olcTLSCertificateFile olcTLSCertificateFile: /etc/ssl/certs/cert - replace: olcTLSCertificateKeyFile olcTLSCertificateKeyFile: /etc/ssl/private/cert.key But we show it here, and content changes (strangely) the cn=config.ldif last modified timestamp, but do nothing realy cn=config.ldif is being modified by the ldapmodify process, I verified that by changing file permissions on cn=config.ldif, running the ldapmodify command, and then checking cn=config.ldif. ldapmodify updated the timestamp and file permissions on the file. The file changed, but the configuration changes in ssl.ldif were not made in cn=config.ldif. I ended up replacing the values (or adding them in the new instance) in the /etc/ldap/slapd.d/cn=config.ldif file manually. Making the changes manually and restarting slapd works, but my understanding was that changes to cn=config should be made through ldapmodify. Bad practice, it's best to avoid. Yes, and when I can modify the configuration using ldapmodify, I will no longer make the changes manually. I found a note about enabling logging using ldapmodify: https://help.ubuntu.com/lts/serverguide/openldap-server.html logging.ldif: dn: cn=config changetype: modify replace: olcLogLevel olcLogLevel: stats ldapmodify -Q -Y EXTERNAL -H ldapi:/// -f logging.ldif I executed this command on my first instance and it added the logging to cn=config. I executed this command on the second instance, where olcLogLevel already existed, and it did not alter the log level. I have also been experimenting with this script: https://github.com/cepharum/slapd-config With it, I was able to delete the TLS entries from cn=config: slapd-config raw delete cn=config olcTLSCACertificateFile 1 but when I tried to add the entries back, I got this error: slapd-config raw insert cn=config olcTLSCACertificateFile 1 /etc/ssl/certs/cert.pem modifying entry ldap_modify: Server is unwilling to perform (53) additional info: modify upon the root DSE not supported I have not looked at the details but it seems that there is a bug in this script. (modifying entry ) I was able to change the olcLogLevel back to its original state vi ldapmodify, so maybe there is something particular about the TLS entries, perhaps having to do with permissions on the certs and keys themselves? I have come across this bug in several forums and have yet to see someone who solved it in the “correct” manner using ldapmodify. Robert I also found a tech note at CentOS: https://www.centos.org/docs/5/html/CDS/cli/8.0/Configuration_Command_File_Reference-Core_Server_Configuration_Reference-Accessing_and_Modifying_Server_Configuration.html in section 2.2.2.2 that indicates changes to cn=config will be ignored: If an attribute is added to |cn=config|, the server ignores it. So am I mistaken? Do I need to do
Objectclass not enabled in PHPldapadmin
Hi, I have installed LDAP 2.4 version and using phpldapadmin to manage it. I am not seeing all the options enabled in create object page. Like I can see Generic: Organisational Role and Generic: Organisational Unit but other options like Generic: Address Book Entry, Generic: Posix Group, Generic: User Account are in disabled mode. I want them to be available to create group and users. Please guide me how to resolve this issue. I noticed below errors/warning during login to phpldapadmin and not sure about it. Samba: Group Mapping: posixGroup removed from template as it is not defined in the schema Alias: inetOrgPerson removed from template as it is not defined in the schema Thanks Gokulnath
