I have Jive Messenger using Active Directory
for user authentication. The problem is, our users are required to change
their windows passwords every few months, when they do the client still has
their old password saved and wont allow the users to log in. Users being
users, they just hit “ok” and dont update their password in the client which keeps
them offline. Is their a way to authenticate using just the username and ignore
the password?
Thanks!
SkidVis,
I don’‘t think this is a feature we want to support in Jive Messenger by default – it’'s a bit too easy to abuse. However, you could modify the LdapAuthProvider class yourself to bypass password checking.
Regards,
Matt
It’'s a feature supported by the soapbox server.
I believe they call it sspi or “Single Sign-on”
http://www.coversant.net/portal/DesktopDefault.aspx?tabid=51
It would certainly be useful to me since my users are pc-saavy
enough to know what the error messages they get mean when
they change their system password.
About changing it myself in the class… I only WISH I knew
enough about programming to make something so cool.
Actually, Coversant uses SSPI/NTLM to do single sign-on, which is a feature of their client. They don’'t just ignore passwords.
Regards,
Matt
Touché!!
So I should be dealing with this on the client side perhaps?
My understanding is that Pandion supports this feature in their client. However, Jive Messenger would also need to support it so that the SSO key the client sends could be used. We can definitely consider adding this in the future, but it wouldn’‘t be something done in the short-term (we have to support SASL as a first step). Is Coversant’‘s server too expensive for your implementation? I know it’'s a good product.
Regards,
Matt
Firstly, you should never allow unauthenticated connections (my day job is Security Engineer).
If your users have to change their password periodically and they have to relogin to Jive when that happens, well, “thems the breaks”. I’‘m not a big fan of passwords and I’'m a security engineer.
From my understanding of SASL, you should be able to support the Kerberos-like ticketing of Win2K/AD from within SASL by authenticating against the SASL interface and telling your LDAP server the realm is ActiveDir.
SASL should then delegate the authentication and ticketing to ActiveDir.
SASL default authentication is enough like Kerberos that glueing to ActiveDir through LDAP/SASL shouldn’'t be too much of a hassle.
I haven’'t looked deep inside SASL, but that seems like a much cleaner solution.
That way you should only have to write one LDAP/SASL authentication interface and the middleware does the rest.