Is it possible to automatically use AD details to authenticate

Hi,

New to Spark so apologies if this is a frequent question…

I’m running Spark in a windows domain environment ith OpenFire setup for Active Directory authentication for Spark user’s. Aside from several security issues like allowing user’s access to the “Account” tab and the “Advanced” tab on login, it’s a fantastic client for my needs but I would like to remove access for the users to those two tabs on the startup window AND if somehow possible, does anyone know of a way to automatically authenticate the Spark client’s login with the user’s current AD password?

I can setup the user to auto-login with their current AD details, thus taking away the user’s ability to access the advanced and account options but when the user’s windows password changes, the user will have access to these again when it complains the the auto-login and saved password are no longer valid.

Is the only way to fiddle with the source code? Another example is removing the option in the menu for adding Plugins…

Thanks for any help

Daryn

It is called Single Sign On and is anything but an exact science. Every AD system is different. This is the procedure that worked for me twice: http://www.igniterealtime.org/community/docs/DOC-1616

Thanks for your reply… sorry, I forgot to mention, the openfire is running now on a Centos 5.x server. It’s successfully communicating with AD on a Windows 2003 box just using the OpenFire Ldap config. I think that your procedure is for a Windows Openfire server… should that make much of a difference?

obviously commands like

C:>ktpass /princ xmpp/fqdn.of.chat.server@YOUR.DOMAIN.COM /mapuser

would have to be adapted (if at all possible) for a linux environment?

It will eliminate some of the steps specific to changes to the Server OS. Otherwise no most of the stuff is the same. there are lots of other docs on this community regarding this including nix AD SSO.

that command is run from an AD domain controller. it generates the kerberos file spark needs to authenticat correctly.

gotcha. I’ve already setup Openfire on the linux box so I’ll see if I can hack my system so that I don’t have to reinstall it but it shouldn’t be a hassle to get going if I do…

Thanks very much for setting me on this thoroughly terrifying path… just done a quick search for sso on the community and the amount of problems people’re having is already making me wonder if it’s worth it…!

Trust me if you get it to work it is very much worth it. Every new user gets signed in right away, works with roaming profiles, works with AD password policies, etc.

finally got it working… **** myself thoroughly when had to remake a number of keytabs, as I dont understand the theory that well, wondering if they were corrupt somehow. ended up using

http://www.igniterealtime.org/community/docs/DOC-1060

and

http://www.igniterealtime.org/community/docs/DOC-1522

and

http://www.igniterealtime.org/community/docs/DOC-1362

in the end, my test system worked fine as I created the linux centos box from scratch for this purpose. I got told to install openfire on a pre-created server for the live environment that already had kerberos setup and had been joined to the domain under an incorrect domain name which confused java and it didnt like the AD-generated keytabs at all. had to use one generated on linux as per 1522 above…

all good clean fun. now to start hacking at the client so I can cut it down to bare minimum to avoid 65mb of memory usage plus users having privileges they dont need like installing plugins or checking for updates and the like. very dangerous.

Thanks for the help