Jump to content

Recommended Posts

Posted
Man-in-the-middle would send the auth to a third party authentication before sending it back. Ours sends it to Kerberos, which is where it would go anyway. Essentially, it authenticates with AD twice rather than once, but I know you don't like the concept. I suppose similar could be achieved by requesting users re-auth the S: drive when they try to load SIMS, thereby not involving anything but NTFS and Kerberos...
Posted
Man-in-the-middle would send the auth to a third party authentication before sending it back. Ours sends it to Kerberos, which is where it would go anyway. Essentially, it authenticates with AD twice rather than once, but I know you don't like the concept. I suppose similar could be achieved by requesting users re-auth the S: drive when they try to load SIMS, thereby not involving anything but NTFS and Kerberos...

The password is passed via your app. User enters it into the app, then goes to AD, then passes the token to the user and runs SIMS. It's a man in the middle. Literally its in the middle of the diagram of how it works. Fine, it might not do anything wrong, but doesn't mean it can't be weaponized. Fine it's more secure then SIMS logins, but again, it's missing the point. Windows + L - lock your workstations.

 

PS: SIMS doesn't need an S drive (except for a few legacy bits for a 1-2 users). So again, S drive = security hole.

Posted
PS: SIMS doesn't need an S drive (except for a few legacy bits for a 1-2 users). So again, S drive = security hole.

 

Ooh, really? Would be nice to not have to map it if it's not necessary.

Posted
The password is passed via your app. User enters it into the app, then goes to AD, then passes the token to the user and runs SIMS. It's a man in the middle. Literally its in the middle of the diagram of how it works. Fine, it might not do anything wrong, but doesn't mean it can't be weaponized. Fine it's more secure then SIMS logins, but again, it's missing the point. Windows + L - lock your workstations.

 

PS: SIMS doesn't need an S drive (except for a few legacy bits for a 1-2 users). So again, S drive = security hole.

 

It does the job - it could be weaponised if the exe was hacked or swapped it's true. Only so much we can do. Agreed with Windows+L - we try to push this more and with Windows 10 we have finally enforced an inactivity lock on the workstations. I know S: isn't needed as such, but if you point connect.ini at it surely SIMS won't load without it? As in:

 

[sIMSConnection]
Redirect=S:\SIMS

Posted

Our connect.ini points at SQL rather than the drive, so we don't have much need for it anymore.

 

We have also been using SSO with SIMS for about 2 years now and as others have said, we just keep reminding staff about Windows+L, we also have a 10 minute timeout.

Posted

We only allow Trusted for admin offices where the person lives in their office all day and are very good at locking their PCs when they leave.

 

Classrooms or pastoral offices (year teams) etc are not allowed it.

Posted
@3s-gtech @jthompson like @KibosJ said, you just point your connect.ini directly at the server. No point having a drive just for a file. The only reason you use to do that was when you moved the server it was easier, but really, you'd just push it out via S3 nowadays. The legacy stuff is things like attendance letters, Nova-T etc, you can also use it for CTF and census files - but its the sort of stuff you don't want to give access to teachers\classroom :D
  • Thanks 1
Posted
I guess we just keep the mapping because our admin staff all use S: for things like EXAMIIN. Teachers get the mapping but it's hidden. Might get rid next time we update the server.
Posted
I guess we just keep the mapping because our admin staff all use S: for things like EXAMIIN. Teachers get the mapping but it's hidden. Might get rid next time we update the server.

 

We still have ours but it's G: here. We use permissions to restrict access to the sims folder. We use the drive to host other documents though, including the sims update files because every so often we get a laptop that has the update "deploying" through solus but doesn't actually do anything. So quicker to run the updates manually, easy to get to in the sims drive.

Posted
For those of you saying SSO is not more secure than having a separate password for SIMS you haven't seen the trick you can do with Task Manager to find the SIMS password obvs.

 

Open a SIMS module like T6, go to Task Man, enable the command line column. Oh looky! There's my password. Most likely for convenience this will be the same as the users network login.

 

Best to have a tight policy on locking screens I would recommend and have SSO

 

[ATTACH=CONFIG]45375[/ATTACH]

 

BTW megasecurepassword is obviously not my password for anything lol

 

This is one of the reasons we switched to SSO, being able to see the password in plain text is just.... >.< and just how insecure SIMS passwords are, the fact they aren't case sensitive too, how is it still like this?

Posted (edited)
Best to have a tight policy on locking screens I would recommend and have SSO

Capita recommend Windows authentication / SSO too...

 

www.edugeek.net/forums/mis-systems/165330-changing-preset-username-format-sims.html#post1415997

 

See also @pete's post further down the page...

 

  1. N+1 passwords = people writing them down.
  2. One decent password is better than two terrible ones
  3. SIMS access is curtailed as soon as a leaver's domain account is disabled, no need to manage accounts in two places.
  4. You can set password policies for a Windows domain login.
  5. SIMS-based logins leave the username and password in the clear (viewable in taskmanager with command-line column turned on) when launching SIMS components like exams organiser, leading to password disclosure to anyone with admin rights on the computer/terminal server they're using. Since SIMS has practically zero auditing unless money is changing hands, a user with admin rights on the computer can act as another user within SIMS.

Edited by Arthur
Posted
We use the same numbering system for staff logons and SIMS usernames so what I implemented last week was to get the SIMS to start automatically at log in to show the sign in box at startup. Feedback has been very positive. I understand pushing it to the SSO level though does fill me with the DPF (Data Protection Fear).
Posted
For those of you saying SSO is not more secure than having a separate password for SIMS you haven't seen the trick you can do with Task Manager to find the SIMS password obvs.

 

Open a SIMS module like T6, go to Task Man, enable the command line column. Oh looky! There's my password.

 

Nice! Thanks, best post so far :eek:

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...