SSH for domain users

Probably not at all, as ssh should just use PAM. Configure PAM to include winbind from Samba, which you need anyways to join a FreeBSD machine to a Windows domain.
 
Probably the easiest to accomplish that is to use security/sssd.

Strictly speaking ADS is just a combination of Kerberos, LDAP and DNS. So really all you need is to enable kerberos authentication. But you're going to need LDAP access too in order to get information like group membership, shells, home directories etc. SSSD can take care of all this for you.
 
Probably the easiest to accomplish that is to use security/sssd.
Although sssd docs recommend to use the "AD" provider and join the domain, for which it depends on samba. So, if you want to do this, using samba directly (winbind offers integration with PAM and NSS) might be simpler ;)

Of course, if for some reason you don't want to join the domain, sssd should still work.
 
It's the tool that's used on RHEL to make it possible. It's actually fairly easy to configure and use. We have about 800+ RHEL servers and you can login on all of them with an AD account (and the proper access permissions of course, we don't just let anyone login on servers). Cross-domain authentication/trusts work, cross-forest however does not work. Although I have figured out how to effectively make that work too (even though RedHat says it can't be done).
 
I only have a single domain here, so that's all I can test, but for that, plain samba gets the job done just as well. All you have to do is to enable winbindd and add winbind to /etc/nsswitch.conf and /etc/pam.d/system (and maybe a few concrete pam services if they don't include system).

So, pretty well possible sssd adds features on top of that :) But I think for a simple usecase (if you want to join the domain, which would be the normal thing to do), just samba is fine.
 
Probably the easiest to accomplish that is to use security/sssd.

Strictly speaking ADS is just a combination of Kerberos, LDAP and DNS. So really all you need is to enable kerberos authentication. But you're going to need LDAP access too in order to get information like group membership, shells, home directories etc. SSSD can take care of all this for you.
Give an example if possible sssd.conf.
Since even service sssd not started.
 
dp_module_open_lib] (0x0010): Unable to load module [ad] with path [/usr/local/lib/sssd/libsss_ad.so]:

Yes indeed not such a module. Where to get?
 
Build the port yourself with option SMB enabled. Or just use samba directly. In any case, you WILL have some documentation reading to do.
 
Give an example if possible sssd.conf.
The important part is the [domain/...] section:
Code:
[domain/example.com]
debug_level = 3
ad_domain = example.com
krb5_realm = EXAMPLE.com
realmd_tags = manages-system joined-with-samba
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/sh
ldap_id_mapping = True
use_fully_qualified_names = False
fallback_homedir = /home/%u@%d
access_provider = ad
dyndns_update = false
krb5_ccname_template = FILE:/tmp/krb5cc_%U
ldap_user_gecos = description
ad_gpo_access_control = permissive
ad_maximum_machine_account_password_age = 0
ldap_referrals = false
krb5_renewable_lifetime = 7d
krb5_renew_interval = 8h

That should get you started. Use net ads join to join the computer to the domain. That should also create the appropriated keys in krb5.keytab.

Note that I've done this a gazillion times on RHEL, never on FreeBSD. I really should set up a Windows server with a domain and do a proper write-up for FreeBSD.
 
  • Like
Reactions: bjs
Thanks for an example file.
Computer with FreeBSD in the domain.
Code:
checking for xsltproc... /usr/local/bin/xsltproc
checking for xmllint... /usr/local/bin/xmllint
checking for /usr/local/share/xml/catalog... yes
checking for Docbook XSL profiling templates in XML catalog... no
configure: WARNING: Man pages might contain documentation for experimental features
checking for /usr/local/share/xml/catalog... (cached) yes
checking for Docbook XSL templates in XML catalog... no
configure: error: could not find the docbook xsl catalog
===>  Script "configure" failed unexpectedly.
Please report the problem to [email]lukas.slebodnik@intrak.sk[/email] [maintainer] and attach
the "/usr/ports/security/sssd/work/sssd-1.16.5/config.log" including the
output of the failure of your make command. Also, it might be a good idea to
provide an overview of all packages installed on your system (e.g. a
/usr/local/sbin/pkg-static info -g -Ea).
*** Error code 1
This installation from ports for enable sssd/SMB.
sssd/DOC disable.
From packages sssd/SMB disable.
 
That looks like a problem with the port itself. Does it build properly if you keep DOCS enabled?
 
Computer with FreeBSD in the domain.
If by that, you mean the machine is already joined to the domain (with net ads join), then again, authentication can be done with winbind only. winbindd must be running, e.g. with the following /etc/rc.conf entries:
Code:
samba_server_enable="YES"
winbindd_enable="YES"
Then just configure NSS, e.g. with the following changed entries in /etc/nsswitch.conf:
Code:
group: files winbind
passwd: files winbind
Details here: https://wiki.samba.org/index.php/Se...in_Member#Configuring_the_Name_Service_Switch

And for PAM, read https://wiki.samba.org/index.php/Authenticating_Domain_Users_Using_PAM

With FreeBSD's PAM, you probably want to change /etc/pam.d/system. E.g. mine has the following:
Code:
auth        sufficient    pam_winbind.so        try_first_pass krb5_auth krb5_ccache_type="FILE"
auth        required    pam_unix.so        use_first_pass nullok

account        requisite    pam_login_access.so
account        sufficient    pam_unix.so
account        required    pam_winbind.so        cached_login

session        required    pam_lastlog.so        no_fail
session        required    pam_winbind.so

password    sufficient    pam_winbind.so
password    required    pam_unix.so        no_warn try_first_pass
Then you want to make sure the "sshd" service (/etc/pam.d/sshd) uses this as well, the simplest solution looks like this:
Code:
auth        include        system
account        include        system
session        include        system
password    include        system

For kerberos authentication ( krb5_auth) to work, you have to configure this as well, it's also in the samba wiki linked above.
 
Everything is accurate.
As you wrote.
I will add just a few touches.

Samba4 already worked.

In /etc/ssh/sshd_config

Code:
PasswordAuthentication yes
ChallengeResponseAuthentication no

for /etc/pam.d/sshd and /etc/pam.d/system (for example)
Code:
auth            sufficient      /usr/local/lib/pam_winbind.so   -
Thanks.
 
When executing the command su, the following appeared even for users from passwd.

su
Password:
LDAP Password:
su: Sorry

From where LDAP?
 
Did you check /etc/pam.d/su? I've never seen this behavior with samba and winbind, so I'd assume some PAM configuration is wrong.

Edit: I left my /etc/pam.d/su alone, so it doesn't have any reference to winbind and just includes system for "auth" … it looks like this here:
Code:
#
# $FreeBSD$
#
# 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

# account
account        include        system

# session
session        required    pam_permit.so
 
The OP modified system which gets included in a bunch of other PAM configurations, including su. If post #14 is correct it looks like only the auth section was done and not account,session and password too.
 
Yes, there were wrong lines in the file. /etc/pam.d/system.
I forgot that I changed it.

Certainly strings
"include system"
more correct and convenient, , but it's easier for me to edit the file for each service in /etc/pam.d/.

Command "su" works.

Thank you.
 
I'm gettin stuck with /usr/local/lib/sssd/libsss_ad.so, samba416 didn't contain such library.

Code:
(Mon Mar 27 16:11:10 2023) [sssd[be[LAB.DOMAIN.COM]]] [dp_module_open_lib] (0x0010): Unable to load module [ad] with path [/usr/local/lib/sssd/libsss_ad.so]: Cannot open "/usr/local/lib/sssd/libsss_ad.so"

Any ideas?
 
I still don't understand what sssd is offering that you can't have using samba (and the included pam_winbind.so/nss_winbind.so) directly?
 
I still don't understand what sssd is offering that you can't have using samba (and the included pam_winbind.so/nss_winbind.so) directly?
Using sssd we can auth against AD using public keys while the keys are stored in AD. We can also use sudo roles stored in AD.
I don't know if pam_winbind.so/nss_winbind.so has these features. If they do, I'm curios to learn more about them.
 
Update: with dvl@ 's help we implemented SSSD on 13.1, works like a a charm ??
In Active Directory the ssh public key is attached to each user's *altSecurityIdentities attribute, The key no longer have to be present local on all of FreeBSD servers. Upon ssh login, sssd checks against AD if the presented private key matches. If it does access is granted, otherwise denied.
I the same time sssd check sudo roles configured in AD for the user for the particular host.
This works on a mixed environment too, the same configuration ca be used by Linux servers.

Where helps is still needed is porting the new SSSD. FreeBSD only has 1.16.5_8 version, while at this time 2.9.0 was released already.

*We tried sshPublicKey field as well, however that is stored in Hexadecimal format and with Active Directory Users and Computers you can only specify one (Apache Directory Studio handles it better).
 
Back
Top