FreeIPA/IdM provide centralized identity, authentication, and access management for Linux environments. LDAP, Kerberos, DNS, centralized RBAC, etc in an extremely easy-to-install package. FreeIPA is Red Hat's open-source version of IdM. They're nearly identical in every way, but here's a quick list of differences between the two for posterity: | Feature/Aspect | FreeIPA | Red Hat IdM | |-----------------------------|------------------------------------|--------------------------------------| | **Base Software** | Open-source identity management project | Downstream enterprise version of FreeIPA | | **Support** | Community support (forums, mailing lists, etc.) | Full support from Red Hat (including SLAs, security patches, etc.) | | **Packaging** | Available on multiple distributions (Fedora, Rocky Linux, CentOS, etc.) | Packaged for RHEL with specific RHEL optimizations | | **Integration** | Integrates with various Linux services and apps | Deep integration with the broader Red Hat ecosystem (RHEL, Satellite, OpenShift, etc.) | | **Updates** | Faster updates and feature releases | Slower, more stable updates with a focus on enterprise needs | | **Stability** | Community-driven updates and patches, faster release cycles | Enterprise-grade stability with long-term support | | **UI** | Web UI and CLI | Web UI, CLI, and a Desktop Management Console | | **Lifecycle** | Community-defined lifecycle | Red Hat's defined lifecycle with extended support (7-10 years) | | **Features** | New features arrive sooner | Red Hat may delay some features until they are fully tested and stable | | **Security** | Community-released security patches | Red Hat-backed security patches and extended vulnerability fixes | | **Availability** | Can be installed on multiple platforms (Fedora, Rocky Linux, etc.) | Only available on Red Hat Enterprise Linux (RHEL) | Functionally, the two are equivalent, and commands, LDIFs, files/dirs, etc will behave the same on both. # Actually Useful Trivia * FreeIPA is based off of [389-DS](https://www.port389.org/), which used to be called Fedora Directory Server. This will be important to know when Googling around, since 389-DS is **not** the same as OpenLDAP. * FreeIPA uses [DNA](https://www.port389.org/docs/389ds/design/dna-plugin.html) for automatic ID allocation for users/groups. It can be `2000-19999`, `796600000-796799999`, or other ranges depending on your version, install parameters, etc. Basically, well outside the normal Linux range so it should be easy to spot LDAP users with an `id` or similar. * FreeIPA's CA/PKI is based off of [Dogtag](https://www.dogtagpki.org/), which is widely used even outside of IPA. Recommend getting familiar with [Tomcat](https://tomcat.apache.org/) troubleshooting. * FreeIPA uses [BIND](https://en.wikipedia.org/wiki/BIND) (BIND 9) for DNS, which, if configured through FreeIPA, stores DNS records in LDAP, which is automatically synced between masters. It's extremely important that you are at least familiar with the "big picture" overall design of BIND and where its config files are located if you're using DNS. # Installation Honestly, it's pretty easy- just `dnf install freeipa-server freeipa-server-dns freeipa-client` and then `ipa-server-install` If you prefer a guide, I followed this one the first time I ever did this. It's quite detailed. https://computingforgeeks.com/install-freeipa-server-on-rocky-almalinux/ ```embed title: "Install FreeIPA Server on Rocky Linux 9 / AlmaLinux 9 | ComputingForGeeks" image: "https://computingforgeeks.com/wp-content/uploads/2021/07/IPA-Server-Port-Requirements.png" description: "In this article we discuss in detail the installation and configuration of FreeIPA Server on Rocky Linux 9 / AlmaLinux 9 system. FreeIPA is popular and widely" url: "https://computingforgeeks.com/install-freeipa-server-on-rocky-almalinux/" ``` # Troubleshooting ## Allocation of a new value for range cn=posix ids,cn=distributed numeric assignment plugin,cn=plugins,cn=config failed! Unable to proceed. This *can* happen after a fresh install or upgrade. It's not totally uncommon. Check that your DNA range is actually set and set it if needed. Use the link below. https://rcritten.wordpress.com/2015/01/05/freeipa-and-no-dna-range/ ```embed title: "FreeIPA and no DNA range" image: "https://s0.wp.com/i/blank.jpg" description: "Ok, so let’s say you have an initial IPA master and one more more additional masters (aka replicas). You’ve always done all administration on the first one and it is now temporarily or …" url: "https://rcritten.wordpress.com/2015/01/05/freeipa-and-no-dna-range/" ``` ## NFS mounts configured, but not appearing on clients (autofs.service not running) I've encountered this a few times. Sometimes the autofs service isn't fully configured or it fails and doesn't restart. Try the following steps: Run the following on each of the affected client(s): ```bash ipa-client-automount --unattended sed -i '/^\[Service\]/a Restart=on-failure' /usr/lib/systemd/system/autofs.service sed -i '/^\[Service\]/a RestartSec=5' /usr/lib/systemd/system/autofs.service systemctl daemon-reload systemctl restart autofs ``` You should be able to get to your mounted directories. ## DNS not responding to external queries This is the default behavior for FreeIPA, and you have to configure BIND to respond to queries. 1. Edit `/etc/named/ipa-ext.conf` and add the following: ``` acl "trusted_network" { localnets; localhost; 10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16; } ``` 2. Edit `/etc/named/ipa-options-ext.conf` and change `dnssec-validation yes;` to `dnssec-validation no;` or else things like `nslookup google.com` will return a `SRVFAIL`. If you don't care about external domains, then keep DNSSEC enabled. 3. Edit `/etc/named/ipa-options-ext.conf` and add the following: ``` allow-recursion { trusted_network; }; allow-query-cache { trusted_network; }; ``` 4. Restart the `named` service: `systemctl restart named` Also make sure your firewall isn't blocking port 53. ## OH NO MY REPLICA/DIRSRV WON'T START WHAT HAVE I DONE This happens (a lot, actually) - it's probably fine. Normally it happens after an upgrade but sometimes it just happens out of nowhere, for no reason. Automatic LDIF backups are created by FreeIPA and stored in `/etc/dirsrv/slapd-<DOMAIN>-<NAME>/` as `.ldif.bak` files. Most often what's happened is that your main `dse.ldif` file has been zeroed out (for whatever reason) and simply overwriting that file with its backup copy and restarting your `dirsrv@<DOMAIN>-<NAME>` service will do the trick. > [!warning] > Be VERY careful about overwriting files in this directory. For example, that backup LDIF file is your **one and only** backup copy for the current master. Worst-case scenario, you can often restore from a recent backup of your VM and re-initialize from another current/working replica. IPA is fairly tolerant of mis-matched internal stuff even if it's pretty far out. Speaking of which, sometimes restoring from the backup copy partially works but things are out-of-sync with the other systems. In that case.. ## Masters are out of sync / replica has been offline for a long time If your masters are out of sync (you see discrepancies in return values when running commands and/or in the web UI) and/or one of your replicas has been offline for a while (a week or more, or thereabouts) it's recommended to re-initialize it from a working replica. Simply run the following: ```bash kinit admin ipa-replica-manage re-initialize --from <working replica fqdn> ``` Pretty easy! ## DKIM keys not working / can't see DNS records longer than 255 characters Yep, this is a BIND limitation. Thankfully this is pretty easy to work around because BIND supports multi-line strings which work perfectly fine instead. In order to take your very long string (eg. DKIM record) and turn it into a multi-line string, simply add spaces where you want new lines to be. Yep, that's it! As long as each line is < 255 characters BIND will take it. For example, you have the DNS record (a string) `abcdefgh..xyz` - you can turn it into a multiline string by simply doing `abc def ghi...xyz`. In this example, the first line will be `abc`, the second line will be `def`, and so on. When looking at this record externally (through tools like `dig`) you will find that there's no spaces and it's all put together on a single line. When BIND responds to a DNS query with a multi-line string, it puts it all back together into one line for the client. So, really, multi-line strings are a construct of BIND and not the DNS system. A solution to a limitation by the software. ## \[SSL: SSLV3_ALERT_HANDSHAKE_FAILURE\] ssl/tls alert handshake failure This is going to sound really obvious, but: have you tried rebooting the master/replica that the system you're working on is communicating with? Sometimes funny things happen that reboots can solve. ## General troubleshooting tips The following services are important to proper operation and break the most often: * dirsrv@<DOMAIN\>-<NAME\> * you'll need to use your own domain name. Tab-complete should help you out. * named / named-pkcs11 * BIND server. Uses different service names/files depending on your PKCS11 setup. * autofs * Used for auto-mounting `auto.direct` and `auto.home` files configured through FreeIPA * httpd * Web server for FreeIPA web UI. Doesn't usually break, but I've had to follow its trail once or twice. Useful logs can be found in the following locations: * /var/log/ipa/ * FreeIPA logs. Unless your upgrade or install went bad (which it sometimes does) they're not super useful, but if you run into that specific situation then they become invaluable * /var/log/httpd/ * More useful than you'd think. If your issue also affects the web UI, you can trigger then and then check the logs for more detail * /var/log/pki/ & /var/log/tomcat/ * A *lot* of data to sift through, but it's very often useful when troubleshooting PKI/CA things * /var/log/sssd/ * I've only had luck searching through these when [enabling debug in the sssd service](https://sssd.io/troubleshooting/basics.html#sssd-debug-logs), but when they're useful they're very useful Useful commands for troubleshooting: * ipa-replica-manage * Mostly useful for re-initializing a replica, but it's saved me many times * ipa-server-upgrade * Sometimes your update gets borked. You can re-try it after checking the logs * ipa-getcert * Check on any certs you generated "manually" - sometimes it'll let you know if/how it failed (if it did) * ipactl * Useful for restarting *all* IPA master services gracefully (and checking their status) - sometimes all you need to fix something is a quick service restart # Other Useful Tips ## Configuring ACME automatic certificate renewal It doesn't take a whole lot of setup, and once it's done you can use things like [cert-manager](https://cert-manager.io/) for Kubernetes to automatically manage and renew certs that would be generated by your CA. The general steps, as follows: 1. On **one** of your IPA master servers (this only needs to be done once, ever, per individual cluster) ``` kinit admin tsig-keygen -a hmac-sha512 acme-update >> /etc/named/ipa-ext.conf ipa dnszone-mod example.com --dynamic-update=True --update-policy='grant acme-update wildcard * ANY;' ipa dnszone-mod my.domain.tld --dynamic-update=True --update-policy='grant acme-update wildcard * ANY;' ipa dnszone-mod test.me --dynamic-update=True --update-policy='grant acme-update wildcard * ANY;' # Basically, any DNS zone (internal domain) you wish to enable ACME for, run the dnszone-mod command. ``` 2. Get your zone key so you can add it to the other masters (if needed): ```bash cat /etc/named/ipa-ext.conf ``` 3. On each of the **other** IPA masters (again, only needed once ever- just for each master in the domain) ```bash kinit admin ipa-acme-manage enable # Edit /etc/named/ipa-ext.conf and add the TSIG key lines (the acem-update block) generated on the first master systemctl restart named ``` Then, you just have to make sure zone transfers are allowed. For each domain you have: ```bash kinit admin ipa dnszone-mod <your>.<domain>. --dynamic-update=1 ldapmodify -Y GSSAPI << EOF dn: idnsname=<your>.<domain>.,cn=dns,dc=<domain>,dc=<name> changetype: modify replace: idnsAllowTransfer idnsAllowTransfer: key keyname; - EOF ``` eg. for my system: ```bash kinit admin ipa dnszone-mod yggdrasil.home. --dynamic-update=1 ldapmodify -Y GSSAPI << EOF dn: idnsname=yggdrasil.home.,cn=dns,dc=yggdrasil,dc=home changetype: modify replace: idnsAllowTransfer idnsAllowTransfer: key acme-update; - EOF ``` Now you can use your new TSIG key for automatic ACME cert generation and renewal on any zone you configured! > [!warning] > Keep this TSIG key secret. Anyone with the key can easily generate valid certs for any hostname on your domain. ## Generate and auto-renew a cert with ipa-getcert It's fairly easy to do, and the IPA client will take care of auto-renewal for you. As an example, I'll use the cockpit web UI. Simply run the following commands: ```bash kinit admin semanage fcontext -a -t cert_t "/etc/cockpit/ws-certs.d(/.*)?" restorecon -FvR /etc/cockpit/ws-certs.d rm -f /etc/cockpit/ws-certs.d/$(hostname -f).cert rm -f /etc/cockpit/ws-certs.d/$(hostname -f).key ipa-getcert request -f /etc/cockpit/ws-certs.d/$(hostname -f).cert -k /etc/cockpit/ws-certs.d/$(hostname -f).key -D $(hostname -f) -K host/$(hostname -f) -m 0640 -o root:cockpit-ws -O root:root -M 0644 ``` What we're doing, here, is getting a kerberos ticket for our admin user so we can create certs, setting up SELinux to allow cockpit (and the IPA client) to access these certs, removing the self-signed certs that cockpit generated, and finally using `ipa-getcert` to request a new certificate for us. `$(hostname -f)` is just a trick to get the FQDN of the current host and name our certs appropriately (and get the right ticket for the host). Pretty easy! You can do the same sort of thing for any application. The `ipa-getcert` command will generate a certificate file and a private key for you and put them in any directory you want with any owner and permissions you want. ## Replication Replication is extremely easy through the web UI. Log in as an admin, go to IPA Server -> Topology -> Topology Graph and use the interactive graph to add and remove CA and domain (LDAP) replication agreements between systems. It's practically drag-and-drop!  ## Service Accounts [freeipa-sam](https://github.com/noahbliss/freeipa-sam) is an extremely useful tool in creating and managing service accounts. Did you know FreeIPA supports special service accounts? It does!  ## Automounts Managing automounts (home dirs, public mounts, etc) is also extremely easy in the web UI. Log in as an admin, head to Network Services -> Automount and `Add` maps named `auto.direct`, `auto.home`, and `auto.master` to get started. In your new `auto.master` mount, `Add` a new key named `/-` and use `auto.direct` as the mount information. Similarly, `Add` a key named `/mnt/home` and use `auto.home` as the mount information.   > [!warning] Home directory locations > Note that many people use `/home` instead of something like `/mnt/home` for their automount home directory. Although this often works, it is inadvisable as it can cause problems with programs, provisioning systems, etc that expect `/home` to be a local filesystem, and confuses local accounts with non-local ones which leads to more [cognitive load](https://en.wikipedia.org/wiki/Cognitive_load) when troubleshooting. When creating new mounts in your `auto.direct` entry, your key should be something like `/mnt/public` and mount information should be a string similar to an fstab entry or manual mount with all of the accompanying flags. After plenty of trial-and-error on my own systems, I've discovered the following flags work quite well on my home system where there's a LACP (dual-)10-Gbit fiber pipe between the NFS storage system and the VMs mounting the locations: | Flag | Description | Value | Reasoning | | -------- | -------------------------------- | -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | fstype | File system type | nfs4 | Uses NFSv4 (4.2) for better security and performance. STIG item. | | sec | NFS security flavor | sys:krb5:krb5i:krb5p | Combines basic UID/GID auth with Kerberos options for security. | | defaults | Default mount options | | Standard mount options, most (but not all) overridden in this table for security or performance. | | nodev | Disallow device files | | Prevents device files. STIG item. | | noexec | Do not allow executable files | | Prevents running binaries from this filesystem. STIG item. | | nosuid | Ignore setuid and setgid | | Prevents privilege escalation. STIG item. | | auto | Mount automatically at boot | | Automatically mounts the filesystem on boot. | | nofail | Do not fail boot if mount fails | | Prevents boot failure if NFS share is unavailable. | | noatime | Do not update access times | | Disables access time updates to boost performance. Big performance increase, but [file atime](https://www.geeksforgeeks.org/file-timestamps-mtime-ctime-and-atime-in-linux/) is left unset. Usually that's a perfectly fine tradeoff. | | bg | Retry mounting in the background | | Allows retrying mount in the background if it fails initially. | | hard | Mounts with hard option | | Retries indefinitely on failure. | Optionally, you can include the following: | Flag | Description | Value | Reasoning | | ------ | ------------------------------------ | ------- | ----------------------------------------------------------------------------------------------- | | nolock | Disable NFS file locking | | Bypasses NFS file locking; useful when locking isn't needed. | | intr | Allow NFS requests to be interrupted | | Permits NFS operations to be interrupted if the server is unresponsive. | | async | Enable asynchronous writes | | Boosts performance by writing data asynchronously; may risk data loss on crashes, but unlikely. | | rsize | Maximum read size | 1048576 | 1MB block size. Big pipe means more data throughput available. | | wsize | Maximum write size | 1048576 | 1MB block size. Big pipe means more data throughput available. | Your `auto.direct` keys and mount information would look something like this:  The `auto.home` key and mount information is a bit special, in that it uses some special characters. see below:  The `key` is listed as `*` for all users, and the NFS mount location has an `&` sybol in it, which is where the user's UID is placed when mounting. As an example- in this setup, home directories are mounted on each system at `/mnt/home/<uid>` and the NFS export location being mounted is `/mnt/misc/home/<uid>` on the remote storage server. ## Certificates Log into the web UI and go to Authentication -> Certificates. Here, you can issue a new certificate with an appropriate [CSR](https://en.wikipedia.org/wiki/Certificate_signing_request), download a certificate (downloading your root CA cert with serial number `1` is advised because it's quite useful to have on hand), and revoke or expire certs. ## DNS There's a few configuration options/sections here, so w'll go through them in a logical order. Log into the FreeIPA web UI and go to Network Services -> DNS -> DNS Global Configuration. The forward policy for an internet-connected IPA should probably be "Forward first" and your global forwarders would be whatever DNS server (IP addresses) you want your upstream DNS to be. > [!notice] > Don't forget to save! Now, head to Network Services -> DNS -> DNS Zones. Here's where you'll find your internal domains- both forward and reverse. Generally, it's all pretty self-explanatory. Take a poke around. It's really difficult to screw up your DNS here, as you'll get plenty of warnings and errors if you try. Just remember that zones always end in a dot (eg. `my.domain.tld` would be `my.domain.tld.`) - same with CNAME records and a few others like some MX records. > [!warning] Split-horizon DNS > [Split-horizon DNS](https://en.wikipedia.org/wiki/Split-horizon_DNS) is [officially unsupported](https://www.freeipa.org/page/DNS#dns-views-split-horizon-dns) and is a massive pain to maintain. It's recommended to have an entirely internal domain instead. Remember to add any new DNS zones in IPA Server -> Realm Domains if they aren't already there. # Windows / "We have AD at home" Officially, FreeIPA/IdM doesn't support Windows systems. They assume you'll be using a real Active Directory (AD) setup for that and [hooking the two systems together](https://www.freeipa.org/page/Active_Directory_trust_setup). That said, you can definitely get Windows login and even Kerberos to work with FreeIPA. It just *feels* like it's held together with bubble gum and duct tape- and, in some ways, it is. That said, it works pretty well and you can do some fancy stuff if you configure it correctly. And it's free! ## pGina (fork) So, yes - you can, in fact, add a Windows system to FreeIPA. While FreeIPA isn't a replacement for AD, with the help of [pGina fork](https://mutonufoai.github.io/pgina/) you can get pretty close with emulating at least its main functionality as a Windows directory. You'll want to use the newer forked version because the original doesn't have the configuration options we need for the specific 389-DS settings that FreeIPA uses.  pGina isn't well-documented, so these settings are almost entirely trial-and-error. I've managed to get most everything working the way I think they should, but Kerberos is still a little off and I still haven't gotten SMB shares working with TrueNAS Scale when they require Kerberos tickets. Linux clients work fine with NFS, but Windows has problems with SMB. Go figure. The way I usually do things is with two groups: `windows-admins` for people that belong in the `Administrators` group, and `windows-users` for those that belong in the `Users` group. You can map any LDAP group to any local group(s) with pGina, though. First, create your Windows 10 system however you feel you should - just makes ure you're using a version that includes GPO (eg. Pro). Most settings changes and hardening won't affect pGina. For this example, I used [Ameliorated](https://ameliorated.io/) with the [AtlasOS playbooks](https://atlasos.net/) after a quick base install (and update) on a VM. It just makes Windows a little lighter and nicer to use. No ads, less telemetry, some optimizations, etc. Download and install [pGina fork](https://mutonufoai.github.io/pgina/download.html) and run the configuration UI, which will be in your start menu. The UI should look something like this:  Here, the only thing I suggest changing is the NTP servers to use your local systems or your preference of NTP servers. You can change the MOTD and icon here for a white-label treatment if you'd like. > [!note] If you decide to change the icon, make sure it's a BMP (bitmap) or PNG in RGB format or it [won't show up on the login screen](https://github.com/pgina/pgina/issues/279#issuecomment-816886138). In the "Plugin Selection" section of the UI, we'll select the following: - KRB5 - Authentication - LDAP - Authentication - Authorization - Gateway - Local Machine - Authentication - Gateway  And, in the "Plugin Order" section, we'll set KRB5 before LDAP before Local Machine in each section.  > [!warning] > LDAP, at least, needs to be ordered above Local Machine [so it can set groups correctly](http://pgina.org/docs/v3.0/local_machine.html). Now, go back to the "Plugin Selection" so we can configure each plugin. ### **KRB5** Double-click `KRB5` (or select it and click `Configure...` at the bottom) to configure it. There's only one option, so fill out your Kerberos Realm here. Again, Kerberos doesn't seem to work, but it doesn't hurt anything to have it enabled. Or not. Up to you.  Just remember to hit "Save" and not just close the dialog box after. ### **LDAP** Same with LDAP. Double-click to configure. This is one of the important ones, since it'll be doing most of the heavy-lifting. Most of this is self-explanatory, but here's my settings anyway:  > [!note] > For whatever reason, TLS with a valid root certificate doesn't seem to work here even though every other system I've used seems fine with it. Make sure your `Search DN` and `Search password` are set appropriately. I used [`freeipa-sam`](#Service%20Accounts) to create credentials for this. #### **Authentication** Similarly, your bind section (under authentication) should be set correctly. For FreeIPA (again, based on 389-DS) your user accounts are loated under `cn=users,cn=accounts,dc=<your>,dc=<domain>` and groups are under `cn=groups,cn=accounts,dc=<your>,dc=<domain>`. For the attribute converter section, set whatever feels appropriate. I set `email` to `Email` and `cn` to `Fullname`.  #### **Authorization** The authorization section controls who is allowed to log in, and that's the only thing it does. Keep that in mind, here. Under the authorization section, set your default to deny and add any groups that you'd like to be able to log in to the "allow" list. For FreeIPA, your "path" will be `cn=users,cn=accounts,dc=<your>,dc=<domain>` and your filter will be something like `(memberOf=cn=windows-users,cn=groups,cn=accounts,dc=<your>,dc=<domain>)`. Make sure the search is set to "Subtree" (the default is "Base") and you should be good to go. There's a lot of options for configuration, here, so feel free to play around with it. Here's an example:  The checkboxes here give you some helpful info about what they do when you hover over them. My selections here aren't the most secure, so decide what you want within your own org. Try checking "Deny when LDAP authentication fails" and unchecking "Allow when server is unreachable" for more secure settings. #### **Gateway** Next, the gateway section controls what local groups the LDAP users are added to. That's it- the only thing it does. The configuration here is similar to the authorization section. Here's an example of adding the `windows-users` LDAP group to the local `Remote Desktop Users` group:  > [!note] Remember the "Subtree" selection from the dropdown. Then, hit "Save" and you're done! > [!note] > You **can** also enable the "Change Password" section, here, but I've never actually tested this functionality. > > The settings I've used previously are: > userPassword -> SSHA1 (Salted SHA1) > shadowLastChange -> Timestamp days since '70 > > Remember that, if you want to enable this feature, you'll need to check the appropriate box in the "Plugin Selection" of the main UI. ### **Local Machine** This one's pretty easy. Just remember to check the "Authorize all authenticated users" and "Failure to create or join local groups should prevent login" checkboxes and you're good.  You're welcome to play around with these settings, as well, but these are what worked for my setups previously. I've has success with enabling the "Mirror groups from local user", "Remove account and profile after logout", and "Scramble password after logout" options previously. It all depends on how you want to configure things. Again, hit "Save", and you're good to go. ### **pgSMB2** This is where you'd put down your SMB home directory information. If you can get it working, then great, but I haven't figured it out with TrueNAS Scale myself yet. If you're curious, here are my settings:  ### **Finishing Touches** Apply, then save your changes to close the pGina configuration UI. Optionally, for a cleaner login screen, you can perform the following steps: 1. Click **Start**, and then click **Run**. 2. In the **Open** box, type _gpedit.msc_, and then click **OK**. 3. Under **Computer Configuration**, expand **Windows Settings**, expand **Security Settings**, expand **Local Policies**, and then click **Security Options**. 4. In the right pane, double click the setting **Interactive logon: Don't display last signed-in** and enable the option And you're set! Reboot your system and you should be able to log in as any of your LDAP users in the `windows-users` group - or whatever you had set up. ## RDP & pGina If you're planning on using RDP, make sure to [skip RDP pre-authentication as pGina doesn't support it](https://mutonufoai.github.io/pgina/documentation/rdp.html). To do this, add the following like to your RDP file or connection config on your RDP client: ``` enablecredsspsupport:i:0 ``` > [!note] > This setting is only for Windows RDP clients. Linux RDP clients will work automatically and don't need this. Additionally, for RDP servers running on Windows 10, run these registry edits on the RDP server machine (once, as administrator) to disable preauthentication for any users logging into it: ```cmd reg add “HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp” /v SecurityLayer /t REG_DWORD /d 0 /f reg add “HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp” /v UserAuthentication /t REG_DWORD /d 0 /f ``` You should be greeted by the regular Windows login screen when running your RDP clients to it instead of being asked for credentials right away. This lets pGina take over the login from there. The downside to this setup is that even unauthenticated users can shutdown or reboot your machine from the login screen, so let's fix that: 1. Click **Start**, and then click **Run**. 2. In the **Open** box, type _gpedit.msc_, and then click **OK**. 3. Under **Computer Configuration**, expand **Windows Settings**, expand **Security Settings**, expand **Local Policies**, and then click **Security Options**. 4. In the right pane, double click the setting **Shutdown: Allow system to be shut down without having to log on** and disable the option Again, reboot the system and you should see these changes take effect. ## Kerberos I'll say again that I never managed to get Kerberos fully-functional, but I think this gude gets you fairly close: logins work but they don't add the account to local groups automatically (you need pGina for that, or you need to do it manually) and SMB to TrueNAS Scale (when requiring a Kerberos ticket, eg. SMB home dirs) still isn't functional for whatever reason. If you're interested, though.. First, create a host for your Windows box in the IPA UI.  Then, SSH into your IPA master and run the following: ```bash kinit admin ipa-getkeytab -s <your>.<kdc>.<fqdn> -p host/<desktop>.<fqdn>@<YOUR>.<DOMAIN> -e aes128-cts-hmac-sha1-96,aes256-cts-hmac-sha1-96,aes128-cts-hmac-sha256-128,aes256-cts-hmac-sha384-192 -k krb5.keytab.<desktop>.<fqdn> -P ``` eg. for my system: ```bash kinit admin ipa-getkeytab -s heimdall.yggdrasil.home -p host/[email protected] -e aes128-cts-hmac-sha1-96,aes256-cts-hmac-sha1-96,aes128-cts-hmac-sha256-128,aes256-cts-hmac-sha384-192 -k krb5.keytab.desktop-4p5252j.yggdrasil.home -P ``` Set some password that you'll remember later when you log into the Windows machine to set it up. No need to copy the generated keytab file anywhere, though. Now, log into the Windows 10 system and open up a command prompt (or PS window) as an administrator: ```cmd ksetup /setdomain <YOUR>.<DOMAIN> ksetup /addkdc <YOUR>.<DOMAIN> <your>.<kdc>.<fqdn> ksetup /addkpasswd <YOUR>.<DOMAIN> <your>.<kdc>.<fqdn> ksetup /setcomputerpassword <password you used for the keytab> ksetup /mapuser * * ``` eg. for my system: ```cmd ksetup /setdomain YGGDRASIL.HOME ksetup /addkdc YGGDRASIL.HOME alfodr.yggdrasil.home ksetup /addkpasswd YGGDRASIL.HOME alfodr.yggdrasil.home ksetup /setcomputerpassword no-this-isnt-the-actual-password-i-used ksetup /mapuser * * ``` > [!warning] > If you don't do this in an administrator cmd/PS window you're going to get some errors like "Failed to set dns domain info: 0xc0000022" which is cryptic and hard to Google Now, close the command prompt and perform the following steps: 1. Click **Start**, and then click **Run**. 2. In the **Open** box, type _gpedit.msc_, and then click **OK**. 3. Under **Computer Configuration**, expand **Administrative Settings**, expand **System**, and then click **Logon**. 4. In the right pane, double click the setting **Assign a default domain for logon** and choose **Enabled**. 5. Under **Options**, set the default logon domain to `<YOUR>.<DOMAIN>` (eg. `YGGDRASIL.HOME`) and also: 1. Click **Start**, and then click **Run**. 2. In the **Open** box, type _gpedit.msc_, and then click **OK**. 3. Under **Computer Configuration**, expand **Windows Settings**, expand **Security Settings**, expand **Local Policies**, and then click **Security Options**. 4. In the right pane, double click the setting **Network security: Configure encryption types allowed for Kerberos** and select **AES128_HMAC_SHA1** and **AES256_HMAC_SHA1** Then reboot, and you should be able to log in as any FreeIPA user (since there's no real controls on user mapping or groups with this method). Users can log in, but they won't be admins or automatically assigned to any groups. You'll need to do that manually on the machine itself. On the upside, maybe this will somehow work with SMB shares with some extra fiddling? It's not something I tested thoroughly, but I couldn't immediately get a ticket that worked with my own home directory on TrueNAS with this method. Additionally, the user that's created with this method is a **different user** than what pGina will create, so using both login methods at the same time may not be the wisest choice unless you and everyone logging into that machine know what's going on: - pGina will create a user called `<uid>` - eg. `amason` - Kerberos will create a user called `<uid>.<DOMAIN>` - eg. `amason.YGGDRASIL` - No, not `amason.YGGDRASIL.HOME` - you'd think it would be this, but it's not If you can find a way to reconcile the two users, maybe that works for you. I don't know if I see a purpose to that, however, unless somehow you can get Kerberos tickets working with pGina by doing this.