Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Disabling a User's Login Ability System
I needed a way to keep a user from logging in to the computer via any method. In OS 9, it was just a matter of unchecking a box, but now in OS X there is no easy way--until now. I knew that changing the password to "*" would make this happen but I didn't want the original password to go away. After testing, I found out that OS X only reads the first value of the passwd property no matter how many values there are. I inserted a value of "*" to the beginning of the passwd property of that user. Now the user is completely unable to login. To restore the account, simply remove that new value.

To find out how to do this, read on...

We can use the command line or NetInfo Manager to accomplish this. I will show the commands via the Terminal command line because it is easier for me.
To disable the account, we insert the *:
sudo niutil -insertval . /users/user-in-question passwd '*' 0
And to re-enable it, we remove the *:
sudo niutil -destroyval . /users/user-in-question passwd '*'
I have a couple of friends who don't know their way around OS X but they needed this functionality. I wrote them a simple AppleScript to toggle between these two settings. I won't go into the details of the script for that is beyond the scope of this hint. The only work on your part, is to paste this code into Script Editor being sure to change "user-in-question" to the user you want to disable. Save it as an application and you now have an easy way to toggle a user's login!
--begin AppleScript
--change user-in-question to the short name of the user you want to toggle on and off
set user_name to "user-in-question"
--the rest of this doesn't need to be edited but feel free if you want to
set passwd to do shell script "niutil -readval . /users/" & user_name & " passwd 0"
set full_name to do shell script "niutil -readval . /users/" & user_name & " realname 0"

if passwd is "*" then
 set action_word to "Enable "
 set ni_command to "-destroyval"
 set other_word to "now"
 set action_word to "Disable "
 set ni_command to "-insertval"
 set other_word to "no longer"
end if

display dialog action_word & full_name & "'s Login?" buttons {"Yes", "No"} default button 2 with icon 2
if the button returned of the result is "Yes" then
 do shell script "niutil " & ni_command & " . /users/" & user_name & " passwd '*' 0" with administrator privileges
 display dialog full_name & " can " & other_word & " log in." buttons {"OK"} default button 1 with icon 1
 display dialog "No changes were made." buttons {"OK"} default button 1 with icon 1
end if
--end AppleScript
[Sudo Editor's Warning: Please be comfortable with the command line before you try this hint. The user you are tring to alter login abilities for might not be able to log back in if you make a mistake.]
  • Currently 1.00 / 5
  • 1
  • 2
  • 3
  • 4
  • 5
  (2 votes cast)

Disabling a User's Login Ability | 15 comments | Create New Account
Click here to return to the 'Disabling a User's Login Ability' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Application user control?
Authored by: babbage on Mar 10, '02 11:46:43PM
Is this a way to control which "virtual" users are displayed at login? In order to support some of the background processes I have going on my Mac -- special accounts for Apache, MySQL, PostgreSQL, etc -- and some of these are blocked from the login screen while others show up. I don't want anyone logging into my system as Postgres, but I can't figure out how to block that account from performing system logins. (I wouldn't mind keeping process based logins -- "su postgres -c command" -- but if this had to go I could live without it.)

I know that OSX doesn't use the same /etc based text system that a lot of older Unixes do, but rather that it has NetInfo working (and apparently requests for e.g. /etc/passwd end up getting channeled through the NetInfo databases), so I've been poking around there and only getting confused by what I've found. I can find all the user accounts, and each of them has a list of properties (from around half a dozen to maybe 20 or so), but I can't tell what properties are working in such a way that logins are blocked for some but allowed for others. Maybe this password trick will help -- I didn't want to mess around with that field blindly because I don't want to trigger any nasty side effects...

[ Reply to This | # ]

This would work for you
Authored by: Xeo on Mar 11, '02 01:07:07AM

This method would work for you as a way to disable the accounts. You could use the AppleScript I made to toggle these users on and off. When off, there is no way to login as these users. It's probably not what you need, though.

Most people just use NetInfo Manager to change the "passwd" property of the daemon users to "*" which disables them permanently (until you used sudo or something to regive it a password). That is probably the best way to go since there really isn't a good reason to log in as these users. You can use sudo if you need to run things as them by hand.

This method uses the same concept of changing the passwd to "*" but still keeps the old password around so it's easily "turned back on". You don't really need that functionality for a daemon user.

[ Reply to This | # ]
Don't display user accounts
Authored by: Jaharmi on Mar 11, '02 02:47:29PM

If you change the user account to have a UID of less than 500 (as I recall), then that user account should not be displayed in the picture-button version of the loginwindow. I haven't done this, so I'm not sure of the procedure ... of the top of my head, it would probably require work in NetInfo Manager and chown at the Terminal prompt.

However, if you really want that security, you might just want to switch to use the other version of loginwindow, which just displays blank username and password fields.

[ Reply to This | # ]
Don't display user accounts
Authored by: babbage on Mar 12, '02 11:41:20AM

Well, I'm not *really* worried about locking it down that badly -- it's a home computer, and 99% of the time my fiance & I are the only ones around the computer, nevermind using it. I just want it so that we have pushbutton login access for her, me, and the guest user accounts, and I want to disable login at that level for all the daemon accounts. Very rarely it's useful to be able to switch to one of those user accounts while logged in as myself (mainly for issuing commands as the postgres user), but for the most part I want to make them be dormant. Setting the password to '*' worked, though the UID<500 trick sounds like it's on the right track too (yes, this is easy to do in NetInfo Manager, thogh you could probably use the ni* commands too).

[ Reply to This | # ]
Authored by: vonleigh on Mar 11, '02 03:34:56AM

One question, can the user still log in through ftp? I'm looking for a method that will _not_ allow the user to log into the computer via shell, but will allow him/her to ftp to their account.


[ Reply to This | # ]
Authored by: jkusnier on Mar 11, '02 06:58:50AM

try changing their shell to /usr/bin/true i've never tried this on os x, but it works on every linux distro i've ever used

[ Reply to This | # ]
Authored by: Moo0 on Mar 11, '02 10:33:00AM

I've changed it to /dev/null which works too :)

a comment on that: i heard proftpd requires a valid shell. Here, using slack 8, we set it to /etc/ftponly - but I have no idea wether this is linux/proftpd-only.

[ Reply to This | # ]
Authored by: a1291762 on Mar 11, '02 04:46:36PM

The "Unix way" would be to set the user's shell to /sbin/nologin. You may need to add that to /etc/shells if your ftpd requires users to have a valid shell.

/sbin/nologin is better than /usr/bin/true and /dev/null because it notifies the user that they can't login by writing a message when they log in.

[ Reply to This | # ]
adding a * in front of the encrypted pw should be enough
Authored by: betabug on Mar 11, '02 04:05:32AM
I didn't want the original password to go away.

Actually accroding to Unix wisdom, just inserting a "*" in front of the encrypted password
should be enough. The "*" is outside of the range of characters that the crypt() library uses
to encrypt passwords. That way the users password cannot be checked, result: No login possible.

When you want to re-enable login with the same password, you just remove the "*" in front of
the password. I haven't tryed it on Mac OS X, but this would be the Unix way of doing it. Also as
an additional measure of security set the shell to "/sbin/nologin".

[ Reply to This | # ]
adding a * in front of the encrypted pw should be enough
Authored by: babbage on Mar 11, '02 11:43:08AM
Ok, so just to clarify what you're saying here, if a user's hashed password is, say, Q2w3E4r5T6y, then you can disable that account by simply changing it to *Q2w3E4r5T6y, and it can be restored by changing it back to Q2w3E4r5T6y? I didn't realize that hashed passwords could be tampered with at all without damaging them, so I've always made a point of leaving /etc/passwd alone for the most part (read-only usage only, no editing except by shell tools like "passwd").

So would something like this be considered the canonical way to disable logins on OSX? I know that some things are different here than on other Unixes, and I'm trying to get in the habit of doing things the OSX way...

[ Reply to This | # ]

adding a * in front of the encrypted pw should be enough
Authored by: a1291762 on Mar 11, '02 04:41:42PM

If you modify the encrypted password, chances are it'll be very hard (if not impossible) to guess what the unencrypted version will be. So by adding a char to the beginning (especially a char that isn't valid in an encrypted password) you're changing the unencrypted password to something that the user won't be able to guess.

When you remove that character, the password will be the same as it originally was. There's no "timestamp" or other such information in the password, it's just an encrypted phrase.

[ Reply to This | # ]
re: adding a * in front of the encrypted pw should be enough
Authored by: Xeo on Mar 11, '02 09:15:00PM

True, adding a * would do this as well, but I think the method I use is much more elegant. To me, it's a lot easier to insert a value then destroy that value instead of actually tampering with the password itself.

I actually toyed with the idea of prepending a * but the method to take that * away is more risky than inserting a separate value that can be destroyed.

[ Reply to This | # ]
Be careful with this and ssh/rsh!
Authored by: miketja on Mar 11, '02 05:17:55PM

Simply modifying the password to something that no longer works is normally fine, but be careful of login methods that do not check the user's password. If you have rsh enabled, and the user has a .rhosts file, they can login directly to your machine without specifying a password -- rsh will not check /etc/passwd if .rhosts is valid.

Similarly with ssh, if RSA/DSA key authentication is enabled (which I believe it is in OSX by default). If the user has an authorized_keys or authorized_keys2 file in their ~/.ssh directory, they can ssh into the OSX box using RSA/DSA keys rather than a password. Like rsh, simply changing the entry in /etc/passwd (or in NetInfo) doesn't stop this.

In short, changing a user's password will only stop them from logging in if their password is actually checked by the system at login time.

[ Reply to This | # ]
Okay, usefull, but what about ftp-only accounts?
Authored by: tsaar on May 02, '02 02:03:43PM

Okay, so I can temporarily disable login ability whenever I want. That may be usefull in some situations.

Unfortunately, this also makes this particular user unable to ftp in.
(at least when I do it.....)

I've read some tips here on how to enable anonymous ftp, but that is not what I want.

I would like to make an 'ftp only' account: password is checked, but user cannot login to aqua (nor via ssh, figured that one out allready using /dev/null for shell, works like a dream)

Any tips on how to do this with a minimum amount of those confusing chmod commands? (btw- is there a graphical utility that lets me do that? I'm comfortable with the command prompt but chmod drives me crazy)



[ Reply to This | # ]
Disabling a User's Login Ability
Authored by: glubzor on Nov 14, '03 05:25:06PM

This hints does'nt work in panther for new accounts or for old accounts after password modification. This is because the default authentification method has been changed to ShadowHash and the password is no longer stored in netinfo database (you will find "********" string instead).
This is tricky because it seems to work as the user name disappears from login window. But the user can still login using alt + down arrow and then return to enter his login name. He may also use fast user switching menufrom an other account, if it is enabled.
The best way seems now to modify the authentication_authority property to ";DisabledAccount;".
Useful information at

[ Reply to This | # ]