[Frog] AD authentication problems.

Just come up against something very strange recently with the AD authentication of our Frog box. We noticed that one student was logging into Frog as someone else in order to access the network home drive. Immediately we changed the victims password thinking that that was job done. Except that I then saw the student still logging in as the victim. I then tried logging in as the victim with their old password and indeed I was allowed in. I then thought I had made a mistake and changed the wrong users password. So I logged on to a computer (not Frog) as the victim with their old password and it failed, then I tried the new password and it worked.

I have since replicated this problem. By:

Created a test student in AD and set a password (A).
Create the matching user in Frog with random password and AD authentication ticked.
Log into Frog with password A. It works.
Reset the password (B) in AD and wait for AD replication to happen.
Log into Frog with password A. It still works.
Try a different browser and log into Frog with password A. It still works.
Try yet another browser and log into Frog with password A. It still works.
Log into Frog with password B. It works.
Log into Frog with password A. It now fails.

Has anyone else seen this?
Would someone else have the time to try this out to see if it is just us?

our frog box imports our students for us and any changes to passwords replicate with no issues what version of frog are you using check in your toolkitas frog are known for breaking things with updates.

also do you have 2 dcs if so check to see if replication is working

we have main dc and a backup dc here and replication is working

i have noticed sometimes that the dc a users logs in from changes now and again

Frog keeps a encrypted copy of all passwords in its database.

It checks against the Frog copy of password first and only if it fails it will try the password against AD using LDAP.

Frog have designed it like this for speed so it dose not need to authenticate to your domain controlers every time.

Unfortunatly that means that if you change a password the old one will continue to work as its stored on Frog, up until the point you use the new one and it checks it via LDAP.

Quote:

---

Originally Posted by MicrodigitUK

Frog keeps a encrypted copy of all passwords in its database.

---

That is what I suspected. Now to get Frog to confirm it also and put a timeout on the password cache!

I will now be adding an extra step to our password change policy to include logging into Frog using the new password.

Did you get anywhere with this?

I've just been told (thirdhand!) that we've encountered this problem ourselves. Students who have just changed their passwords / had them changed can log into Windows fine as you'd expect - but if their attempt to then get into Frog then fails.

Seems our Frog platform is more-or-less relying very heavily on the cache and doesn't bother to refer to AD all that often - if the student waits an indeterminate period of time, they can eventually log in using their new password. Or they can log in again immediately using their old AD password.

You'd have thought that a fail in the request to cache for authentication would then prompt an immediate call to AD - but it doesn't seem to quite work that way in our case.