LDAP using aliases

Hello folks.

I started to teste Wildfire server this week and I need some help. It is quite easy I think.

Well, I got a Novell eDirectory here at my company. We have lots of containers. To authenticate users, we create for every object able to authenticate an alias in a ou=users,o=root container.

This way, I got a user like this (this data was obtained thru ldapsearch -x -b ou=users,o=root -h ldap cn=abc)

  1. ABC, USERS, ROOT

dn: cn=ABC,ou=USERS,o=ROOT

objectClass: alias

objectClass: top

cn: ABC

aliasedObjectName: cn=ABC,ou=CONTAINER,o=ROOT

As you can see, this is just an alias. The object in fact, the real object, is at cn=ABC,ou=CONTAINER,o=ROOT.

Finally, my question. I tried to setup wildfire using . But this is bad for me, because only users in that ou=container will be able to use the server.

So, this is a limitation of wildfire or do I need to setup something else?

PS: I have installed version 2.5.0 from rpm package. Thanks a lot!


this may help----


For the time being, I use jabberd2s10 with pipe authenticator. The code listed bellow is the part of code in the authenticator that does the dereference for me. It is written in Perl and is very, very simple. The script calls the function by doing cmdcheck_password(user,password)


part of the perl script----


  1. Compare the given password with the stored password.

sub cmdcheck_password

{

my ($user, $encoded_pass, $realm) = @_;

my $pass = decode_base64($encoded_pass);

return “NO” if not $pass;

my $ldap = Net::LDAPS->new( ‘‘ldap.server’’, port => ‘‘636’’ ) or die “$@”;

my $mesg = $ldap->search(

base => “ou=users,o=root”,

filter => “(cn=$user)”

); # does the search, same as ****

ldapsearch -x -b ou=users,o=root -h ldap.server cn=abc

my $entry = $mesg->entry();

if (!$entry) {
return “NO”; # user does not exist, deny access
}
else {
my $dn = $entry->get_value(’‘aliasedObjectName’’); # get the path of the real object
$mesg = $ldap->bind( “$dn”, password => “$pass”); # here the bind in the real object

if ($mesg->code == 0) {
return “OK”; # user and password are ok, allow the user
}
else {
return “NO”; # wrong password, deny the user
}
}
$mesg = $ldap->unbind;
}

Id love to hear more about this… I have Novell eDirectory as well filled with a lot of containers and aliases pointing to different OUs.

For me only users in some OUs are able to login to Wildfire. The LDAP server itself is running on a Netware 6.5 box and if I watch the console monitor the processor utilization hits 100% when one of these users tries to log in. For no good reason just some of the other OUs work fine and the utilization isnt noticed like this. I have set the baseDN as O=SMC which is the root container at the top of my tree. Experimenting with alternatebaseDN set to the containers that don’'t work hasnt solved this either.

This used to happen with Apache trying to authenticate users against the LDAP server. There was a switch built in that we found to ignore aliases in eDirectory as it was just sending it in loops. Can we have a switch for the wildfire ldap provider that will do the same? I think it will be the solution to all my problems

You’‘re solution to the problem is way out of my league at this stage so I’'m hoping the Jive team can implement something like I mentioned.

Cheers, John.

In your example code, you are intrepreting the data in a specific way. Thats not to say this isnt useful, but a few things need to be defined. Can aliases be recursive? If so, what happens when you loop?

Its also slightly more complicated than it needs to be if the ldap server supports dereferencing aliases natitvely. I assume Netware does based on your description of things, so its really a matter of adding a single line of code when the ldap context is built:

env.put(“java.naming.ldap.derefAliases”, “always”);

/code

Put that in the checkAuthentication and getContext methods of LdapManager and you should be set. Here is more info on how it all works with Java:

http://java.sun.com/products/jndi/tutorial/ldap/misc/aliases.html

Something to keep in mind, is not all servers support binding to an alias.