kuronen
Visitor.
1035 views

LDAP simple auth agains replica

I just set up a read-write replica and I cannot remember if I need to do some actions to make users be able to authenticate via LDAP simple authentication to the replica. At it's default state it does not. It only simple-LDAP-authenticates admin user but not normal users. I've set up certificates, got a connection to ports 389 and 636 and I am able to successfully LDAP authenticate with admin.

Using openldap ldapsearch LDAP simple authentication works with admin user:
ldapsearch -x -Z -H ldap://hostname -D cn=admin,xxx -W -s sub -b o=xxx 'cn=testlogin' cn

But non-admin user results in success only with the master replica but does not succeed with read-write replica:
ldapsearch -x -Z -H ldap://hostname -D cn=testlogin,ou=xxx,ou=xxx,ou=xxx,o=xxx -W -s sub -b o=xxx 'cn=testlogin' cn

Ndstrace from the read-write replica tells me that it really is wrong password:
Bind name:cn=testlogin,ou=xxxf,ou=xxx,ou=xxx,o=xxx, version:3, authentication:simple
Failed to authenticate local on connection 0xe5c5180, err = failed authentication (-669)
Sending operation result 49:"":"NDS error: failed authentication (-669)" to connection 0xe5c5180
Monitor 0x5ed3c700 found connection 0xe5c5180 ending TLS session
DoUnbind on connection 0xe5c5180
Preempting operation 0x0:0x0 on connection 0xe5c5180 before processing because connection is closing
Connection 0xe5c5180 closed

The object does exist in the replica when querying it with admin user.
Labels (1)
0 Likes
7 Replies
Knowledge Partner
Knowledge Partner

Re: LDAP simple auth agains replica

On 09/18/2018 02:44 AM, kuronen wrote:
>
> I just set up a read-write replica and I cannot remember if I need to do
> some actions to make users be able to authenticate via LDAP simple


No, you should not need to do anything assuming the read/write replica is
of the partition where the user exists (vs. another partition where the
user is not), and assuming you gave the read/write replica time to get to
the "On" state, as otherwise it is not fully there yet.

> authentication to the replica. At it's default state it does not. It
> only simple-LDAP-authenticates admin user but not normal users. I've set


What is different between the admin and other users? By default an admin
is just a user with one more ACL to the tree [root] than other users, so
there is nothing else special about the admin which would make LDAP binds
work. Also, LDAP binds work regardless of ACLs, because you do not need
any rights in order to bind as yourself in eDirectory.

> up certificates, got a connection to ports 389 and 636 and I am able to
> successfully LDAP authenticate with admin.
>
> Using openldap ldapsearch LDAP simple authentication works with admin
> user:
> ldapsearch -x -Z -H ldap://hostname -D cn=admin,xxx -W -s sub -b o=xxx
> 'cn=testlogin' cn
>
> But non-admin user results in success only with the master replica but
> does not succeed with read-write replica:
> ldapsearch -x -Z -H ldap://hostname -D
> cn=testlogin,ou=xxx,ou=xxx,ou=xxx,o=xxx -W -s sub -b o=xxx
> 'cn=testlogin' cn


How do you know it does not succeed? Does it not return the one user for
which you are searching, because that does not mean it will not bind, but
just means it may not find the user, which may be a rights problem, or an
incorrectly-specified base DN problem (we cannot see your user's base DN
and compare it with your search base DN). Seeing the output, either from
ldapsearch or from ndstrace, or both, would be helpful so we can help you.
If you see a three (3) second delay after entering the password before
the prompt comes back, that may indicate an authentication problem, but if
it is much shorter, or much longer, then it is likely something else too.
I see you have ndstrace stuff below which points to authentication, but
again it would be nice to see more here.

If I were you I would be using ldaps, and TCP 636 (unless you are not
using that port, and assuming you have allowed it in the host and network
firewalls), since you are dealing with passwords here: e.g.:



LDAPTLS_REQCERT=allow /usr/bin/ldapsearch -x -H ldaps://hostname:636 -D
cn=admin,o=xxx -W -s base -b o=xxx 'objectClass=*'



I also made a few other minor changes to your ldapsearch command since
searching the entire organization just to test a bind is overkill, and
possibly loses important messages at the start of the connection.

> Ndstrace from the read-write replica tells me that it really is wrong
> password:


Please use CODE tags in the future; in the web UI's advanced interface it
is the little '#' button which will make your code be treated specially,
not interpreted by the UI in any way.

> Bind name:cn=testlogin,ou=xxxf,ou=xxx,ou=xxx,o=xxx, version:3,
> authentication:simple


This is a very different-looking DN than the one in your example above. I
presume your attempts to obfuscate there were different than here, and I
presume both were correct, but it would be nice if they were consistent so
we could assume nothing was missed in the process. A typo'd DN will also
get you a -669 because otherwise attackers can guess at usernames/DNs when
the result of a username failure is different from the result of a
password failure. For this reason, troubleshooting can be a bit harder,
but as an admin it is not really a problem unless we incorrectly type the DNs.

> Failed to authenticate local on connection 0xe5c5180, err = failed
> authentication (-669)
> Sending operation result 49:"":"NDS error: failed authentication (-669)"
> to connection 0xe5c5180
> Monitor 0x5ed3c700 found connection 0xe5c5180 ending TLS session
> DoUnbind on connection 0xe5c5180
> > Preempting operation 0x0:0x0 on connection 0xe5c5180 before processing

> because connection is closing
> Connection 0xe5c5180 closed
>
>
> The object does exist in the replica when querying it with admin user.


What do you mean? Do you mean you are doing an ldapsearch as the admin,
searching for the user, hitting the read/write replica, and it is not
returned? That would be doubly-odd since even if it was a server with no
replicas at all eDirectory would, by default, walk the tree to a server
with a real replica and pull it down.

Have you tried using iMonitor to browse the local read/write replica
directly to see what objects it has, or how its health appears? Have you
tried running 'ndsrepair -E' in order to get replication status
information? Perhaps this goes back to what I mentioned above about
replicas not being on fully. If this is a new box and firewalls are
misconfigured it could prevent the replica from being on at all, and
possibly from accessing other systems, which would cause these problems.

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

Re: LDAP simple auth agains replica

Hello Ab and thanks for your time and answer.

ab;2487732 wrote:

How do you know it does not succeed? Does it not return the one user for
which you are searching, because that does not mean it will not bind, but
just means it may not find the user, which may be a rights problem, or an
incorrectly-specified base DN problem (we cannot see your user's base DN
and compare it with your search base DN).


Please see below. It is an authentication failure.

ab;2487732 wrote:

Seeing the output, either from
ldapsearch or from ndstrace, or both, would be helpful so we can help you.
If you see a three (3) second delay after entering the password before
the prompt comes back, that may indicate an authentication problem, but if
it is much shorter, or much longer, then it is likely something else too.
I see you have ndstrace stuff below which points to authentication, but
again it would be nice to see more here.


It is 3 seconds delay as you can see from the timed command below. Please also see trace from the corresponding ldap queries below.

ab;2487732 wrote:

If I were you I would be using ldaps, and TCP 636 (unless you are not
using that port, and assuming you have allowed it in the host and network
firewalls), since you are dealing with passwords here: e.g.:


I am using ldaps and I've set up certificate chains correctly but I tested with ldap just to eliminate that possibility. Here is the command with response (I used replace on all the rest material so it should be consistent):


time LDAPTLS_REQCERT=allow /usr/bin/ldapsearch -x -H ldaps://host.domain:636 -D cn=testlogin,ou=aaa,ou=bbb,ou=ccc,o=org -w password -s sub -b o=org 'cn=testlogin' cn
ldap_bind: Invalid credentials (49)
additional info: NDS error: failed authentication (-669)

real 0m3.070s
user 0m0.030s
sys 0m0.004s


Here is the corresponding ndstrace:


New TLS connection 0xe5c5180 from 1.2.3.4:34110, monitor = 0x5ed3c700, index = 1
Monitor 0x5ed3c700 initiating TLS handshake on connection 0xe5c5180
DoTLSHandshake on connection 0xe5c5180
BIO ctrl called with unknown cmd 7
Completed TLS handshake on connection 0xe5c5180
DoBind on connection 0xe5c5180
Bind name:cn=testlogin,ou=aaa,ou=bbb,ou=ccc,o=org, version:3, authentication:simple
Failed to authenticate local on connection 0xe5c5180, err = failed authentication (-669)
Sending operation result 49:"":"NDS error: failed authentication (-669)" to connection 0xe5c5180
DoUnbind on connection 0xe5c5180
Connection 0xe5c5180 closed


For comparison here is the exact same command, only with changed hostname to master replica:


time LDAPTLS_REQCERT=allow /usr/bin/ldapsearch -x -H ldaps://host2.domain:636 -D cn=testlogin,ou=aaa,ou=bbb,ou=ccc,o=org -w password -s sub -b o=org 'cn=testlogin' cn
# extended LDIF
#
# LDAPv3
# base <o=org> with scope subtree
# filter: cn=testlogin
# requesting: cn
#

# testlogin, aaa, bbb, ccc, org
dn: cn=testlogin,ou=aaa,ou=bbb,ou=ccc,o=org
cn: testlogin

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

real 0m0.086s
user 0m0.029s
sys 0m0.013s


ab;2487732 wrote:

> The object does exist in the replica when querying it with admin user.

What do you mean? Do you mean you are doing an ldapsearch as the admin,
searching for the user, hitting the read/write replica, and it is not
returned? That would be doubly-odd since even if it was a server with no
replicas at all eDirectory would, by default, walk the tree to a server
with a real replica and pull it down.


As I wrote the object does exist in the replica (read/write, ok state) when querying it with admin user. It is available from the replica when queried as admin using LDAP.

ab;2487732 wrote:

Have you tried using iMonitor to browse the local read/write replica
directly to see what objects it has, or how its health appears? Have you
tried running 'ndsrepair -E' in order to get replication status
information? Perhaps this goes back to what I mentioned above about
replicas not being on fully. If this is a new box and firewalls are
misconfigured it could prevent the replica from being on at all, and
possibly from accessing other systems, which would cause these problems.


It is also there when browsing the replica with iMonitor. All my health checks report nothing to be concerned of. Did repairs too.

Looks like all options are exhausted then, unless you can think of something else. The master server ran out of memory a few weeks back and perhaps that has done something to the Flaim database. Maybe I could try and reconstruct it?
0 Likes
Knowledge Partner
Knowledge Partner

Re: LDAP simple auth agains replica

On 09/20/2018 01:24 AM, kuronen wrote:
>
> Here is the corresponding ndstrace:


Let's get some additional output from your trace, please:


ldapconfig set 'LDAP Screen Level=all' -a admin.sa.system

ndstrace
set dstrace=nodebug
dstrace +time +tags +ldap +auth +nmas +nici +dbg +recm
dstrace file on
set dstrace=*r

#perform LDAP authentications here, one admin, one regular usre

dstrace file off
quit


The resulting file should be, by default, in
/var/opt/novell/eDirectory/log/ndstrace.log and should have just what we
need, hopefully.

In addition could we get the ndsrepair output from a couple reports?


ndsrepair -E
ndsrepair -T


Finally what happens if you create a new test user via LDAP, specifically
against the read/write replica, so that it starts here and then replicates
to the Master? Does authentication of the user work after that? A sample
LDIF to create the user follows, which you can apply directly via a tool
like Apache Directory Studio or ldapmodify:


dn: cn=testuser-from-rw,ou=aaa,ou=bbb,ou=ccc,o=org
changetype: add
objectClass: inetOrgPerson
sn: testuser-from-rw-lname
uid: testuser-from-rw
userPassword: supersecure1234%%


Perhaps use the same ndstrace steps above to catch the authentication of
this user.

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

Re: LDAP simple auth agains replica

Added the trace options. I used the same exact ldapsearch commands as above so I will not repost them.

Here is the dstrace from successful admin LDAP login:


1327531776 RECM: [2018/09/21 9:08:10.610] Iter #4f2076e0 setIndex( 261)
1327531776 RECM: [2018/09/21 9:08:10.610] Iter #4f2076e0 query PartID==5 && Obituary$257A$
1327531776 RECM: [2018/09/21 9:08:10.610] Iter #4f2076e0 index = Obituary$IX$261
1327531776 RECM: [2018/09/21 9:08:10.610] Iter #4f2076e0 first( ID_INVALID)
1593042688 LDAP: [2018/09/21 9:08:10.909] New TLS connection 0xe5c5180 from 192.168.1.200:40608, monitor = 0x5ed3c700, index = 1
1590937344 LDAP: [2018/09/21 9:08:10.938] Monitor 0x5ed3c700 initiating TLS handshake on connection 0xe5c5180
1266919168 LDAP: [2018/09/21 9:08:10.938] (192.168.1.200:40608)(0x0000:0x00) DoTLSHandshake on connection 0xe5c5180
1266919168 LDAP: [2018/09/21 9:08:10.943] BIO ctrl called with unknown cmd 7
1266919168 LDAP: [2018/09/21 9:08:10.943] (192.168.1.200:40608)(0x0000:0x00) Completed TLS handshake on connection 0xe5c5180
1281042176 LDAP: [2018/09/21 9:08:10.943] (192.168.1.200:40608)(0x0001:0x60) DoBind on connection 0xe5c5180
1281042176 LDAP: [2018/09/21 9:08:10.943] (192.168.1.200:40608)(0x0001:0x60) Bind name:cn=admin,ou=fff,o=ddd, version:3, authentication:simple
1281042176 AUTH: [2018/09/21 9:08:10.943] [0000805d] <.admin.fff.ddd.TREE.> LocalLoginRequest. Error success, conn: 17.
1281042176 LDAP: [2018/09/21 9:08:10.943] (192.168.1.200:40608)(0x0001:0x60) Sending operation result 0:"":"" to connection 0xe5c5180
1264813824 LDAP: [2018/09/21 9:08:10.944] (192.168.1.200:40608)(0x0002:0x63) DoSearch on connection 0xe5c5180
1264813824 LDAP: [2018/09/21 9:08:10.944] (192.168.1.200:40608)(0x0002:0x63) Search request:
base: "o=ddd"
scope:2 dereference:0 sizelimit:0 timelimit:0 attrsonly:0
filter: "(cn=admin)"
attribute: "cn"
1264813824 AUTH: [2018/09/21 9:08:10.944] Starting SEV calculation for conn 17, entry .admin.fff.ddd.TREE..
1264813824 AUTH: [2018/09/21 9:08:10.944] 1 GlobalGetSEV.
1264813824 AUTH: [2018/09/21 9:08:10.944] 4 GlobalGetSEV succeeded.
1264813824 AUTH: [2018/09/21 9:08:10.944] SEV calculation complete for conn 17, (0:0 s:ms).
1264813824 RECM: [2018/09/21 9:08:10.944] Iter #e77a6f0 query ((Flags&1)==1) && ((CN$217A$.Flags&8=="admin") && (AncestorID==32854))
1264813824 RECM: [2018/09/21 9:08:10.944] Iter #e77a6f0 index = CN$IX$222
1264813824 RECM: [2018/09/21 9:08:10.944] Iter #e77a6f0 first( eid=32861)
1264813824 LDAP: [2018/09/21 9:08:10.945] (192.168.1.200:40608)(0x0002:0x63) Sending search result entry "cn=admin,ou=fff,o=ddd" to connection 0xe5c5180
1264813824 LDAP: [2018/09/21 9:08:10.945] (192.168.1.200:40608)(0x0002:0x63) Sending operation result 0:"":"" to connection 0xe5c5180
1587779328 LDAP: [2018/09/21 9:08:10.945] (192.168.1.200:40608)(0x0003:0x42) DoUnbind on connection 0xe5c5180
1587779328 LDAP: [2018/09/21 9:08:10.945] Connection 0xe5c5180 closed
1264813824 AUTH: [2018/09/21 9:08:15.2] UpdateLoginAttributesThread page 1 processed 1 login in 2 milliseconds


Here is dstrace from failed testuser LDAP login:


1593042688 LDAP: [2018/09/21 9:08:15.672] New TLS connection 0xe5c5180 from 192.168.1.200:40612, monitor = 0x5ed3c700, index = 1
1590937344 LDAP: [2018/09/21 9:08:15.700] Monitor 0x5ed3c700 initiating TLS handshake on connection 0xe5c5180
1587779328 LDAP: [2018/09/21 9:08:15.700] (192.168.1.200:40612)(0x0000:0x00) DoTLSHandshake on connection 0xe5c5180
1587779328 LDAP: [2018/09/21 9:08:15.704] BIO ctrl called with unknown cmd 7
1587779328 LDAP: [2018/09/21 9:08:15.705] (192.168.1.200:40612)(0x0000:0x00) Completed TLS handshake on connection 0xe5c5180
1328584448 LDAP: [2018/09/21 9:08:15.705] (192.168.1.200:40612)(0x0001:0x60) DoBind on connection 0xe5c5180
1328584448 LDAP: [2018/09/21 9:08:15.705] (192.168.1.200:40612)(0x0001:0x60) Bind name:cn=testlogin,ou=aaa,ou=bbb,ou=ccc,o=ddd, version:3, authentication:simple
1328584448 AUTH: [2018/09/21 9:08:15.705] [0000af8e] <.testlogin.aaa.bbb.ccc.ddd.TREE.> EmuVerifyPassword returned error request unknown or no such property (-251), conn: 17
1328584448 NMAS: [2018/09/21 9:08:15.705] 262178: Create NMAS Session
1328584448 NMAS: [2018/09/21 9:08:15.705] 262178: Failed to find login sequence for proxy client can do: 0x9
1328584448 NMAS: [2018/09/21 9:08:15.705] 262178: Client Session Destroy Request
1328584448 NMAS: [2018/09/21 9:08:15.705] 262178: Destroy NMAS Session
1328584448 NMAS: [2018/09/21 9:08:15.705] 262178: Aborted Session Destroyed (with MAF)
1328584448 AUTH: [2018/09/21 9:08:15.705] [0000af8e] <.testlogin.aaa.bbb.ccc.ddd.TREE.> DCSimplePasswordVerifyEx returned error -1660 (0xfffff984), conn: 17
1328584448 AUTH: [2018/09/21 9:08:15.705] UpdateLoginAttributesThread page 1 processed 1 login in 0 milliseconds
1328584448 AUTH: [2018/09/21 9:08:15.705] [0000af8e] <.testlogin.aaa.bbb.ccc.ddd.TREE.> LocalLoginRequest. Error failed authentication (-669), conn: 17.
1263761152 AUTH: [2018/09/21 9:08:15.705] UpdateLoginAttributesThread page 1 processed 0 login in 0 milliseconds


Here is the output of ndsrepair -E:


[root@ldap-2 ~]# ndsrepair -E

[1] Instance at /etc/opt/novell/eDirectory/conf/nds.conf: ldap-2.o=ddd.LDAP
Repair utility for NetIQ eDirectory 8.8 - 8.8 SP8 v20812.12
DS Version 20812.20 Tree name: LDAP
Server name: .ldap-2.ddd

Size of /var/opt/novell/eDirectory/log/ndsrepair.log = 744 bytes.

Preparing Log File "/var/opt/novell/eDirectory/log/ndsrepair.log"
Please Wait...
Collecting replica synchronization status
Start: Friday, September 21, 2018 09:22:38 Local Time
Retrieve replica status

Partition: .IDM Driver Set.Services.system
Replica on server: .ldap-2.ddd
Replica: .ldap-2.ddd 09-21-2018 09:16:07
Replica on server: .ldap-1.ddd
Replica: .ldap-1.ddd 09-21-2018 09:10:41
All servers synchronized up to time: 09-21-2018 09:10:41
Partition: .[Root].
Replica on server: .ldap-2.ddd
Replica: .ldap-2.ddd 09-21-2018 09:22:36
Replica on server: .ldap-1.ddd
Replica: .ldap-1.ddd 09-21-2018 09:22:36
All servers synchronized up to time: 09-21-2018 09:22:36
Finish: Friday, September 21, 2018 09:22:38 Local Time

Total errors: 0
NDSRepair process completed.


And output of ndsrepair -T


[root@ldap-2 ~]# ndsrepair -T

[1] Instance at /etc/opt/novell/eDirectory/conf/nds.conf: ldap-2.o=ddd.LDAP
Repair utility for NetIQ eDirectory 8.8 - 8.8 SP8 v20812.12
DS Version 20812.20 Tree name: LDAP
Server name: .ldap-2.ddd

Size of /var/opt/novell/eDirectory/log/ndsrepair.log = 1484 bytes.

Building server list
Please Wait...
Preparing Log File "/var/opt/novell/eDirectory/log/ndsrepair.log"
Please Wait...
Collecting time synchronization and server status
Time synchronization and server status information
Start: Friday, September 21, 2018 09:22:40 Local Time

---------------------------+---------+---------+-----------+--------+-------
DS Replica Time Time is Time
Server name Version Depth Source in sync +/-
---------------------------+---------+---------+-----------+--------+-------
Processing server: .ldap-1.ddd
.ldap-1.ddd 20812.20 0 Non-NetWare Yes 0
Processing server: .ldap-2.ddd
.ldap-2.ddd 20812.20 0 Non-NetWare Yes 0
---------------------------+---------+---------+-----------+--------+-------
Total errors: 0
NDSRepair process completed.


I created a testuser with ldapmodify to that specific replica and tried authenticating to it with the exact same command as shown in previous post, just with the testuser-from-rw login and password. The authentication similarly to before. To eliminate the possibility of typo I did the same exact ldapsearch against the master replica and it was successful.

Here is the dstrace from the failed attempt


1593042688 LDAP: [2018/09/21 9:49:59.928] New TLS connection 0xe5c5180 from 192.168.1.200:46984, monitor = 0x5ed3c700, index = 1
1590937344 LDAP: [2018/09/21 9:49:59.956] Monitor 0x5ed3c700 initiating TLS handshake on connection 0xe5c5180
1266919168 LDAP: [2018/09/21 9:49:59.956] (192.168.1.200:46984)(0x0000:0x00) DoTLSHandshake on connection 0xe5c5180
1266919168 LDAP: [2018/09/21 9:49:59.961] BIO ctrl called with unknown cmd 7
1266919168 LDAP: [2018/09/21 9:49:59.961] (192.168.1.200:46984)(0x0000:0x00) Completed TLS handshake on connection 0xe5c5180
1264813824 LDAP: [2018/09/21 9:49:59.962] (192.168.1.200:46984)(0x0001:0x60) DoBind on connection 0xe5c5180
1264813824 LDAP: [2018/09/21 9:49:59.962] (192.168.1.200:46984)(0x0001:0x60) Bind name:cn=testuser-from-rw,o=ddd, version:3, authentication:simple
1264813824 AUTH: [2018/09/21 9:49:59.962] [0000afde] <.testuser-from-rw.ddd.LDAP.> EmuVerifyPassword returned error request unknown or no such property (-251), conn: 17
1264813824 NMAS: [2018/09/21 9:49:59.962] 262182: Create NMAS Session
1264813824 NMAS: [2018/09/21 9:49:59.962] 262182: Failed to find login sequence for proxy client can do: 0x9
1264813824 NMAS: [2018/09/21 9:49:59.962] 262182: Client Session Destroy Request
1264813824 NMAS: [2018/09/21 9:49:59.962] 262182: Destroy NMAS Session
1264813824 NMAS: [2018/09/21 9:49:59.962] 262182: Aborted Session Destroyed (with MAF)
1264813824 AUTH: [2018/09/21 9:49:59.962] [0000afde] <.testuser-from-rw.ddd.LDAP.> DCSimplePasswordVerifyEx returned error -1660 (0xfffff984), conn: 17
1264813824 AUTH: [2018/09/21 9:49:59.962] UpdateLoginAttributesThread page 1 processed 1 login in 0 milliseconds
1281042176 AUTH: [2018/09/21 9:49:59.962] UpdateLoginAttributesThread page 1 processed 0 login in 0 milliseconds
1264813824 AUTH: [2018/09/21 9:49:59.962] [0000afde] <.testuser-from-rw.ddd.LDAP.> LocalLoginRequest. Error failed authentication (-669), conn: 17.


I saw that EmuVerifyPassword before writing here but could not find enough information to work with.
0 Likes
Knowledge Partner
Knowledge Partner

Re: LDAP simple auth agains replica

The problem here appears to be that your regular users are trying to use
some NMAS sequence that is not available for some reason, a very rare issue:

https://www.novell.com/support/kb/doc.php?id=3938451

You may want to check tree keys with sdidiag as mentioned in this TID:
https://www.novell.com/support/kb/doc.php?id=3455150

Otherwise is there anything interesting about this tree's Security
container or contents which is where NMAS login sequences are kept? Are
the Master and Read/Write replicas on the same platform (Linux, I
presume), and are they using the same architecture (x86_64 vs. x86_32) on
there? Login sequences should be replicated like most other things, but
the login methods themselves are architecture-specific, so maybe that
explains something being broken here.

I believe you can see and manage your login sequences with iManager as
shown here, so you may want to peruse those to see how they look:
https://www.netiq.com/documentation/edirectory-9/edir_admin/data/a53vifw.html

The "Authorizing Login Sequences for Users" section might be applicable.

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

Re: LDAP simple auth agains replica

Hello sir Ab,

ab;2487898 wrote:
The problem here appears to be that your regular users are trying to use
some NMAS sequence that is not available for some reason, a very rare issue:

https://www.novell.com/support/kb/doc.php?id=3938451

You may want to check tree keys with sdidiag as mentioned in this TID:
https://www.novell.com/support/kb/doc.php?id=3455150



I've got a 64 bit RHEL 6 and sdidiag is not avaibable to this environment as far as I know so that pretty much stops me from getting there. Unless it is available and I just could not find it?

ab;2487898 wrote:

Otherwise is there anything interesting about this tree's Security
container or contents which is where NMAS login sequences are kept? Are
the Master and Read/Write replicas on the same platform (Linux, I
presume), and are they using the same architecture (x86_64 vs. x86_32) on
there? Login sequences should be replicated like most other things, but
the login methods themselves are architecture-specific, so maybe that
explains something being broken here.

I believe you can see and manage your login sequences with iManager as
shown here, so you may want to peruse those to see how they look:
https://www.netiq.com/documentation/edirectory-9/edir_admin/data/a53vifw.html

The "Authorizing Login Sequences for Users" section might be applicable.


Nothing is jumping to my eyes with Security container and we've got default NMAS login sequences of nds and challenge response authorized. Same goes with login methods and my test user had them as well.
Same RHEL 6 OS and same architecture.

We're going way past profitable use of time but I would be interested in exploring SDI diagnostics. Do you have a way to use sdidiag in 64 bit Linux? Or can I diagnose SDI keys in some other manner?
0 Likes
Knowledge Partner
Knowledge Partner

Re: LDAP simple auth agains replica

sdidiag has an x86_64 RPM at least at this site:

https://download.microfocus.com/protected/Summary.jsp?buildid=P0UMP7M5YgI~

There may be an even newer version with eDirectory 9.x, which now supports
stronger and better types of keys, but that's not for you today as I see
you are on 8.8 SP8 with a semi-current path as I recall.

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