[389-users] Re: intro to 389 LDAP administration

[William Brown]

>  On 14 May 2020, at 05:54, Matt Zagrabelny <mzagrabe(a)d.umn.edu&gt;
> wrote:
>  
>  Greetings 389 users,
>  
>  I am a sysadmin that has never really used LDAP before. I have installed 389-ds and am a
> little stuck as to how to start. 
Hey there, welcome to LDAP and 389-ds!

>  
>  I am using Debian Buster...
>  
>  389-ds:
>   Installed: 1.4.0.21-1
>  
>  From the site:
>  
>  https://www.port389.org/docs/389ds/howto/howto-install-389.html
>  
>  I see it recommends setting a .dsrc file to ease usage as the root user:
>  
>  For local instance administration (on the server), you want to use settings like:
>  
>  # cat ~/.dsrc
>  [localhost]
>  # Note that '/' is replaced to '%%2f'.
>  uri = ldapi://%%2fvar%%2frun%%2fslapd-localhost.socket 
Yeah, this socket file name is encoded. Check for /var/run/slapd-<instance
name>.socket, which in your case, is slapd-gopher.socket.

>  basedn = dc=example,dc=com
>  binddn = cn=Directory Manager
>  
>  I don't have the socket file in my installation. I don't see any sockets owned by
> the directory service:
>  
>  # systemctl status dirsrv(a)gopher.service
>  ● dirsrv(a)gopher.service - 389 Directory Server gopher.                                   
>                                                                                           
>                                                         
>    Loaded: loaded (/lib/systemd/system/dirsrv@.service; enabled; vendor preset: enabled)  
>                                                                                           
>                                                        
>    Active: active (running) since Wed 2020-05-13 12:38:22 CDT; 2h 5min ago                
>                                                                                           
>                                                        
>  Main PID: 12270 (ns-slapd)                                                               
>                                                                                           
>                                                        
>    Status: "slapd started: Ready to process requests"                           
>                                                                                           
>                                                                  
>     Tasks: 25 (limit: 4722)                                                               
>                                                                                           
>                                                        
>    Memory: 19.2M                                                                          
>                                                                                           
>                                                        
>    CGroup: /system.slice/system-dirsrv.slice/dirsrv(a)gopher.service                        
>                                                                                           
>                                                        
>            └─12270 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-gopher -i
> /var/run/dirsrv/slapd-gopher.pid
>  
>  # tree /var/run/dirsrv
>  /var/run/dirsrv
>  ├── slapd-gopher.pid
>  └── slapd-gopher.stats
>  
>  The Debian package states to initialize the server to run the command:
> /usr/sbin/setup-ds
>  
>  I don't know if that is a distribution agnostic program or not. The command did
> prompt me for a password - which I entered. 
Which program did you use to create the server? It should be dscreate as setup-ds.pl has
been deprecated and should be removed ....

>  
>  When I run a command like dsidm or ldapmodify, the command prompts me for a password. I
> enter the one that was prompted for with setup-ds, but I get: 
Whin you run dsidm you need to use it as root or user dirsrv - this is because it reads
the .dsrc of the user, finds the ldapi socket, and then uses the uid/gid of the current
process to map your authetication through. 

When you use ldapmodify, you need to configure the related openldap tools instead, at
/etc/openldap/ldap.conf. You can generate a configuration for this with:

>  dsidm <instance name> client_config ldap.conf 
#
# OpenLDAP client configuration
# Generated by 389 Directory Server - dsidm
#

# See ldap.conf(5) for details
# This file should be world readable but not world writable.

BASE    dc=blackhats,dc=net,dc=au
# Remember to check this: you can have multiple uris on this line. You may have
# multiple servers or load balancers in your environment.
URI     ldapi://%2fdata%2frun%2fslapd-localhost.socket
# If you have DNS SRV records you can use:
# URI   ldaps:///dc%3Dblackhats%2Cdc%3Dnet%2Cdc%3Dau

DEREF   never
# To use cacert dir, place *.crt files in this path then run:
# /usr/bin/c_rehash /etc/openldap/certs
TLS_CACERTDIR /etc/openldap/certs
# TLS_CACERT /etc/openldap/certs/ca.crt


>  
>  SASL/SCRAM-SHA-1 authentication started
>  Please enter your password: 
>  ldap_sasl_interactive_bind_s: Invalid credentials (49)
>  
>  I guess I have two questions.
>  
>  1. Should there be a socket somewhere owned by slapd for local communication?
>  
>  2. What password should I enter for ldap<command> and dsidm? 
It depends who the user is. If you have .dsrc with ldapi, you won't need a password as
your are binding with cn=Directory Manager aka "root for 389-ds ldap". If you
end up delegating privileges, you wouldbind as "that users dn".

Hope that helps somewhat! 

>  
>  Thanks for any pointer, advice, or help!
>  
>  -m
>  _______________________________________________
>  389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]... 
—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs