How To Login To Windows With A FreeIPA Account

In most cases Windows desktops or servers will typically be joined to a Windows domain controller running Microsoft’s Active Directory, however this is not the only option.

It is possible to join Windows to a FreeIPA realm and then log into the Windows computer with an account from FreeIPA as it makes use of Kerberos for single sign on (SSO). FreeIPA is an open-source project sponsored by Red Hat, which attempts to provide similar functionality to Active Directory for Linux and Unix systems.

This may be a good option if you already run a large Linux or Unix environment, but need to have a small amount of Windows servers capable of using the same centrally managed user accounts.

We are assuming that you already have FreeIPA set up and ready to use. We will only be detailing how to configure the Windows operating system to join an existing Kerberos realm. In this example FreeIPA is setup on the domain.

FreeIPA will only be providing the authentication service for our Windows server here with Kerberos. FreeIPA is not able to maintain an account database for Windows computers in the same manner that Active Directory does, so we therefore still need to create local Windows accounts for each user on the Windows computer, although they will have no passwords set in Windows.

Configure FreeIPA

Log into FreeIPA and under Identity, select Hosts. Click the +Add button to create a new host.

FreeIPA Hosts

In this instance the hostname of our Windows computer is ‘windows’, we also specify the DNS domain afterwards. As FreeIPA is managing DNS for me, this is prefilled. if you are not using FreeIPA to manage DNS then you may need to manually enter the domain name.

FreeIPA add new host principal

Next on the FreeIPA server we need to run the ipa-getkeytab command to generate a keytab file for the Windows computer. In order to perform administrative tasks on the IPA server we must first authenticate, we do this with the kinit command and specify the IPA admin user, as shown below.

[[email protected] ~]# kinit admin
Password for [email protected]:

You can run the ‘klist’ command afterwards to check that you have a valid ticket.

Now we can run the ipa-getkeytab command as shown below. The -s option is used to specify the IPA server, which in this example is – the server we are running this command on. The -p option is used to specify the principal-name of the host, which in this case is ‘host/’ followed by the fully qualified domain name (FQDN) of the Windows computer that we added through the FreeIPA web interface previously. The -e option is used to specify the encryption type used to generate the keys, here we’re using arcfour-hmac. The -k option is used to specify the keytab file that we want to create, in this case the file will be made in the current working directory. Finally the -P option is used to specify the password for the key, you will need to remember this as we will enter it on the Windows computer later.

[[email protected] ~]# ipa-getkeytab -s -p host/ -e arcfour-hmac -k -P
New Principal Password:
Verify Principal Password:
Keytab successfully retrieved and stored in:

If you get the error message “Kerberos User Principal not found. Do you have a valid Credential Cache?” be sure that you successfully ran the ‘kinit’ command.

Configure Windows

The Windows computer will need to be able to resolve the name of the IPA server with DNS, so ensure that Windows has appropriate DNS configuration for this. As my FreeIPA server is managing DNS, I have simply set the Windows machine to use FreeIPA for DNS.

On the Windows computer, open command prompt as administrator and run the below commands. Note that the Realm must be specified in capital letters, as this is the custom for realm names in Linux/Unix. In my example the realm is EXAMPLE.COM and the key distribution center (KDC) is the FreeIPA server, which for me is

ksetup /setdomain [REALM]
ksetup /addkdc [REALM] [KDC]
ksetup /addkpasswd [REALM] [KDC]
ksetup /setcomputerpassword [PASSWORD]
ksetup /mapuser * *

Note that the Password above is the one that we set in the FreeIPA web interface for the host principal earlier. The /mapuser command will map all accounts within the EXAMPLE.COM Kerberos realm to any existing account of the same name on this Windows computer.

These changes will require a reboot, as you will be advised, hold off on this for now.

Windows ksetup join FreeIPA kerberos realm

Next press the Windows key + R to open the Run window, type gpedit.msc and select OK. This will open up the Local Group Policy Editor for the machine.

Windows run gpedit.msc

From the Computer Configuration options, select Windows Settings > Security Settings > Local Policies > Security Options > Network Security: Configure encryption types allowed for Kerberos.

Windows Local Group Policy Editor

In this instance we will select everything except for the first two DES options. The official FreeIPA documentation claims to only require RC4_HMAC_MD5 selected, but I received an error regarding supported encryption types with only this enabled. Select Apply or OK to save the changes.

Windows Kerberos Encryption Types

Once this is complete, reboot the Windows machine to apply the ksetup changes from earlier.

When the Windows machine is back up, create a local user account that maps to a user that exists in FreeIPA. In my example I have a user called ‘test’ that was created in the FreeIPA web interface, so I will create a user with the username of test in Windows. You do NOT need to set a password on this user account in Windows, as authentication will be handled by FreeIPA.

You can create a local user account by pressing the Windows key + R to open the Run window, and enter ‘mmc’ then select OK.

Windows Run MMC

Once the MMC window opens, select File > Add/Remove Snap-in…

Windows MMC Add/Remove Snap-in

From the next window, select Local Users and Groups, then click the “Add >” button, followed by Finish, then OK. From here you can create your local user accounts in Windows. Remember, we do NOT want to add any passwords to these. The username also needs to match the username that exists in FreeIPA.

Adding local users and groups mmc snap-in

Configure Remote Desktop

By default a fresh user account will not be able to connect via remote desktop unless it has been given permission to do so. While you still have the Local Users and Groups console open through MMC, go to Groups and select the Remote Desktop Users group and add your user account that was just created to this group.

Windows add user to remote desktop users group

Before performing the first login, you’ll want to temporarily disable remote desktops Network Level Authentication (NLA) on the Windows server otherwise you will receive an error about NLA failing to contact a Windows domain controller on first login. This only seems to happen when logging into an account for the first time with an expired password that requires changing. Once the password has been set and is no longer in an expired state, logging in with NLA will work fine.

That’s it, you should now be able to log into Windows with this account. You will need to specify [email protected] to login, so if you’ve been following this example I’ll be using [email protected] Don’t forget that the realm name must be in caps. Also by default when you create a new user account in FreeIPA the password will be in the expired state and will need to be changed on first login, as shown below.

Windows Remote Desktop Change Password

By doing this we no longer need to access this singular Windows server with local user accounts, we can now access it with our accounts in the FreeIPA Kerberos realm. Granted we still have to create a local account on the Windows computer initially, however the authentication is handled centrally on the FreeIPA server using Kerberos, no passwords are stored on the Windows machine which can make credential management easier.


I had all sorts of different problems along the way while originally setting this up, so I have documented them all here along with associated solutions. In most cases the steps above should “just work”. Hopefully these solutions are useful, as most of these errors came from the Windows server, and of course when you perform a Google search for those errors you get solutions for fixing the problems in Windows, rather than answers relating to FreeIPA.

  • There are currently no logon servers available to service the logon request.
    For me this was due to a lack of DNS on the Windows server. The Windows server was not pointing to a DNS server that had the required records for FreeIPA. As I have set my FreeIPA server itself to provide DNS, the fix here was to simply use the FreeIPA server for DNS.

    If your instance of FreeIPA is not configured to manage DNS, it can be added on by installing the ipa-server-dns package. To set it up, run the ‘ipa-dns-install’ command and follow the prompts. As I was setting this up to manage DNS for the domain, I received the below error message.

    2016-12-29T04:27:00Z DEBUG The ipa-dns-install command failed, exception: ValueError: DNS zone already exists in DNS and is handled by server(s):,

    This was simply because DNS for the domain exists out there on the Internet already. I temporarily changed the /etc/resolv.conf file to point to the FreeIPA server itself rather than an external DNS server and then ran ipa-dns-install again. During this process you can specify an external forwarder to use. If you already have some other DNS server that handles the records for your Kerberos realm, you’ll likely want to use this instead of configuring FreeIPA to manage DNS.

  • The encryption type requested is not supported by the KDC.
    When I attempted to Windows connect via remote desktop, I was asked to change my expired password. This is expected, as it is required for all new accounts created in FreeIPA by default. After entering my new password, I received the error “The encryption type requested is not supported by the KDC.” This was because originally in Windows I did not enable enough encryption types, with all selected except for the first two DES options as mentioned previously I was able to log in without further problems. Scroll up a little bit and take a loon at the section where we configured this.
  • preauth (encrypted_timestamp) verify failure: Decrypt integrity check failed.
    When trying to log in through remote desktop, I received some generic message about the login failing. Only when I checked the /var/log/krb5kdc.log file on the FreeIPA server did this make sense.
  • Dec 28 20:44:14 krb5kdc[44951](info): AS_REQ (7 etypes {18 17 23 3 1 24 -135}) NEEDED_PREAUTH: [email protected] for kadmin/[email protected], Additional pre-authentication required
    Dec 28 20:44:14 krb5kdc[44950](info): preauth (encrypted_timestamp) verify failure: Decrypt integrity check failed
    Dec 28 20:44:14 krb5kdc[44950](info): AS_REQ (7 etypes {18 17 23 3 1 24 -135}) PREAUTH_FAILED: [email protected] for kadmin/[email protected], Decrypt integrity check failed

    If you know anything about Kerberos, you’ll know that it’s important for all servers to maintain the same time. In this case, my Windows server was in my local timezone of AEDT, but the FreeIPA server was in PST. I was able to resolve this by setting the timezone on the FreeIPA server with the below command so that it matched the time of the Windows server.

    [[email protected] log]# date
    Wed Dec 28 20:45:04 PST 2016
    [[email protected] log]# timedatectl set-timezone Australia/Sydney
    [[email protected] log]# date
    Thu Dec 29 15:46:29 AEDT 2016

    I suggest our guide on configuring NTP in Linux if you need further assistance with this.

  • Your account has been disabled. Please see your system administrator.
    This one was fairly straightforward, after many login attempts while performing troubleshooting I locked out the account in FreeIPA. The /var/log/krb5kdc.log file on the FreeIPA server showed:

    Dec 29 15:46:39 krb5kdc[44950](info): AS_REQ (7 etypes {18 17 23 3 1 24 -135}) CLIENT KEY EXPIRED: [email protected] for krbtgt/[email protected], Password has expired
    Dec 29 15:46:49 krb5kdc[44951](info): AS_REQ (7 etypes {18 17 23 3 1 24 -135}) LOCKED_OUT: [email protected] for kadmin/[email protected], Clients credentials have been revoked
  • Don’t forget FreeIPA password requirements.
    While attempting to set a new password on first login with a new account, I was not choosing a strong enough password as per my FreeIPA password policy. This resulted in the below error message in the /var/log/kadmind.log file on the FreeIPA server. The solution was of course to use a stronger password.

    Dec 29 15:54:58 kadmind[44955](Error): password quality module empty rejected password for [email protected]: Empty passwords are not allowed
    Dec 29 15:54:58 kadmind[44955](Notice): chpw request from for [email protected]: Password is too short
  • The security database on the server does not have a computer account for this workstation trust relationship.
    I’m not exactly sure how I fixed this, basically the below is what showed in the /var/log/krb5kdc.log file on the FreeIPA server when the Windows server reported this error.

    Dec 29 15:55:16 krb5kdc[44951](info): AS_REQ (7 etypes {18 17 23 3 1 24 -135}) NEEDED_PREAUTH: [email protected] for krbtgt/[email protected], Additional pre-authentication required
    Dec 29 15:55:16 krb5kdc[44951](info): AS_REQ (7 etypes {18 17 23 3 1 24 -135}) ISSUE: authtime 1482987316, etypes {rep=18 tkt=18 ses=18}, [email protected] for krbtgt/[email protected]
    Dec 29 15:55:16 krb5kdc[44951](info): TGS_REQ (7 etypes {18 17 23 3 1 24 -135}) UNKNOWN_SERVER: authtime 0,  [email protected] for krbtgt/[email protected], Server not found in Kerberos database

    Basically I reran the ksetup commands mentioned above, performed the reboot again, and everything was fine, so it’s possible I had some sort of typo the first time around or that my DNS was not properly configured the first time I ran through the ksetup commands. Other things to check would be that the host principal in FreeIPA correctly matches the hostname of the Windows server and the value specified in the -p option when running ipa-getkeytab.

  • The remote computer that you are trying to connect to requires Network Level Authentication (NLA), but your Windows domain controller cannot be contacted to perform NLA. If you are an administrator on the remote computer, you can disable NLA by using the options on the Remote tab of the System properties dialogue box.
    The solution, as advised, is to disable NLA on the Windows computer. This will fail as there is no Windows domain controller to contact as we’re using FreeIPA. I have found that this is only a problem when connecting with remote desktop with a new account for the first time. After the first login and the expired password for the account has been reset, turning NLA back on seems to work without issue. Note that leaving NLA on may be problematic in the future when an accounts password expires. As long as you change the password on some other Linux server or directly in FreeIPA itself this should not be a problem and you should be fine to leave NLA enabled.
  • Other problems
    For any other connectivity issues, I’d recommend confirming the firewall on your FreeIPA server is allowing the necessary ports through from the Windows server. There are a fair amount of ports required for everything to work nicely, if in doubt you can try temporarily disabling your firewall and testing again as this should either confirm or deny whether or not the firewall was the issue. If it was, simply check the firewall logs and view the traffic that is being dropped, or better yet just do this rather than temporarily reducing your security by disabling the firewall.


To get the full features that Microsoft Windows offers, it is recommended that you join the Windows machine to an Active Directory domain. However if this is not practical due to a small number of Windows machines in your environment, it is possible to perform the steps above in order to log into Windows using user credentials from FreeIPA by using Kerberos, providing us with single sign on.

While that sounds good in theory this solution can often be difficult to get working correctly, as you have seen in the troubleshooting section above I had my fair share of random errors during the setup process.

  1. This is still far from Active Directory and not worth the hassle if you can’t manage the Directory / users on Windows Server.

    Thanks for the tutorial, but I find joining Windows server worthless to IPA, no benefits at all besides logging in with IPA users.

    • Fair enough, however I can tell you it’s been exactly what has been required in a number of production environments for me and has worked perfectly in mixed environments where IPA is not possible.

Leave a Comment

NOTE - You can use these HTML tags and attributes:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>