FreeIPA

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:

kg-card-begin: html

kg-card-end: html

Functionally, the two are equivalent, and commands, LDIFs, files/dirs, etc will behave the same on both.

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.

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/

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):

You should be able to get to your mounted directories.

This is the default behavior for FreeIPA, and you have to configure BIND to respond to queries.

Also make sure your firewall isn't blocking port 53.

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.

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..

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:

Pretty easy!

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.

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.

The following services are important to proper operation and break the most often:

Useful logs can be found in the following locations:

Useful commands for troubleshooting:

It doesn't take a whole lot of setup, and once it's done you can use things like cert-manager for Kubernetes to automatically manage and renew certs that would be generated by your CA.

The general steps, as follows:

Then, you just have to make sure zone transfers are allowed. For each domain you have:

eg. for my system:

Now you can use your new TSIG key for automatic ACME cert generation and renewal on any zone you configured!

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:

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 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!

freeipa-sam is an extremely useful tool in creating and managing service accounts. Did you know FreeIPA supports special service accounts? It does!

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.

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:

kg-card-begin: html

kg-card-end: html

Optionally, you can include the following:

kg-card-begin: html

kg-card-end: html

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.

Log into the web UI and go to Authentication -> Certificates. Here, you can issue a new certificate with an appropriate CSR, 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.

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.

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.

Remember to add any new DNS zones in IPA Server -> Realm Domains if they aren't already there.

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.

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!

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 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 with the AtlasOS playbooks 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 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.

In the "Plugin Selection" section of the UI, we'll select the following:

And, in the "Plugin Order" section, we'll set KRB5 before LDAP before Local Machine in each section.

Now, go back to the "Plugin Selection" so we can configure each plugin.

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.

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:

Make sure your Search DN and Search password are set appropriately. I used freeipa-sam to create credentials for this.

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.

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.

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:

Then, hit "Save" and you're done!

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:

Apply, then save your changes to close the pGina configuration UI.

Optionally, for a cleaner login screen, you can perform the following steps:

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.

If you're planning on using RDP, make sure to skip RDP pre-authentication as pGina doesn't support it. To do this, add the following like to your RDP file or connection config on your RDP client:

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:

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:

Again, reboot the system and you should see these changes take effect.

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:

eg. for my system:

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:

eg. for my system:

Now, close the command prompt and perform the following steps:

and also:

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:

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.