1

I'm asking a client why some password parameters are not defined in the Linux OS level and he's saying that, internally, Linux and Windows complexity and timeout settings are different. If they set the Linux password complexity/timeout settings, then there is potential that the Linux system will ask for a password change before Windows AD will, AND/OR Linux password complexity will be different to Windows complexity and the user will change their password to something that is valid in Linux, but is not valid in Windows and therefore gets locked out their account.

Is this true? Can't they just set up the password settings of OS and AD the same way (i.e account lockout, idle session timeout, complexity) to avoid this?

  • 2
    What makes you think that two completely different operating systems would have exactly the same settings and can be made to work in exactly the same way? – Joseph Sible-Reinstate Monica Aug 26 '19 at 1:03
  • I think that you are missing some details here. why are you comparing the 2 systems? Are they linked? Are passwords shared? Is there a federation? – schroeder Aug 26 '19 at 12:21
  • If they are loosely linked, and credentials are passed from one to the other, then mis-matched settings will create a mis-match. If they are independent systems, then everything your client said does not apply. If they are linked, then you need to describe the linkage. – schroeder Aug 26 '19 at 12:25
  • There exist software products that do precisely this; synchronize passwords across unlike systems. It is not an inherent feature of either product, and thus depends on how much you want to spend (time and money) to fix the problem. – DaveM Aug 26 '19 at 13:11
0

The authentication systems in Windows AD and Linux are completely different. Windows AD uses Kerberos, which uses various "tokens", "tickets" and keys to establish identity. Linux systems can use Kerberos authentication if there is a Pluggable Authentication Module (PAM) to support it, but more likely they continue to use their native authentication system which is as Scottie H described.

It is, of course, possible for the most part to set the various parameters (password complexity, expiration, etc.) the same in both systems, but finding all the right levers to push and knobs to twist on two disparate systems may be an exercise in futility, and there may be certain combinations of parameters which may be mutually incompatible across the two platforms.

I would also consider that passwords themselves are rapidly outliving their usefulness, and multifactor authentication (MFA) is the secure way to go. However, implementing MFA cross-platform is fraught with the same sorts of incompatibilities unless the infrastructure (e.g. RADIUS for hardware or software token authentication) is carefully chosen with both platforms in mind.

0

The client is using Active Directory (AD) as a central authentication. As such, there should be no password policy configuration on either Linux or Windows clients. That should go only on the AD.

internally, Linux and Windows complexity and timeout settings are different.

Kind of agree, if we were talking about local accounts (which we are not).

If they set the Linux password complexity/timeout settings, then there is potential that the Linux system will ask for a password change before Windows AD will

The AD stores the time of the last password change for the account. The AD global object stores the number of days (well, microseconds) after which the passwords expire.

So, the actual time when the passwords expire is known to both Windows and Linux ()and it's enforced by the AD, anyway). You might have Windows encouraging you to change your passwords since -made up numbers- 7 days before expiration and Linux only from 5 before (which you can ignore), but that's not what is being stated here, and isn't that relevant.

Moreover, if the password was changed earlier than required, that's perfectly fine, too. That resets the password expiry, it doesn't matter if there were 3 days left or 30. So I don't see why that would be a problem, either.

Linux password complexity will be different to Windows complexity and the user will change their password to something that is valid in Linux, but is not valid in Windows and therefore gets locked out their account

No. When you change the AD password from Linux (eg. with smbpasswd, but passwd may be hooked to do the network password change), it sends the old and new passwords to the AD. It is therefore the AD the one that needs to accept it.

It is true that you may easily set some passwords from Linux that are not (easily) usable from Windows due to different keyboard settings (you could set the password a character that you can't type from Windows login screen, oops!), but Windows itself would be happy to accept it (as shown for instance when providing it through RDP). But that would be completely unrelated to complexity rules.

Also note that should you end up in such a situation, you can go back and change the password from Linux to something accepted and typable from Windows.

Is this true? Can't they just set up the password settings of OS and AD the same way (i.e account lockout, idle session timeout, complexity) to avoid this?

You are mixing a few different values. Idle session timeout would be indeed a local configuration. But the password settings wouldn't be handled locally (in nsswitch terms, by the passwd/compat provider) but from the AD, where most settings are configured and stored, and which is enforcing the status of the different accounts (if there were too many bad password attempts, the AD will refuse a bind with those credentials, no matter if the client verifies itself the badPwdCount or not¹).

¹ Exception: if a program was manually checking the provided password against the password hash, it would need to do itself all those AD checks. I don't consider it a good practice when the AD can do it for you, though, and you would probably need to go out of your way in order to have the AD disclose the password hash to the application.

It could be that the client is actually using separate accounts. An AD from which Windows clients authenticate, and local accounts in Linux. Then, some of the above confusion could happen. But they would actually be different accounts! (even if they use the same username, and have users normally change the passwords at the same time) In that case, the right thing would be to integrate the Linux clients in the AD, instead of using separate accounts. It is more complex to setup than creating local unconnected users, and most Linux users -not being on a corporate environment- usually don't go that route, but it's perfectly doable and on an environment such as the described one it's the right move.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.