[EvanAnderson]

You could do this right now w/ w/ a "Startup Script" or using Group Policy Preferences. The authorization to logon is, presumably, tied to the "User Right" to logon interactively and shouldn't have anything to do w/ the SSH server (since it's just userland).

[zrm]

Authorized keys in the context of ssh means the ability to logon without password using public key authentication.

Now that I'm thinking about this, anybody know how they're doing public key authentication for domain accounts at all? If you don't use a password to logon, how are you supposed to get a Kerberos ticket to use domain network resources?

[EvanAnderson]

Yeah-- that was a pretty braindead response. I was thinking "authorized hosts". Now I feel silly.

re: the public key authentication for domain accounts - They're calling the undocumented NtCreateToken() API in "win32auth.c". They don't need a password to create a token going that route. They've also got an LSA Security Package to do the key validation inside LSA. I'm looking at this very quickly, but I'm not seeing that they extended the AD schema to store the public key in the user's AD account. That would be the best way to handle it, ultimately-- just have the DCs use that SSH-LSA Security Package to authenticate the users against the public key stored in their AD account.

[brazzledazzle]

I think you can use "klist" with "get":

https://technet.microsoft.com/en-us/library/hh134826.aspx?f=...

[dijit]

On Linux you can still execute 'kinit' to power up and get a ticket. (Via password).

I'm sure there will be something similar. Unless authentication in the first place cannot be decoupled from ssh login, then your key would have to be able to grant you a Kerberos ticket.