Account Replication and Password Synchronization with FreeIPA and Active Directory on CentOS - rharmonson/richtech GitHub Wiki

[DRAFT]Account Replication and Password Synchronization with FreeIPA and Active Directory on CentOS

Published: October 20, 2017

FreeIPA is the upstream project for Red Hat Identity Manager (IdM). It provides similiar functionality as Microsoft Active Directory but for Fedora, CentOS, and RHEL servers and workstations. There are two distinct process to integrate the two products. First, replicate user accounts. Second, detect password changes in Active Directory and synchronize with FreeIPA. This article discribes the installation procedures for both.

Note that Red Hat's states that the best practice, today, is to integrate using Forest Trusts between directory seravices; IPA, IdM, or AD. In large or complex environments, I agree. However, environments with one Active Directory Domain and one FreeIPA Realm, password replication is appropriate. Red Hat provides excellent documentation on how to migrate from the account and password synchronization model to the Forest Trust model. The document, "Windows Integration Guide," and other useful referenceare are provided under the section titled References.

Assumptions

In this article, I am making a number of assumptions about you and your environment.

FreeIPA & Active Directory

You must have installed CentOS FreeIPA (IPA) and Microsoft Active Directory Directory Services (AD). In production, you would have at least two of each for high-availability, but only one of each is required if inadvisable. In fact, replication occurs from only one AD server to one IPA server. Password changes in AD by design may occur on any Domain Controller (DC), so the installation of software must occur on all DCs to identify password changes then synchronize with IPA.

Name Resolution

IPA and AD directory services will need to have seperate DNS name spaces. For example the domains ad.mydomain.net and ipa.mydomain.net. In addition, all participants must be able to resolve each other. Use conditional forwarders, stub or slave zones, or whatever, but each synchronization and replication host must be able to resolve the other participants.

My Active Directory uses IPA as its forwarder, however, I created a DNS Forwarder Zone on each IPA server using its IPA admin portal; winauth.mydomain.net and 192.168.1.13. If using a domain without delegation from SOA, disable DNSSEC validation.

Certificates

Both the synchronization and replication processes rely on x.509 certificates. You must have at least one Root Certificate Authority (CA). It is possible to have a Root CA for IPA and a Root CA for AD. Unlike AD, IPA requires the installation of a CA during the IPA installation. As a consequence of installing IPA, a Root CA should already be present in your environment. I will describe certificate management tasks for my environment, so the steps may differ for your environment.

My environment is comprised of a Dogtab Root CA where Subordinate CA or signing certificates where issued to the IPA servers. As part of the article, we will be requesting a certificate to enable AD use of LDAPS from the Dogtag Root CA.

Miscellaneous

I may not provide detailed instructions on basic administration task like account, firewall, or DNS management.

Prerequisites

Replication

Service Account

To replicate user accounts, an AD user or service account is needed with "Account Operators" and "Read-only Domain Controller" group membership. In addition, the account needs "Replicating Directory Changes" on the AD domain.

Use the dsa.msc or Active Directory Users and Computer Microsoft Management Console to create the account, svcpasssync, and assign group membership. To provide the replication change permissions, right-click the top level and select security properties.

Certificate

A server certificate on the AD DC selected to replicate accounts is required to provide secure LDAP or LDAPS. IPA will not synchronize with LDAP.

If LDAPS is already setup, export the DC public key for use later in this guide. If LDAPS is not setup, a certificate request will be created using a "request.inf" file on the DC. Using notepad, copy and paste the example below and revise for your environment. Note the "Extensions" section is optional, but it provides the Subject Alternative Name (SAN) attribute to the certificate.

[Version]

Signature="$Windows NT$

[NewRequest]
Subject = "CN=ad.winauth.mydomain.net"
KeySpec = 1
KeyLength = 2048
Exportable = TRUE
MachineKeySet = TRUE
SMIME = False
PrivateKeyArchive = FALSE
UserProtected = FALSE
UseExistingKeySet = FALSE
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12
RequestType = PKCS10
KeyUsage = 0xa0

[Extensions]
2.5.29.17 = "{text}"
_continue_ = "dns=ad.winauth.mydomain.net&"
_continue_ = "dn=CN=AD,OU=Domain Controllers,DC=winauth,dc=mydomain,DC=net&"
_continue_ = "ipaddress=192.168.1.13&"
_continue_ = "guid=3b0f95e7-e8c2-6446-b4F8-11869d6c32d7"

[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.1

Using certreq.exe

certreq.exe -new request.inf request.csr

Submit request to CA as a Server Certificate using pki CLI or the user self-service portal; https://ca.intranet.mydomain.net:8443. The portal is easiest, but make sure to specify "Manaual Server Certificate Enrollment."

Once submitted, you will be provided the submission number. In the example below, it is number 8. Note the use of the argument --file. It creates a file to review and edit in a 2nd shell. If satisfied, enter "approve" to approve the certificate request.

# pki -c 'Password1' -d ~/.dogtag/nssdb/ -n "PKI Administrator for intranet.mydomain.net" cert-request-review 8 --file /tmp/csr8request

Results

-------------------------------
Retrieved certificate request 8
-------------------------------
  Request ID: 8
  Profile: Manual Server Certificate Enrollment
  Type: enrollment
  Status: pending
  Filename: /tmp/csr8request

Action (approve/reject/cancel/update/validate/assign/unassign): approve
------------------------------
Approved certificate request 8
------------------------------
  Request ID: 8
  Type: enrollment
  Request Status: complete
  Operation Result: success
  Certificate ID: 0x8

Export the approved certificate.

# pki -c 'Password1' -d ~/.dogtag/nssdb/ -n "PKI Administrator for intranet.mydomain.net"  cert-show 8 --encoded --output ad.crt

Also, export the Root CA

# pki ca-cert-show 1 --encoded --output rootca.crt

Altnernatively, use the URL below to obtain the Root CA certificate:

http://ds1.intranet.mydomain.net/ipa/config/ca.crt

On the AD server, use the "Certificates" plugin for MMC, import both the ca.crt and ad.crt into the local machine (not user) certificate store.

Retain the ad.crt for later use on the IPA server.

Reboot AD server after the above change and before proceeding.

Account Replication

In theory, IPA will create a default account, passsync, and you will specify its password during the creation of the Synchronization Agreement.

Synchronization Agreement

# ipa-replica-manage connect --winsync --passsync=passwd4IPApasssync --cacert=ad.crt --binddn "cn=svcpasssync,ou=serviceaccounts,dc=winauth,dc=mydomain,dc=net" --bindpw passwd4ADsvcpasssync --win-subtree="ou=replicateaccounts,dc=winauth,dc=mydomain,dc=net" -v ad.winauth.mydomain.net
Directory Manager password:

Added CA certificate ad.crt to certificate database for ds1.intranet.mydomain.net
ipa: INFO: AD Suffix is: DC=winauth,dc=mydomain,DC=net
The user for the Windows PassSync service is uid=passsync,cn=sysaccounts,cn=etc,dc=intranet,dc=mydomain,dc=net
Adding Windows PassSync system account
ipa: INFO: Added new sync agreement, waiting for it to become ready . . .
ipa: INFO: Replication Update in progress: FALSE: status: Error (0) Replica acquired successfully: Incremental update started: start: 0: end: 0
ipa: INFO: Agreement is ready, starting replication . . .
Starting replication, please wait until this has completed.

Update succeeded

Connected 'ds1.intranet.mydomain.net' to 'ad.winauth.mydomain.net'

ipa-replica-manage

If the creation of the Synchronization Agreement completes successfully, but you are not seeing accounts populate, review the arguments provided. Oddly enough, it does not validate the distinguished name (DN) of the AD subtree or organization unit. Use ipa-replica-manage re-initialize --from ad.winauth.mydomain.net to test your changes.

To list replication agreements, use the ip-replica-manage command.

Example

# ipa-replica-manage list
ad.winauth.mydomain.net

Also, delete

# ipa-replica-manage del ad.winauth.mydomain.net

or, force replication

# ipa-replica-manage force-sync --from ad.winauth.mydomain.net

or, copy the entire database or identity store

[root@server ~]# ipa-replica-manage re-initialize --from ad.winauth.mydomain.net

Password Synchronization

Acount

The IPA user "passsync" was populated at the creation of the Synchronization Agreement with its password, also, set using --passsync.

You can verify the account was created using ldapsearch on the IPA server.

# ldapsearch -D "cn=Directory Manager" -W -b uid=passsync,cn=sysaccounts,cn=etc,dc=intranet,dc=mydomain,dc=net

Results

ldapsearch -D "cn=Directory Manager" -W -b uid=passsync,cn=sysaccounts,cn=etc,dc=intranet,dc=mydomain,dc=net
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <uid=passsync,cn=sysaccounts,cn=etc,dc=intranet,dc=mydomain,dc=net> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# passsync, sysaccounts, etc, intranet.mydomain.net
dn: uid=passsync,cn=sysaccounts,cn=etc,dc=intranet,dc=mydomain,dc=net
memberOf: cn=PassSync Service,cn=privileges,cn=pbac,dc=intranet,dc=mydomain,d
 c=net
memberOf: cn=System: Change User password,cn=permissions,cn=pbac,dc=intranet,d
 c=harmonson,dc=net
memberOf: cn=System: Read User NT Attributes,cn=permissions,cn=pbac,dc=intrane
 t,dc=mydomain,dc=net
objectClass: account
objectClass: simplesecurityobject
objectClass: inetUser
objectClass: top
uid: passsync
userPassword:: [passwordhash]

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

For password changes of the passsynch user, execute the followingon the IPA server.

ldappasswd -D "cn=Directory Manager" -W -s NewPasswdHere uid=passsync,cn=sysaccounts,cn=etc,dc=intranet,dc=mydomain,dc=net

Test the password using the passsynch user and provide passsynch's password when prompted or replace "-W" with "-w TestPasswdHere"

ldapsearch -D "uid=passsync,cn=sysaccounts,cn=etc,dc=intranet,dc=mydomain,dc=net" -W -b "uid=passsync,cn=sysaccounts,cn=etc,dc=intranet,dc=mydomain,dc=net"

Download

Obtain 389 PassSynch from the website given below and place the installation package on all AD DCs for the domain. I am using 389-PassSync-1.1.7-x86_64.msi.

http://directory.fedoraproject.org/docs/389ds/download.html

Install

Execute the installer which will then prompt you to provide the IPA connection information.

Host Name: ds1.intranet.mydomain.net
Port Number: 636
User Name: uid=passsync,cn=sysaccounts,cn=etc,dc=intranet,dc=mydomain,dc=net
Password: (password as configured in the Synch Agreement --passsync)
Cert Token: [not used]
Search Base: cn=users,cn=accounts,dc=intranet,dc=mydomain,dc=net

Enter the values for your environment, however, the user account and search base values will work for most installations for they are the defaults.

Certificate

PassSynch will not function until you install the certificate of the IPA server in its own certificate store; cert8.db. Import the FreeIPA DS certificate (public) by executing the following within the PassSynch installation folder C:\Program Files\389 Directory Password Synchronization.

# Create New cert8 and key databases
certutil.exe -d . -N

# Import into databases
certutil.exe -d . -A -n "DS1 CA cert" -t CT,, -a -i ds1.cert

# Verify it was imported
certutil.exe -d . -L -n "DS1 CA cert"

Reboot the AD host or restart the "Password Synchronization" service.