Guest User!

You are not Sophos Staff.

This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

SG6 almost bricked my mac! I figured out how to unbrick!

SG6 has a few issues still, it's a good product, especially free as in beer but under certain circumstacnes you can get locked out of your mac.  I had an issue where i could use the POA but the user login screen wouldn't appear, it just showed a textured mac background, no login window.  I had the right settings as far as I knew (yes I read the KB article on which login mode to use, it was set to use name and password, I tried both after fixing it and it can happen on both just most often with use name and password in the system logon preferences).  I didn't run into this problem until messing with all the settings repeatedly, if I only messed with it a few times I didn't run into this until I tried to simulate user abuse so take all this with a grain of salt.  SG6 for mac is good and simple to use. FYI you have to fix this with an automaited log on to be able to restore GUI logon access and reset the system. 

I figured out how to fix this, now because single user mode is a limited environment by design it’’’’s not going to have mounted kernel access and a lot of other stuff like USB automounting doesn't work.  Also your filesystem is in read only mode and you don't have access to the kernel so you can't turn POA on or off, only SSO.

Enter single user mode with command +s (you have to press this immediately after pressing the enter key, the time window to get this done with POA is SHORT! Only a few milliseconds)

Check the filesystem for errors and fix them (important if you have config issues of any kind while using volume encryption!):

Fsck –fy

Mount the root partition in read-write mode:

Mount –t update /

turn SSO off:

sgadmin --disable-sso

Determine the username and UID of the user you want to set autologin for

ls –n /users

This will display the user folders along with their username on the right, and the UID of the user which will be the second column of numbers, MAC like most unix systems starts the first UID at 501.

Once you have that you can use the defaults utility to overwrite the login window configurations with the expected username and UID like so:

/usr/bin/defaults write /Library/Preferences/com.apple.loginwindow autoLoginUser yourusername
/usr/bin/defaults write /Library/Preferences/com.apple.loginwindow autoLoginUID yourUIDnumber

REBOOT!

FYI depending on how badly mangled your loginwindow config is it may or may not work automatically and you may still get prompted for the password, you can reset these to the values you want in the system preferences GUI menu now.  This was tested and solved my problem on OS X 10.7

This will require more testing but if anyone runs into an issue that breaks the mac logon system this is the ONLY way to fix it in and it has to be in single user mode that I've found so far.  Backing up your kernel and authentication files with SG6 won't fix this.

:22911


This thread was automatically locked due to age.
  • Hello _JOEL_,


    first of all many thanks for your forum post regarding this and the detailed steps you have provided.

    If not already done, please would you open up a support case with all steps on how to replicate this issue.


    But I will also forward this internally.


    Regards,Tim

    :22931
  • Already done, Bob in support already got pushed the case, he has some more detailed steps but it's definately an issue having to do with multiple users and one of them gets out of sync with the system somehow with SSO even after changing user information via the recoomended methods.  It's difficult to recreate and won't affect most mac users, I have only recreated this twice, both by accident.  Man I had to dig deep into some developer docs to find the answer to this one.

    To anyone reading this post please take the issue with a grain of salt (i.e. in moderation).  This is a difficult to recreate issue and most users won't experience it, SG6 for mac is still a good product.  I was simulating extensive user abuse of the system so there may be more underlying factors here than what I directly did mysel as a general disclaimer.  FYI this sort of testing is required for the hopitals I contract for because if it can happen it WILL in this type of environment, it's just a matter of when.  Looking forward to the next SG6.X release for MAC.

    :22949
  • I have this issue also and what I founf to fix it is a little easier. As long as the system in on the network you can SSH into it and just run the sgadmin --disable-sso to turn sso off. Then send a reboot command to it and it will be OK.

    just make sure the accounbts are set up correctly before turning it back on.

    :23245
  • That's interesting, I had tried that and it didn't work for me, to make a long story short I tried everything I knew to do remotely via SSH and I couldn't get anything to work.  I suppose maybe I missed something or there were extenuating circumstances, I was working with an unlcean system at the time and I couldn't get the login screen back no matter what I did in multi-user mode.  Also SSH is not enabled by default on our MAC images so it wouldn't be an option company wide to use to fix things.

    At least SOPHOS has confirmation there are issues with SSO that other customers have experienced.  Thanks for the feedback mate!

    :23263
  • Yes you do need ssh enabaled. I have it set for all out macs as we use it to manage them.

    I don't think Sophos did any real testing on this at all. I could understand the issues if they called it a beta which it sould be. This should have never been released as an update as it has multiple issues.

    :23549
  • I did the same thing. Was testing POA+SSO on one machine, then tried it on another. But wanted to try without POA and didn't change SSO. Had this unsettling feeling, which I quickly found out the reason after rebooting.

    Connected via ssh, disabled SSO, rebooted and it was fine. Obviously without ssh on, it will be a bit harder. But, we always have ssh on in case the GUI gets hosed plus it can be a lot faster for maintenance than using ARD.

    Wouldn't call this a big problem as users can't change this. But would be nice to have a message when setting the commands warning of this situation.

    Very minor nitpick: Change the POA CLI command to be consistent with the others: sgadmin --disable-poa, --enable-poa. 

    Been using SG for a couple of weeks and pretty happy with it.

    :23661
  • The big issue why I had to log in via single user mode was because SSH was disabled by default on our images.  In single user mode you have limited access to kernel resoureces and other services, also some things just aren't loaded, I couldn't turn POA off and even though I was able to turn SSO of that didn't fix the issue. I could get past POA but not log in.

    :23737