On 12/24/2012 09:13 AM, Nate Marks wrote:
I'd love some feedback on these. They seemed to work for me.Thanks!

This guide starts at the point where your freeipa server is correctly replicating accounts from a windows active directory server. The following steps are intended to help you roll out the passync software to all of your domain controllers. Detailed descriptions of how the software works are available from people far more competent than myself. I'm just covering some installation tips. One thing that really screwed me up is that there are great passsync docs for 389 directory server and great passsync docs for freeipa server. They are similar. They are NOT interchangeable. When using freeipa server stick with freeipa docs . I know this seems obvious, but when passsync doesn't work the first time, my instinct is to cast about on google for things that seem to be related. When you find the 389 server docs under those circumstances and try to apply them to freeipa, you find a rathole.

Fixed - see below.

Getting started:

It's theoretically possible to get the passsync to work on the first attempt. I've just never done it. In order for that to work, you have to have exactly the right values ready to go when you run the passsync installer. The installer has input fields for the following items:

verifying the hostname, username password and search base values
hostname: <FQDN of the freeipa server>
port: 636
username: uid=passsync,cn=sysaccounts,cn=etc,dc=<xxx>,dc=<xxx>
password: <password>
cert token : tried it with and without the /etc/dirsrv/slapd-instance/pwdfile.txt contents

Right - not needed

serach base=cn=users,cn=accounts,dc=inframax,dc=ncare

The best tool I found in windows for checking the passsync installation settings is ldp. First I'll talk about verifying the easy stuff (hostname, username, password, search base). run notepad on the windows server and put in the values you're going to use before running the passsync installer. Then run ldp.exe and use the values from notepad and the steps below to verify the hostname, username, password and search base.

connection > connect
enter the freeipa server hostname in the server field
enter port 636 (non-ssl port) in the port field

636 is the SSL port
Does ldp have an option for StartTLS?

check the SSL box
click OK

connection > bind
select the 'simple bind' radio button
enter the DN for the passsync account on the freeipa server in the userfield. this is "uid=passsync,cn=sysaccounts,cn=etc,dc=<domain>,dc=<domaintld>" by default
enter the password for the passsync account in the password field
click ok

select view > tree and make sure you can browse the tree in the ipa server. browse to the subtree that you're going to use for search base and make sure you
see your replicated accounts in that container.
if you can, then the values you used for the hostname, username, password and search base are all correct. It also means that the ca.crt file you imported for ldap account syunchronization is working correctly.

NOTE: I left cert token empty. it seems to be used for encrypting the certificate db in c:\program files\389 directory password synchronization. That can be done after you get password synchronization working.
Right - it is not needed

Installing Passsync:
Now we've done a bunch of work to check our values, but we haven't accomplished anything. So go ahead and run the passsync msi installer and enter your values into the appropriate fields.

The installer will create files, directories and registry stuff, but we're not nearly done.

Step 5 in the link below seems to have the correct steps. Be sure to import the same certificate that you imported in the account synchronization process. I got mine with wget http://<iapserver>/ipa/config/ca.crt.


One mroe thing before rebooting, use regedit to change the value of HKLM->Software->PasswordSync "Log Level" from 0 to 1. If everything works and you don't need it, great!

If the stars line up, you've put good values into the passsync installer, imported the freeipa servers certificate into the cert DB that passsync uses and the installer registered a new dll to capture password change events. You need to reboot the server to get the dll registration to take effect. After it restarts, change the password on an account that's being replicated to free ipa. use notepad to open the file c:\program files\389 directory password synchronization\ passsync.txt
if the passhook.dll is working correctly, you'll see an entry like:
'1 new entries loaded from data file'

If ssl is working correctly, you'll be able to log into the freeipa server with the test account and newly changed password.

Ifit doesn't work, verify your cert and your values with ldp.exe. I just don't have anything better that that yet.

This takes me to the point where I'd love more tools to troubleshoot the problem.

Other things I've tried:
1) UAC. I disable it, but I'd love some feedback on whether or not that's required on win 2k8R2. 2) some of my DCs have certificate services installed and some don't. I don't think any of that matters or passsync, but I'd love feedback there too.

It doesn't matter, as long as the Active Directory is using TLS/SSL somehow, and you have access to the CA cert of the CA that issued the Active Directory Server cert.

3) Here are the details on the 389 directory server steps that screwed me up.:

I found these steps for exporting cert from the linux that apparently apply to 389 and not to freeipa(http://directory.fedoraproject.org/wiki/Howto:WindowsSync) and they really screwed me up with freeipa:
cd /usr/lib/dirsrv/slapd-instance_name
certutil -d . -L -n "CA certificate" -a > dsca.crt
# NOTE - it might not be called CA certificate - use certutil -d . -L to list your certs
I think the problem is that it tells you to use /usr/lib/dirsrv/slapd-INST which is bogus - it should be /etc/dirsrv/slapd-INST - I've fixed the wiki page

instead, just use the process that worked for the account replication setup. just use the ca.crt from http://<ipaserver>/ipa/config/ac.crt <http://ipaserver/ipa/config/ac.crt>.
this is probably simpler and will  work from the windows machine as well

The steps don't throw any errors, but that certificate didn't work for me. It may be a little obvious, but it only worked if I imported the same cert file used in the replication process. I got that file

Freeipa-users mailing list

Freeipa-users mailing list

Reply via email to