Welcome Serena Central users! CLICK HERE
The migration of the Serena Central community is currently underway. Be sure to read THIS MESSAGE to get your new login set up to access your account.
Knowledge Partner
Knowledge Partner
1114 views

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.
Labels (1)
0 Likes
10 Replies
Knowledge Partner
Knowledge Partner

Re: AD Driver - syncing eDir password expiration date to AD?

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.
>
>


0 Likes
Knowledge Partner
Knowledge Partner

Re: AD Driver - syncing eDir password expiration date to AD?

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.
0 Likes
Knowledge Partner
Knowledge Partner

Re: AD Driver - syncing eDir password expiration date to AD?

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.
0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

Re: AD Driver - syncing eDir password expiration date to AD?

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.
0 Likes
Knowledge Partner
Knowledge Partner

Re: AD Driver - syncing eDir password expiration date to AD?

> 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).


0 Likes
Knowledge Partner
Knowledge Partner

Re: AD Driver - syncing eDir password expiration date to AD?

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.
Alex McHugh - Knowledge Partner - Stavanger, Norway
Who are the Knowledge Partners
If you appreciate my comments, please click the Like button.
If I have resolved your issue, please click the Accept as Solution button.
0 Likes
Knowledge Partner
Knowledge Partner

Re: AD Driver - syncing eDir password expiration date to AD?

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.
0 Likes
Knowledge Partner
Knowledge Partner

Re: AD Driver - syncing eDir password expiration date to AD?

kjhurni;2492901 wrote:
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.


If a system is poorly designed, but working correctly according to that design, you're doomed to the misery of living with it. Maybe you can at least turn it in to a profit centre, $5 at a time.
0 Likes
Knowledge Partner
Knowledge Partner

Re: AD Driver - syncing eDir password expiration date to AD?

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’d 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.
Alex McHugh - Knowledge Partner - Stavanger, Norway
Who are the Knowledge Partners
If you appreciate my comments, please click the Like button.
If I have resolved your issue, please click the Accept as Solution button.
0 Likes
Knowledge Partner
Knowledge Partner

Re: AD Driver - syncing eDir password expiration date to AD?

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’d 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"))}}
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.