Deploy Windows 2016 AD and Fedora 25 IPA with a One-way Trust

Introduction

For the purpose of this post, the two machines I used for these instructions are VMs running atop a Fedora 25 hypervisor which was configured as outlined here:

Configuring Fedora 25 as a Hypervisor using Virtual Machine Manager

Note: Make sure that when deploying IPA and AD that you do so on separate domains.  Otherwise, IPA clients will be querying the AD server directly when they dig the domain for ldap records.

INCORRECT: IPA Server: ipa01.example.com | AD Server: ad01.example.com
CORRECT: IPA Server: ipa01.linux.example.com | AD Server: ad01.example.com
CORRECT: IPA Server: ipa01.example.com | AD Server: ad01.win.example.com
CORRECT: IPA Server: ipa01.linux.example.com | AD Server: ad01.win.example.com
CORRECT: IPA Server: ipa01.somedomain.com | AD Server: ad01.otherdomain.com

Deploying Windows 2016 AD

  1. On my first VM, I booted using a Trial ISO of Windows Server 2016:
  2. Begin the installation with Windows Server 2016 Standard Evaluation (Desktop Experience).
  3. After the machine boots from installation, configure the Hostname:
    1. Server Manager – Local Server.
    2. Click on the machine’s current hostname.
    3. Click Change and change the hostname to your preference.
      • Example: win16ad01
  4. Configure Active Directory and DNS:
    1. Server Manager – Dashboard.
    2. Add Roles and Features.
    3. For Installation Type, choose Role-based or feature-based installation.
    4. For Server Roles, click Active Directory Domain Services and DNS Server.
    5. Within Server Manager, go to AD DS and click on More.
    6. Click on Promote this server to a domain….
    7. In the next window, choose Add a new Forest.
      • Here, set the full DN of your Forest.
        • Example: win.terranforge.com

Deploying Fedora 25 IPA

  1. For the second VM, I booted using the HTTP link to Fedora 25 Server:
  2. During pre-installation:
    1. Choose Minimal at Software Selection.
    2. In Network & Host Name, set the full hostname of the machine.
      • Example: f25ipa01.linux.terranforge.com
    3. Make sure to give /var a large amount of space, as this is where the IPA Database and Logs will be stored.
  3. After installation and reaching a root prompt:
    1. Install the IPA packages and the RNG package:
      • dnf install ipa-server ipa-server-dns ipa-server-trust-ad rng-tools -y
      • The RNG daemon will generate free entropy to be used during the certificate database creation, otherwise that process can take a very long time to complete.
    2. Open the correct ports that IPA will use:
      • firewall-cmd --add-service=freeipa-ldap --add-service=freeipa-ldaps --add-service=freeipa-trust --permanent
      • firewall-cmd --reload
    3. Start the RNG Daemon:
      • systemctl start rngd
    4. Configure the IPA instance:
      • ipa-server-install --setup-dns
        1. For Server host name, press Enter (Hostname was set during pre-install).
        2. For Domain name and Realm name, press Enter.
        3. Press Enter when prompted for DNS forwarders.
        4. For Enter an IP address for a DNS forwarder, enter the IP Address of your Windows 2016 AD.
        5. Type yes and press Enter to finalize the pre-configuration and begin installation.

Configure the One-way Trust

  1. From the Fedora root prompt, prepare IPA for the trust:
    • ipa-adtrust-install
    • All options should be default.
  2. Configure and Verify the trust:
    1. ipa trust-add --type=ad --admin Administrator --password
      • Example: ipa trust-add --type=ad win.terranforge.com --admin Administrator --password
    2. id administrator@win.terranforge.com

Get involved and ask questions

You can get in touch with the IPA community by joining the #freeipa and #sssd channels on Freenode and the freeipa-users and sssd-users mailing lists.

Authenticating to Fedora using Active Directory credentials that lack Unix attributes

This weekend at the SouthEast LinuxFest, I had a talk about how you can authenticate to Fedora using Active Directory credentials that lack Unix attributes.  Since newer deployments of the most recent versions of Active Directory no longer give you the ability by default to configure Unix attributes, it is important to know that this is not a show stopper.

In my talk, I showed how SSSD uses ID Mapping by converting an objectSID value from a user object from binary to a human-readable number and then runs that number through an algorithm to generate a UID.  It will do the same thing for group objects so that you also have GIDs.  Besides the UID and GID, SSSD has the ability to use a ‘fallback’ mode for home directory and shell locations.  This way, you can “fill in the blanks” of missing information.

Here is an example user object we used in the demonstration to show this:

ldapsearch -LLL -h coldharbour.win.terranforge.com -D Administrator@WIN.TERRANFORGE.COM -W -b dc=win,dc=terranforge,dc=com samaccountname=youknownothing

dn: CN=Jon Snow,CN=Users,DC=win,DC=terranforge,DC=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: Jon Snow
sn: Snow
givenName: Jon
distinguishedName: CN=Jon Snow,CN=Users,DC=win,DC=terranforge,DC=com
instanceType: 4
whenCreated: 20160610164605.0Z
whenChanged: 20160610164605.0Z
displayName: Jon Snow
uSNCreated: 20499
uSNChanged: 20504
name: Jon Snow
objectGUID:: Y7sOFvVwRkmrKNCJiXYkSw==
userAccountControl: 66048
badPwdCount: 0
codePage: 0
countryCode: 0
badPasswordTime: 0
lastLogoff: 0
lastLogon: 0
pwdLastSet: 131100507651203267
primaryGroupID: 513
objectSid:: AQUAAAAAAAUVAAAAoKzsMxIUlCWCTFRxUQQAAA==
accountExpires: 9223372036854775807
logonCount: 0
sAMAccountName: youknownothing
sAMAccountType: 805306368
userPrincipalName: youknownothing@win.terranforge.com
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=win,DC=terranforge,DC=
com
dSCorePropagationData: 16010101000000.0Z

# refldap://win.terranforge.com/CN=Configuration,DC=win,DC=terranforge,DC=com

As you can see, Jon Snow (youknownothing) lacks four of the things that POSIX compliant systems require a user to have: UID, GID, Home Directory and Shell.  However, on a Fedora 23 system that has been joined to the same AD domain, we can successfully see that the user DOES have a UID, GID, Home Directory and Shell:

[root@garden ~]# cat /etc/fedora-release
Fedora release 23 (Twenty Three)
[root@garden ~]# id youknownothing
uid=436801105(youknownothing) gid=436800513(domain users) groups=436800513(domain users)
[root@garden ~]# getent passwd youknownothing
youknownothing:*:436801105:436800513:Jon Snow:/home/youknownothing:/bin/bash

And, we can authenticate as that user to the Fedora system:

[root@garden ~]# ssh youknownothing@localhost
youknownothing@localhost’s password:
[youknownothing@garden ~]$ id
uid=436801105(youknownothing) gid=436800513(domain users) groups=436800513(domain users) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
[youknownothing@garden ~]$

This happens successfully because SSSD is converting the binary SID value to a number, turning that number into a UID based off of an algorithm and then filling in whatever attributes are necessary for the POSIX-compliant system to accept the user as valid.  The only thing SSSD requires from AD to make this happen is an ‘id’, such as a username and the SID attribute.  In sssd.conf, we specify the Shell and Home Directory attributes:

[domain/win.terranforge.com]
id_provider = ad
ad_server = coldharbour.win.terranforge.com
default_shell=/bin/bash
fallback_homedir=/home/%u

[sssd]
services = nss, pam
config_file_version = 2
domains = win.terranforge.com

[nss]

[pam]

Using the ‘default_shell’ and ‘fallback_homedir’ options means that if SSSD does not find these attributes within AD, it will substitute what you give it.  In this case, /bin/bash and /home/%u.  This allows you to specify the unixHomeDir and unixShell attributes in AD for a user if you still desire to do so, and SSSD will use those.

To generate an UID and GID based off of the object’s SID value, SSSD’s ID Mapping algorithm is very similar to how Winbind’s autorid backend works.  This makes it trivial to move from older Winbind configurations to SSSD and continue to retain original UID and GID values.  Using SSSD in this fashion will make the UIDs and GIDs across all systems joined to AD consistent for each user and group, making things like file-sharing hassle-free.