Wildfile 3.1.1 rpm on FC 5, openldap issues - no admin login etc

The Issue is admin login doesn’'t work, even though the user and password is correct, the openldap server has been in use for years and is used daily. the admin username is in the admin users section of the wildfire.xml.

Here is the setup

Fedora core 5 wildfire 3.1.1 server

Installation went fine, started wildfire and use the web interface to configure the wildfire.xml file.

This connected to the database (mysql) properly, set the openldap parameters and test connection worked fine.

But when using the user test and group test pages no results would be returned.

so I stopped the wildfire server and configured the wildfire.xml file my hand.

wildfire server starts fine now. how ever the ldap authentication does not work.

*Here is the config: /opt/wildfire/conf/wildfire.xml

<

/searchFilter> memberUid

Note: The mysql server is on the same server as the wildfire is, the ldap server is running on a separate Redhat AS 3 box.

Here is the wildfire debug.log file after a startup and unsuccessful admin login

I know the username and password are correct since we use the ldap directory for all our linux cluster systems.

-bash-3.1$ more debug.log

2007.01.03 14:19:13 Created new LdapManager() instance, fields:

host:

port: 389

usernamefield: uid

baseDN: dc=ctg,dc=albany,dc=edu

alternateBaseDN: null

nameField: cn

emailField: mail

adminDN: null

adminPassword: null

searchFilter: (&(objectClass=posixAccount)(ou=People)(uid=))
subTreeSearch:true
ldapDebugEnabled: true
sslEnabled: false
initialContextFactory: com.sun.jndi.ldap.LdapCtxFactory
connectionPoolEnabled: false
autoFollowReferrals: false
groupNameField: cn
groupMemberField: memberUid
groupDescriptionField: description
posixMode: true
groupSearchFilter: (&(objectClass=posixGroup)(memberUid=))

2007.01.03 14:19:20 Loading plugin admin

2007.01.03 14:19:30 Loading plugin search

2007.01.03 14:22:36 Trying to find a user’'s DN based on their username. uid: superuser, Base DN: dc=ctg,dc=albany,dc=edu…

2007.01.03 14:22:36 Creating a DirContext in LdapManager.getContext()…

2007.01.03 14:22:36 Created hashtable with context values, attempting to create

context…

2007.01.03 14:22:36 … context created successfully, returning.

2007.01.03 14:22:36 Starting LDAP search…

2007.01.03 14:22:36 … search finished

2007.01.03 14:22:36 User DN based on username ‘‘superuser’’ not found.

2007.01.03 14:22:36 Exception thrown when searching for userDN based on username

‘‘superuser’’

How is the LDAP search constructing the userDN ?

If I use ldapsearch with the search filter I get the names from the ldap as expected.

  1. extended LDIF

  2. LDAPv3

  3. base <dc=ctg,dc=albany,dc=edu> with scope subtree

  4. filter: (objectClass=posixAccount)(ou=People)(uid=
    like: ldapsearch -b “dc=ctg,dc=albany,dc=edu” “(objectClass=posixAccount)(ou=People)(uid=)” # )

  5. requesting: ALL

dn: uid=user,ou=People,dc=ctg,dc=albany,dc=edu

Our plan is to use CAS authentication in to help integrate the user account and passwords.

http://www.ja-sig.org/products/cas/

Thanks

Derek

OK answered my own problem while setting up a ldap replica

When users are having problems not being able to login with the new version 3.1.1 when 2.5 worked, even with the same wildfire.xml config file. It seems that the openldap server config file as a directive that tells clients what password hash is used. The default is SSHA, but at times ldapadd or other ldap editor programs are used to modify user passwords using a different hash like MD5.

So it seems that when these two values are not the same, a client requesting the authentication may never get a password match because they are using different hashes.

Setting the password-hash slapd.conf parameter to the has used in creating the userPassword:: values is the correct way to configure the ldap server. The java app Ldap Browser is a nice too that you can browse your directory and see what hash is used in your users password entries in your directory.

slapd.conf

Values for password-hash are: ,

, , , and .

Cheers