Devuan freeipa domain users control local devices

The Debian method of granting access to devices like the network cards, audio output, printers, etc., is to add a user to the appropriate system group. For domain users, however, do I have to add every single domain user to the local group? I have sought an answer to this problem for a long time. After a lot of research, and coming back to the problem, I finally have a solution I find acceptable for general use and for sharing.

Overview

You have to adjust pam, nsswitch, and the local groups themselves. However, no additional packages should be needed!

Assumptions

I did this with lightdm display manager, which calls pam. During my research, I read on one of those pages somewhere that not all DMs use pam. Just make sure yours does.
You have domain groups named netdev, plugdev, audio, etc. Making extra groups in the directory, with either nested groups or direct members, is a small price to pay for this goal!

The steps

Configure pam

You have to configure pam to include the pam_group library.

tf=/usr/share/pam-configs/my_groups
sudo touch "${tf}" ; sudo chmod 0644 "${tf}" ; sudo chown root.root "${tf}"
cat <<EOF | sudo tee "${tf}" 1>/dev/null
Name: activate /etc/security/group.conf
Default: yes
Priority: 900
Auth-Type: Primary
Auth:
        required                        pam_group.so use_first_pass
EOF

And run the debian pam-auth-update program. Obviously there is not a EL equivalent, but then you can’t have this problem on a EL derivative.

pam-auth-update

And select the option that we just wrote, “Activate /etc/security/group.conf”

Configure nsswitch.conf

Change the group: line in nsswitch.conf to the following:

group:      compat [SUCCESS=merge] sss

You can accomplish that with a sed oneliner:

sed -i -r -e '/^\s*group:/s/(compat|files) sss/\1 [SUCCESS=merge] sss/;' /etc/nsswitch.conf

Change the local groups

To take advantage of the glibc group merging, you have to be using glibc 2.24 or higher, and Devuan Ceres has 2.28 so we’re good. Also, the GIDs have to match exactly. Of course your GID range will be different from mine, but I wrote a general solution.

test -z "${LOGFILE}" && LOGFILE=/root/deploy.log
for word in netdev video audio dip ;
do
   {
      tgid="$( getent group -s  sss  "${word}" | awk -F':' '{print $3}' )"
      ogid="$( getent group -s files "${word}" | awk -F':' '{print $3}' )"
   } 2>/dev/null
   # if group exists locally and in domain
   test -n "${ogid}" && test -n "${tgid}" && test ${ogid} -ne ${tgid} && {
      # use sed because groupmod fails because the new GID already exists
      sed -i -r -e "/^${word}:/s/:${ogid}:/:${tgid}:/;" /etc/group
      # log to stdout and logfile
      printf '%s %s\n' "$( date -u "+%FT%TZ" )" "Change ${word} from gid ${ogid} to ${tgid}" | tee -a "${LOGFILE}"
   }
done

This snippet changes the gid of the requested local groups, to match the gid of the netgroups. A reboot is required to get the updated permissions on the device special files.

References

Web searches

pam_group add domain user to netdev

Weblinks

  1. pam – Add all network users to local group for specific hosts in CentOS7 – Server Fault
  2. OpenLDAP/SSSD Automatically Add User to Local Group – Server Fault
  3. LDAPClientAuthentication – Community Help Wiki [help.ubuntu.com]
  4. Proposals/GroupMerging – glibc wiki
  5. SystemGroups – Debian Wiki
  6. My question from a few months ago Grant domain user access like he is in netdev group [linuxquestions.org]

Devuan join freeipa domain

FreeIPA is a great identity management domain for GNU/Linux systems. This post explains how to join a Devuan installation as a client to FreeIPA so that you can use centralized users, sudo policies, certificates, and everything else that is managed by freeipa.

Prerequisites

Running Devuan Ceres

You must be running Devuan ceres (unstable) to make the freeipa packages available. To get there, you need these exact apt sources:

deb http://packages.devuan.org/merged ceres main contrib non-free
deb-src http://packages.devuan.org/merged ceres main contrib non-free

To use the packages from these repos, you should do the normal update, upgrade, and dist-upgrade. Here is my full command for an unattended upgrade.

mkdir -p ~/log ; sudo apt-get update ;
_myact() {
   sudo DEBIAN_FRONTEND=noninteractive apt-get -q -y -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold" -o Dpkg::Options::="--force-overwrite" upgrade ;
   sudo DEBIAN_FRONTEND=noninteractive apt-get -q -y -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold" -o Dpkg::Options::="--force-overwrite" dist-upgrade ;
} ;
time _myact 2>&1 | tee -a ~/log/apt-get.upgrade.$( date "+%F" ).log

After a reboot, you are ready for the next steps.

Building custom oddjob-mkhomedir

You need a custom package, because in Devuan package oddjob is banned (because of systemd dependencies). I built a dummy package, which you can install from my OBS account.
I will briefly describe the build process so you can do this in your environment. My build resources are in version control on my gitlab in two directories.

  1. Build a dummy source tarball
    mkdir -p ~/deb/oddjob-mkhomedir-0.0.1/ ; cd ~/deb/oddjob-mkhomedir ; echo "Dummy package" >> README-oddjob-mkhomedir.md
  2. Build a debian/ directory
    debmake

    I modifed the debian control files to make it an all-architecture deb so I didn’t have to recompile for i686 and x86_64, but for a one-off package for yourself, don’t bother.

  3. Compile the package
    debuild -us -uc

    In the parent directory, which in my example is ~/deb, there should be the oddjob-mkhomedir_0.0.1-1_amd64.deb
    Loading it into an apt repository is beyond the scope of this conversation.

  4. Install the package
    apt-get install ~/deb/oddjob-mkhomedir_0.0.1-1_amd64.deb

Because of this fake mkhomedir package, we will have to take steps to enable the mkhomedir behavior farther ahead.

Install packages and files

Install the client software.

sudo apt-get -y install freeipa-client

You will need to have a dummy file for systemctl and for hostnamectl. Some components of freeipa are hardcoded to use that. Maybe we should recompile the freeipa package for Devuan instead of just using the debian one. But that sounds way beyond my capacity. So let’s just keep hacking.

tf=/bin/systemctl
sudo touch "${tf}" ; sudo chmod 0755 "${tf}"
sudo tee "${tf}" <<EOF /dev/null
#!/bin/sh
true
EOF

tf=/usr/bin/hostnamectl
sudo touch "${tf}" ; sudo chmod 0755 "${tf}"
sudo tee "${tf}" <<EOF /dev/null
#!/bin/sh
true
EOF

Configure freeipa client

Now we are ready to do the main work! I found that I had to disable ntp so the script could do its thing, which recently has been installing chronyd. I guess I don’t care; I just don’t want drift. I picked my battles, and ntp clients is not the battle I will fight today.

sudo service ntp stop

The script does not make a few important directories, so just make these yourself, and then run the install script.

sudo mkdir -p /etc/ipa /var/lib/ipa-client/pki
sudo ipa-client-install --hostname="$( hostname --fqdn )" --mkhomedir --configure-firefox

Of course if you don’t want those options, remove them. I think the configure-firefox step is broken anyway. I forget what it’s supposed to do; maybe load the ipa CA cert into the nss database.
I found that I always have to restart sssd after my initial client configuration. It’s a small price to pay for domain user resolution, so just do it. In this case, actually stop it and then start it.

sudo service sssd stop ; sudo service sssd start

That should be the bare minimum to get freeipa domain user auth working.

Followup and extra goodies

For the quality-of-life improvements, you need a few extra steps.

Add mkhomedir

Now is the time to add pam_mkhomedir to the pam stack.

# add pam_mkhomedir
tf=/etc/pam.d/common-session ; ! grep -q 'mkhomedir' "${tf}" && { thisline="$(( $( grep -nE 'session\s+optional' "${tf}" | head -n1 | awk -F':' '{print $1}' ) - 0 ))" ; awk -v thisline="$thisline" 'NR == (thisline) {print "session optional        pam_mkhomedir.so"; } {print;}' "${tf}" > "${tf}.2" ; test -f "${tf}.2" && mv "${tf}.2" "${tf}" ; }

This one-liner checks for the existence of the string “mkhomedir” in the common-session file and then adds the pam_mkhomedir.so lib to the pam session stack if it was absent. It cleverly sticks it at the beginning of the “session optional” section, because the order of pam statements is important. So if you have heavily customized your pam configuration, you need to be careful. This line works with a bog-standard pam config straight from the ISO. If you want to stick it in there yourself, you need this line:

session optional        pam_mkhomedir.so

Kerberos trust dns

If you want to just use short hostnames to access other systems, you need to tell kerberos to trust dns.
If you have bgscripts package installed, you can use the updateval command in a oneliner.

sudo updateval -a /etc/krb5.conf -s '[libdefaults]' '^(\s*dns_canonicalize_hostname\s*=\s*).*' '  dns_canonicalize_hostname = true'

Basically, in /etc/krb5.conf change dns_canonicalize_hostname to true.

Troubleshooting

If the install fails for any reason, before you reinstall it, you have to run ipa-client-install –uninstall. And in order for that second command to succeed, you probably have to run “certmonger” first. I don’t really know why running that allows it to uninstall, but just take it under advisement.

References

Original research

PolicyKit rule for admins to automatically mount iso files in file manager

If you use a graphical file manager and want to take advantage of automatically mounting .iso files, you might be prompted to authenticate as an authorized user. This interrupts the workflow, and should not happen.

XFCE PolicyKit Agent warning about authentication required to perform an action
Workflow interruption detected! A Linux guru is needed if you want to automate this.

Here is a polkit rule you can make and place in the /usr/lib/polkit-1/rules.d directory. I don’t think freeipa has policykit abilities, so you have to apply this file locally for any system that needs it.
https://gitlab.com/snippets/1793736

// File: /usr/share/polkit-1/rules.d/mount-iso.rules
// File: /usr/share/polkit-1/rules.d/mount-iso.rules
// Author: bgstack15
// Startdate: 2018-12-29 19:18
// Title: PolicyKit Rules for Allowing FreeIPA admins to mount loop devices for ISO files
// History:
// Usage:
// Reference:
//    https://www.freeipa.org/page/Howto/FreeIPA_PolicyKit
//    lightdm.rules
//    https://askubuntu.com/questions/536405/location-of-policykit-log-output/536432#536432
// Documentation: comments are C-style
polkit.addRule(function(action, subject) {
    if ( (action.id.indexOf("org.freedesktop.udisks2.filesystem-mount-system") == 0) || 
         (action.id.indexOf("org.freedesktop.udisks2.loop-modify-others") == 0) ) {
        polkit.log("action=" + action);
        polkit.log("subject=" + subject);
        if (subject.isInGroup ("wheel") || subject.isInGroup("admins") || subject.isInGroup("cdrom")) {
            return polkit.Result.YES;
        }
    }
});

I realize the logic is crude so if you have any improvements, please share them!

Fedora 27 ssh and default kerberos config

On my new Fedora 27 system which I joined to my FreeIPA domain, I encountered an error I hadn’t seen before.
In the past I could just say “ssh remotehost” and it would connect me with GSSAPI auth using my kerberos key– no password or ssh key needed! It was wonderful. However, I ran into this issue, as seen with ssh -v remotehost

debug1: Unspecified GSS failure.  Minor code may provide more information
Server host/remotehost@IPA.EXAMPLE.COM not found in Kerberos database

But I know for a fact it’s in the kerberos database!
I duckducked (new verb) the error message and found the culprit.
In file /etc/krb5.conf, this variable should be set to this value:

[libdefaults]
  dns_canonicalize_hostname = true

The default is true according to man krb5.conf. but for whatever reason, whether by joining the domain, or some default of some package in Fedora 27, it was set to false.

For the followers of my bgscripts package, just use this command:

sudo updateval -a /etc/krb5.conf -s '[libdefaults]' '^(\s*dns_canonicalize_hostname\s*=\s*).*' '  dns_canonicalize_hostname = true'

References

Weblinks

  1. https://superuser.com/questions/1166094/ssh-single-sign-on-with-kerberos/1166101#1166101

Samba and ntlm for Windows clients

tl;dr

Use one or the other:

1. Insecure but fast, in /etc/samba/smb.conf:

[global]
ntlm auth = yes

2. Best, on client Windows machine:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa]
"LmCompatibilityLevel"=dword:00000001

Samba and ntlm

With the published “ETERNALBLUE” vulnerability (CVE-2017-0146) a few months ago, the effects finally trickled down to the default settings for samba in CentOS 7.

After updating to samba 4.6.2, I was unable to access my samba share from a Windows client (using my freeipa credentials).

Here’s what I found in /var/log/samba/log.lsasd after setting [global] log level = 3:

  check_ntlm_password:  Authentication for user [bgstack15] -> [bgstack15] FAILED with error NT_STATUS_WRONG_PASSWORD
[2017/10/01 16:45:54.106771,  2, pid=5289] ../auth/gensec/spnego.c:768(gensec_spnego_server_negTokenTarg)
  SPNEGO login failed: NT_STATUS_WRONG_PASSWORD
[2017/10/01 16:45:54.106860,  3, pid=5289] ../source3/smbd/smb2_server.c:3097(smbd_smb2_request_error_ex)
  smbd_smb2_request_error_ex: smbd_smb2_request_error_ex: idx[1] status[NT_STATUS_LOGON_FAILURE] || at ../source3/smbd/smb2_sesssetup.c:134
[2017/10/01 16:45:54.107513,  3, pid=5289] ../source3/smbd/server_exit.c:246(exit_server_common)
  Server exit (NT_STATUS_CONNECTION_RESET)
[2017/10/01 16:45:54.113588,  3, pid=5249] ../source3/lib/util_procid.c:54(pid_to_procid)
  pid_to_procid: messaging_dgm_get_unique failed: No such file or directory

After lots and lots of research, I finally found the answer at the FreeBSD forum! Gotta love the FreeBSD folks; they keep us all sane and grounded in free and open computing.
Just add ntlm auth = yes to your [global] section of smb.conf!

However, I looked it up and that enables samba to accept ntlmv1, which was the vulnerable protocol based on that CVE I mentioned earlier in this article.

I wanted to find out how to stick to ntlmv2 authentication, if possible, and I did discover it! You can just configure your Windows clients to use the more secure settings either using the registry or the graphical secpol.msc tool.
For the Local Security Policy (secpol.msc) tool, navigate to Security Settings->Local Policies->Security Options->”Network security: LAN Manager authentication level.” Set it to “Send LM & NTLM – use NTLMv2 session security if negotiated.”

secpol.msc utility showing directory tree navigated to Network security: LAN Manager authentication level setting
Local Security Policy window with setting

To automate this setting, you can make a registry file such as ntlmv2.reg with the following contents:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa]
"LmCompatibilityLevel"=dword:00000001

I recognize this location from when I’ve adjusted it in the past, at a place that would not have been affected by this vulnerability or its remediation because they were forcing NTLMv2 years ago on the workstations.

Reference

Weblinks

      1. Samba quick answer https://forums.freebsd.org/threads/62169/
      2. Client secpol.msc answer https://support.symantec.com/en_US/article.TECH132917.html
      3. Client registry answer https://kb.iu.edu/d/atcb

Enabling mkhomedir on Ubuntu for FreeIPA

The story

In my endeavors to practice with FreeIPA, I tested the Ubuntu port of freeipa. There is a known bug where the –mkhomedir option of the ipa-client-install command for Ubuntu does not actually enable making homedirs for users on first login.

The solution

apt-get install freeipa-client
th="$( hostname --fqdn )"; case "${th}" in *.*) :;; *) th="${th}.$( awk '/search/ {print $2}' /etc/resolv.conf )";; esac;
ipa-client-install --mkhomedir --force-ntpd --enable-dns-updates --hostname "${th}"
sed -i -r -e 's/Default:\s\w+/Default: yes/;' /usr/share/pam-configs/mkhomedir
pam-auth-update # and add the homedir option manually because it cannot be scripted.

References

Weblinks

  1. https://bugs.launchpad.net/ubuntu/+source/freeipa/+bug/1336869

Generate certificate with SubjectAltName attributes in FreeIPA

Overview

Last updated 2018-05-17

If you want to serve webpages with ssl certificates that have Subject Alternative Names, and you use FreeIPA, you will need to take a few steps to make this possible. If you got to this page, you probably already know the importance of SAN on a cert.

This document will demonstrate how to get IPA to sign a certificate that has the ever-important SubjectAltName.

Example environment

Freeipa domain is at ipa.example.com

Host storage1.ipa.example.com is serving https, and I want to also serve on other domain names:

secondary.domain.com
http://www.ipa.example.com
http://www.example.com

You don’t even need to have all the SANs in the same domain!

Generate certificate with SAN in freeipa

Generate private key

openssl genrsa -aes256 -out /root/certs/https-storage1.ipa.example.com.key 2048

Use a simple passphrase you can remember.

Generate certificate signing request

Before you generate the csr, you will need to modify the default openssl.cnf file so it will make a csr with Subject Alternative Names.
In CentOS 7, that file is /etc/pki/tls/openssl.cnf.
In section [req] add line

req_extensions = v3_req

In section [ v3_req ] add lines (to add a new section as well)

subjectAltName = @alt_names

[alt_names]
DNS.1 = secondary.domain.com
DNS.2 = storage1.ipa.example.com
DNS.3 = www.ipa.example.com
DNS.4 = www.example.com

You can also include IP.1 = 192.168.1.1 entries.
On my CentOS 7 system, here is the diff:

# diff /etc/pki/tls/openssl.cnf /etc/pki/tls/openssl.cnf.2017-05-19.01 
126c126
< req_extensions = v3_req # The extensions to add to a certificate request --- > # req_extensions = v3_req # The extensions to add to a certificate request
225,232d224
< 
< subjectAltName = @alt_names
< 
< [alt_names]
< DNS.1 = secondary.domain.com
< DNS.2 = storage1.ipa.example.com
< DNS.3 = www.ipa.example.com
< DNS.4 = www.example.com

Reference: http://apetec.com/support/GenerateSAN-CSR.htm
Now generate the csr.

# openssl req -new -key /root/certs/https-storage1.ipa.example.com.key -out /root/certs/https-storage1.ipa.example.com.csr
Enter pass phrase for /root/certs/https-storage1.ipa.example.com.key:
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:US
State or Province Name (full name) []:Some State
Locality Name (eg, city) [Default City]:Default City
Organization Name (eg, company) [Default Company Ltd]:Example.com
Organizational Unit Name (eg, section) []:IT
Common Name (eg, your name or your server's hostname) []:storage1.ipa.example.com
Email Address []:bgstack15@gmail.com

Make entries in freeipa

To be able to sign a certificate in freeipa with whatever SANs you want, you need to have a host entry for each domain.
So manually create the hosts. You can force it; they are just dummy hosts.
Also manually create HTTP service entries for each of those hosts.

HTTP/secondary.domain.com@IPA.EXAMPLE.COM
HTTP/www.ipa.example.com@IPA.EXAMPLE.COM
HTTP/www.example.com@IPA.EXAMPLE.COM

I used the web interface for this, because it was easier for me. But everything in freeipa can be done with the cli; I simply haven’t done the research for how to make new host objects in FreeIPA on the command line yet.
Reference: https://www.redhat.com/archives/freeipa-users/2014-September/msg00267.html

Sign the certificate

In the web UI, you can navigate to Identity -> Services -> principal HTTP/storage1.ipa.example.com@IPA.EXAMPLE.COM.
Select the Actions button, and then New Certificate.
Paste the contents of the csr file.

Retrieve the certificate

In the web UI, under the section Service Certificate, select the Actions button -> Get certificate. You can copy the text and save it in the terminal.

References

Weblinks

  1. Generate CSR with SAN http://apetec.com/support/GenerateSAN-CSR.htm
  2. Generate each host and HTTP service https://www.redhat.com/archives/freeipa-users/2014-September/msg00267.html
  3. Generate CSR https://bgstack15.wordpress.com/2016/06/30/manipulating-ssl-certificates/

Samba share with freeipa auth

Use FreeIPA Authentication for Samba CIFS Shares for Non-domain Windows Clients

I couldn’t find a singular place on the Internet for a descriptive guide of how to configure samba to use freeipa authentication for cifs shares for non-domain Windows clients.
There are guides out there for freeipa cross-domain trust, so you can share with a domain-joined Windows client, including https://www.freeipa.org/page/Howto/Integrating_a_Samba_File_Server_With_IPA.

This document will show you how to set up Samba 4.4.4 to use FreeIPA 4.4.0 usernames and passwords to allow Windows clients to connect to cifs shares.

Example environment

  • Freeipa domain is vm.example.com.
  • A freeipa master on CentOS7 host1.vm.example.com 192.168.100.10
  • A freeipa replica on CentOS7 host2.vm.example.com 192.168.100.11
  • Samba server will go on host2.vm.examplecom.
  • Windows client is horatio.vm.example.com.

Samba share with freeipa auth

Install freeipa server (and replica)

You need a working freeipa environment, which is outside the scope of this document. A quick sample installation process is:

### INSTALL FREEIPA host1.vm.example.com
firewall-cmd --permanent --add-service=freeipa-ldap --add-service=freeipa-ldaps --add-service=ntp --add-service=dns --add-service=dhcp --add-service=kerberos
firewall-cmd --reload

yum install -y ipa-server ipa-client
ipa-server-install -r VM.EXAMPLE.COM -n vm.example.com --mkhomedir --hostname="$( hostname --fqdn )" --admin-password='adminpassword' --ds-password='dspassword'

### INSTALL REPLICA host2.vm.example.com
firewall-cmd --permanent --add-service=freeipa-ldap --add-service=freeipa-ldaps --add-service=ntp --add-service=dns --add-service=dhcp --add-service=kerberos
firewall-cmd --reload

yum install -y ipa-server ipa-client
ipa-client-install --mkhomedir --force-ntpd --enable-dns-updates
ipa-replica-install --setup-ca --mkhomedir

Install samba server

Install the samba packages.

yum -y install samba samba-client sssd-libwbclient

Create the cifs principal for samba on one of the ipa controllers.

# run on an ipa controller. This principal name is "service/hostname"
ipa service-add cifs/host2.vm.example.com

Fetch the keytab to the samba server. In this example, it’s the same as the replica.

# on samba server
kinit -kt /etc/krb5.keytab
ipa-getkeytab -s host1.vm.example.com -p cifs/host2.vm.example.com -k /etc/samba/samba.keytab
setsebool -P samba_enable_home_dirs on &

Reference: https://www.freeipa.org/page/Howto/Integrating_a_Samba_File_Server_With_IPA

Install adtrust components

On the freeipa controller

yum -y install ipa-server-trust-ad
ipa-adtrust-install --add-sids

I recommend running this interactively, as shown above. Let it overwrite your samba config. It will configure it to use the registry, and we will rewrite it to suit the demands here.
The ipa-adtrust-install command generates the records you need to add to dns. They will look like:

Add the following service records to your DNS server for DNS zone vm.example.com: 
_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.vm.example.com. 86400 IN SRV 0 100 389 host2.vm.example.com.
_kerberos._udp.dc._msdcs.vm.example.com. 86400 IN SRV 0 100 88 host2.vm.example.com.
_kerberos._udp.Default-First-Site-Name._sites.dc._msdcs.vm.example.com. 86400 IN SRV 0 100 88 host2.vm.example.com.
_ldap._tcp.dc._msdcs.vm.example.com. 86400 IN SRV 0 100 389 host2.vm.example.com.
_kerberos._tcp.dc._msdcs.vm.example.com. 86400 IN SRV 0 100 88 host2.vm.example.com.
_kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.vm.example.com. 86400 IN SRV 0 100 88 host2.vm.example.com.

I successfully added them just fine by pasting them into my zone file and running rndc reconfig or systemctl restart named.
The adtrust mechanism adds new attributes to each user and group, specifically ipaNTSecurityIdentifier (the SID) and ipaNTHash. Technically the ipaNTHash can only be generated when the user changes passwords.
Reference: https://www.redhat.com/archives/freeipa-users/2015-September/msg00052.html

On the samba server

Install the ipa-server-trust-ad package on the samba server. You need this package there to get the ipasam config option in smb.conf.

yum -y install ipa-server-trust-ad

Open the firewall for the ports mentioned in the output of the command. You can use this script.

tf=/lib/firewalld/services/freeipa-samba.xml
touch "${tf}"; chmod 0644 "${tf}"; chown root:root "${tf}"; restorecon "${tf}"
cat <<EOFXML > "${tf}"
<?xml version="1.0" encoding="utf-8"?>
<service>
  <short>IPA and Samba</short>
  <description>This service provides the ports required by the ipa-adtrust-install command.</description>
  <port protocol="tcp" port="135"/>
  <port protocol="tcp" port="138"/>
  <port protocol="tcp" port="139"/>
  <port protocol="tcp" port="445"/>
  <port protocol="tcp" port="1024-1300"/>
  <port protocol="udp" port="138"/>
  <port protocol="udp" port="139"/>
  <port protocol="udp" port="389"/>
  <port protocol="udp" port="445"/>
</service>
EOFXML
systemctl restart firewalld
firewall-cmd --permanent --add-service=freeipa-samba
firewall-cmd --reload
echo done

Allow samba to read passwords

This is the magic part that is so hard to find on the Internet.
You will need to give special permissions to the samba service to read user passwords.

ipa permission-add "CIFS server can read user passwords" \
   --attrs={ipaNTHash,ipaNTSecurityIdentifier} \
   --type=user --right={read,search,compare} --bindtype=permission
ipa privilege-add "CIFS server privilege"
ipa privilege-add-permission "CIFS server privilege" \
   --permission="CIFS server can read user passwords"
ipa role-add "CIFS server"
ipa role-add-privilege "CIFS server" --privilege="CIFS server privilege"
ipa role-add-member "CIFS server" --services=cifs/host2.vm.example.com

Reference: http://freeipa-users.redhat.narkive.com/ez2uKpFS/authenticate-samba-3-or-4-with-freeipa

Explanation

If you use ldapsearch with kerberos authentication (after a kinit admin, of course), you can see attributes about users.

ldapsearch -Y gssapi "(uid=username)"

Even if the user has generated a new password since the adtrust installation, even the admin cannot see the ipaNTHash attribute.
To confirm the samba service can read the ipaNTHash, use its keytab and search for that attribute.

# on the samba server, so host2.vm.example.com
kdestroy -A
kinit -kt /etc/samba/samba.keytab cifs/host2.vm.example.com
ldapsearch -Y gssapi "(ipaNTHash=*)" ipaNTHash

Configure samba to use freeipa auth

When freeipa adjusts the samba config, it will just make it use the registry backend. You can view the equivalent conf file with testparm.
Here is a complete /etc/samba/smb.conf.

tf=/etc/samba/smb.conf
touch "${tf}"; chmod 0644 "${tf}"; chown root:root "${tf}"; restorecon "${tf}"
cat <<EOFCONF > "${tf}"
[global]
	debug pid = yes
	realm = VM.EXAMPLE.COM
	workgroup = VM
	domain master = Yes
	ldap group suffix = cn=groups,cn=accounts
	ldap machine suffix = cn=computers,cn=accounts
	ldap ssl = off
	ldap suffix = dc=vm,dc=example,dc=com
	ldap user suffix = cn=users,cn=accounts
	log file = /var/log/samba/log
	max log size = 100000
	domain logons = Yes
	registry shares = Yes
	disable spoolss = Yes
	dedicated keytab file = FILE:/etc/samba/samba.keytab
	kerberos method = dedicated keytab
	#passdb backend = ipasam:ldapi://%2fvar%2frun%2fslapd-VM-EXAMPLE-COM.socket
	#passdb backend = ldapsam:ldapi://%2fvar%2frun%2fslapd-VM-EXAMPLE-COM.socket
	passdb backend = ipasam:ldap://host2.vm.example.com ldap://host1.vm.example.com
	security = USER
	create krb5 conf = No
	rpc_daemon:lsasd = fork
	rpc_daemon:epmd = fork
	rpc_server:tcpip = yes
	rpc_server:netlogon = external
	rpc_server:samr = external
	rpc_server:lsasd = external
	rpc_server:lsass = external
	rpc_server:lsarpc = external
	rpc_server:epmapper = external
	ldapsam:trusted = yes
	idmap config * : backend = tdb

	ldap admin dn = cn=Directory Manager

[homes]
	comment = Home Directories
	valid users = %S, %D%w%S
	browseable = No
	read only = No
	inherit acls = Yes
EOFCONF
systemctl restart smb.service

Appendices

Get localsid

Get the local SID

net getlocalsid

Changing ipa domains

It’s possible that if you change ipa domains, the sssd cache is not cleared and you will have cached information for the old domain which can prevent user authentication from happening. You can just clear the cache directory manually and restart sssd.

rm -rf /var/lib/sss/db/*
systemctl restart sssd.service

Reference: https://bgstack15.wordpress.com/2017/05/07/freeipa-client-uninstall-and-reinstall/

References

Weblinks

  1. install samba and kerberize it https://sites.google.com/site/wikirolanddelepper/directory-services/ipa-server-with-samba
  2. add cifs/servername entry https://www.freeipa.org/page/Howto/Integrating_a_Samba_File_Server_With_IPA
  3. cifs service needs custom privilege to read password http://freeipa-users.redhat.narkive.com/ez2uKpFS/authenticate-samba-3-or-4-with-freeipa
  4. Each user must generate a new password https://www.redhat.com/archives/freeipa-users/2015-September/msg00052.html
  5. Seminal article about freeipa and samba integration https://techslaves.org/2011/08/24/freeipa-and-samba-3-integration/
  6. Changing ipa domains https://bgstack15.wordpress.com/2017/05/07/freeipa-client-uninstall-and-reinstall/

Freeipa client uninstall and reinstall

If you are changing ipa domains on a client, you first uninstall the client.

ipa-client-install --uninstall

Then you install in the new domain. (The lack of options here indicates it will search dns, so make sure your _kerberos entries are correct!)

ipa-client-install --mkhomedir --force-ntpd --enable-dns-updates

If you have problems with user accounts on the client for the new domain, it’s possible you need to manually clear out the sss cache to remove traces of the old domain.

rm -rf /var/lib/sss/db/*
systemctl restart sssd.service

References

Weblinks

  1. https://serverfault.com/questions/582854/how-to-reset-keytab-for-freeipa-server-and-client#583319

New user in freeipa has plain bash shell instead of reading .bashrc

So you have a new user in freeipa, and he can successfully log in to a freeipa client. And you know for certain you executed ipa-client-install with the –mkhomedir option. But when you open a terminal as the new user, it shows you the boring bash prompt ‘bash-4.1$’ or whatever version.

You checked the /etc/skel, and it has a valid .bashrc file, and when you dot source your own ~/.bashrc, it then loads the prompt you expect.

Here’s your issue: do a getent passwd username. Look at the login shell of the user. It’s going to be the default /bin/sh. Just change it in ipa to be /bin/bash! An sss_cache -E command was not enough; you have to log out and then back in to have it take effect. It’s probably because the terminal emulator is being called from a process that was started before the account was changed.