Настроить общие папки в samba через sssd, который стучится в AD. В CentOS 7
Есть файлопомойка на CentOS 7, есть Active Directory на Windows Server 2012. Сама CentOS введена в домен. С SSH проблем не возникло — он просто стал пускать доменных пользователей. Теперь хочется сделать так же легко с общими папками. Что прописать в /etc/samba/smb.conf ? В сети есть километровые руководства по правке krb5.conf , но судя по всему — это всё равно что сейчас настраивать графику через xorg.conf .
2 ответа 2
Получилось благодаря пинку @alexanderbarakin в нужную сторону. Итак:
Ставим нужные зависимости:
dnf -y install realmd sssd oddjob oddjob-mkhomedir adcli samba-common samba-common-tools sssd-libwbclient samba Вводим centos в домен с юзером admin-of-ad в домен example.com :
realm join -U admin-of-ad example.com [global] workgroup = example security = ads kerberos method = system keytab realm = example.com [share] comment = My shared folder path = /data/share public = yes writeable = yes browseable = yes guest ok = yes valid users = @"depit@example.com" directory mask = 0775 create mask = 0664 vfs objects = acl_xattr inherit permissions = yes inherit acls = yes map acl inherit = yes store dos attributes = yes Если шарится папка на ext*, то в параметры монтирования /etc/fstab надо дописать атрибуты acl и user_xattr . Должно хватить и acl , но мы же нанотехнологичные чуваки. Для XFS ничё не надо, всё «искоробки»:
UUID=dabdd229-52dc-49d6-add2-a10f9f582bf5 / ext4 defaults,acl,user_xattr 0 0 Разрешаем полный доступ на уровне ugo . Локально всё равно только по ssh можно цепляться (ну только если у вас не проходной двор), а демон самбы сам разрулит кому можно, а кто идёт пасти бобров.
Конкретно в CentOS самба после установки сама не запускается. И ей даже не разрешено это делать. Так что разрешаем запускаться:
systemctl enable smb.service Разрешаем firewalld пускать самбу в сеть:
firewall-cmd --permanent --zone=public --add-service=samba Применить правила без разрыва соединений:
ДАЛЬШЕ ОЧЕНЬ ХРЕНОВЫЙ И ГРЯЗНЫЙ ХАК. Я ниасилил мандатное управление доступом, но записал себе в todo. Может потом допишу как надо.
sed -i 's/SELINUX=enforcing/SELINUX=disabled/' /etc/selinux/config Перезагружаем весь сервер, просто потому что.
Joining AD Domain Manually
The manual process of joining the GNU/Linux client to the AD domain consists of several steps:
- Acquiring the host keytab with Samba or create it using ktpass on the AD controller
- Configuring sssd.conf
- Configuring the system to use the SSSD for identity information and authentication
Creating Host Keytab with Samba
On the GNU/Linux client with properly configured /etc/krb5.conf (see below) and suitable /etc/samba/smb.conf , replacing your REALM/Domain name:
[logging] default = FILE:/var/log/krb5libs.log [libdefaults] default_realm = AD.EXAMPLE.COM dns_lookup_realm = true dns_lookup_kdc = true ticket_lifetime = 24h renew_lifetime = 7d forwardable = true rdns = false # You may also want either of: # allow_weak_crypto = true # default_tkt_enctypes = arcfour-hmac [realms] # Define only if DNS lookups are not working # AD.EXAMPLE.COM = # kdc = server.ad.example.com # master_kdc = server.ad.example.com # admin_server = server.ad.example.com # > [domain_realm] # Define only if DNS lookups are not working # .ad.example.com = AD.EXAMPLE.COM # ad.example.com = AD.EXAMPLE.COM
Make sure kinit aduser@AD.EXAMPLE.COM works properly. If not, using KRB5_TRACE usually provides helpful information:
KRB5_TRACE=/dev/stdout kinit -V aduser@AD.EXAMPLE.COM.
Update /etc/samba/smb.conf , replacing the sample domain/realm name with yours:
[global] security = ads realm = AD.EXAMPLE.COM workgroup = EXAMPLE log file = /var/log/samba/%m.log kerberos method = secrets and keytab client signing = yes client use spnego = yes
kinit Administrator net ads join -k
Alternatively, without using the Kerberos ticket:
net ads join -U Administrator
Additional principals can be created later with net ads keytab add if needed.
You don’t need a Domain Administrator account to do this, you just need an account with sufficient rights to join a machine to the domain. This is a notable advantage of this approach over generating the keytab directly on the AD controller.
Creating Service Keytab on AD
Do not do this step if you’ve already created a keytab using Samba. This part of the guide might be useful if the password for Administrator or another user who is able to enroll computers can’t be shared.
- Open Users & Computers snap-in
- Create a new Computer object named client (i.e., the name of the host running SSSD)
- On the command prompt
setspn -A host/client.ad.example.com@AD.EXAMPLE.COM client setspn -L client ktpass /princ host/client.ad.example.com@AD.EXAMPLE.COM /out client-host.keytab /crypto all /ptype KRB5_NT_PRINCIPAL -desonly /mapuser AD\client$ +setupn +rndPass +setpass +answer - This sets the machine account password and UPN for the principal
- If you create additional keytabs for the host add -setpass -setupn for the above command to prevent resetting the machine password (thus changing kvno) and to prevent overwriting the UPN
- Transfer the keytab created in a secure manner to the client as /etc/krb5.keytab and make sure its permissions are correct:
chown root:root /etc/krb5.keytab chmod 0600 /etc/krb5.keytab restorecon /etc/krb5.keytab See the next section for verifying the keytab file and the example sssd.conf below for the needed SSSD configuration.
Pre-flight check
To verify the keytab was acquired correctly and can be used to access AD:
net ads join -U Administrator klist -ke kinit -k CLIENT\$@AD.EXAMPLE.COM Now using this credential you’ve just created try fetching data from the server with ldapsearch (in case of issues make sure /etc/openldap/ldap.conf does not contain any unwanted settings):
net ads join -U Administrator /usr/bin/ldapsearch -H ldap://server.ad.example.com/ -Y GSSAPI -N -b "dc=ad,dc=example,dc=com" "(&(objectClass=user)(sAMAccountName=aduser))"
By using the credential from the keytab, you’ve verified that this credential has sufficient rights to retrieve user information.
You can also check if searching the Global Catalog works and whether the attributes your environment depends on are replicated to the Global Catalog:
net ads join -U Administrator /usr/bin/ldapsearch -H ldap://server.ad.example.com:3268 -Y GSSAPI -N -b "dc=ad,dc=example,dc=com" "(&(objectClass=user)(sAMAccountName=aduser))"
After both kinit and ldapsearch work properly proceed to actual SSSD configuration.
SSSD setup
Configuring SSSD consists of several steps:
- Install the sssd-ad package on the GNU/Linux client machine
- Make configuration changes to the files below
- Start the sssd service
Copy the following sssd.conf, additional options can be added as needed
[sssd] config_file_version = 2 domains = ad.example.com services = nss, pam [domain/ad.example.com] # Uncomment if you need offline logins # cache_credentials = true id_provider = ad auth_provider = ad access_provider = ad # Uncomment if service discovery is not working # ad_server = server.ad.example.com # Uncomment if you want to use POSIX UIDs and GIDs set on the AD side # ldap_id_mapping = False # Uncomment if the trusted domains are not reachable #ad_enabled_domains = ad.example.com # Comment out if the users have the shell and home dir set on the AD side default_shell = /bin/bash fallback_homedir = /home/%d/%u # Uncomment and adjust if the default principal SHORTNAME$@REALM is not available # ldap_sasl_authid = host/client.ad.example.com@AD.EXAMPLE.COM # Comment out if you prefer to use shortnames. use_fully_qualified_names = True # Uncomment if the child domain is reachable, but only using a specific DC # [domain/ad.example.com/child.example.com] # ad_server = dc.child.example.com
Set the file ownership and permissions
chown root:root /etc/sssd/sssd.conf chmod 0600 /etc/sssd/sssd.conf restorecon /etc/sssd/sssd.conf NSS/PAM Configuration
Depending on your distribution you have different options how to enable SSSD.
dnf install oddjob-mkhomedir authselect select sssd with-mkhomedir systemctl enable --now oddjobd.service
dnf install oddjob-mkhomedir authselect select sssd with-mkhomedir systemctl enable --now oddjobd.service
apt install libnss-sss libpam-sss On Debian/Ubuntu, add pam_mkhomedir.so to the PAM session configuration manually and restart SSSD.
Configure NSS/PAM manually
Manual configuration can be done with the following changes. The file paths for PAM in the example below are from Debian/Ubuntu, in Fedora/RHEL corresponding manual configuration should be done in /etc/pam.d/system-auth and /etc/pam.d/password-auth . See the sample nsswitch.conf below, it is expected to contain other modules.
passwd: files sss shadow: files sss group: files sss hosts: files dns bootparams: files ethers: files netmasks: files networks: files protocols: files rpc: files services: files sss netgroup: files sss publickey: files automount: files sss aliases: files sudoers : files sss
in the /etc/pam.d/common-auth file , Right after the pam_unix.so line, add:
auth sufficient pam_sss.so use_first_pass
in the /etc/pam.d/common-account file, Right after the pam_unix.so line, add:
account [default=bad success=ok user_unknown=ignore] pam_sss.so
in the /etc/pam.d/common-password file, Right after the pam_unix.so line, add:
password sufficient pam_sss.so use_authtok
In the /etc/pam.d/common-session file. Just before the pam_unix.so line, add:
session optional pam_mkhomedir.so
Also in this file right after the pam_unix.so line, add:
session optional pam_sss.so