Join Log in
Score:0
avatar Server

Does using an SSH jump host count as a login?

lc flag
LHMathies

I have asked for a service account from the AD guys that will let me use a specific server as an SSH jumphost (using ProxyJump), and of course I've set up an SSH private key for the purpose. The jumphost itself is running SSSD to authenticate users against the AD.

However, I have been warned that if the AD LastLoginTimeStamp attribute on the service account gets too old, the account will be purged. So the question is, will whatever SSSD does on behalf of the pam modules that SSHD activates for a tunnel-only login (no user command) actually update that time stamp? Looking up the user's groups with LDAP is presumably not enough, but what is? I can do the research on the Linux side to see what SSSD does, but I don't have easy access to the AD side to check if the time stamp updates.

92
0 + 0
ssh
Semicolon avatar
jo flag
Semicolon
Your timestamp will never update as long as you continue using public key authentication; you are not performing an account logon to AD. Use a password or GSSAPI/Kerberos and you'll see the timestamp increment.
0
Reply
Score:1
Jevgenij Martynenko avatar Server
us flag
Jevgenij Martynenko

In theory AD attribute lastLogonTimestamp is updated after one of the following:

  • interactive or network NTLM logon
  • LDAP simple bind

So this will depend on the mechanism used by the service (sorry, I have no experience with JumpHost or SSSD).

In my personal experience some services integrated with AD via LDAP use their service account successfully, but attribute value is not updated. I didn't have a chance to figure out why exactly this happens, but since it's a different story with every service, I think the only safe bet is to try and see for yourself. The attribute should be update at once during first login. Afterwards, the value can be up to 14 days late.

Please check attribute technical spec for more information.

Couple of things to make sure in case of troubleshooting:

  • AD has a history of bugs when the attribute lastLogonTimestamp isn't updated when it should. Last one I remember was patched 3 years ago (KB4457127)
  • AD attribute msDS-LogonTimeSyncInterval must be non-zero. Otherwise lastLogonTimestamp will not be updated

Hope this helps

0 + 0
lc flag
LHMathies
This answers my question to the extent that I will not investigate further, but just set up an expect script in cron to login with a password. (Short attention span, waiting two weeks to see results is the recipe for forgetting). One factor is that I know that simple bind was disabled in our AD and SSSD is using Kerberos, so we are not in any of the two cases that are supposed to update.
1
Reply
lc flag
LHMathies
Also the timestamps clearly do update for normal logins, since the AD admins do use it to purge inactive accounts.
0
Reply
mx flag
strongline
> AD attribute msDS-LogonTimeSyncInterval must be non-zero. Otherwise lastLogonTimestamp will not be updated Doubt the correctness of this statement. I checked multiple environments, all have this attribute not set, I assume this is default and the 15 days interval follows.
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.