LDAP with W2K3

I have installed version 3.1.0 Beta 2 on a W2K3 server to use for our internal messaging. Having tried every possible scenario (except the correct one) in the wildfire.xml file to actually pull users from AD, I was hoping someone could kindly point out my problem. I have verified from that server, that I can query AD successfully, so I’'m fairly certain that it is the wildfire configuration rather than a network or communication issue. Also, the DB is on a different server, which is W2K3 OS and SQL 2K5. Here is the config file

Any help anyone could provide would be so greatly appreciated. I have looked at this until I’'m blue in the face and am sure its probably something staring me right in the face. M

You might want to try adding <debugEnabled>true</debugEnabled> inside the <ldap> element to see more of what’'s going on. Also, have you tried using an external LDAP browser such as http://www.ldapbrowser.com/ to bind to the AD? Try using it and binding to AD with the adminDN you specified, then make sure you can browse the baseDN you used.

thanks so much for the response! I used that utility to verify LDAP was working correctly, using the same credentials as are in my wildfire.xml file. I also added debugging. There is absolutely nothing in the debug.log, warn.log or error.log files. the info.log file shows this:

2006.09.21 09:44:25 Multi User Chat domain: conference.

2006.09.21 09:44:25 Started plain (unencrypted) socket on port: 5222

2006.09.21 09:44:27 Started SSL (encrypted) socket on port: 5223

2006.09.21 09:44:27 Publish-Subscribe domain: pubsub.

2006.09.21 09:44:28 Wildfire 3.1.0 Beta 2

2006.09.21 09:44:35 Admin console listening at:

any ideas? M

Change the following entries in your xml file

Let me know if this worked.

no such luck. I made the change and even rebooted the server. This is very frustrating!

Try creating a test user under your baseDN and use the same as your AdminDN and check it out.

Try this, I made an attempt to populate your data into here, please re-verify after you cut and paste that everything is correct.

Red shows missing and needed

Blue shows missing but useful

<?xml version=“1.0” encoding=“UTF-8”?>







<authorizedUsernames>** Put your AD admin Account name here **</authorizedUsernames> </admin>



<clientSideSorting>true</clientSideSorting> <host></host>






<adminDN>CN=Jive IM;OU=_Service Accounts;OU=HMI users;DC=hmi;DC=universaltrailer;DC=com</adminDN>



<vcard-mapping> <![CDATA[<vCard xmlns=’‘vcard-temp’’>
<FN attrs=“displayName”></FN>
<N><FAMILY attrs=“sn”></FAMILY><GIVEN attrs=“givenName”></GIVEN><MIDDLE/></N>
<NICKNAME attrs=“displayName”></NICKNAME>
<TEL><VOICE/><HOME/><NUMBER attrs=“homePhone”></NUMBER></TEL>
<ADR><WORK/><STREET attrs=“streetAddress”></STREET></ADR>
<ADR><WORK/><POBOX attrs=“postOfficeBox”></POBOX></ADR>
<ADR><WORK/><REGION attrs=“st”></REGION></ADR>
<ADR><WORK/><PCODE attrs=“postalCode”></PCODE></ADR>
<ADR><WORK/><CTRY attrs=“co”></CTRY></ADR>
<TEL><VOICE/><WORK/><NUMBER attrs=“telephoneNumber”></NUMBER></TEL>
<TEL><FAX/><WORK/><NUMBER attrs=“facsimileTelephoneNumber”></NUMBER></TEL>
<TEL><CELL/><WORK/><NUMBER attrs=“mobile”></NUMBER></TEL>
<TITLE attrs=“title”></TITLE>
<ROLE attrs=“Rank”></ROLE>
<ORGNAME attrs=“company”></ORGNAME>
<ORGUNIT attrs=“department”></ORGUNIT>
<URL attrs=“wWWHomePage”></URL>
<DESC attrs=“description”></DESC>
</vCard>]]> </vcard-mapping> </ldap>








<className>org.jivesoftware.wildfire.ldap.LdapUserProvider</className& gt;



<className>org.jivesoftware.wildfire.ldap.LdapAuthProvider</className& gt;



<className>org.jivesoftware.wildfire.ldap.LdapVCardProvider</className >




<className>org.jivesoftware.database.DefaultConnectionProvider</classNa me>





<serverURL>jdbc:jtds:sqlserver://hminws01/IM;appName=jive</serverURL&gt ;










Nothing in the logs? You should see a trace of every LDAP packet that crosses the wire.

You’'ve got




You should then see a whole bunch of stuff in stderr.log starting with a printback of the settings…

Created new LdapManager() instance, fields:


port: 389

usernamefield: sAMAccountName

baseDN: DC=xxxxxx,DC=xxx

alternateBaseDN: null

nameField: cn

emailField: mail

adminDN: CN=WFAdmin,OU=Service Accounts,DC=xxxxx,DC=xxx

adminPassword: xxxxxxxxx

searchFilter: (& (sAMAccountName=) (userPrincipalName=@xxxxxx.xxx) (| (objectClass=user) (objectClass=userProxyFull) ) )


ldapDebugEnabled: true

sslEnabled: false

initialContextFactory: com.sun.jndi.ldap.LdapCtxFactory

connectionPoolEnabled: false

autoFollowReferrals: false

groupNameField: displayName

groupMemberField: member

groupDescriptionField: description

posixMode: false

groupSearchFilter: (& (displayName=) (displayName=_*) (objectClass=group) )

thanks so much! After a couple of minor changes to syntax, I’‘m working. I can’'t tell you how much I appreciate your help! Have a great day! M

Message was edited by: mdavis513

Hi all,

I have tried connecting WF 3.1.0 with AD on W2K3 and got the following LDAP error “code 1 - LdapErr DSID-0C090627. In oder to perform this operation a successful bind must be completed on the connection, data 0, vece”

The only solution I have found was to change in “Local Security Options” the “LDAP client signing requirements” on the Domain Controller. It was set to “Require signature” but WF only worked when it was set to “None”.

Allows WF setting a server property or do I use a wrong configuration? Changing the domain controller security setting is not a good solution. I have already tried changing POSIX and SSL without success.



From MS AD Help:

This security setting determines the level of data signing that is requested on behalf of clients issuing LDAP BIND requests, as follows:

  • None: The LDAP BIND request is issued with the options that are specified by the caller.

  • Negotiate signing: If Transport Layer Security/Secure Sockets Layer (TLS\SSL) has not been started, the LDAP BIND request is initiated with the LDAP data signing option set in addition to the options specified by the caller. If TLS\SSL has been started, the LDAP BIND request is initiated with the options that are specified by the caller.

  • Require signature: This is the same as Negotiate signing. However, if the LDAP server’'s intermediate saslBindInProgress response does not indicate that LDAP traffic signing is required, the caller is told that the LDAP BIND command request failed.