In windows you can use the runas command, which will attempt to authenticate with AD with the credentials you give it.
When trying to do something similar in linux, with pkexec for example, I get this error:
error changing to home directory /home/[email protected]
Which implies to me that this will only work if [email protected] has logged into this device previously.
What I am trying to do is verify that domain accounts can authenticate to this machine, while logged in to an RDP session as the local admin account.
pkexec is not really suitable, since it doesn’t prompt for the target user’s credentials in the first place – it only asks for “an administrator’s” credentials.
sudo machinectl login may be the most useful choice, as it would simulate a full logon through a local console (tty), from the interactive login prompt to a shell session.
Similarly, if the machine accepts SSH, you can ssh myuser@localhost – there is no loopback restriction like Windows has for RDP’ing back to the same host.
The closest functional equivalent to runas would be su – not sudo, not sudo su, but plain old su myuser.
The general “logging in” procedure of Linux consists of two parts: 1) retrieving user information from the ‘passwd’ name-service database, 2) calling PAM to authenticate the user and verify authorization. These can be tested individually:
getent (e.g. getent passwd myuser) would directly perform a user information lookup, i.e. verify that the AD or LDAP modules in /etc/nsswitch.conf are functioning.
pamtester (e.g. sudo pamtester login myuser authenticate acct_mgmt) would directly test the authentication configuration (i.e. /etc/pam.d modules) of the specified service; in this example ‘login’ is again the configuration used for console tty logins, while a graphical login might use the ‘gdm-password’ service or similar.
(Specifying ‘authenticate’ tests password auth, while ‘acct_mgmt’ does authorization checks – for example, SSH with a public-key login would do only the latter but of course not the former – but presumably you want to test both.)
If the AD membership is managed through Samba’s winbind service, wbinfo can be used to poke winbindd in various ways, e.g. wbinfo -a to test authentication through winbindd – although that would be tested via PAM anyway.
kinit (e.g. kinit -c /tmp/newcc user@REALM) can be used to test simply whether a KDC is reachable for obtaining a Kerberos ticket. (It doesn’t verify against the local system’s keytab like a real local logon would do, so it won’t catch e.g. “trust relationship” failures.)
1