Frog query - for those using Active Directory authentication

[TheCrust]

We currently have a problem editting pages in Frog - the toolbar simply won't appear. However, disable AD authentication for a user and the same page can then be editted as normal. Re-enable AD authentication and within minutes the same page cannot then be editted by the same user.

 

After much head-scratching, Frog second line support eventually enabled the "Store encrypted copy of Active Directory password" in the appropriate login profile settings and the problem seems to go away with AD authentication enabled.

 

However I am a bit puzzled as to why this particular setting is needed as it suggests to me an issue with their Active Directory authentication module that relies on the local storage of authentication details to fall back on or for particular actions.

 

If other Frog site admins have a moment, could you check to see what your profile settings are in relation to storing copies of AD passwords please? Particularly in relation to the Staff and Teacher login profiles.

 

I would also be interested to see if this problem could be replicated on your sites by (if it's ticked of course!) unticking the "store copy of password" setting, waiting a bit, and seeing what happens.

 

Thanks in advance!

[mthomas08]

Very strange, our integration had zero issues with AD and SIMs.

 

I have just checked, our setting is enabled. Only thing I can really think of is when did they originally setup your AD Authentication? (Without the Store Enabled).

 

Our Frog server was installed a year ago.

[TheCrust]

Ours was installed last summer and we've not really used it in anger yet because it has exhibited more than a few niggles that have stopped us getting it set up as we want - the biggest of which was when it refused to import the xml file generated by the SIMS extractor and we couldn't bring any students in.

 

I can't say as this particular setting has ever been active - but I could be wrong. I certainly don't recall fiddling with it anyway. Another school in the LA using Frog has confirmed theirs was also set, but the only effect unticking it on their system seemed to have was one user couldn't get into their mailbox - it didn't prevent them editting pages.

 

Would you consider temporarily turning off the setting for one of your user groups and seeing what effect it has? On our server it takes up to 30 minutes to have an effect (and that one effect seems to be users cannot edit their pages anymore) but turning it back on resolves that instantly so any perceived difficulties are easily reversed.

[mthomas08]

Shouldnt be a problem, will get back to you shortly

[mthomas08]

You are right, problem occured when editting pages. I have put my setting back in to place so wouldnt worry about it if I was you. Strange though your setting wasn't there to begin with but here it had already been enabled.

[TheCrust]

That's great - thanks for confirming.

 

FrogTrade have referred that one back to the development team to fix - there should be no need to store copies of any parts of AD on the Frog server if the authentication module was working properly in the first place...

[TheCrust]

As an update to this issue while I'm in a thinking-about-Frog mood tonight, I raised the issue with the Frog development team before the summer - and one of their technical chaps came back to me and said that caching wasn't important and could be turned off if I wanted as it was only used to speed up access in some situations.

 

However, our own experience detailed above shows this may not quite be the case - as turning the storage of cached copies of passwords off definitely has a tangible effect on Frog: specifically the toolbar fails to appear when editing pages!

 

The only way we found we could restore access to the frog toolbar was to either re-enable password caching - or to configure staff to not use AD authentication at all.