Hello to all.
I recently installed FDS on a CentOS 3 box. My network authenticates to a win2k3 AD box. I'd like to use the Winsync feature of FDS to keep it automatically updated.
Firstly, FDS does work, to the extent that I populated ou=People, and can see and use those entries in Kmail. I've followed the Admin manual regarding installation and configuration of Winsync on both the FDS and AD boxes, but I can't get it to work. I receive an error "81- LDAP error: can't contact LDAP server". By now, it's entirely probable that I've munged up the configuration, having tried so many tweaks.
I'm really not sure where to begin in terms of providing info to you so that you can help me out. With your kind indulgence, it might be better for you to ask me questions about my setup, and we can go from there (I realize that's a bassackwards way to ask for help, but ...).
Here, at least, are some basics: I obtained server and CA certs from CACert.org, and plugged those into FDS. I created the user Admin on both the FDS and ADS boxes. I created a Replica Agreement. I ran the Winsync utility on the ADS box. I'm trying to use port 636.
I do have a couple of questions: what's the proper way to specify a Supplier DN, and should I use "SSL client authentication" or simple authentication" in the Replica Agreement?
Many thanks.
Dimitri
Dimitri Yioulos wrote:
Hello to all.
I recently installed FDS on a CentOS 3 box. My network authenticates to a win2k3 AD box. I'd like to use the Winsync feature of FDS to keep it automatically updated.
Firstly, FDS does work, to the extent that I populated ou=People, and can see and use those entries in Kmail. I've followed the Admin manual regarding installation and configuration of Winsync on both the FDS and AD boxes, but I can't get it to work. I receive an error "81- LDAP error: can't contact LDAP server". By now, it's entirely probable that I've munged up the configuration, having tried so many tweaks.
I'm really not sure where to begin in terms of providing info to you so that you can help me out. With your kind indulgence, it might be better for you to ask me questions about my setup, and we can go from there (I realize that's a bassackwards way to ask for help, but ...).
Here, at least, are some basics: I obtained server and CA certs from CACert.org, and plugged those into FDS. I created the user Admin on both the FDS and ADS boxes. I created a Replica Agreement. I ran the Winsync utility on the ADS box. I'm trying to use port 636.
One tip: try to get the thing working without SSL first. SSL is only _required_ to propagate password changes from FDS to AD (without SSL everything else will work but password changes themselves will fail). It will be much (much !) easier to diagnose your configuration once you know that everything is correct except SSL is not enabled. You can then proceed to do battle with SSL alone.
I do have a couple of questions: what's the proper way to specify a Supplier DN, and should I use "SSL client authentication" or simple authentication" in the Replica Agreement?
I think you can use either, but unless you know why you need client auth, just use simple auth.
The supplier DN isn't actually used in winsync, so you can give any DN (or the DN that you'd use for any other replication that you are doing : the supplier DNs are a property of the server in general, not winsync). The UI does force you to enter something before it will enable the replica.
Some other ideas: enable replication logging to get more verbose messages from the server as to what it thinks its doing in winsync. Use a sniffer such as ethereal or tcpdump to see if the server is connecting to AD (it sounds like it is not at present, but that might be due to an SSL config issue). Again, disabling SSL makes sniffing the traffic much easier.
On Tuesday August 2 2005 10:32 am, David Boreham wrote:
Dimitri Yioulos wrote:
Hello to all.
I recently installed FDS on a CentOS 3 box. My network authenticates to a win2k3 AD box. I'd like to use the Winsync feature of FDS to keep it automatically updated.
Firstly, FDS does work, to the extent that I populated ou=People, and can see and use those entries in Kmail. I've followed the Admin manual regarding installation and configuration of Winsync on both the FDS and AD boxes, but I can't get it to work. I receive an error "81- LDAP error: can't contact LDAP server". By now, it's entirely probable that I've munged up the configuration, having tried so many tweaks.
I'm really not sure where to begin in terms of providing info to you so that you can help me out. With your kind indulgence, it might be better for you to ask me questions about my setup, and we can go from there (I realize that's a bassackwards way to ask for help, but ...).
Here, at least, are some basics: I obtained server and CA certs from CACert.org, and plugged those into FDS. I created the user Admin on both the FDS and ADS boxes. I created a Replica Agreement. I ran the Winsync utility on the ADS box. I'm trying to use port 636.
One tip: try to get the thing working without SSL first. SSL is only _required_ to propagate password changes from FDS to AD (without SSL everything else will work but password changes themselves will fail). It will be much (much !) easier to diagnose your configuration once you know that everything is correct except SSL is not enabled. You can then proceed to do battle with SSL alone.
I do have a couple of questions: what's the proper way to specify a Supplier DN, and should I use "SSL client authentication" or simple authentication" in the Replica Agreement?
I think you can use either, but unless you know why you need client auth, just use simple auth.
The supplier DN isn't actually used in winsync, so you can give any DN (or the DN that you'd use for any other replication that you are doing : the supplier DNs are a property of the server in general, not winsync). The UI does force you to enter something before it will enable the replica.
Some other ideas: enable replication logging to get more verbose messages from the server as to what it thinks its doing in winsync. Use a sniffer such as ethereal or tcpdump to see if the server is connecting to AD (it sounds like it is not at present, but that might be due to an SSL config issue). Again, disabling SSL makes sniffing the traffic much easier.
Thanks, David. Skipping SSL for the time being makes perfect sense.
But now, I'm confused. I use synchronization, right? Now, I'm getting the following error:
The comsumer initialization has unseccessfully completed. The error received by the replica is: '49 - LDAP error - invalid credentials'
Wher am I going wrong?
Dimitri
Thanks, David. Skipping SSL for the time being makes perfect sense.
But now, I'm confused. I use synchronization, right? Now, I'm getting the following error:
The comsumer initialization has unseccessfully completed. The error received by the replica is: '49 - LDAP error - invalid credentials'
Wher am I going wrong?
This would typically be a typo in either the bind DN or the password supplied for the sync agreement.
On Tuesday August 2 2005 5:51 pm, David Boreham wrote:
Thanks, David. Skipping SSL for the time being makes perfect sense.
But now, I'm confused. I use synchronization, right? Now, I'm getting the following error:
The comsumer initialization has unseccessfully completed. The error received by the replica is: '49 - LDAP error - invalid credentials'
Wher am I going wrong?
This would typically be a typo in either the bind DN or the password supplied for the sync agreement.
But I've checked and rechecked those. My bind DN is cn=Admin. That's the correct format, isn't it?
But I've checked and rechecked those. My bind DN is cn=Admin. That's the correct format, isn't it?
Indeed no. You want the DN for the Administrator user in AD. Typically that would be something like 'cn=Administrator, ou=users, dc=company, dc=com'. However, I would recommend that you use ldapsearch to first establish the correct DN (search for all users in AD and go looking for the administrator user).
389-users@lists.fedoraproject.org
-
David Boreham -
Dimitri Yioulos