matt4 Trusted Contributor.
Trusted Contributor.
1542 views

Distribution Password Not Being Set

I have a site that I'm in the process of upgrading to eDir 9.0.4 (can't go to 9.1 yet due to IdM). They are mostly on 8.8 SP8 FTF 11. There are 10 servers in the tree and I've upgraded two of them to eDir 9.0.4. Everything seems fine, but a really odd problem was noticed.

They have IdM so they noticed that when new users were created, they were not getting sync'd to AD. I discovered that the reason was there was no password. However, I quickly determined by doing some tests that the new users were getting passwords, but it appears the distribution password was not being set.

So I did a whole bunch of poking around. The password policies being used have been in place for many years. The main policy being used is assigned to the ou=users container, which is where all the users get created. I double checked the settings and sure enough, it is configured to set the Distribution Password.

Next I tried creating some dummy users using a really simple LDIF, just the name and password. The user's create fine, but low and behold, no distribution password! So I used the old getpass tool to double check (it works against eDir 9 if you disable FIPS mode). And sure enough, no distribution password!

But here is where it gets even stranger. If I just do a simple LDAP bind with one of the users I created and then check again, the distribution password is there! I'm totally baffled.

I even tried creating dummy users using iManager and I experienced the same behavior. I also tried explicitly setting the password policy in my LDIF too, directly assigning it to the user. Still, NO DP on new user creation!!!

Has anyone ever seen this? It is causing me tons of grief. The policy isn't anything special, it is using Microsoft Windows 2008 syntax.

Matt
Labels (1)
0 Likes
17 Replies
Knowledge Partner
Knowledge Partner

Re: Distribution Password Not Being Set

A few questions:

I would guess this is something NICI/SDI-related. Have you used sdidiag
to ensure that you have all keys on all servers? eDirectory 9.x
introduces new stronger keys for encryption which have interesting effects
on IDM. For example, if you change a Universal Password (Distribution
Password) to use the new key, it appears to IDM as a password change
because all it sees are changing values on which it must act.

Anyway, eDirectory 9.x has this second set of keys, and stronger keys, so
I wonder if your create happens on 9.x (please fill in lots of details),
replicates to 8.x boxes, and then cannot decrypt either because the new
9.x keys are not there, or even because there are more traditional key
issues where they are not on the target boxes. That would cause the
system to be able to fall back on NDS Password when the UP cannot be
accessed, and then during that successful NMAS (LDAP) bind the system
would set the UP (and DP) to the successful-bind value.

To verify some of this it would help if you could explain where your
creates happen, which versions of eDir is on those boxes, and then where
the IDM boxes involved are. Maybe IDM is on multiple boxes, which would
explain a bit more. Typically I try to keep clients' IDM engine on a
single box, and I've yet to have a customer tho needed more than one main
box and one dedicated SAP box (because of SAP's insanely-wasteful iDOCs),
so that helps prevent some of these issues, though if the theory above is
valid at all then the problem would happen regardless one keys were out of
sync.

sdidiag is your friend, though; start there. TID# 3455150 has some steps
for it.

--
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
matt4 Trusted Contributor.
Trusted Contributor.

Re: Distribution Password Not Being Set

Thanks for the reply.

I did not check the tree key, so I will run SDIDiag and check the tree key. Didn't even think to check that. Maybe that is the whole issue!!

This is a very large IdM environment that has been around a very long time, nearly back to the inception of DirXML.

There are about 105 IdM drivers in a single driver-set across something like 6 servers (yeah, don't get me started, long long story here).

The system has been rock solid stable for a long time, but XDAS problems, lack of support, and a weird replication issue finally forced the upgrades to start here (I say start because it is going to be a long process of moving drivers as we upgrade servers).

The user creates are happening against an eDir 9.0.4 server. They use the UserApp to create the users, but I've duplicated the problem using an LDIF just to rule out the UserApp, so I don't think it has anything to do with IdM or IdM components (and as I mentioned I used iManager too). This particular server though does have IdM 4.5.6 and is running a few drivers.

I'm doing my testing against this one server running 9.0.4 and IdM 4.5.6. I did try one create against an 8.8 SP8 FTF 11 server and I had the same issue.

This was not an issue until the two 9.0.4 servers were introduced into the environment (in-place upgrades from 8.8 SP8 FTF 11).

I did test a brand new password policy with no options. I assigned it to the Login Policy object and dis-associated the other policy from the ou=Users container. When I did that, the UP and DP were set when I created a user via an LDIF! So I thought, bad password policy maybe? But then I modified the policy to match one of the original policies (using Microsoft Windows 2008 Syntax) and the problem came back. No DP (and I assume no UP), but password still there because I could bind as the new user.

I then started testing adding and removing password polices and changing how they are assigned and I cannot get any sort of reliable behavior going. However, the original policies should really be fine. They do assign the policies to users directly using UserApp and/or IdM drivers, so I cannot just remove these old policies and make new ones.

I'll focus on SDDiag right now and report back what I find tomorrow.

Thanks.
0 Likes
matt4 Trusted Contributor.
Trusted Contributor.

Re: Distribution Password Not Being Set

I used SDIDIAG and I check the tree.

All 11 servers (there are 11 of them not 10 as I originally stated) have a single 168-bit key and it is the same key on all 11 servers.
All 11 servers are listed as tree key servers.
All 11 servers have the exact same replicas and partitions.


So it looks like the tree key is fine.

Where do you see a second set of stronger keys for eDir 9? I don't ee that anywhere.

Matt
0 Likes
Knowledge Partner
Knowledge Partner

Re: Distribution Password Not Being Set

On 4/26/2018 3:54 PM, matt wrote:
>
> I have a site that I'm in the process of upgrading to eDir 9.0.4 (can't
> go to 9.1 yet due to IdM). They are mostly on 8.8 SP8 FTF 11. There
> are 10 servers in the tree and I've upgraded two of them to eDir 9.0.4.
> Everything seems fine, but a really odd problem was noticed.
>
> They have IdM so they noticed that when new users were created, they
> were not getting sync'd to AD. I discovered that the reason was there
> was no password. However, I quickly determined by doing some tests that
> the new users were getting passwords, but it appears the distribution
> password was not being set.
>
> So I did a whole bunch of poking around. The password policies being
> used have been in place for many years. The main policy being used is
> assigned to the ou=users container, which is where all the users get
> created. I double checked the settings and sure enough, it is
> configured to set the Distribution Password.
>
> Next I tried creating some dummy users using a really simple LDIF, just
> the name and password. The user's create fine, but low and behold, no
> distribution password! So I used the old getpass tool to double check
> (it works against eDir 9 if you disable FIPS mode). And sure enough, no
> distribution password!
>
> But here is where it gets even stranger. If I just do a simple LDAP
> bind with one of the users I created and then check again, the
> distribution password is there! I'm totally baffled.


So this sounds like NMAS on login, seeing the UP is not set, sets the
UP. This is normal.

The question is why your user create attempt via LDAP is failing to set
UP. (Again this is NMAS's job).

Try iManager to create a user and see. In which case, there is
something up with your LDAP create, I wouldl think.

0 Likes
matt4 Trusted Contributor.
Trusted Contributor.

Re: Distribution Password Not Being Set

It turned out to be two known bugs in 9.0.4:

- Bug 1059208 - nmasldap_get_password_status() returns -1658 in a specific case

- Bug 1048966 - Unable to set universal passwords when Require unique passwords and password history are enabled.


I got an FTF for 9.0.4 to fix it. It is fixed in 9.1, but I cannot go to 9.1 since this environment is still IdM 4.5.6.


Matt
0 Likes
Knowledge Partner
Knowledge Partner

Re: Distribution Password Not Being Set

On 5/18/2018 12:44 PM, matt wrote:
>
> It turned out to be two known bugs in 9.0.4:
>
> - Bug 1059208 - nmasldap_get_password_status() returns -1658 in a
> specific case
>
> - Bug 1048966 - Unable to set universal passwords when Require unique
> passwords and password history are enabled.
>
>
> I got an FTF for 9.0.4 to fix it. It is fixed in 9.1, but I cannot go
> to 9.1 since this environment is still IdM 4.5.6.


Do they mentione what the specific case is? 🙂 Has me interested.


0 Likes
Knowledge Partner
Knowledge Partner

Re: Distribution Password Not Being Set

On 6/5/2018 9:54 AM, Geoffrey Carman wrote:
> On 5/18/2018 12:44 PM, matt wrote:
>>
>> It turned out to be two known bugs in 9.0.4:
>>
>> - Bug 1059208 - nmasldap_get_password_status() returns -1658 in a
>> specific case
>>
>> - Bug 1048966 - Unable to set universal passwords when Require unique
>> passwords and password history are enabled.
>>
>>
>> I got an FTF for 9.0.4 to fix it.  It is fixed in 9.1, but I cannot go
>> to 9.1 since this environment is still IdM 4.5.6.

>
> Do they mentione what the specific case is?  :)  Has me interested.


Went and looked at the bug, and it seems like your case is the specific
case. 🙂 That you have the NDS password set, but not UP and you login.

Interesting, the test case they have, builds a Password Policy object in
the o=novell container, which I suppose is valid, I have just never seen
a password policy outside the cn=Password Policies, cn=Security
container. Wonder if the plugins can manage it there? I.e. Do they
query the tree for objectclass=nspmPasswordPolicy or just the container?

Fun to see, since you learn something interesting each time.


0 Likes
Knowledge Partner
Knowledge Partner

Re: Distribution Password Not Being Set

On 06/05/2018 07:58 AM, Geoffrey Carman wrote:
>> Do they mentione what the specific case is? 🙂 Has me interested.

>
> Went and looked at the bug, and it seems like your case is the specific
> case. 🙂 That you have the NDS password set, but not UP and you login.


It may be notable that the password is set in the same operation as the
password policy is assigned, meaning it might happen first since it is not
happening as part of the create and may happen at the exact same time.
Looks like it is still a bug, but that's an unusual case.

> Interesting, the test case they have, builds a Password Policy object in
> the o=novell container, which I suppose is valid, I have just never seen a
> password policy outside the cn=Password Policies, cn=Security container.
> Wonder if the plugins can manage it there? I.e. Do they query the tree
> for objectclass=nspmPasswordPolicy or just the container?


Sometime many years ago the default schema was extended to allow placing a
password policy anywhere in the tree, effectively. The plugins can manage
it, but I think you need to browse to the object manually as, by default,
they MAY only look under cn=security for the password policy container.

With that said, all the time working there, and since, I've never
personally seen anybody (other than myself for testing once when it first
came out) actually use a password policy elsewhere in the tree. One of
the reasons was to keep the password policy object near the user,
specifically in the same partition, to avoid unnecessary tree-walking in
huge environments where cn=security is separate from dc=user,dc=org or
something. As you know, logins are optimized so that a password policy
takes, at most, four (4) calls to find, and three of those are local to
the user (user, container, and partition root) object; this makes all four
of them local to the user, potentially. eDirectory has proved in many
ways since then, so I do not know how relevant it is, particularly with
networks being faster and designs being more-efficient, but it's still there.

--
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
matt4 Trusted Contributor.
Trusted Contributor.

Re: Distribution Password Not Being Set

I only saw someone do password policies in other containers once a long time ago, maybe 10 years ago. It was a highly distributed environment with distributed administration. So I think they spread them out to speed up login time and allow for delegated administration I believe.

I also remember in the early days of universal password having to partition the Security container and replicate it in large highly distributed environments as well.

But again, that was like over ten years ago now at least.

Matt
0 Likes
Knowledge Partner
Knowledge Partner

Re: Distribution Password Not Being Set

On 06/05/2018 09:04 AM, matt wrote:
>
> I only saw someone do password policies in other containers once a long
> time ago, maybe 10 years ago. It was a highly distributed environment
> with distributed administration. So I think they spread them out to
> speed up login time and allow for delegated administration I believe.


Exactly; that is another good use case as long as your administrators have
rights to the container (likely) and know how to convince iManager to look
there (training is easy).

> I also remember in the early days of universal password having to
> partition the Security container and replicate it in large highly
> distributed environments as well.


Exactly; when you login and use UP the login must check the policy so that
if you make the password restrictions stronger, or invalidate old
passwords, that will be done immediately, and early on that meant finding
a real replica. A lot of attributes are now magically cached by
eDirectory removing that need, not to mention the faster links, etc.

--
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
Highlighted
Knowledge Partner
Knowledge Partner

Re: Distribution Password Not Being Set

On 6/5/2018 11:20 AM, ab wrote:
> On 06/05/2018 09:04 AM, matt wrote:
>>
>> I only saw someone do password policies in other containers once a long
>> time ago, maybe 10 years ago. It was a highly distributed environment
>> with distributed administration. So I think they spread them out to
>> speed up login time and allow for delegated administration I believe.

>
> Exactly; that is another good use case as long as your administrators have
> rights to the container (likely) and know how to convince iManager to look
> there (training is easy).
>
>> I also remember in the early days of universal password having to
>> partition the Security container and replicate it in large highly
>> distributed environments as well.

>
> Exactly; when you login and use UP the login must check the policy so that
> if you make the password restrictions stronger, or invalidate old
> passwords, that will be done immediately, and early on that meant finding
> a real replica. A lot of attributes are now magically cached by
> eDirectory removing that need, not to mention the faster links, etc.


Is it caching of objects/attributes that were once tree walked, or is it
caching the entire partition?

0 Likes
Knowledge Partner
Knowledge Partner

Re: Distribution Password Not Being Set

On 6/5/2018 11:04 AM, matt wrote:
>
> I only saw someone do password policies in other containers once a long
> time ago, maybe 10 years ago. It was a highly distributed environment
> with distributed administration. So I think they spread them out to
> speed up login time and allow for delegated administration I believe.
>
> I also remember in the early days of universal password having to
> partition the Security container and replicate it in large highly
> distributed environments as well.


I thought Security was implicitly replicated to all servers, even
thouogh it is not a distinct partition, or am I remembering something else?


0 Likes
Knowledge Partner
Knowledge Partner

Re: Distribution Password Not Being Set

On 06/05/2018 03:42 PM, Geoffrey Carman wrote:
> On 6/5/2018 11:04 AM, matt wrote:
>>
>> I only saw someone do password policies in other containers once a long
>> time ago, maybe 10 years ago. It was a highly distributed environment
>> with distributed administration. So I think they spread them out to
>> speed up login time and allow for delegated administration I believe.
>>
>> I also remember in the early days of universal password having to
>> partition the Security container and replicate it in large highly
>> distributed environments as well.

>
> I thought Security was implicitly replicated to all servers, even thouogh
> it is not a distinct partition, or am I remembering something else?


Of what you are thinking, I know not, but the Security container is just
another container, and in some environment was partitioned on its own so
it could be replicated dozens of times without any other partitions being
so overly-replicated. It's rare, but big customer did it because of the
need to do so, particularly in eDirectory 8.7 which is now very, very old.

--
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: Distribution Password Not Being Set

On 6/6/2018 10:48 AM, ab wrote:
> On 06/05/2018 03:42 PM, Geoffrey Carman wrote:
>> On 6/5/2018 11:04 AM, matt wrote:
>>>
>>> I only saw someone do password policies in other containers once a long
>>> time ago, maybe 10 years ago. It was a highly distributed environment
>>> with distributed administration. So I think they spread them out to
>>> speed up login time and allow for delegated administration I believe.
>>>
>>> I also remember in the early days of universal password having to
>>> partition the Security container and replicate it in large highly
>>> distributed environments as well.

>>
>> I thought Security was implicitly replicated to all servers, even thouogh
>> it is not a distinct partition, or am I remembering something else?

>
> Of what you are thinking, I know not, but the Security container is just
> another container, and in some environment was partitioned on its own so
> it could be replicated dozens of times without any other partitions being
> so overly-replicated. It's rare, but big customer did it because of the
> need to do so, particularly in eDirectory 8.7 which is now very, very old.


There was some partition, that automatically replicated (be it just
simply cached, or actual replica) like the hidden schema partition. But
maybe I am misremembering.


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.