(Copied from another Question. These are my notes/guide on how I got all this working at a large client with existing AD infra)

Here is my guide on AD integration via SSSD with these versions of FreeBSD, at the time of this writing (6/2017)

• FreeBSD 10.3 and 11.0 (10.3-RELEASE-p18 & 11.0-RELEASE-p9)

• Installation (and the fun packaging and dependency issues)

  • The packages required don’t seem to be compatible with Heimdal Kerberos, so things must be installed and compiled with the MIT Kerberos flags enabled. This is likely more of a packaging dependency issue than an actual compatibility issue.
  • Heimdal is installed with the base system, so this leaves you with two sets of Kerberos commands if you install MIT Kerberos, one set in /usr/bin, and the other in /usr/local/bin. Since none of the base system files seems to be in a package, you can’t simply remove the Heimdal KRB stuff. Something to be aware of.

  • Forward dependencies of the various packages (interesting deps in bold, conflicting deps in bold italics):

    • net-mgmt/adcli:net/openldap24-sasl-client
    • security/cyrus-sasl2-gssapi: security/cyrus-sasl2
    • net/openldap24-sasl-client: security/cyrus-sasl2
    • security/sssd: security/nss
    • security/sssd:security/krb5
    • security/sssd: security/cyrus-sasl2
    • security/sssd:net/openldap24-client
    • security/sssd: lang/python27
    • security/sssd: lang/python2
    • security/sssd: dns/c-ares
    • security/sssd: devel/tevent
    • security/sssd: devel/talloc
    • security/sssd: devel/popt
    • security/sssd: devel/pcre
    • security/sssd: devel/libunistring
    • security/sssd: devel/libinotify
    • security/sssd: devel/gettext-runtime
    • security/sssd: devel/ding-libs
    • security/sssd: devel/dbus
    • security/sssd: databases/tdb
    • security/sssd: databases/ldb

  • Reverse dependencies of the various packages:

    • net/openldap24-sasl-client: sysutils/msktutil
    • net/openldap24-sasl-client: net/nss-pam-ldapd-sasl
    • net/openldap24-sasl-client: net-mgmt/adcli
      • As we see sssd itself requires the MIT Kerberos, even though we have Heimdal as the base package
      • adcli wants openldap-sasl-client, but other packages (including sub-dependencies of sssd) pull in openldap-client, which is mutex with the sasl client (for whatever silly reason). This makes installation a bit of a pain, even with a minimum set of binary packages.
      • These dependencies are present for both the binary repo packages, and if the packages are built in the ports tree. This necessitates an annoying particular method of installation to get everything we need (covered below).

  • As of this writing, the binary pkg for SSSD for FreeBSD does not include AD support in SSSD

    • The ports version of SSSD had to be built with the appropriate (make config) options enabled:
      • SMB
    • SSSD also wants to pull in openldap-client, when it really needs openldap-sasl-client to function correctly.
  • The pkg binary version of adcli exists, but as of this writing, doesn’t work.
    • Again, ports version was compiled with proper options enabled:
      • GSSAPI_MIT
  • cyrus-sasl-gssapi is required, but the pkg binary version doesn't work, and has odd dependency issues which cause it to remove SSSD.
    • Build it from ports with the MIT-KRB5 option enabled:
      • GSSAPI_MIT
  • openldap-sasl-client is required for functionality but SSSD wants to pull in the non SASL version of openldap.
    • To make this work
      • configure openldap-sasl-client with the GSSAPI option selected (make config) in ports.
      • Do the make in ports to build it
      • Before make install, do a pkg remove –f openldap-client
        • This will remove openldap-client without doing any autoremoves of any other packages (like SSSD) and allow installation of the SASL version
      • Do a make install for the openldap-sasl-client
        • This will install it to the system
  • This will provide what’s needed for a functional SSSD with AD capabilities.
  • Please note that if you compile SSSD from ports it will pull in a LOT of dependencies, which will cause them to be built, and require config options to be picked.
    • It is suggested that you install the binary package first with pkg install sssd then remove it with pkg remove –f sssd
      • This will cause the binary packages for most things that SSSD needs to be pulled in, and remove the need to build all of these depends in ports, which takes quite some time.
    • Once removed, reinstall SSSD from ports with the above mentioned options enabled and you will only need to rebuild the four packages mentioned above to get a working setup.

  • (Optional) Once everything is working and verified, you can use pkg create to create binary packages of the four packages with the proper options enabled and use those instead of building them in ports on every system. Installation of binary follows a similar pattern to the ports build process:

    • pkg install sssd-1.11.7_8.txz
      • Your version may be different of course
      • This will install the binary package for SSSD and pull in everything it needs from the FreeBSD repo.
    • pkg add the other packages (not install, add), saving the openldap package for last.
    • Before adding openldap-sasl-client do a pkg remove –f openldap-client
      • This gets rid of the non-SASL version and allows our version to be installed
    • pkg add openldap-sasl-client-2.4.44.txz
      • Again, your version may be different
    • You should wind up with the required packages installed.
    • It may be possible to change the metadata for the SSSD binary before doing the pkg create to replace the dependency on openldap-client with openldap-sasl-client to remove the need to do this remove/reinstall. I haven't had the time to look into doing this.
      • Plus, there are sub dependencies of SSSD which also pull in openldap-client, so you would have to fix those too.
    • Please note that all of these notes are as of the versions of these packages currently in the ports tree as of this writing, and the dependencies they have associated with them. This all may change as FreeBSD updates the ports tree and binaries. Maybe one day we’ll have a binary version of everything that pulls all the right dependencies with the proper options configured for AD functionality right out of the box.

  • Kerberos Configuration:

    • Sample /etc/krb5.conf file:

[libdefaults]
   default_realm = MYDOMAIN.NET
   forwardable = true
# Normally all you need in an AD environment, since DNS SRV records
# will identify the AD/KRB servers/services.  Comment out if you
# want to manually point to your AD server
dns_lookup_kdc = true
[realms]
   MYDOMAIN.NET = {
# If you're manually pointing to a different AD server than what's in DNS
#      admin_server = adserver.mydomain.net
#      kdc = adserver.mydomain.net
   }
[domain_realm]
   mydomain.net = MYDOMAIN.NET
   .mydomain.net = MYDOMAIN.NET

• (indent)
  • SSSD Configuration:
    • This example presumes POSIX attributes in AD for users and groups, generally required for when one is replacing an existing environment which already has established UIDs and GIDs.
    • Sample /usr/local/etc/sssd/sssd.conf file:

[sssd]
config_file_version = 2
domains = MYDOMAIN.NET
services = nss, pam, pac
fallback_homedir = /home/%u

[domain/MYDOMAIN.NET]
id_provider = ad
access_provider = ad
auth_provider = ad
chpass_provider = ad
# use AD POSIX attributes, comment out if you are using automatically generated
# UIDs and GIDs.
ldap_id_mapping = False
cache_credentials = true
ad_server = adserver.mydomain.net
# if you don't have bash, or whatever is in the AD account's loginShell
# attribute installed
override_shell = /bin/tcsh

• (indent)
  • PAM Configuration:
    • PAM configuration on FreeBSD is a bit tricky because of the way OpenPAM works. I won't go into details, but to use pam_sss for SSSD and have it work, and also have passwd logins work, you need to put pam_unix in the file twice. From what I understand, this has to do with a secondary check that is done "behind the scenes" that requires that second pam_unix module to pass.
      • Here is the listing of the /etc/pam.d files I’ve had to modify to make SSSD work with FreeBSD:

/etc/pam.d/sshd:

#
# $FreeBSD: releng/11.0/etc/pam.d/sshd 197769 2009-10-05 09:28:54Z des $
#
# 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_unix.so    no_warn try_first_pass nullok
auth     sufficient  pam_sss.so     use_first_pass
auth     required pam_unix.so    no_warn use_first_pass

# account
account     required pam_nologin.so
#account required pam_krb5.so
account     required pam_login_access.so
account     required pam_unix.so
account     sufficient  pam_sss.so

# session
#session optional pam_ssh.so     want_agent
session     optional pam_sss.so
session         required   pam_mkhomedir.so  mode=0700
session     required pam_permit.so

# password
#password   sufficient  pam_krb5.so    no_warn try_first_pass
#password   sufficient  pam_unix.so    try_first_pass use_authtok nullok
password sufficient  pam_unix.so    try_first_pass use_authtok
password sufficient  pam_sss.so     use_authtok

/etc/pam.d/system:

#
# $FreeBSD: releng/11.0/etc/pam.d/system 197769 2009-10-05 09:28:54Z des $
#
# 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    required pam_unix.so    no_warn try_first_pass nullok
auth     sufficient  pam_unix.so    no_warn try_first_pass
auth     sufficient  pam_sss.so     use_first_pass
auth     required pam_deny.so

# account
#account required pam_krb5.so
account     required pam_login_access.so
account     required pam_unix.so
account     sufficient  pam_sss.so

# session
#session optional pam_ssh.so     want_agent
session     required pam_lastlog.so    no_fail
session     optional pam_sss.so
session         required   pam_mkhomedir.so  mode=0700

# password
#password   sufficient  pam_krb5.so    no_warn try_first_pass
#password   required pam_unix.so    no_warn try_first_pass
password sufficient  pam_unix.so    no_warn try_first_pass nullok use_authtok
password sufficient  pam_sss.so     use_authtok
#password   required pam_deny.so

/etc/pam.d/su:

#
# $FreeBSD: releng/11.0/etc/pam.d/su 219663 2011-03-15 10:13:35Z des $
#
# PAM configuration for the "su" service
#

# auth
auth     sufficient  pam_rootok.so     no_warn
auth     sufficient  pam_self.so    no_warn
auth     requisite   pam_group.so      no_warn group=wheel root_only fail_safe ruser
auth     include     system.dist

# account
account     include     system.dist

# session
session     required pam_permit.so

• (indent)

  • Notes:
    • system.dist is a copy of the stock /etc/pam.d/system file. It is included in the /etc/pam.d/su file above to prevent issues with the su command.
    • One is still able to su to AD accounts as root, since once root, su doesn’t need to authenticate and the account info is pulled through the name service switch via SSSD.
    • If you really want switch from one user (not root) to a different user, one should use sudo for security reasons alone
    • You can also use ksu and that works for switching from user A to user B
      • Heimdal's ksu (in /usr/bin) doesn't have SUID set by default
        • To make Heimdal ksu work, chmod u+s /usr/bin/ksu
      • MIT Kerberos (krb5 package installed in /usr/local/bin) is SUID on install
    • Since Heimdal is part of the base package, you will have both sets of Kerberos binaries.
      • You may want to adjust the default paths so that /usr/local/bin is before /usr/bin, etc
    • ksu will prompt the user for the AD/Kerberos password of the target user
    • passwd will not work to change your AD/Kerberos password even if you add pam_sss.so to the passwd PAM file. The passwd binary only supports local and NIS Use kpasswd to change your password on the AD/Kerberos server(s).

  • Name Service Switch:

    • The /etc/nsswitch.conf file should be configured to use the sss service for passwd and groups. Example:
      • group: files sss
      • passwd: files sss

  • Joining a Domain:

    • There are two main tools on *nixs to join your linux box
      • adcli
        • This is my preferred tool. It works very well and everything can be done on a single command line. Credentials can be given non-interactively (via stdin, etc)
        • Doesn't require doing a kinit before using, it does it for you based on provided creds.
          • Example:
            • adcli join -D mydomain.net -U Administrator--show-details –v
            • adcli join –H adclient.mydomain.net -D mydomain.net -U Administrator --show-details -v
              • This form is recommended since the utility doesn't always figure out the FQDN correctly. When you provide the FQDN which matches both forward and reverse DNS for the host, the principles are created correctly. If the utility uses the incorrect hostname (not including the DNS domain, for instance), some service principals won't be created, and things like SSH into the host may fail.
      • Samba net utility
        • The net utility is part of the Samba suite.
        • This utility requires the domain details to be set up in the smb.conf configuration file, which makes it more difficult and inconvenient to use, especially non-interactively.
        • This tools also requires that you obtain a Kerberos ticket before using it by using kinit. Again, this is more inconvenient, and makes it a bit more difficult to use non-interactively in a script, since there are two steps instead of one.
          

  • SSHD considerations:

    • Getting SSHD to work with AD and SSSD is typically fairly simple
    • The following options need to be added to /etc/ssh/sshd_config
      • GSSAPIAuthentication yes
        • Turn on GSS API auth for SSHD. This will cause SSHD to auth against the AD KDC
      • PasswordAuthentication yes
        • Allow users to log in with passwords. Required if you wish a user to get a KRB5 ticket upon login. Without this enabled, the system can't decrypt the TGT sent by the KDC.
      • ChallengeResponseAuthentication yes
        • For FreeBSD, this method seems to work best.
          • Make sure you configure PasswordAuthentication no when using this option.
          • This is the only method I’ve found for FreeBSD that works to change an expired password upon login. If you use the other, it calls /bin/passwd, which doesn’t support anything but NIS and local passwd file.
      • GSSAPICleanupCredentials yes
        • (optional) Will do a kdestroy upon logout
      • GSSAPIStrictAcceptorCheck no
        • (optional) This option is often required if SSHD is confused about its own hostname, or is multihomed, etc, or otherwise uses a different service principal to communicate with the KDC. Normally SSHD will use the service principal host/<FQDN>@REALM to speak with the KDC, but sometimes gets it wrong (for instance, if the hostname doesn't match the DNS name of the SSH server). This option allows SSHD to use any principal in the /etc/krb5.keytab file, which includes the proper host/<FQDN>@REALM
    • Depending on the combination of options you use, you may or may not need to add host principals to the KDC for the IPv4 and IPv6 addresses of your host for ssh -K <ip> to work without prompting for a password (presuming you have done a 'kinit' already, of course).