Hi there
I managed to get the AD (LDAP) Authentiation up and running.
In order to make is as easy for our customers and partners to add our employees as their Jabber Accounts (we’re going to completely get rid of MSN & Co), I want the Jabber ID to be the official email address, which is firstname.lastname@company.com.
This is available in AD under {mail}. But the problem is, that the part behind the jabber ID is the server, so it becomes firstname.lastname@company.com@company.com which obviously confuses the server (and myself)
I can setup our DNS so that domain.com get’s redirected to the Jabber server, that’s sorted, but the User / Jabber ID gives me some headache …
I tried making {mail} as the username, but then I can’t add any admins. getting either a Server 500 Error Message or “User not found”
I think, I’d need an object which gives me firstname.lastname out of the AD, unfortunately, there is no such object. Anything I can do with filter?
Is this possble at all? I’m doing it iin that way for my private server, but this hasn’t any LDAP / AD integration …
Any help is appreciated
Andre
then you need to set the openfire server name, xmpp.domain, and server self signed certificates to company.com. Then use the AD sAMAccountName field for the username in Openfire. when they combine it will be username@company.com
Hi Todd
this is exactly what I’ve done so far.
The problem is, that the LDAP conatins the username in the form of first letter of the firstname + lastname, i.e. jdoe, but the email address is jon.doe@company.com, not jdoe@company.com (although jdoe@company.com would work, it’s just not what the “public” knows)
f0rd42
Hi f0rd42, I was able to do this in a pretty easy way.
You should set the “Server Name” to your domain, in your example “Server name” should be “company.com”. That setting can be changed in the Admin Console, Server Manager, Server Information, Edit Properties.
And should use “sAMAccountName” as the username field (this is set by default).
The only change you should do is in the client, you should set the actual server name (jabber.company.com maybe?) to which it should connect to, as they can no longer figure out through DNS the actual IP of it. This setting depends on the client, we use Psi and you’ve got to change the Account configuration to do so. Spark on the other hand allows you to type the server to which connect in the login prompt.
Let me know if I’m not as clear as I’d like.
Joaquin
Ok, all of the above would work, but the problem is other…
Have you tried usig {givenName}.{sn} as your username field? Concatenation works in ldap field mappings, not sure if it works there…
This should be some ways you could try: {givenName}.{sn},
givenName.sn
{givenName.sn}
Hope it works,
Joaquin
Message was edited by: Joaquin Casarini as he read the other posts.
Hi as said in the post above, my problem is the username convention (jdoe vs. jon.doe). the dns thing is easy to sort out
f0rd42
Have you tried concating in the username field as recommended?
givenName is the field used by ldap for one’s name, sn in the field for surname. So, if concating works either of the three options I gave you should solve it.
You should try these at the username field of your Openfire server config:
{givenName}.{sn},
givenName.sn
{givenName.sn}
I’d say that first and second are more likely to work.
Joaquin
lovely, sounds logical 
I’ll try it first thing tomorrow morning
Thanks
Andre
Great, let me know if it works. I’m pretty curious now about if it works. I’d try it, but my server is in production already, can’t touch something like that.
Hehehe
Joaquin
hi
unfortunately that didn’t do the trick.
If I leave it with the default (sAMAccountName), the test works fine, but any of the suggestions above result in a
—cut—
Status: Error
No users were found using the specified configuration. Try changing the base DN, user filter or username field.
—cut—
I do have a filter (nicked from somewhere here in the forum :
—cut—
(&(objectClass=organizationalPerson)(memberOf=cn=de_openfire,ou=Distribution Groups,ou=Comapny,dc=domain,dc=com))
—cut—
as said, leaving it with the default sAMAccountName works fine …
Andre
Hi Andre,
the filter is only usefull when you want to allow to connect to openfire only user who share a caracteristic, won’t do much in your situation.
About your actual problem, too more options:
The good one, maybe someone from the development team could tell us If there’s a way to get Openfire to accept a concatenated username field, maybe (and I’m guessing here…) some way of scaping the “.” character.
The not that good one: LDAP has a lot of unused attributes (here’s a list of all of them: http://www.it.ufl.edu/projects/directory/ldap-schema/attributes.html) that can be manualy set by the administrator, you could use one of them and fill them in a batch (AD modify does this very quickly, I think the syntax in the field would be %givenName%.%sn%), and then use that taken attribute as your username field mapping in openfire.
It’s twisted I know, but it’s the only way I can see it working…
Are you using LDAP or Active Directory?
Joaquin
Hi
I’m using Active Directory …
I’d love to see the concatination way working, as I don’t wat to change too much in the AD (our UK guys might kill me if they see it )
So, I wait for (hopefully) one of the devs comes back on this …
Andre
If you use an obscure enough attribute maybe those guys won’t even notice it…
I use AD too, and AD modify “works like a charm” as your UK friends would say. I’ve used it to touch much more vital attributes and haven’t failed.
If no one answers you here, try in the devs chat, I think it’s still on once a month…
Joaquin
The “mail” attribute in AD holds the users primary email address. That will be first.last@domain.com in your case. Can you try mapping that in OpenFire?
If he does that he will have to login as "firstname.lastname@company.com@company.com", as openfires append the “Server name” to the username, and thta’s not quite good. Besides, I think he already tried that.
It happened to me too when I was testing it.
Joaquin
Hi
I used the extension.Attribute2 (as 1 is already used), and tried to use this as the username.
Unfortunately I get an :
Status: Error
No users were found using the specified configuration. Try changing the base DN, user filter or username field.
no matter whether I use extension.Attribute2 or {extension.Attribute2}. changing it back to the default sAMAccountName and everything works fine - at least for the query …
Hello Dev’s Any Idea?
ignore my last post … stupid me, it’s called extensionAttribute, not extension.Attribute 