FreeIPA settings for managing clients (Sudo Policies, Host and User certificate, automount)
Hello there,
today we are going through the settings in FreeIPA. We will set the sudo rules for the users, create a client host certificate and deploy a samba file server.
System Information
| Hostname | IP | Function |
| TEST-IPA01 | 192.168.152.220/24 | Identity, Policy Management, DNS, DHCP, Certificate Authority |
| TEST-FEDORA | 192.168.152.225/24 | Linux Client |
| TEST-SHARE | 192.168.152.221/24 | NFS / SMB Server |
Network Information
| Network | 192.168.152.0 |
| Subnet | 255.255.255.0 |
| Gateway | 192.168.152.254 |
FreeIPA Settings
FreeIPA sudo policies
Sudo command
Let’s begin with the sudo policies. Currently, the users have no sudo permissions on the hosts. We want to allow a couple of commands, so let’s create a new policy.
Open the FreeIPA WebUI and navigate to “Policy” -> “Sudo” -> “Sudo Commands” and click on “Add“.
In the new window, type in the full path of the command you want the user to be able to execute.
Save the command.
Sudo Rule
Next navigate to “Policy” -> “Sudo” -> “Sudo Rules“. In here, click on “Add” on the right side.
I will create a new rule naming it “ALLOW_DNF“. Click on “Add and Edit“.
Now, on the new page, click on “Add” under the “Who” “User Groups” setting.
Select the “ipausers” and add it to the “Prospective” side. Click on “Add“.
Scroll down, and click on “Add” under “Access this host” -> “Hosts“.
Select the client and add it.
Under the “Run Commands” section, click on “Add” for the “Sudo Allow Commands“.
In here, select the command we created earlier and save the configuration.
It should look something like this.
Ok. That’s it. Let’s test it.
Sudo rule test on Client
Alright. Let’s log into our client and open a terminal.
I mentioned it in the previous post, but we have to remove the user from the wheel group if we want to use the central sudo management.
To do this, execute the following command with an administrator account, for the user we want to remove from the group.
fedora :: ~ » sudo usermod -r -G wheel <username>
Ok, back to our tests.
To speed up the sudo policy synchronization, type in the following with an administrator account.
fedora :: ~ » sudo sss_cache -R
This will invalidate all cached sudo rules.
Now let’s test it.
First, let’s check if we can use sudo in general. Type in “sudo top“.
If everything worked, we should get an error message, telling us that the user is not allowed to execute the command.
Let’s test the allowed commands.
I will type in “sudo dnf clean all“.
Great, it worked. We can add as many commands as we want through the FreeIPA webui, and limit the use to specific users. We could also specify explicit options for a command. For instance, something like this would also work.
This would allow the user to update existing packages but not install new ones.
Requesting Host Certificate
Host certificate
Let’s request a certificate for the client. I am not complete sure if this is the right way to do it, also I don’t really know how to use this certificate we create :). But, it definitely generates one. Maybe it’s usable for radius authentication, I don’t know if I can test this. I will update this post if I can.
Let’s begin.
We need administrative permissions for this, so either give your user sudo permissions or switch to an administrator account on the client.
I switched to a local “administrator” account with full sudo permissions.
Login to your client and open the terminal.
Here, type in the following command to list the known CA configurations. This should have the IPA entry.
fedora :: ~ » sudo ipa-getcert list-cas
CA 'IPA':
is-default: no
ca-type: EXTERNAL
helper-location: /usr/libexec/certmonger/ipa-submit
Once, we have verified that the entry exists, we can execute the next command to request a new host certificate.
fedora :: ~ » sudo ipa-getcert request -d /etc/pki/nssdb/ -n "fedora-gnome" -K HOST/$(hostname)
New signing request "20240603192424" added.
Ok. Now execute the following, to list our requested certificate.
fedora :: ~ » sudo ipa-getcert list
Request ID '20240603192424':
status: MONITORING
stuck: no
key pair storage: type=NSSDB,location='/etc/pki/nssdb',nickname='fedora-gnome',token='NSS Certificate DB'
certificate: type=NSSDB,location='/etc/pki/nssdb',nickname='fedora-gnome',token='NSS Certificate DB'
CA: IPA
issuer: CN=Certificate Authority,O=TEST.INTRA
subject: CN=fedora-gnome.test.intra,O=TEST.INTRA
issued: 2024-06-03 21:24:27 CEST
expires: 2026-06-04 21:24:27 CEST
dns: fedora-gnome.test.intra
principal name: HOST/fedora-gnome.test.intra@TEST.INTRA
key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command:
track: yes
auto-renew: yes
Great. We can verify on the server if the certificate has been generated.
Login into the WebUI and navigate to “Authentication” -> “Certificates“. Here we should see our newly generated certificate.
We can see the new certificate. Alright.
Client Certificate
Ok. This next part took forever to figure out. It is actually very simple, but I barely found any information on this. Also, I never figured out how to actually track and automate this (without a script I mean). Oh well. Let’s continue.
To generate a user certificate we need to allow the user to actually generate one first (the alternative would be, to create one with an administrative account). I will show you the WebUI and the CLI way.
Allow user to create certificate (WebUI)
Skip to the next section, if you want to do this via the CLI.
Log into the FreeIPA WebUI and navigate to “Authentication” -> “Certificate ACLs” and click on “Add”.
Give it a name and click on “Add and Edit”.
On the new page, select “Add” in the “Profiles” section and choose the “IECUserRoles” profile.
Next, we either select “Anyone” or a specific user in the “Permitted to have certificates issued” section for the “Users“.
That’s it. Save the setting and navigate to “Identity” and click on the user we want to create a certificate for. “Max Mustermann” in my case.
In here, select “Action” -> “New Certificate“.
We will get a new window with instructions.
These next steps need to be on the cli, so log into the client.
I will create a database in the user home folder and follow the instructions.
# Create a folder for the database
fedora :: ~ » mkdir -p ~/.pki/nssdb
# Initialize the database and type in you password of choice.
fedora :: ~ » certutil -N -d ~/.pki/nssdb
Enter a password which will be used to encrypt your keys.
The password should be at least 8 characters long,
and should contain at least one non-alphabetic character.
Enter new password:
Re-enter password:
# Create a CSR
fedora :: ~ » certutil -R -d ~/.pki/nssdb -a -g 4096 -s 'CN=m.mustermann,O=TEST.INTRA'
A random seed must be generated that will be used in the
creation of your key. One of the easiest ways to create a
random seed is to use the timing of keystrokes on a keyboard.
To begin, type keys on the keyboard until this progress meter
is full. DO NOT USE THE AUTOREPEAT FUNCTION ON YOUR KEYBOARD!
Continue typing until the progress meter is full:
|************************************************************|
...
Unfortunately I do not see a way to automate this yet. But I will show another way, in the cli, after this. Anyway. We should receive the CSR (starting with —–BEGIN NEW CERTIFICATE REQUEST—–). Copy and paste the CSR into the text area and click on “Issue“.
Now we have our certificate. Clicking on Action would allow us to download it, if necessary.
Let’s take a look at the cli way.
Allow user to create certificate (CLI)
If you did the previous section, you can skip this.
Log into your FreeIPA server and create a group, we will give permission to create certificates later.
test-ipa01 :: ~ » ipa group-add generate_cert_user
--------------------------------
Added group "generate_cert_user"
--------------------------------
Group name: generate_cert_user
GID: 1298800008
Add the “m.mustermann” user to the new group.
test-ipa01 :: ~ » ipa group-add-member generate_cert_user --users=m.mustermann
--------------------------------
Added group "generate_cert_user"
--------------------------------
Group name: generate_cert_user
GID: 1298800008
[admin@test-ipa01 ~]$ ipa group-add-member generate_cert_user --users=m.mustermann
Group name: generate_cert_user
GID: 1298800008
Member users: m.mustermann
-------------------------
Number of members added 1
-------------------------
Create the CA ACL which allows the group to create certificates.
test-ipa01 :: ~ » ipa caacl-add USER_CERT
------------------------
Added CA ACL "USER_CERT"
------------------------
ACL name: USER_CERT
Enabled: True
Now add the group to the ACL.
test-ipa01 :: ~ » ipa caacl-add-user USER_CERT --group generate_cert_user
ACL name: USER_CERT
Enabled: True
User Groups: generate_cert_user
-------------------------
Number of members added 1
-------------------------
Last step. Add the certificate profile to the CA ACL.
test-ipa01 :: ~ » ipa caacl-add-profile USER_CERT --certprofile IECUserRoles
ACL name: USER_CERT
Enabled: True
Profiles: IECUserRoles
User Groups: generate_cert_user
-------------------------
Number of members added 1
-------------------------
Request User Certificate
Finally we can generate a CSR and request a new user certificate. For this, log into the client. The “${USER}” variable will be automatically replaced with the current username. This would allow us to automate the process (I think).
# Generate the CSR.
fedora :: ~ » openssl req -new -newkey rsa:4096 -days 365 -nodes -keyout ${USER}.key -out ${USER}.csr -subj /CN=${USER}
# Request a new certificate for the user
fedora :: ~ » ipa cert-request ${USER}.csr --principal=${USER} --profile-id=IECUserRoles --certificate-out=${USER}.crt
Now, verify that the new certificate was assigned to the user. I marked the certificates red. The first one was generated through the WebUI, the second one we just created.
fedora :: ~ » ipa user-show ${USER}
User login: m.mustermann
First name: Max
Last name: Mustermann
Home directory: /home/m.mustermann
Login shell: /bin/bash
Principal name: m.mustermann@TEST.INTRA
Principal alias: m.mustermann@TEST.INTRA
Email address: m.mustermann@test.intra
UID: 1298800004
GID: 1298800004
Certificate: MIIFhjCCA+6gAwIBAgIBEzANBgkqhkiG9w0BAQsFADA1MRMwEQYDVQQKDApURVNULklOVFJBMR4wHAYDVQQDDBVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMjQwNjA3MjEwMDI3WhcNMjYwNjA4MjEwMDI3WjAsMRMwEQYDVQQKDApURVNULklOVFJBMRUwEwYDVQQDDAxtLm11c3Rlcm1hbm4wggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDBPVkxAxCsHuKHag/k+cIS+zPGUQgvTwNosInryIEfOQ3JE9CJFUw3rukBKzRGWapM9kjSKrHHXqzBvimq9kLqG3EUeVl7U03XGzykOvgfrqjiYpSeAd/GInUUNeyn0A9ZkxTMWsvVQSGCpWgUYqrgo6ACsSaLrlwhaiJXQihsmjV1Oa/K/M/cXHcBdZGXjzCXi3Wfu0s8MykyS9k51PHuqFlYIAgeAtTCgWCWmgY+uXabAmxnbwEmdl5clYJhplMpkD94r3JYz0r4hPwnJml/LzJwPlri5es0ipsnDyYg1MXYyPdr3t3gfjwcRddSgHEvuS8++hUSJyhpYvzHq5nxx0th8y9iTGUKMTAPKtt/143XI13iqYt0cbQ73JZdOS7dbCjFM6W2zfTlm5wU+n6dHsvZ6pu4ZCOcQiKtSROSL8uE9D02jh1pdO3VdU8I7UE1eKlO05DkE3MQhSxZ0sakcb2CiKVvmEL4708ltSsIFH13+TTOo+7cROOJepu+bEYo4WrAY6WpznF8evrYVIoZeI2rdVJwPKi/6+nX/FZtZ8eYl+zRya9ZoqTHkh1H8ebOcB0tgxHgJbbSuvH69licWNUhD6wLZNZN3fUnG2VDA7FNHC1YINSXtWFv0k+XEEUpeJ6Mx1zK7i4MlAVjDQH7dPD9mej6VcXRvYfYyWno7QIDAQABo4IBKDCCASQwHwYDVR0jBBgwFoAUjX+ti+vjZ4nvryCZko1DWsIEJRcwPAYIKwYBBQUHAQEEMDAuMCwGCCsGAQUFBzABhiBodHRwOi8vaXBhLWNhLnRlc3QuaW50cmEvY2Evb2NzcDAOBgNVHQ8BAf8EBAMCBPAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMHUGA1UdHwRuMGwwaqAyoDCGLmh0dHA6Ly9pcGEtY2EudGVzdC5pbnRyYS9pcGEvY3JsL01hc3RlckNSTC5iaW6iNKQyMDAxDjAMBgNVBAoMBWlwYWNhMR4wHAYDVQQDDBVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHQYDVR0OBBYEFPNpFDE7HreWZKzsurzTlLvKX4VfMA0GCSqGSIb3DQEBCwUAA4IBgQCHVNaUG0VX3sWJhVACCjgadsILRI+3lAZdWJ4DSWxi4LrKimb9Vg+KuvFkaHlUHQxbUnDnFU2jfyp4LdDjq4JXa5LIqtm5Hk7A7BphzGPriRhHQFB7/JQGd3uCREMCHyQmsGNbt2497H/Ze7IeOTeG5bUIOr25jIuYn4eFgr2gEt7/bJbnVGnV28l+awJS1W5FMJX/mlG4e8Ef1/prBPpo/AQ/gUOukRMlj8XGjfy0nHxO6MX7N2ZmMLEkU2KKcyvampPiDaPOR4RaeJWMyXJwwqU0VKqKk+7+QMDnQDIAWhIPUSq+vJuHSRerY1IOAha/MV6fZ9bLY1fhPGZ6AcDxBe7GBVxaZ+wDNtGbVzqqPvzVhANwUIXzTWy+Tey3HnSMj9xJsV52WuTvaE6JdgNNIMBS1uM0eKHikkTjHdNFb6RlaJNrVG6YhZp7BRlw6RzdDsJPFTe9q+Ds/XJWCCXiwIOMwZr64J41cB9oNNsm6HpyuPZ67q2ojB+xGhqqXkY=,
MIIFhjCCA+6gAwIBAgIBFTANBgkqhkiG9w0BAQsFADA1MRMwEQYDVQQKDApURVNULklOVFJBMR4wHAYDVQQDDBVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMjQwNjA3MjExNDE2WhcNMjYwNjA4MjExNDE2WjAsMRMwEQYDVQQKDApURVNULklOVFJBMRUwEwYDVQQDDAxtLm11c3Rlcm1hbm4wggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDEKFTHGDx+MAZN0U1ACyWFkrmKzVnKDQ4ox+ArpQZMrHVndAiJDdHGD2LzdNz8dNkrfFBGyh7SDT+Df8JUvl5nAw7cQRDSulX+vPiKLWb4AVnO4MY2upsOH1E5f33jSnliVi/nYJ9/5MrTncr870mosUodUaZjkT7aa223m8GhV5h/dvJhJ4F/AUMHq33Q69AHnXamFhOoDHCbVB7/GfJ9f62ifvNbKC5Co/DwAcP37EThhCvHI/80Clg+zp4NVU9bvE7ZYOluNt9akQAcXoXr9rFDYMwHExp2wf0VGDNIhxz1rrJoQvvy4vd6WfghMk3n5yFLGZLPo26KlyduZcxLyKGed9nL07YM3KwgrIdnoG6zYcs9RU1euL5uzziquasbjjN+/OxqxiNRjH8dJsmjiMRnbz+hilMRefOTYuqIAK3CWZbzmbUTiISCmJZdFc9CYLlNZhFM+m5srmfBXTyTFvoxaqI0PNdOOzYQWG26K2QBG5F8oPmCfJs6HMn0yzQ14wSM1reIxxyMkeMyOl2KQVcCfOaRcaOvMkYL5+47Pv9a5qP6MlkB8mVex2bX09auFTG15xZoOddkQS8WkWDojAOuzKqxlRfgtDf/chef+e6incBBZ6j51qGfT1E7a4NhBLLLGkxkTCltFGN7rdv2oK7/pjpGvE0HSP5Fi0xzxQIDAQABo4IBKDCCASQwHwYDVR0jBBgwFoAUjX+ti+vjZ4nvryCZko1DWsIEJRcwPAYIKwYBBQUHAQEEMDAuMCwGCCsGAQUFBzABhiBodHRwOi8vaXBhLWNhLnRlc3QuaW50cmEvY2Evb2NzcDAOBgNVHQ8BAf8EBAMCBPAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMHUGA1UdHwRuMGwwaqAyoDCGLmh0dHA6Ly9pcGEtY2EudGVzdC5pbnRyYS9pcGEvY3JsL01hc3RlckNSTC5iaW6iNKQyMDAxDjAMBgNVBAoMBWlwYWNhMR4wHAYDVQQDDBVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHQYDVR0OBBYEFI6mVPFiDkjZawRsnU/kD1v3Mc31MA0GCSqGSIb3DQEBCwUAA4IBgQB+c7kEfCqbKLK7zHeXFKRkMvSJfnlLgzRkFA560NxUIf8a+Z/4zsFR/x5IkEQwbbqB43r0WZLBkVR0FVGQSWzsiOhAxx7nzzINDOXeQ+X8nLWfG2Uu37dW6sijcEs6K4WBpvpfqq2yZff5ibRJXjmRVMrIMEwjSw3fFIjlorersqDZ3f0BVTUmc43BoQw6XDoFQj0J2rHu5F3Fy5af/Loq8eqjqxZO/UqRgFNDLFJldiLULm2RkAJMJNvtaejoKQ7X8LQUIu94i/du0xWBfvbRRBOghXq/UEwH5XXlEZ5+Pg4eXcLKI2AjAvsOD3DVFpmzbQbMXnNQp2jDIrsZ7My5AN9LrHsmMnrb8dp+NLG1Dh/89aIexHb+ASJPeFckCRRveGIC0Lhr7eh4goMSfxk9P5gTOpupdPt7borC68AtXVnLSsVE67qE0NvDolHMDH7tZ0yk3n6DOjatwY+jFtEsparcPCxqD/LuFMUWKHTH/r9SwjXMNYoDm44tGJil/NM=
Account disabled: False
Password: True
Member of groups: generate_cert_user, nfs, ipausers
Member of Sudo rule: ALLOW_ALL
Member of HBAC rule: HBAC_RULE_ALLOW
Subordinate ids: 473b6ff4-03c0-4cf8-a481-e420e06cf96d
Indirect Member of Sudo rule: ALLOW_DNF
Kerberos keys available: True
Great. I have to admit, figuring this out, took way to long for me.
File server Configuration
Samba Server Installation and Configuration
Let’s go through the file server configuration. First, I want an SMB/CIFS share, so Windows clients can access it as well. Also, I want to make it as simple as possible, that’s why I am going to show the setup using “Cockpit” for the management.
Samba server configuration
I deployed another Rocky Linux 9 server and named it “TEST-SHARE“. The IP is “192.168.152.221“.
First, let’s join the server to the domain, for this we need the “ipa-client” package.
test-share :: ~ » sudo dnf install ipa-client -y
We also need the “ipa-client-samba” package. This makes configuring the samba server very easy, basically automatic.
test-share :: ~ » sudo dnf install ipa-client-samba -y
Next we execute the “ipa-client-install” command. Make sure the DNS server points to our “TEST-IPA01” server.
test-share :: ~ » sudo ipa-client-install --mkhomedir
This program will set up IPA client.
Version 4.11.0
Discovery was successful!
Do you want to configure chrony with NTP server or pool address? [no]: yes
Enter NTP source server addresses separated by comma, or press Enter to skip: 0.de.pool.ntp.org
Enter a NTP source pool address, or press Enter to skip:
Client hostname: test-share.test.intra
Realm: TEST.INTRA
DNS Domain: test.intra
IPA Server: test-ipa01.test.intra
BaseDN: dc=test,dc=intra
NTP server: 0.de.pool.ntp.org
Continue to configure the system with these values? [no]: yes
Synchronizing time
Configuration of chrony was changed by installer.
Attempting to sync time with chronyc.
Time synchronization was successful.
User authorized to enroll computers: admin
Password for admin@TEST.INTRA: PASSWORD
Successfully retrieved CA cert
Subject: CN=Certificate Authority,O=TEST.INTRA
Issuer: CN=Certificate Authority,O=TEST.INTRA
Valid From: 2024-05-31 10:05:18+00:00
Valid Until: 2044-05-31 10:05:18+00:00
Enrolled in IPA realm TEST.INTRA
Created /etc/ipa/default.conf
Configured /etc/sssd/sssd.conf
Systemwide CA database updated.
Hostname (test-share.test.intra) does not have A/AAAA record.
Missing reverse record(s) for address(es): 192.168.152.221.
Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub
Adding SSH public key from /etc/ssh/ssh_host_ed25519_key.pub
Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub
SSSD enabled
Configured /etc/openldap/ldap.conf
Client configuration complete.
The ipa-client-install command was successful
Ok, now install “cockpit“, the 45Drives cockpit plugin “cockpit-file-sharing” and the samba server.
test-share :: ~ » sudo dnf install cockpit samba -y test-share :: ~ » sudo dnf install https://github.com/45Drives/cockpit-file-sharing/releases/download/v3.3.7/cockpit-file-sharing-3.3.7-1.el8.noarch.rpm -y
Now the “ipa-client-samba” command. This will also generate the correct “smb.conf” and install the keytab file.
test-share :: ~ » sudo ipa-client-samba
Searching for IPA server...
IPA server: DNS discovery
Chosen IPA master: test-ipa01.test.intra
SMB principal to be created: cifs/test-share.test.intra@TEST.INTRA
NetBIOS name to be used: TEST-SHARE
Discovered domains to use:
Domain name: test.intra
NetBIOS name: TEST
SID: S-1-5-21-762749505-3141249797-982319214
ID range: 1298800000 - 1298999999
Continue to configure the system with these values? [no]: yes
Samba domain member is configured. Please check configuration at /etc/samba/smb.conf and start smb and winbind services
Next, edit the “smb.conf” file in the “/etc/samba” folder and add the line “include = registry” under the [global] section.
test-share :: ~ » sudo vim /etc/samba/smb.conf
[global]
# Limit number of forked processes to avoid SMBLoris attack
max smbd processes = 1000
# Use dedicated Samba keytab. The key there must be synchronized
# with Samba tdb databases or nothing will work
dedicated keytab file = FILE:/etc/samba/samba.keytab
kerberos method = dedicated keytab
# Set up logging per machine and Samba process
log file = /var/log/samba/log.%m
log level = 1
# We force 'member server' role to allow winbind automatically
# discover what is supported by the domain controller side
server role = member server
realm = TEST.INTRA
netbios name = TEST-SHARE
include = registry
workgroup = TEST
# Local writable range for IDs not coming from IPA or trusted domains
idmap config * : range = 0 - 0
idmap config * : backend = tdb
idmap config TEST : range = 1298800000 - 1298999999
idmap config TEST : backend = sss
Open the required ports.
test-share :: ~ » sudo firewall-cmd --add-service={cockpit,samba} --permanent
test-share :: ~ » sudo firewall-cmd --reload
Enable and start the cockpit, samba and winbind services.
test-share :: ~ » sudo systemctl enable {cockpit,smb,winbind} --now
Now, open a browser and navigate to the cockpit webui. The credentials are your system admin account you created during the Rocky Linux installation.
Once in, click on “Turn on administrative access” and type in your password.
Navigate to “File Sharing” and click on the + under “Shares“.
Type in the share name and the path, “SHARE” “/mnt/SHARE” respectively, in my case.
It will tell us that the path does not exist, click on “Create now“.
Click on “Edit Permission” right below the path. For this example, I will configure the share with full permissions.
Scroll down and click on “Confirm“.
Let’s test the samba server with the Fedora client.
Testing the File server
Login to your client and open the file explorer. Here we type in the full path into the location. Make sure you type in the full hostname with the domain.
Let’s create folder.
Great. Of course, we would like to automate mounting a network drive with the automount function. Unfortunately I did not get it working with SMB, but we still have NFS as an option. I will look into that in the next post. This should be enough for now.