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-casCA '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 listRequest 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 databasefedora :: ~ » mkdir -p ~/.pki/nssdb# Initialize the database and type in you password of choice.fedora :: ~ » certutil -N -d ~/.pki/nssdbEnter 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 CSRfedora :: ~ » 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 thecreation of your key. One of the easiest ways to create arandom seed is to use the timing of keystrokes on a keyboard.To begin, type keys on the keyboard until this progress meteris 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 userfedora :: ~ » 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 --mkhomedirThis program will set up IPA client.Version 4.11.0Discovery was successful!Do you want to configure chrony with NTP server or pool address? [no]: yesEnter NTP source server addresses separated by comma, or press Enter to skip: 0.de.pool.ntp.orgEnter a NTP source pool address, or press Enter to skip: Client hostname: test-share.test.intraRealm: TEST.INTRADNS Domain: test.intraIPA Server: test-ipa01.test.intraBaseDN: dc=test,dc=intraNTP server: 0.de.pool.ntp.orgContinue to configure the system with these values? [no]: yesSynchronizing timeConfiguration of chrony was changed by installer.Attempting to sync time with chronyc.Time synchronization was successful.User authorized to enroll computers: adminPassword for admin@TEST.INTRA: PASSWORDSuccessfully 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:00Enrolled in IPA realm TEST.INTRACreated /etc/ipa/default.confConfigured /etc/sssd/sssd.confSystemwide 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.pubAdding SSH public key from /etc/ssh/ssh_host_ed25519_key.pubAdding SSH public key from /etc/ssh/ssh_host_rsa_key.pubSSSD enabledConfigured /etc/openldap/ldap.confClient 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-sambaSearching for IPA server...IPA server: DNS discoveryChosen IPA master: test-ipa01.test.intraSMB principal to be created: cifs/test-share.test.intra@TEST.INTRANetBIOS name to be used: TEST-SHAREDiscovered domains to use: Domain name: test.intraNetBIOS name: TEST SID: S-1-5-21-762749505-3141249797-982319214 ID range: 1298800000 - 1298999999Continue to configure the system with these values? [no]: yesSamba 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} --permanenttest-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.
Kommentare