[sims] SIMS single sign on

[jcs808]

Is any one using single sign on for SIMS. I'd like to get your opinions for and against please. Thanks

[synaesthesia]

For. Convenience only.

Against. Set up time. Lessened security. Don't do it.

[IWDave]

Yep, use it here, as mentioned above, convenience but certainly not good for security, you do need to drum it into staff to "Lock" their workstation when they are not in the classroom. Apparently you can tie it in to AD and still get them to login to SIMS with those details rather than letting it go straight in, that's what I'm trying to sort out now.

[jcs808]

Yep, use it here, as mentioned above, convenience but certainly not good for security, you do need to drum it into staff to "Lock" their workstation when they are not in the classroom. Apparently you can tie it in to AD and still get them to login to SIMS with those details rather than letting it go straight in, that's what I'm trying to sort out now.

 

I'd prefer this way. Please post if you work it out.

[GREED]

Last time I worked in a school we had it on for about 6 months, then turned it off due to security issues.

 

This is where I pushed for SAME Sign ON (SaSO) where passwords are the same as Windows, but if you leave your PC unlocked then you still need to know the password.

[Heebeejeebee]

This is where I pushed for SAME Sign ON (SaSO) where passwords are the same as Windows, but if you leave your PC unlocked then you still need to know the password.

 

Doesn't really help when they leave the PC open with SIMS already logged in though.

 

If you go for it drum a security policy into them, make them re-sign the (amended) AUP again and set a (reasonable - not restrictive) screensaver timeout requiring a password.

 

HBJB

[matt40k]

It doesn't "Lessened security". It adds a false layer of security.

 

You're generally find the SIMS password is something unbelievably simple, never changes and normally located on a piece of paper in the laptop back, a post note stuck to the monitor or failing that, known by class.

 

Windows Key + L is the only way to secure "SIMS" not to mention if your only "protecting" SIMS you've already failed.

 

[/rant]

[IWDave]

Just opened a Case with Capita; they have said to modify the connect.ini to just connectiontype=trusted from connectiontype=trustedAuto, but this just lets them click OK and it carries on into SIMS; they're passing it on to see if I can get a login box that required their AD login; I don't fancy going back to separate SIMS username and passwords; that was our hold up when we pushed out Attendance in the Classroom years ago.

[GREED]

Doesn't really help when they leave the PC open with SIMS already logged in though.

 

If you go for it drum a security policy into them, make them re-sign the (amended) AUP again and set a (reasonable - not restrictive) screensaver timeout requiring a password.

 

HBJB

 

Not at all, and never meant to suggest it did. However it is one more layer of security than true SSO.

[3s-gtech]

Hmmm - how about a small .NET program that the SIMS shortcut points to - this then asks for the user's AD credentials (obviously their AD and SIMS usernames would need to be the same) then if they check out it loads SIMS, using connectiontype=trustedauto

 

Not mega secure (e.g. if you create a new shortcut on the desktop and point it to Pulsar it'll still load) - but if you have redirected Start Menus then swapping out should cover most bases.

 

In fact - we'll try this and report back.

[vikpaw]

Hmmm - how about a small .NET program that the SIMS shortcut points to - this then asks for the user's AD credentials (obviously their AD and SIMS usernames would need to be the same) then if they check out it loads SIMS, using connectiontype=trustedauto

 

Not mega secure (e.g. if you create a new shortcut on the desktop and point it to Pulsar it'll still load) - but if you have redirected Start Menus then swapping out should cover most bases.

 

In fact - we'll try this and report back.

 

Great idea and much quicker than getting SIMS to use SaSO.

 

We use Trusted in our central connect.ini but it's only configured for admin and management as they use the same PCs and have physical security. Plus i can go anywhere and still login with backup credentials for troubleshooting, so no need to log off or switch user.

 

The real benefit of linking to AD is you have more control over complexity and renewal, plus it's one less thing for them to remember.

 

It's all useless unless you can drill in best practise like locking the PC though.

 

We're looking at upping the game on password policy, and although complexity is a big deal these days, it's far easier for users and more beneficial to have a longer password. They'll remember it and won't write it down -> xkcd: Password Strength

[3s-gtech]

Riiiiiiiiiiiiiight. For some unknown reason, SIMS pulls the domain\username from the logged on session as the SIMS username (specifically so) meaning that it's looking for usernames that can't exist in our scenario. Can't think of any way round it at present. It may work fine if you have a single domain though, but that is not the case for us.

 

Edit: found the threads on EG about changing SIMS usernames to domain\user, our little program then works nicely. We'll have to go through and change every teacher username, then push out updated connect.ini files, but that's easy enough.

Edited February 13, 2014 by 3s-gtech

[vikpaw]

When you configure users in system manager you have a dropdown for domain, is it available there? The server would need to be able to see both domains. Not sure if the client needs to, but presumably the domain they are on, is the right one for access.

[3s-gtech]

Yeah just played around and sorted it, see above post.

[SovietRussia]

So, as @3s-tech mentioned, we were going to test it and get back to you.

 

Whipped up a small EXE which does a LDAP Bind to verify your credentials are correct, if they are then passes you onto Pulsar, which you should have set your connect.ini to "connectiontype=trustedauto" (You can use trustedauto without this, but you get signed in automatically, for extra security - placing this EXE over the top will ensure that a password is inputted AND the user is verified to AD)

 

 

It can be configured using a XML config file included in the directory with things like Domain, Pulsar Location, School Name etc

 

I will release it soon after some more testing.

 

(Feedback on the design would also be helpful)

Edited February 13, 2014 by SovietRussia

[vikpaw]

Excellent job , happy to help test if time permits.

I had a routine i wrote to intercept logins and first check if an upgrade was due, so the user could opt out if they were on wireless.

 

Actually, just thinking it through, in order to keep that workflow for SIMS upgrades - assuming it's still a SOLUS 2 scenario. You should pass the authenticated user on to SIMSload.exe with pulsar as teh parameter.

 

You might consider a ver2 where you let the user specify if they want to use simsload or pulsar depending on if they are on SOLUS 2 or 3. I don't use 3, but i think it negates teh need for a simsload check. Might need to research the diff setup.

[3s-gtech]

It can do that already, as it has a variable in the config file that defines the SIMS path (so that it can be changed for 32 bit clients). If you point that to SIMSLoad instead of Pulsar, it should still work. In fact, due to its nature you could technically use it to launch any exe while first checking against AD!

[matt40k]

Riiiiiiiiiiiiiight. For some unknown reason, SIMS pulls the domain\username from the logged on session as the SIMS username (specifically so) meaning that it's looking for usernames that can't exist in our scenario.

 

It uses the Windows token. Idea is the application will never prompt for your Windows password which could result in a man-in-the-middle attack and end up with your username and passwords being posted on pastebin along with tesco customers details.

[3s-gtech]

Makes sense. Seeing as it's a simple change in SIMS itself it's no hardship, even for 110 or so users.

[vikpaw]

It can do that already, as it has a variable in the config file that defines the SIMS path (so that it can be changed for 32 bit clients). If you point that to SIMSLoad instead of Pulsar, it should still work. In fact, due to its nature you could technically use it to launch any exe while first checking against AD!

This is quickly becoming marketable. ) Stop all production and quit your job, before you lose all IP rights. We can set up a new company called "My SaSO, Your Way", and blitz the market.

[SovietRussia]

This is quickly becoming marketable. ) Stop all production and quit your job, before you lose all IP rights. We can set up a new company called "My SaSO, Your Way", and blitz the market.

 

That means I would have to quit too! MY CODE *gollum*

[matt40k]

It's not a question of the complexity of the problem. Let me just break it down.

 

OK, so lets start at an odd starting point, the solution. If we, the community, create a tool that we release, we are going to reduce the security. We are, lets face it creating a man-in-the-middle attack, we do however have good intentions. Regardless, this is a security hole we are, on purpose introducing.

 

Now lets look at why we're doing it. I won't say why Windows logons are better than SQL logins, they just are, don't get me wrong SQL logins have a time and a place. They are brilliant for things like background tasks like B2B. We're doing it because we believe staff should re-authenticate to access SIMS. Question is why? Why should staff have to re-enter something they've already entered - after all teachers don't have to (legally) do data entry twice, why are we adding time and complexity to the situation. Are the staff logged on as a pupil? Surely not. Are they leaving their pc logged in or letting pupils using? Surely not. If the computer has SIMS installed then you can be fairly sure they have a export of sensitive information somewhere in the user documents. All it takes is a pupil or anyone for that matter to get hold of this document for your plan to fall apart. SIMS isn't the only thing you need to secure. Teachers generally have access to pupil work - if nothing more.

 

So, why are we doing this and not promoting locking your workstation? Seriously, login to SIMS in the morning, lock your machine when your not in front of it. Shut it down at the end of the day, how is closing SIMS every 5 mins better? Surely leaving it open is faster, even if just a few seconds then re-opening it all the time. If a pupil or someone else needs to use the machine, you switch users and SIMS will resume when they switch back. I've only ever heard 1 reason why I would even consider doing this.

 

Going back to the whole reason why I wouldn't do it, if you have a prompt, how will you deal with login failures - ie what's to stop a student keep try until AD locks the account out, pretty sure that's going to cause more chaos as everything stops working!

 

Any just my 2p, I know worse things that people believe is secure then a prompt window.

[GREED]

As much as I love a good start up... There are quite a lot of reasons this might not be a great idea... least of all it won't take much for Capita to add a few lines of code and completely kick the venture into touch...

[vikpaw]

SIMS has the trustedauto system, the benefit is that it stops them using a weak SIMS password, and it's one less set of credentials to remember, so you can enforce better password policies through Windows, and yes locking would help secure the whole system.

 

The slight weakness is that it does remove that barrier to entry which was there before. We have a full environment where people have to login to SIMS. What they do after and the poor practise is a separate issue. Easily mitigated by locking, true, but people don't and setting a policy, getting it agreed etc. is a pain. Not to say we shouldn't try.

 

All this does is ask them to login with the same credentials and so for situations as above, where they are rubbish at security, you have put in a barrier of sorts. It doesn't fix everything, but is a solution they can't argue with as it's no different to logging in like they did before except you've made the credentials the same. That is the benefit of SaSO. It's no different to implementing it on any other system, be it intranet, linked portal, any other internal or external system, that can link to AD.

 

It would be great if Capita did it, but when will that Change Request earn enough votes? This just does it for the schools that want it. You would have to declare in big bold letters that the by pass to the barrier is dead simple and so it's not a security implementation, but it is still useful. Granted, about as useful as taking registers during a fire! Sometimes people just want piece of mind.

 

If a student sees two scenarios one with auto sign in and one with a login prompt, they hopefully think the login method is a barrier and so be less likely to try and sneakily open it up if the teacher nips out or has to deal with something urgent (which could well bypass a lock your PC scenario anyway). Obviously, all the student hackers are on EG anyway, but that's besides teh point.

 

A student could do a lock out scenario on any PC, like they do to other students, without having to have the ldap tool.

As for Capita changing the code, all the system is relying on is the trustedauto mechanism they put in place works. Why would they stop that? Or want to prevent you from authenticating first.

 

I think it's a good idea, for this scenario. I'm not seriously suggesting it is marketed, come on, the bypass is as simple as typing Windows, then SIMS!

[matt40k]

Why would Capita spend time and money making the system LESS secure in order to add a false layer of security? The security token is MORE secure than passing your AD username and password to get a security token. It goes against everything Microsoft says.

 

Locking your workstation IS the way forward to secure your data. It is everyone who accesses the data responsibility to ensure they lock their workstation. It's not difficult, it's not long winded. It's simple. If they can't do that, they shouldn't have access to the data. Period.

 

Stop looking for workarounds, there aren't any. If it isn't policy, push it to become policy. If you're saying staff can't lock workstations then that is and will always be your weakest point regardless what software you implement or buy. It isn't IT problem, it's SLT's.