AD Driver - syncing eDir password expiration date to AD?

Other than some really old KB articles from 2012, just wondering if this can even be done or how to deal with the situation I'm dealt.

eDir <-> eDir Vault <-> AD

Passwords, however, are synced only one way from eDir -> AD (there's no password driver installed on the AD DC).

For political, oh I mean, "security" reasons, the AD Default Domain policy regarding passwords needs to be changed to use MS Complexity and the Max Password age set to 90 and the Min. set to 1)

I've got the eDir NMAS stuff setup as "equivalent" as I can.

Now, we have a loopback driver that adjusts the TIME of the password expiration in eDirectory so that if you change the password, it adjusts the time (not the date) to 90 days at midnight.

Ie, if I change it today, it'll set to 3/20/19 at midnight.

Now, in AD of course, it sets the pwdLastSet to the actual date/time that the password was changed, so it'll be like, 12/20/19 @ 10:50 a.m.

So the issue that we've encountered in testing is that, the user will sit down to their PC and login with the Novell Client, which will (or used to) seamlessly login to AD. But you'll then get prompted by the MS Client to change your AD password (this depends on WHEN you login to the PC obviously), and you have to do that first before you can get the desktop and then change the eDirectory password.

I'm racking my brain to come up with any method that would sync the password expiration date/time to AD (and of course AD stores the value in some hideous format).

BUT, I'm now thinking, that even if that's is accomplished, we'd run into the same situation:
You'll login to eDirectory via the Novell Client, which will try to login to AD (so that you can actually change the password) but even if both passwords expire at midnight, you'll be prompted to change the AD password before you load up the desktop.

The only viable option I see is to not set AD to expire passwords every 90 days which won't fly (well it's not my decision, but I'm 99% certain the answer will be "no").

We could try to mitigate it via pre-emptive password change emails, but it seems that doesn't work reliably (from a cursory forum search), and knowing our users (we have another system that emails every 15 days prior to password expiration and I'd say at least 50% of the people don't pay attention to it).

But I'm open to ideas/suggestions that I can pass along.
  • Some details for you to consider.

    eDir stores Password Expiration Time in CTIME format. (Count of seconds
    since Jan 1, 1970).

    AD stores pwdLastSet in FILETIME format (Count of 100ns intervals since
    Jan 1, 1601).

    And thus expiration is calculated as pwdLastSet Expiration setting. If
    in the past, expired, if not active.

    You can only write 0 (must change on next login) or -1 (Never expire) to
    pwdLastSet.

    So short answer, writing to AD is not an option.

    PWNotify to warn people change passwords is pretty easy, but as you
    noted the issue is not the technology. People just ignore it.

    eDir when you expire gives you grace logins. AD once you expire locks
    you out.

    I forget, do you have AD Password filters? I.e. Do you get password
    changes FROM AD, or just eDir password changes sent to AD?

    You could consider setting the expiration 1 day apart.

    Say AD 90 days, and eDir 89. (Or 91 and 90).

    Then eDir will expire first and then AD. So they change eDir, it syncs
    to AD and resets their expiration time in AD again.


    On 12/20/2018 10:54 AM, kjhurni wrote:
    >
    > Other than some really old KB articles from 2012, just wondering if this
    > can even be done or how to deal with the situation I'm dealt.
    >
    > eDir <-> eDir Vault <-> AD
    >
    > Passwords, however, are synced only one way from eDir -> AD (there's no
    > password driver installed on the AD DC).
    >
    > For political, oh I mean, "security" reasons, the AD Default Domain
    > policy regarding passwords needs to be changed to use MS Complexity and
    > the Max Password age set to 90 and the Min. set to 1)
    >
    > I've got the eDir NMAS stuff setup as "equivalent" as I can.
    >
    > Now, we have a loopback driver that adjusts the TIME of the password
    > expiration in eDirectory so that if you change the password, it adjusts
    > the time (not the date) to 90 days at midnight.
    >
    > Ie, if I change it today, it'll set to 3/20/19 at midnight.
    >
    > Now, in AD of course, it sets the pwdLastSet to the actual date/time
    > that the password was changed, so it'll be like, 12/20/19 @ 10:50 a.m.
    >
    > So the issue that we've encountered in testing is that, the user will
    > sit down to their PC and login with the Novell Client, which will (or
    > used to) seamlessly login to AD. But you'll then get prompted by the MS
    > Client to change your AD password (this depends on WHEN you login to the
    > PC obviously), and you have to do that first before you can get the
    > desktop and then change the eDirectory password.
    >
    > I'm racking my brain to come up with any method that would sync the
    > password expiration date/time to AD (and of course AD stores the value
    > in some hideous format).
    >
    > BUT, I'm now thinking, that even if that's is accomplished, we'd run
    > into the same situation:
    > You'll login to eDirectory via the Novell Client, which will try to
    > login to AD (so that you can actually change the password) but even if
    > both passwords expire at midnight, you'll be prompted to change the AD
    > password before you load up the desktop.
    >
    > The only viable option I see is to not set AD to expire passwords every
    > 90 days which won't fly (well it's not my decision, but I'm 99% certain
    > the answer will be "no").
    >
    > We could try to mitigate it via pre-emptive password change emails, but
    > it seems that doesn't work reliably (from a cursory forum search), and
    > knowing our users (we have another system that emails every 15 days
    > prior to password expiration and I'd say at least 50% of the people
    > don't pay attention to it).
    >
    > But I'm open to ideas/suggestions that I can pass along.
    >
    >


  • geoffc;2492872 wrote:
    Some details for you to consider.

    eDir stores Password Expiration Time in CTIME format. (Count of seconds
    since Jan 1, 1970).

    AD stores pwdLastSet in FILETIME format (Count of 100ns intervals since
    Jan 1, 1601).

    And thus expiration is calculated as pwdLastSet Expiration setting. If
    in the past, expired, if not active.

    You can only write 0 (must change on next login) or -1 (Never expire) to
    pwdLastSet.

    So short answer, writing to AD is not an option.

    PWNotify to warn people change passwords is pretty easy, but as you
    noted the issue is not the technology. People just ignore it.

    eDir when you expire gives you grace logins. AD once you expire locks
    you out.

    I forget, do you have AD Password filters? I.e. Do you get password
    changes FROM AD, or just eDir password changes sent to AD?

    You could consider setting the expiration 1 day apart.

    Say AD 90 days, and eDir 89. (Or 91 and 90).

    Then eDir will expire first and then AD. So they change eDir, it syncs
    to AD and resets their expiration time in AD again.


    On 12/20/2018 10:54 AM, kjhurni wrote:
    >
    > Other than some really old KB articles from 2012, just wondering if this
    > can even be done or how to deal with the situation I'm dealt.
    >
    > eDir <-> eDir Vault <-> AD
    >
    > Passwords, however, are synced only one way from eDir -> AD (there's no
    > password driver installed on the AD DC).
    >
    > For political, oh I mean, "security" reasons, the AD Default Domain
    > policy regarding passwords needs to be changed to use MS Complexity and
    > the Max Password age set to 90 and the Min. set to 1)
    >
    > I've got the eDir NMAS stuff setup as "equivalent" as I can.
    >
    > Now, we have a loopback driver that adjusts the TIME of the password
    > expiration in eDirectory so that if you change the password, it adjusts
    > the time (not the date) to 90 days at midnight.
    >
    > Ie, if I change it today, it'll set to 3/20/19 at midnight.
    >
    > Now, in AD of course, it sets the pwdLastSet to the actual date/time
    > that the password was changed, so it'll be like, 12/20/19 @ 10:50 a.m.
    >
    > So the issue that we've encountered in testing is that, the user will
    > sit down to their PC and login with the Novell Client, which will (or
    > used to) seamlessly login to AD. But you'll then get prompted by the MS
    > Client to change your AD password (this depends on WHEN you login to the
    > PC obviously), and you have to do that first before you can get the
    > desktop and then change the eDirectory password.
    >
    > I'm racking my brain to come up with any method that would sync the
    > password expiration date/time to AD (and of course AD stores the value
    > in some hideous format).
    >
    > BUT, I'm now thinking, that even if that's is accomplished, we'd run
    > into the same situation:
    > You'll login to eDirectory via the Novell Client, which will try to
    > login to AD (so that you can actually change the password) but even if
    > both passwords expire at midnight, you'll be prompted to change the AD
    > password before you load up the desktop.
    >
    > The only viable option I see is to not set AD to expire passwords every
    > 90 days which won't fly (well it's not my decision, but I'm 99% certain
    > the answer will be "no").
    >
    > We could try to mitigate it via pre-emptive password change emails, but
    > it seems that doesn't work reliably (from a cursory forum search), and
    > knowing our users (we have another system that emails every 15 days
    > prior to password expiration and I'd say at least 50% of the people
    > don't pay attention to it).
    >
    > But I'm open to ideas/suggestions that I can pass along.
    >
    >


    Thanks Geoff,

    No password filters on the AD side, so it's one-way (eDir to AD) only (just the remote loader bit is running on the AD DC).

    Yes, MS seems to be the only directory that expires your password and locks you out and then you can't change it (completely opposite of almost everything else I've looked at). But that's MS for you, LOL.

    While setting the eDir lower than AD won't solve the issue, it should help mitigate it. Now, we'll have to see how much, but the only real way will be to throw it in Prod and see what happens.

    Thanks for the idea/suggestion and explanation.
  • geoffc;2492872 wrote:
    Some details for you to consider.

    eDir stores Password Expiration Time in CTIME format. (Count of seconds
    since Jan 1, 1970).

    AD stores pwdLastSet in FILETIME format (Count of 100ns intervals since
    Jan 1, 1601).

    And thus expiration is calculated as pwdLastSet Expiration setting. If
    in the past, expired, if not active.

    You can only write 0 (must change on next login) or -1 (Never expire) to
    pwdLastSet.

    So short answer, writing to AD is not an option.

    PWNotify to warn people change passwords is pretty easy, but as you
    noted the issue is not the technology. People just ignore it.

    eDir when you expire gives you grace logins. AD once you expire locks
    you out.

    I forget, do you have AD Password filters? I.e. Do you get password
    changes FROM AD, or just eDir password changes sent to AD?

    You could consider setting the expiration 1 day apart.

    Say AD 90 days, and eDir 89. (Or 91 and 90).

    Then eDir will expire first and then AD. So they change eDir, it syncs
    to AD and resets their expiration time in AD again.


    On 12/20/2018 10:54 AM, kjhurni wrote:
    >
    > Other than some really old KB articles from 2012, just wondering if this
    > can even be done or how to deal with the situation I'm dealt.
    >
    > eDir <-> eDir Vault <-> AD
    >
    > Passwords, however, are synced only one way from eDir -> AD (there's no
    > password driver installed on the AD DC).
    >
    > For political, oh I mean, "security" reasons, the AD Default Domain
    > policy regarding passwords needs to be changed to use MS Complexity and
    > the Max Password age set to 90 and the Min. set to 1)
    >
    > I've got the eDir NMAS stuff setup as "equivalent" as I can.
    >
    > Now, we have a loopback driver that adjusts the TIME of the password
    > expiration in eDirectory so that if you change the password, it adjusts
    > the time (not the date) to 90 days at midnight.
    >
    > Ie, if I change it today, it'll set to 3/20/19 at midnight.
    >
    > Now, in AD of course, it sets the pwdLastSet to the actual date/time
    > that the password was changed, so it'll be like, 12/20/19 @ 10:50 a.m.
    >
    > So the issue that we've encountered in testing is that, the user will
    > sit down to their PC and login with the Novell Client, which will (or
    > used to) seamlessly login to AD. But you'll then get prompted by the MS
    > Client to change your AD password (this depends on WHEN you login to the
    > PC obviously), and you have to do that first before you can get the
    > desktop and then change the eDirectory password.
    >
    > I'm racking my brain to come up with any method that would sync the
    > password expiration date/time to AD (and of course AD stores the value
    > in some hideous format).
    >
    > BUT, I'm now thinking, that even if that's is accomplished, we'd run
    > into the same situation:
    > You'll login to eDirectory via the Novell Client, which will try to
    > login to AD (so that you can actually change the password) but even if
    > both passwords expire at midnight, you'll be prompted to change the AD
    > password before you load up the desktop.
    >
    > The only viable option I see is to not set AD to expire passwords every
    > 90 days which won't fly (well it's not my decision, but I'm 99% certain
    > the answer will be "no").
    >
    > We could try to mitigate it via pre-emptive password change emails, but
    > it seems that doesn't work reliably (from a cursory forum search), and
    > knowing our users (we have another system that emails every 15 days
    > prior to password expiration and I'd say at least 50% of the people
    > don't pay attention to it).
    >
    > But I'm open to ideas/suggestions that I can pass along.
    >
    >


    Thanks Geoff,

    No password filters on the AD side, so it's one-way (eDir to AD) only (just the remote loader bit is running on the AD DC).

    Yes, MS seems to be the only directory that expires your password and locks you out and then you can't change it (completely opposite of almost everything else I've looked at). But that's MS for you, LOL.

    While setting the eDir lower than AD won't solve the issue, it should help mitigate it. Now, we'll have to see how much, but the only real way will be to throw it in Prod and see what happens.

    Thanks for the idea/suggestion and explanation.
  • kjhurni;2492875 wrote:
    Thanks Geoff,

    No password filters on the AD side, so it's one-way (eDir to AD) only (just the remote loader bit is running on the AD DC).

    Yes, MS seems to be the only directory that expires your password and locks you out and then you can't change it (completely opposite of almost everything else I've looked at). But that's MS for you, LOL.

    While setting the eDir lower than AD won't solve the issue, it should help mitigate it. Now, we'll have to see how much, but the only real way will be to throw it in Prod and see what happens.

    Thanks for the idea/suggestion and explanation.


    Your best bet is installing the password filters. Then let people change their password whenever. If you're allowing password changes in MAD, and *not* syncing that change up to eDir, you're going to run in to trouble anyway.

    MS warns you X days ahead of your password expiring, so your users will be getting "you need to change your password now before it expires".

    There used to be a fun race condition between the two clients changing the password during login, and the driver. Sometimes you'd get logged in to both eDir and MAD. Sometimes you'd get "wrong password" from MAD, because the MS client tries the one you entered, but the eDir client has already changed it and the driver synced it before the MS client got to the point of trying it.
  • In my experience (contrary to what you (kjhurni) state you found in the
    forums), the e-mail notification stuff is reliable., though maybe you
    meant, as you pointed out, the people side is the problem, and people are
    definitely unreliable in many things. There are people-ways to address
    that, of course: if the people ignore the month/week/three-day/last-day
    e-mail warnings about passwordchanges, and still need to use the helpdesk
    or IT admins to reset passwords, then you just charge them $5. See if it
    happens more than once.

    Ultimately, passwords should not reach the expired state. Grace logins
    are great, and I recommend them when you can, but notifications and
    proactive changes when not in a rush to do so (e.g. not when starting your
    day and you are forced to) is the only sane way to change passworsd while
    maintaining security. Enable the users, make it easy for them, and that
    means notifications, and then maybe have a $5 stick ready for those who
    are just stubborn.

    --
    Good luck.

    If you find this post helpful and are logged into the web interface,
    show your appreciation and click on the star below.

    If you want to send me a private message, please let me know in the
    forum as I do not use the web interface often.
  • > maintaining security. Enable the users, make it easy for them, and that
    > means notifications, and then maybe have a $5 stick ready for those who
    > are just stubborn.


    I was shocked at the cost of 2X4's when I had to buy some this fall.
    (Technically I bought 2X2 and 2X3's but same point, 2X4 has a better
    flat side for a nice wallop).


  • dgersic <dgersic@no-mx.forums.microfocus.com> wrote:
    >
    > Your best bet is installing the password filters. Then let people change

    their password whenever. If you're allowing password changes in MAD, and
    *not* syncing that change up to eDir, you're going to run in to trouble
    anyway.
    >


    1

    This is really the only decent solution.
  • Geoffrey Carman <geoffreycarmanNOSPAM@NOSPAMgmail.com> wrote:
    >
    > AD stores pwdLastSet in FILETIME format (Count of 100ns intervals since
    > Jan 1, 1601).
    >
    > And thus expiration is calculated as pwdLastSet Expiration setting. If
    > in the past, expired, if not active.
    >


    The expiration period does not have to be the same for entire domain. One
    can have fine grained password policies that affect a subset of users.

    All in all, this becomes a mess to sort out/emulate/replicate in another
    system.

    Iâ€Tmd enable password sync in both connected systems and try to harmonise the
    password restrictions as much as possible. Then rely on password expiration
    notifications to minimise helpdesk calls.
  • alexmchugh;2492881 wrote:
    Geoffrey Carman <geoffreycarmanNOSPAM@NOSPAMgmail.com> wrote:
    >
    > AD stores pwdLastSet in FILETIME format (Count of 100ns intervals since
    > Jan 1, 1601).
    >
    > And thus expiration is calculated as pwdLastSet Expiration setting. If
    > in the past, expired, if not active.
    >


    The expiration period does not have to be the same for entire domain. One
    can have fine grained password policies that affect a subset of users.

    All in all, this becomes a mess to sort out/emulate/replicate in another
    system.

    Iâ€Tmd enable password sync in both connected systems and try to harmonise the
    password restrictions as much as possible. Then rely on password expiration
    notifications to minimise helpdesk calls.


    In Win2008 MS introduced ms-DS-User-Password-Expiry-Time-Computed (LDAP attribute name: msDS-UserPasswordExpiryTimeComputed) (Contains the expiry time for the user's current password.)
    https://docs.microsoft.com/en-us/windows/desktop/adschema/a-msds-userpasswordexpirytimecomputed

    It can make life a little bit easy.

    The PowerShell script below will list you Display Name and Password Expiry Date of all AD users.
    Get-ADUser -filter {(Enabled -eq $True) -and (PasswordNeverExpires -eq $False)} -Properties DisplayName, msDS-UserPasswordExpiryTimeComputed | Where-Object {$_.DisplayName -ne $null} | Select DisplayName,@{Name="ExpiryDate";Expression={([datetime]::fromfiletime($_."msDS-UserPasswordExpiryTimeComputed"))}}
  • alexmchugh;2492880 wrote:
    dgersic <dgersic@no-mx.forums.microfocus.com> wrote:
    >
    > Your best bet is installing the password filters. Then let people change

    their password whenever. If you're allowing password changes in MAD, and
    *not* syncing that change up to eDir, you're going to run in to trouble
    anyway.
    >


    1

    This is really the only decent solution.


    Yes, I agree, however, they won't let us do that, so we're kinda stuck with what we have.

    Although I see that there's an updated Novell Client that you can enable the advance password change notification (I haven't tried it yet), so that may be more "in your face" than the notification email and possibly annoy the users ('encourage') to make them actually proactively change their password.

    Although I like Aaron's idea of the $5 beater stick.