When maintaining a number of servers at once, one thing will become tedius (and prone to inconsistencies) fast: user management on all those server.
This is true for linux as well as freebsd. Microsoft has this mostly covered by stealing a splendid idea of novell netware 4 called NDS and renaming it Active Directory, which takes care of this.

There are several methods for authentication of user's passwords (like radius), but not all will work on freebsd/linux because most will only authenticate the user (as in: it just says a given username/password is ok), but no other information.
Since on *nix systems a user needs at least a gid and uid, this wont work unless that user already exists in /etc/passwd for instance, which kindof defeats the purpose since then you would have to create the users on all servers still.

To accomplish what we want, we can use LDAP, which is pretty much the same as NDS and AD in that it's a directory structure that holds objects like groups and users. It is possible to store way more than that, but for our purpose, this is all we need.

Before setting things up, make sure the following points are met:

Make sure that your network is set up and works correct.
Make sure that all server can talk to eachother. Check using ping commands.
Make sure that all your servers at least exist in /etc/hosts for lookups, or better: exist in DNS.
Make sure that all servers have a way to communicate the outside world to fetch packages and updates.

Note: we will not use ldap authentication for the ldap servers itself! If there's a problem on either one, at least they do not depend on a possibly broken ldap service.

For this setup, a couple of things are set as default which ofcourse have to change in the actual live setup:

Ip addresses:

ip address	used for	hostname (if any)
192.168.2.10	LDAP server	ldap.local.com
192.168.2.20	client server	client.local.com
192.168.2.254	default gateway
1.1.1.1	DNS server
europe.pool.ntp.org	time service

Timekeeping
One very important thing within LDAP is to have all the time in-sync on all servers! This can deviate a little, but it's important to keep this as close as possible. To do this, make sure that the time is regularly synchronized to a central server or a time pool like europe.pool.ntp.org.

Ofcourse we want a server with secure connections, so we will be setting things up using TLS and certificates.
Also, an effort is made to have the setup behave as close as possible to AD, in that we have domain admins, ldap admins etc.

The simplest method is to use the scripts and files available for download here. You do have to go through each and replace things like ip addresses, host names, etc to the correct values.
In the files, the defaults are as stated in the setup.

Download: files.tar.gz

The contents of this zipped tar is:

File	location	description
LdapAdmin.exe	on your windows desktop	a nice clean simple free tool to administer your ldap directory
hosts	/etc/	The hosts files with all the servers, please change things to suit your setup!
createcerts.sh	/usr/local/etc/openldap/certs/	The correct openssl commands to create all necessary certificates.
ca.conf	/usr/local/etc/openldap/certs/	The configuration for creating a ca certificate
server.conf	/usr/local/etc/openldap/certs/	The configuration for creating the server certificates
initconfig.sh	/usr/local/etc/openldap/	This will create and import the (initial) settings for the database.
initialize.sh	/usr/local/etc/openldap/	A script to fill in defaults inside the ldap directory
slapd.ldif	/usr/local/etc/openldap/	The main configuration file to set up the service and database
domain.ldif	/usr/local/etc/openldap/ (preferred)	A file to initialize the database with a basic folder, groups and users setup.

There is one 'dangerous' script added to this list, which never should be used unless the whole ldap database is corrupt: resetall.sh. This will:

Stop the slapd service
Remove the folder: /var/db/ldap-data entirely and recreate it with the correct uid/gid set
Start inifconfig.sh
Start initialize.sh

This should then result in an empty, but functioning, ldap server again.
To install the lot, first of all check all the files and adjust everything so it matches your setup.
Take special care to edit the usernames and passwords you intend to use!
Once done, it's a simple matter of running these commands:

installation commands (on freebsd)

# make sure this hostname is set correct..
hostname ldap.local.com 

pkg install openldap26-server openssl
cd /usr/local/etc/openldap/
mkdir certs
# copy all the files in the correct folders
cd certs
sh createcerts.sh
cd ..
sh resetall.sh

That last command (or whenever initialize.sh is started) a password will be asked to enter. THis password is the one set for cn=mdbadmin,dc=local,dc=com.

This is all that is needed to get your ldap server online!

Notes:

Running this service on a public ip is a bad idea, it's ment to run on a privat network!
Because this is supposed to run on a privat lan, using acme to get letsencrypt certificates might be problematic.

Setting up the client is really simple, it just needs a couple of small things set up.

First and foremost: if there's a problem with the ldap server, and you try to login via the console, then logging in with any user account might take some time!!
It will happen, so be patient.

Do not use pam_ldap and nss_ldap anymore! Instead, use nss-pam-ldap, which seems to be actively maintained!!

installation commands

pkg install openldap26-client openssl nss_pam_ldap
service nscd enable
service nslcd enable

now, edit ldap.conf:

nano /usr/local/etc/ldap.conf

#
# LDAP Defaults
#

# See ldap.conf(5) for details
# This file should be world readable but not world writable.
BASE    dc=local,dc=com
SSL     start_tls
URI			ldap://ldap.local.com
TLS_CACERT      /usr/local/etc/openldap/cacert.crt
ldap_version 3
pam_login_attribute     uid

create a new file for /usr/local/etc/nslcd.conf:

nano /usr/local/etc/nslcd.conf

uid nslcd
gid wheel
uri ldap://ldap.local.com/
base dc=local,dc=com
#binddn uid=mdbadmin,dc=local,dc=com
#bindpw Showmtm
bind_timelimit 3
idle_timelimit 10
timelimit 1
reconnect_retrytime 3
nss_initgroups_ignoreusers ALLLOCAL

Note: the times are kept fairly short. Specially the reconnect_retrytime is only 3 seconds. The reason being: if you log in on local console, then at least you do not have to wait a minute before it logs in!
Considering that the ldap server is a fairly important service, it shouldn't be offline much, and if so, for a shortes possible amount of time.

finishing commmands

chown nclcd /usr/local/etc/nslcd.conf
chmow 700 /usr/local/etc/nslcd.conf

service sshd restart
service nscd start
service nslcd start

Next make sure that pam knows about ldap, at first the system itself:

nano /etc/pam.d/system

#
#
# System-wide defaults
#

# auth
auth            sufficient      pam_opie.so             no_warn no_fake_prompts
auth            requisite       pam_opieaccess.so       no_warn allow_local
#auth           sufficient      pam_krb5.so             no_warn try_first_pass
#auth           sufficient      pam_ssh.so              no_warn try_first_pass
auth            sufficient      pam_ldap.so             no_warn try_first_pass
auth            required        pam_unix.so             no_warn try_first_pass nullok

# account
#account        required        pam_krb5.so
account         required        pam_login_access.so
account         required        pam_ldap.so             ignore_unknown_user ignore_authinfo_unavail
account         required        pam_unix.so

# session
#session        optional        pam_ssh.so              want_agent
session         required        pam_lastlog.so          no_fail

# password
#password       sufficient      pam_krb5.so             no_warn try_first_pass
password        required        pam_ldap.so      				use_authok
password        required        pam_unix.so             no_warn try_first_pass

Next sshd:

nano /etc/pam.d/sshd

#
#
# PAM configuration for the "sshd" service
#

# auth
auth            sufficient      pam_opie.so             no_warn no_fake_prompts
auth            requisite       pam_opieaccess.so       no_warn allow_local
#auth           sufficient      pam_krb5.so             no_warn try_first_pass
#auth           sufficient      pam_ssh.so              no_warn try_first_pass
auth            sufficient      pam_ldap.so             no_warn try_first_pass minimum_uid=1000
auth            required        pam_unix.so             no_warn try_first_pass

# account
account         required        pam_nologin.so
#account        required        pam_krb5.so
account         required        pam_login_access.so
account         required        pam_ldap.so             ignore_authinfo_unavail ignore_unknown_user minimum_uid=1000
account         required        pam_unix.so

# session
#session        optional        pam_ssh.so              want_agent
session         required        pam_permit.so
session         required        pam_mkhomedir.so        umask=0077

# password
#password       sufficient      pam_krb5.so             no_warn try_first_pass
password        required        pam_ldap.so             use_authok minimum_uid=1000
password        required        pam_unix.so             no_warn try_first_passd

Tell nssswitch we want to use ldap also:

nano /etc/nssswitch.conf

# in the file look for these lines:
group: compat
passwd: compat

# and change these into:
group: files cache ldap
passwd: files cache ldap

Yes, you can do that last command while being logged in on ssh yourself at the moment!

Last thing to do: copy the ca.crt from the server if we did use a self-signed certificate. Otherwise, we don't need it!
Also, it's nice to have the hosts file from the server, which should have all the ip addresses etc.
This is done easy:

fetching files

scp user@ldap.local.com:/etc/hosts /etc/hosts
scp user@ldap.local.com:/usr/local/etc/openldap/certs/ca.crt /usr/local/etc/openldap/cacert.crt

With that, the client setup is done. Reboot the server and you should be able to login using a user that doesn't exist in /etc/passwd on this machine!

At this time, mainly 1 issue remains to be solved:

- The user only exists in LDAP
- The user is not added to the wheel group in /etc/group
- the user is a member in a group with gid 0, even could be called wheel
Now, when logging in, the only way to actually be able to do 'su' with that user, you have to set the GID of that user to 0 (or, just set the primary group to domainadmins when using the setup here).
If you do not, but do make this user a member of that group, somehow the local server will refuse your su command saying 'sorry'.
You can still simply add that particular user in /etc/groups to the wheel group, but ofcourse it would be way nicer to have this also managed in ldap.
I would like to add hostnames etc. to be able to limit who can login on what server using ssh
I would like to add some property that will allow LDAP to dictate if the user has to be chrooted to a particular folder.
At this time there is mostly one way, be it not perfect:
nano /etc/ssh/sshd_config
```
Match group Chrooted?users
        ChrootDirectory %h
        X11Forwarding no
        AllowTcpForwarding no
```
Note the questionmark, it replaces the space in the LDAP group named 'Chrooted users'. Any member of that group will be chrooted.
One caveat is that if that homedirectory does not exist, the uid and gid is wrong, this should be root:wheel. Chown it afterwards will solve this. But also make sure to add certain tools (like /bin/sh) to that folder!