Hello,
A few clarification points with connecting Openfire to AD (from my experience):
When installing Openfire via its wizard:
• When in the ‘Server Settings’ page, within the ‘XMPP Domain Name’ setting, use the FQDN and not the short NetBIOS name. This will assist when chatting between different chat servers.
• When in the ‘Database Settings’ page, within the ‘Database URL’ settings, enter:
o For AD joined chat server:
‘jdbc:sqlserver://localhost:10800;DatabaseName=Chat;DOMAIN=<NetBIOS_AD_Domain_Name>;integratedSecurity=true;’
o For standalone, non-AD joined chat server:
‘jdbc:sqlserver://localhost:10800;DatabaseName=Chat;DOMAIN=<NetBIOS_Server_Name>;integratedSecurity=false;’
• When in the ‘Profile Settings: User Mapping’, change the ‘UserName Field’ from ‘uid’ to ‘sAMAccountName’, as the AD user object doesn’t contain a ‘uid’ attribute.
• The older version of Openfire that I’m using by default only looks for all AD User and Group objects within the default ‘Users’ Container (not OU) and computers objects within the ‘Computers’ Container (not OU). So as a test, when in the ‘Profile Settings: Connection Settings’ page, try temporarily changing the ‘Based DN’ to this ‘Users’ Container and move a test chat user from its original custom OU up into the ‘Users’ Container. It should find it there -> However, no AD in the world leaves their user objects there, as you can’t apply Group Policies to them. So to get Openfire to look for my AD Chat User, Group & Computer objects within my custom created OU’s, during the installation wizard, I had to perform a forward and backward web browse page process, where I had to keep changing the ‘Based DN’ path save it, browse forward, perform the operation, then browse back again and change the ‘Based DN’ to the next required OU path, save it and move forward again -> Yes, a very ugly work-around for an product that is not fully AD aware.
I hope that works for you,
Cheers,
Cosmo