My blog has moved!

You should be automatically redirected in 6 seconds. If not, visit
http://www.macadmincorner.com
and update your bookmarks.

Saturday, November 24, 2007

Leopard - Keeping the Guest Account Disabled

Much has been said about the new Guest account in Leopard, and how it's not as simple and secure as Apple makes it sound.

The Lame Leopard
Tuttle SVC

I think this is a good feature for what Apple probably intended, at home for friends and family members to "borrow" your Mac. But in a higher education environment, I don't like it too much. It's simple enough to just keep something disabled but our faculty and staff have admin rights of their own machines. I could see them turning on Guest access for their grad students or post-docs to use their machines, but then there is no accountability for any problems that occur or attacks that are launched from that machine. I would rather everyone use their domain account or even a local account that explicitly had to be created for that person(s).

There is however, a simple way to disable the Guest account. It's the same way we disable the root account.

dscl . -create /Users/Guest UserShell /usr/bin/false


This will keep the Guest account from logging in or even showing up in the Login Window (icon view). However, the Guest account will still be listed in the Accounts pane of System Preferences and will appear to be enabled (if enabled) but will not work. I'm hoping to find a way totally eliminate it but have not figured it out so far. I tried deleting the account with dscl which appeared to work, but when re-enabled in System Preferences, it just recreates the account. I also tried removing Guest.plist from /var/db/dslocal/nodes/Default/users.

What do you think about the guest account? Will you be disabling it? Have you found a way to totally nuke it? Leave your comments.

1 comment:

TheChris said...

Whenever we decide to deploy leopard to the machines I take care of, I will be disabling the guest account.

On my test machine I disabled it the same way you did and have yet to find a better way. Though I have spent more time beating my head against the active directory woes than anything else.

Saturday, November 24, 2007

Leopard - Keeping the Guest Account Disabled

Much has been said about the new Guest account in Leopard, and how it's not as simple and secure as Apple makes it sound.

The Lame Leopard
Tuttle SVC

I think this is a good feature for what Apple probably intended, at home for friends and family members to "borrow" your Mac. But in a higher education environment, I don't like it too much. It's simple enough to just keep something disabled but our faculty and staff have admin rights of their own machines. I could see them turning on Guest access for their grad students or post-docs to use their machines, but then there is no accountability for any problems that occur or attacks that are launched from that machine. I would rather everyone use their domain account or even a local account that explicitly had to be created for that person(s).

There is however, a simple way to disable the Guest account. It's the same way we disable the root account.

dscl . -create /Users/Guest UserShell /usr/bin/false


This will keep the Guest account from logging in or even showing up in the Login Window (icon view). However, the Guest account will still be listed in the Accounts pane of System Preferences and will appear to be enabled (if enabled) but will not work. I'm hoping to find a way totally eliminate it but have not figured it out so far. I tried deleting the account with dscl which appeared to work, but when re-enabled in System Preferences, it just recreates the account. I also tried removing Guest.plist from /var/db/dslocal/nodes/Default/users.

What do you think about the guest account? Will you be disabling it? Have you found a way to totally nuke it? Leave your comments.

1 comment:

TheChris said...

Whenever we decide to deploy leopard to the machines I take care of, I will be disabling the guest account.

On my test machine I disabled it the same way you did and have yet to find a better way. Though I have spent more time beating my head against the active directory woes than anything else.

Saturday, November 24, 2007

Leopard - Keeping the Guest Account Disabled

Much has been said about the new Guest account in Leopard, and how it's not as simple and secure as Apple makes it sound.

The Lame Leopard
Tuttle SVC

I think this is a good feature for what Apple probably intended, at home for friends and family members to "borrow" your Mac. But in a higher education environment, I don't like it too much. It's simple enough to just keep something disabled but our faculty and staff have admin rights of their own machines. I could see them turning on Guest access for their grad students or post-docs to use their machines, but then there is no accountability for any problems that occur or attacks that are launched from that machine. I would rather everyone use their domain account or even a local account that explicitly had to be created for that person(s).

There is however, a simple way to disable the Guest account. It's the same way we disable the root account.

dscl . -create /Users/Guest UserShell /usr/bin/false


This will keep the Guest account from logging in or even showing up in the Login Window (icon view). However, the Guest account will still be listed in the Accounts pane of System Preferences and will appear to be enabled (if enabled) but will not work. I'm hoping to find a way totally eliminate it but have not figured it out so far. I tried deleting the account with dscl which appeared to work, but when re-enabled in System Preferences, it just recreates the account. I also tried removing Guest.plist from /var/db/dslocal/nodes/Default/users.

What do you think about the guest account? Will you be disabling it? Have you found a way to totally nuke it? Leave your comments.

1 comment:

TheChris said...

Whenever we decide to deploy leopard to the machines I take care of, I will be disabling the guest account.

On my test machine I disabled it the same way you did and have yet to find a better way. Though I have spent more time beating my head against the active directory woes than anything else.