Not knowing the password makes things complicated, but maybe the solution is: is it possible to temporarily blank out a user's password? (And afterwards reset it to whatever it was before.)
As a start:
First, get the login window to display. Just log out the current user, use fast user switching, or use SSH:
cd "/System/Library/CoreServices/Menu Extras/User.menu/Contents/Resources/"
sudo ./CGSession -suspend
Or, to switch to a specific user right away, which will probably show the login window (this suddenly no longer works on my 10.5 Leopard):
sudo ./CGSession -switchToUserID 501
What's shown now depends a bit on the System Preferences, but let's assume it's the users' icons and their names. To activate a name we'd have to type the first letters. Then, after Return, the password prompt shows. Alternatively one can select any name (like by pressing Arrow Down) and then press Option-Return to be prompted for both any username and its password. I don't know how one can tell which screen is shown, but let's save that for later...
So, to select the first (random) user name and press Option-Return, type a specific user name, hit Return, and type the password:
sudo osascript -e 'tell app "System Events"
key code 125
keystroke return using option down
keystroke "the username"
delay 1.0
keystroke return
delay 1.0
keystroke "the password"
delay 1.0
keystroke return
end tell'
The above shows some error, which as far as I can tell does not limit the usage:
osascript[285] : 3891612: (connectAndCheck) Untrusted apps are not
allowed to connect to or launch Window Server before login.
_RegisterApplication(), FAILED TO establish the default connection to
the WindowServer, _CGSDefaultConnection() is NULL.
Alternatively, use the language specific script from "Script the Login window through Apple Remote Desktop" (maybe one day the comments at that site will show a better solution):
tell process "SecurityAgent"
set value of text field 1 of group 1 of window 1 to "the username"
set value of text field 2 of group 1 of window 1 to "the password"
end tell
click button "Log In" of window 1 of application process "SecurityAgent"
But the main problem is: this still needs the password. However: obviously no password is needed when a user has a blank password. In fact, for blank passwords just clicking a user's icon is all that's needed. So, if sending keystrokes using AppleScript is acceptable, then maybe "all" that's left to figure out:
Is it possible to temporarily blank out a user's password, to allow for starting (or resuming) the session without knowing that password...?
Can one make the AppleScript error-proof? Like:
- How to tell if the login window is visible? (maybe
stat -f%Su /dev/console
can help, as that yields root
while the login window is displayed)
- How to tell which login window is shown? (Like: one showing icons and login names, or a dropdown list, or maybe only a password prompt if someone selected to switch to some specific user?)
- Get rid of the delays.
- What about that error message?
(A note for testing: when using Screen Sharing it seems that setting the preference When controlling computers: Encrypt passwords and keystrokes only also retains the connection when the login window is shown, or after a user has successfully logged in. When using Encrypt all network data then my Mac needs to re-establish the Screen Sharing connection each time a login is shown or a user is switched.)
You are looking to writing a specialized Credential Provider. I an not going to write one for you, not even for 5000 reps, but I can point you in the right direction.
The article Create Custom Login Experiences With Credential Providers For Windows Vista explains the basics of Microsoft's move away from the earlier GINA model. It develops a sample which demonstrates the new features via a hybrid credential provider that allows a user name, password, and domain name to be stored on a smart card, so that upon insertion of the card, the user is automatically logged on.
Microsoft also provides for download Credential Provider Samples, which include an overview document describing how to build them.
If you do intend to develop your Credential Provider, I suggest strongly to debug it inside a virtual machine, for obvious reasons.
Best Answer
A far as I'm aware there is no way to add a network user to the login screen. You could make the network account mobile and then it would persist but I'm not sure if that's what you want to do without the context.