Article
Introduction
There is a feature in eDirectory 8.8sp1 where NMAS enables LDAP authentications (binds) so that they are case-sensitive. This feature can also help ease the deployment of Universal Password. In this AppNote, I provide a bit of history to set the stage and the need for this feature. Next, I describe how the LDAP bind process worked in past versions of eDirectory and how to set up the new feature, including my test cases and results to demonstrate how all this now works.
Over the past 6 or so years, I have have been mostly been involved in projects where eDirectory is primarily used for LDAP applications. In these projects, sometimes security is a concern (for user authentication) and sometimes it is not (complex data repository). When security is a concern, having strong passwords is an important factor to consider.
Most eDirectory environments use eDirectory primarily for traditional NetWare or OES file/print services. Over time, traditional eDirectory environments also use eDirectory for LDAP applications. Usually these environments require strong security and require strong passwords. When Novell introduced Universal Password, it offered numerous advanced password complexity rules that allowed administrators to enforce strong password rules that were not available using the traditional NDS Password. Taking full advantage of these complexity rules, including password case-sensitivity, for LDAP authentication (bind) was easy for my projects - but it was not so easy for environments that supported both LDAP applications and traditional NetWare or OES file/print services. That has changed.
Background Information
In eDirectory 8.7.3, LDAP authentication, also known as an LDAP bind, goes through a rather complex process when migrating from a competitive LDAP directory using the NMAS Simple Password login method. This is to ensure backward compatibility and to maintain passwords. The process, quoted from TID 3057961, goes like this:
"An LDAP bind against an eDirectory 8.7.3 server will always try the NDS password first. If the NDS Password fails, the server invokes the Simple Password NMAS Method, which will first try the Universal Password. If the Universal Password is not currently set it will then try the Simple Password."
Due to these backward compatibility features, the only way LDAP binds can use Universal Password, including its case-sensitivity feature, is to "remove" the old NDS Password. Removing the NDS Password leaves only the Universal Password or Simple Password available for LDAP binds (both of which are case-sensitive). To be precise, the NDS Password is not removed. Instead it renders the NDS Password method useless by setting the password to an unusable value. This forces LDAP binds to use the Simple Password method as described previously.
TID 3057961 offers additional useful information from the following link: TID3057961 - How to get LDAP Case Sensitive Passwords with eDirectory 8.7.3
The Conundrum
Although the NDS Password, Universal Password, and Simple Password can be set to the same word, they really can't be the same value. This is because the NDS Password is not case-sensitive, whereas the Universal and Simple passwords are case-sensitive. So if the user's NDS Password is "novell", then any case combination of the word "NoVeLl" will pass an authentication test. What TID 3057961 does not mention is that when the NDS Password is tested and succeeds, then processing stops. This means that even if the Simple Password or Universal Password matches the NDS Password (except, of course, for its case), then the Universal and Simple Passwords are never used for LDAP binds. That makes them case-insensitive and less secure. When an NDS Password is removed, it is never tested during authentication, so the case-sensitive Universal or Simple Passwords are used. If you are using eDirectory for only LDAP applications, this is fine. However, if you use your eDirectory tree for both LDAP binds and for Novell Client NCP-based logins, this can make migration to Universal Password a bit more difficult.
So is the only way to get case-sensitive passwords for LDAP binds is by removing the NDS Password? For eDirectory 8.7.x - yes. However, in eDirectory 8.8sp1, there is an option where NMAS enables all LDAP binds so that NDS Passwords do not have to be removed. The best part is that this feature, like the NMAS enabled full-fledged Novell NCP-based client, can synchronize the existing NDS Password with the Universal Password. Ah, but previously I said the password can't be synchronized due to case-sensitivity. Well, technically that is still true, but that's where this new feature is helpful. With it, you can migrate from NDS Password to Universal Password without requiring the full NMAS enabled Novell NCP client to establish Universal Passwords. (The full NMAS enabled Novell client is still required to actually use the Universal Password for authentication.) After all, removing NDS passwords before you have fully implemented Universal Password (NMAS enabled Novell client + Universal Password Policies) can confuse and irritate both administrators and end users alike.
I had not seen this feature working myself, and my curiosity got the best of me. So, I set up a test lab and documented the results - hopefully, you will find this useful.
Testing
The Test Environment
- Platform: SLES 10
- eDirectory: 8.8sp1
- ss204 patch (NMAS 3.12)
- iManager 2.6 + current plug-ins
I created a new tree on SLES10 using eDirectory 8.8 SP1 (there are significant fixes in SP1, so it is strongly recommended). I added the ss204 patch to get the latest and greatest NMAS version (always important to have the latest NMAS version for Universal Password). I also installed iManager 2.6 and updated it with the latest plug-ins. Note that by default, Universal Password is not enabled, and the Simple Password method is not installed. For my test, I did not install the Simple Password method so it would not complicate the tests. It can be difficult to tell which password type is being used during authentication, so for my tests I use password case-sensitivity for an easy way to tell whether or not the Universal Password was really being used for the LDAP binds.
In eDirectory 8.8 (SP1 recommended), the documentation refers to a new "Enforcing Case-Sensitive Universal Passwords" feature. I am not a big fan of the way the documentation describes this feature, but it is accurate. Effectively, this feature forces eDirectory to first test passwords during authentication using NMAS based methods before testing the password against the user's old NDS Password method. Previously, the only way to get case-sensitive passwords for LDAP binds was to remove the old NDS Password (as described in the TID: How to get LDAP Case Sensitive Passwords with eDirectory 8.7.3). Now it is possible to have case-sensitive passwords without removing the old NDS Password by configuring LDAP to use NMAS for authentication.
Testing Setup and Results
1. Enable NMAS for LDAP. NMAS for LDAP is enabled by adding environment variables that are set just before eDirectory is started. These are set differently depending on the eDirectory platform you use - I used SLES 10 for my testing. For other platforms, see the eDirectory 8.8 documentation. Here is what I added near the top of my ndsd script (/etc/init.d/ndsd) following the first set of comments:
printf "\n" >> /var/opt/novell/eDirectory/log/ndsd.log
printf "##### Executing ndsd script... #####\n"
>> /var/opt/novell/eDirectory/log/ndsd.log
NDSD_TRY_NMASLOGIN_FIRST=true
export NDSD_TRY_NMASLOGIN_FIRST
printf "Env Variable \"NDSD_TRY_NMASLOGIN_FIRST\" = $NDSD_TRY_NMASLOGIN_FIRST"
>> /var/opt/novell/eDirectory/log/ndsd.log
printf "##### End customizations ##### \n" >> /var/opt/novell/eDirectory/log/ndsd.log
Only lines 3 and 4 are required. The others are there only so I can easily tell if the settings are effective. I do this by writing out the value of the environment variable to my ndsd.log file. There is another way to tell if this setting is effective - using DSTrace/ndstrace. For examples, see the section titled "LDAP DSTrace Examples" near the end of this document.
eDirectory has not yet been restarted, so the changes have not taken effect. We will do this later, in the middle of our test cases.
TIP 1: This change must be made to all eDirectory servers that will be processing LDAP binds. You may not know if your tools are using LDAP or NCP to talk to eDirectory, so it is best to set this on all your servers. I am a big fan of consistency, which is another reason to set this on all your servers.
TIP 2: Keep a log of any changes you make to the ndsd script. Patching or upgrading eDirectory will undo your changes, because a new version of the ndsd script may be installed by patches or upgrades.
2. Create test users using iManager 2.6 in the HQusers.Corp container. Note that I have not yet created any Universal PW policies so only the NDS Password is available for use with these newly created users.
|
ID |
Password Set During User Creation |
Notes |
|
noup1 |
novell |
No UnivPW assigned |
|
noup2 |
novell |
No UnivPW assigned |
|
up1 |
novell |
Will set UnivPW via iManager after UnivPW policy is assigned |
|
up2 |
novell |
Will set UnivPW via iManager after UnivPW policy is assigned later in the tests |
3. Run TEST CASE 1. Test the LDAP binds using ldapsearch and confirmed passwords that are not case-sensitive. Note that eDirectory has not yet been restarted, and no Universal Password Policy has been assigned.
| # | ||||
|
1a |
||||
|
1b |
||||
|
1c |
||||
|
1d |
4. Restart eDirectory so the ndsd script changes take effect. Verify that the environment variable is set by checking the ndsd.log file. As mentioned previously, ndstrace can be used to tell if this setting is effective as shown in the LDAP DSTrace Examples section near the end of this document.
5. Run TEST CASE 2. Re-test LDAP binds using ldapsearch to confirm that passwords are still not case-sensitive, as we expect. Although eDirectory has been restarted with the NDSD_TRY_NMASLOGIN_FIRST environment variable set to true, LDAP binds can't yet be case-sensitive. LDAP binds are still using the old NDS Password because the users have no Universal Password passwords or policies. So the expected results are the same as in the TEST CASE 1 performed previously (Step 3).
|
# |
User ID |
Password Used in Test |
Expected Result |
Actual Result / Notes |
|
2a |
up1 |
novell |
Login = Yes. Same as initial PW. |
PASSED / Login = Yes |
|
2b |
up2 |
Novell |
Login = Yes. NDS PW is not case-sensitive. |
PASSED / Login = Yes |
|
2c |
noup1 |
novell |
Login = Yes. Same as initial PW. |
PASSED / Login = Yes |
|
2d |
noup2 |
Novell |
Login = Yes. NDS PW is not case-sensitive. |
PASSED / Login = Yes |
6. Create a Universal Password Policy. Use all defaults, including the following settings relevant to the tests:
- Advanced Password Rules = enabled
- Allow user to initiate password change = enabled
- Allow the password to be case sensitive = enabled
- Enable Universal Password = Enabled
- Enable Advanced Password Rules = Enabled
- Remove NDS Password when setting Universal Password = Disabled
- Synchronize NDS Password when setting Universal Password = Enabled
-
Synchronize Simple Password when setting Universal Password = Disabled
Full Universal Password settings screen shots are available in the section titled "Universal Password Settings" near the end of this document.
7. Apply Universal Password policy created above to the ou=HQusers.o=Corp container.
8. Use iManager Passwords Plugin to set Universal Passwords on only the users "up1" and "up2" to "Novell".
9. Run TEST CASE 3. Test the LDAP binds using ldapsearch to confirm that passwords are case-sensitive for the users "up1" and "up2", whose Universal Passwords were established in Step 8. We will wait for the next test to see what happens to users "noup1" & "noup2" when they log in for the first time without Universal Passwords.
|
# |
User ID |
Password Used in Test |
Expected Result |
Actual Result / Notes |
|
3a |
up1 |
novell |
Login = No. Wrong password. UnivPW policy and password established and case-sensitive. |
PASSED / Login = No |
|
3b |
up1 |
Novell |
Login = Yes. Correct case-sensitive password |
PASSED / Login = Yes |
|
3c |
up2 |
novell |
Login = No. Wrong password. UnivPW policy and password established and case-sensitive. |
PASSED / Login = No |
|
3d |
up2 |
Novell |
Login = Yes. Correct case-sensitive password |
PASSED / Login = Yes |
10. Run TEST CASE 4. Test the LDAP binds using ldapsearch. Test users "noup1' and "noup2" do not yet have Universal Passwords. However, now that they have been assigned an effective Universal Password policy, and the NDSD_TRY_NMASLOGIN_FIRST environment variable has been set to true, their first successful LDAP bind will be case-insensitive. This first bind will also establish their Universal Password, after which all subsequent binds will be case-sensitive. Recall that before the changes, both users were able to bind to eDirectory using the password of "novell" (no case-sensitivity).
|
# |
User ID |
Password Used in Test |
Expected Result |
Actual Result / Notes |
|
4a |
noup1 |
novell |
Login = Yes. Correct password. The user's UnivPW does not yet exist so the word "novell" used with any case is correct. However, this login will establish the UnivPW which will |
PASSED / Login = Yes |
|
4b |
noup1 |
Novell |
Login = No. Wrong password since the user's UnivPW was just established using during test 4a. The password is now case-sensitive so the correct password is "novell". |
PASSED / Login = No |
|
4c |
noup1 |
novell |
Login = Yes. Correct password. The user's UnivPW was established as "novell" (case-sensitive) during test 4a. |
PASSED / Login = Yes |
|
4d |
noup2 |
NOVELL |
Same as test 4a... Login = Yes. Correct password. The user's UnivPW does yet exist for so the word "novell" used with any case is correct. However, this login will establish the UnivPW which will subsequently enforce case for all subsequent binds. |
PASSED / Login = Yes |
|
4e |
noup2 |
Novell |
Login = No. Wrong password since the user's UnivPW was just established using during test 4d. The password is now case-sensitive so the correct password is "NOVELL". |
PASSED / Login = No |
|
4f |
noup2 |
NOVELL |
Login = Yes. Correct password. The user's UnivPW was established as "NOVELL" (case-sensitive) during test 4d. |
PASSED / Login = Yes |
11. Modify the Universal Password Policy to allow Universal Password authentication to disable case-sensitivity by disabling the "Allow the password to be case sensitive" option.
12. Run TEST CASE 5. Test the LDAP binds using ldapsearch. Now that all the test users have Universal Passwords established, what happens after the Universal Password policy allows for case-insensitive passwords? Let's see ...
|
# |
User ID |
Password Used in Test |
Expected Result |
Actual Result / Notes |
|
5a |
up1 |
novell |
Login = Yes. Correct password. Case-sensitivity is disabled in the user's Universal Password policy so the word "novell" used with any case is correct. |
PASSED / Login = Yes |
|
5b |
up1 |
NoveLL |
Same as test 5a. |
PASSED / Login = Yes |
|
5c |
noup1 |
NOVELL |
Same as test 5a. |
PASSED / Login = Yes |
|
5d |
noup1 |
Novell |
Same as test 5a. |
PASSED / Login = Yes |
13. Return the Universal Password Policy to it its previous configuration, so Universal Password authentication is case-sensitive. Do this by enabling the "Allow the password to be case sensitive" option.
14. Remark the lines in the ndsd script file that set NDSD_TRY_NMASLOGIN_FIRST environment variable to true. After eDirectory is restarted, this will cause LDAP binds to first
use the NDS Password making the passwords case-insensitive. This can happen if you patch or upgrade your servers and forget to add your customizations into the new ndsd script file.
15. Restart eDirectory (/etc/init.d/ndsd restart) so the ndsd script changes take effect.
16. Run TEST 6. Test the LDAP binds using ldapsearch. Confirm that even though the test users have Universal Passwords and an effective Universal Password policy, their LDAP
binds will not be case-sensitive without the NDSD_TRY_NMASLOGIN_FIRST environment variable set to true in the ndsd script.
|
# |
User ID |
Password Used in Test |
Expected Result |
Actual Result / Notes |
|
6a |
up1 |
novell |
Login = Yes. Correct password. Case-sensitivity is disabled without the ndsd script modification so the word "novell", used with any case, is correct. |
PASSED / Login = Yes |
|
6b |
up1 |
NoveLL |
Same as test 6a. |
PASSED / Login = Yes |
|
6c |
noup1 |
NOvELL |
Same as test 6a. |
PASSED / Login = Yes |
|
6d |
noup1 |
noveLL |
Same as test 6a. |
PASSED / Login = Yes |
Testing Summary
My tests demonstrate that by using the eDirectory 8.8 SP1 feature to NMAS-enable LDAP binds, existing NDS Passwords can be effectively synchronized to Universal Passwords. I tested this by using case-sensitivity as the proof. I say "effectively synchronized" because, technically, the NDS Password is not synchronized to the Universal Password. Instead, the Universal Password is created with the password value (including case) entered by the user, immediately after their first successful NMAS-enabled LDAP bind is performed. All subsequent LDAP binds by that user are case-sensitive, as long as (1) the new eDirectory 8.8 feature is enabled by the NDSD_TRY_NMASLOGIN_FIRST environment variable, and (2) the user's effective Universal Password policy dictates that case-sensitivity be enforced.
This feature allows eDirectory trees that serve users performing both LDAP binds and NCP logins (using the NMAS enabled Novell NCP-based client) to really use the same password, Universal Password, without confusion. This feature also offers other complex and creative possibilities when using Novell Identity Manager for password synchronization.
Below is a summary of the tests results performed:
TEST1 - Confirmed the test environment by demonstrating that LDAP binds are not case-sensitive using the default eDirectory
8.8sp1 configuration.
TEST2 - This test confirmed that only enabling NMAS for LDAP binds using the new eDirectory 8.8 SP1 feature (NDSD_TRY_NMASLOGIN_FIRST) is not enough to allow LDAP binds to
use Universal Password (case-sensitive) for authentication instead of the old NDS Password (not case-sensitive).
TEST 3 - This test confirmed that for users ("up1" and "up2") that have established Universal Passwords, their LDAP binds will also use Universal Password (case-sensitive) for authentication, as long as the following are true:
- The user has an effective Universal Password Policy.
- The user's Universal Password Policy has the "Allow the password to be case sensitive" option enabled.
- The eDirectory server used for LDAP authentication has NMAS enabled for LDAP using the NDSD_TRY_NMASLOGIN_FIRST environment variable set and active.
TEST 4 - This test confirmed that users without Universal
Passwords are automatically established during their first successful
LDAP bind after the following are true:
- The user has been assigned an effective Universal Password Policy
- The assigned Universal Password Policy has the "Allow the password to be case sensitive" option enabled
-
The eDirectory server used for LDAP authentication has NMAS enabled for LDAP, using the NDSD_TRY_NMASLOGIN_FIRST environment variable set and active
TEST 5 - This test confirms that even when LDAP is NMAS-enabled and users have established their Universal Passwords, LDAP binds are case-sensitive only when their effective Universal Password Policy has the "Allow the password to be case sensitive" option enabled.
TEST 6 - This test confirms that even though test users have Universal Passwords and have an effective Universal Password policy, their LDAP binds will not be case-sensitive without the NDSD_TRY_NMASLOGIN_FIRST environment variable set to true in the ndsd script and active.
Other Helpful Notes
LDAP DSTrace Setup and Examples
I prefer iMonitor over ndstrace/dstrace, but either will do. Make sure your LDAP server object's Tracing options are enabled. I enabled everything as shown in Figure 1 below, but this should not be necessary.
Figure 1 - LDAP server tracing options
1. Enable the LDAP and NMAS filters in iMonitor as shown in
Figure 2 below.
Figure 2 - Enabling LDAP and NMAS
filters
2. Start tracing.
Without the NDSD_TRY_NMASLOGIN_FIRST=true option set, the trace will not show any NMAS activity during the LDAP bind. With the option set you will see lots of NMAS activity during the LDAP bind. Below are four trace examples for your comparison.
TRACE 1 - ldapsearch test without the environment variable "NDSD_TRY_NMASLOGIN_FIRST" set in the ndsd script (LDAP binds are not NMAS-enabled).
This is a typical DSTrace of an ldapsearch operation, using the NDS Password for the bind.
1 17:01:33 B4FADBA0
LDAP: New cleartext connection 0x8181e08 from 127.0.0.1:35699,
monitor = 0x0, index = 12 17:01:33 B6FADBA0 LDAP: Monitor
0xb6fadba0 started3 17:01:33 945E3BA0 LDAP:
(127.0.0.1:35699)(0x0001:0x60) DoBind on connection 0x8181e084
17:01:33 945E3BA0 LDAP: (127.0.0.1:35699)(0x0001:0x60) Bind
name:cn=up1,ou=HQusers,o=corp, version:3, authentication:simple5
17:01:33 945E3BA0 LDAP: (127.0.0.1:35699)(0x0001:0x60) Sending
operation result 0:"":"" to connection
0x8181e086 17:01:33 945E3BA0 LDAP: (127.0.0.1:35699)(0x0002:0x63)
DoSearch on connection 0x8181e087 17:01:33 945E3BA0 LDAP:
(127.0.0.1:35699)(0x0002:0x63) Search request:8 base: ""9
scope:1 dereference:0 sizelimit:0 timelimit:0 attrsonly:010
filter: "(objectclass=*)"11 no attributes12
17:01:33 945E3BA0 LDAP: (127.0.0.1:35699)(0x0002:0x63) Empty
attribute list implies all user attributes13 17:01:33 945E3BA0
LDAP: (127.0.0.1:35699)(0x0002:0x63) Sending search result entry
"o=CORP" to connection 0x8181e0814 17:01:33 945E3BA0
LDAP: (127.0.0.1:35699)(0x0002:0x63) Sending search result entry
"cn=Security" to connection 0x8181e0815 17:01:33
945E3BA0 LDAP: (127.0.0.1:35699)(0x0002:0x63) Sending operation
result 0:"":"" to connection 0x8181e0816
17:01:33 B43ADBA0 LDAP: (127.0.0.1:35699)(0x0003:0x42) DoUnbind on
connection 0x8181e0817 17:01:33 B43ADBA0 LDAP: Connection
0x8181e08 closed
TRACE 2 - Same ldapsearch, test with the environment variable NDSD_TRY_NMASLOGIN_FIRST=true set in the ndsd script (LDAP binds are NMAS-enabled), but the user does not yet have a Universal Password policy or password.
As you can see, this trace is significantly busier than TRACE 1. This time, the LDAP bind is using NMAS for authentication but without a Universal Password policy or password. The old NDS Password is used for the bind, as shown by line 28: MAF_GetNDSPasswordHash LSM 0x00000007.
1 17:29:55 B4F1FBA0
LDAP: New cleartext connection 0x81c3990 from 127.0.0.1:39779,
monitor = 0xb371fba0, index = 12 17:29:55 948B0BA0 LDAP:
(127.0.0.1:39779)(0x0001:0x60) DoBind on connection 0x81c39903
17:29:55 948B0BA0 LDAP: (127.0.0.1:39779)(0x0001:0x60) Bind
name:cn=up1,ou=HQusers,o=corp, version:3, authentication:simple4
17:29:55 948B0BA0 NMAS: 11: Create NMAS Session5 17:29:55
948B0BA0 NMAS: 11: CheckIfLocalUser: client supplied user DN
CN=up1.OU=HQusers.O=CORP6 17:29:55 948B0BA0 NMAS: 11:
CheckIfLocalUser: checking actual user DN CN=up1.OU=HQusers.O=CORP7
17:29:55 948B0BA0 NMAS: 11: Create thread request8 17:29:55
948B0BA0 NMAS: 11: Using thread 0x817ee209 17:29:55 948B0BA0
NMAS: 11: Server thread started10 17:29:55 948B0BA0 NMAS: 11:
NMAS_CanDo StartClientSession 011 17:29:55 948B0BA0 NMAS: 11:
ClientPut: message size=8 queue Size 012 17:29:55 948B0BA0 NMAS:
11: ClientPut: message size=7 queue Size 813 17:29:55 948B0BA0
NMAS: 11: NMAS_CanDo sendMessage 014 17:29:55 948B0BA0 NMAS: 11:
ClientGet: message size=8 queue Size 015 17:29:55 950B0BA0 NMAS:
11: Pool thread 0x817ee20 awake with new work16 17:29:55 950B0BA0
NMAS: 11: ServerGet: message size=8 queue size 1517 17:29:55
950B0BA0 NMAS: 11: ServerGet: message size=7 queue size 718
17:29:55 950B0BA0 NMAS: 11: CanDo19 17:29:55 950B0BA0 NMAS: 11:
updateLoginStatistics configured failed login delay 320 17:29:55
950B0BA0 NMAS: 11: Found default login sequence NDS for
up1.HQusers.CORP21 17:29:55 950B0BA0 NMAS: 11: Sequence Selected
== "NDS"22 17:29:55 950B0BA0 NMAS: 11: Login Method
0x0000000723 17:29:55 950B0BA0 NMAS: 11: MAF_GetAttribute LSM
0x00000007 AID: 124 17:29:55 950B0BA0 NMAS: 11: MAF_Begin LSM
0x0000000725 17:29:55 950B0BA0 NMAS: 11: ServerPut: message
size=8 queue size 026 17:29:55 950B0BA0 NMAS: 11: ServerPut:
message size=5 queue size 827 17:29:55 950B0BA0 NMAS: 11:
MAF_GetAttribute LSM 0x00000007 AID: 3928 17:29:55 950B0BA0 NMAS:
11: MAF_GetNDSPasswordHash LSM 0x0000000729 17:29:55
950B0BA0 NMAS: 11: MAF_Write LSM 0x0000000730 17:29:55 950B0BA0
NMAS: 11: ServerPut: message size=8 queue size 1331 17:29:55
950B0BA0 NMAS: 11: ServerPut: message size=40 queue size 2132
17:29:55 950B0BA0 NMAS: 11: MAF_XWrite LSM 0x0000000733 17:29:55
950B0BA0 NMAS: 11: ServerPut: message size=8 queue size 6134
17:29:55 950B0BA0 NMAS: 11: ServerPut: message size=36 queue size
6935 17:29:55 950B0BA0 NMAS: 11: MAF_XRead LSM 0x0000000736
17:29:55 950B0BA0 NMAS: 11: ServerGet: message size=8 queue size 037
17:29:55 948B0BA0 NMAS: 11: ClientGet: message size=5 queue Size
9738 17:29:55 948B0BA0 NMAS: 11: NMAS_CanDo getMessage 039
17:29:55 948B0BA0 NMAS: 11: NMAS_CanDo disassembleDoPacket 040
17:29:55 948B0BA0 NMAS: 11: MAF_Begin LCM 0x0000000741 17:29:55
948B0BA0 NMAS: 11: MAF_GetAttribute LCM 0x00000007 AID: 642
17:29:55 948B0BA0 NMAS: 11: MAF_GetAttribute LCM 0x00000007 AID: 143
17:29:55 948B0BA0 NMAS: 11: MAF_Read LCM 0x0000000744 17:29:55
948B0BA0 NMAS: 11: ClientGet: message size=8 queue Size 9245
17:29:55 948B0BA0 NMAS: 11: ClientGet: message size=40 queue Size
8446 17:29:55 948B0BA0 NMAS: 11: MAF_XRead LCM 0x0000000747
17:29:55 948B0BA0 NMAS: 11: ClientGet: message size=8 queue Size
4448 17:29:55 948B0BA0 NMAS: 11: ClientGet: message size=36 queue
Size 3649 17:29:55 948B0BA0 NMAS: 11: MAF_XWrite LCM
0x0000000750 17:29:55 948B0BA0 NMAS: 11: ClientPut: message
size=8 queue Size 051 17:29:55 948B0BA0 NMAS: 11: ClientPut:
message size=56 queue Size 852 17:29:55 948B0BA0 NMAS: 11:
MAF_XRead LCM 0x0000000753 17:29:55 948B0BA0 NMAS: 11: ClientGet:
message size=8 queue Size 054 17:29:55 950B0BA0 NMAS: 11:
ServerGet: message size=56 queue size 5655 17:29:55 950B0BA0
NMAS: 11: MAF_XWrite LSM 0x0000000756 17:29:55 950B0BA0 NMAS: 11:
ServerPut: message size=8 queue size 057 17:29:55 950B0BA0 NMAS:
11: ServerPut: message size=32 queue size 858 17:29:55 950B0BA0
NMAS: 11: MAF_Read LSM 0x0000000759 17:29:55 950B0BA0 NMAS: 11:
ServerGet: message size=8 queue size 060 17:29:55 948B0BA0 NMAS:
11: ClientGet: message size=32 queue Size 3261 17:29:55 948B0BA0
NMAS: 11: MAF_Write LCM 0x0000000762 17:29:55 948B0BA0 NMAS: 11:
ClientPut: message size=8 queue Size 063 17:29:55 948B0BA0 NMAS:
11: ClientPut: message size=12 queue Size 864 17:29:55 948B0BA0
NMAS: 11: MAF_End LCM 0x0000000765 17:29:55 948B0BA0 NMAS: 11:
ClientPut: message size=8 queue Size 2066 17:29:55 948B0BA0 NMAS:
11: ClientGet: message size=8 queue Size 067 17:29:55 950B0BA0
NMAS: 11: ServerGet: message size=12 queue size 2068 17:29:55
950B0BA0 NMAS: 11: MAF_End LSM 0x00000007 successful69 17:29:55
950B0BA0 NMAS: 11: ServerGet: message size=8 queue size 870
17:29:55 950B0BA0 NMAS: 11: WhatNext71 17:29:55 950B0BA0 NMAS:
11: Successful login72 17:29:55 950B0BA0 NMAS: 11: ServerPut:
message size=8 queue size 073 17:29:55 950B0BA0 NMAS: 11:
ServerPut: message size=4 queue size 874 17:29:55 948B0BA0 NMAS:
11: ClientGet: message size=4 queue Size 475 17:29:55 948B0BA0
NMAS: 11: ClientPut: message size=8 queue Size 076 17:29:55
948B0BA0 NMAS: 11: ClientGet: message size=8 queue Size 077
17:29:55 950B0BA0 NMAS: 11: ServerGet: message size=8 queue size 878
17:29:55 950B0BA0 NMAS: 11: ServerPut: message size=8 queue size 079
17:29:55 950B0BA0 NMAS: 11: Server thread exited80 17:29:55
950B0BA0 NMAS: 11: Pool thread 0x817ee20 work complete81 17:29:55
948B0BA0 NMAS: 11: Client Session Destroy Request82 17:29:55
948B0BA0 NMAS: 11: Local Session Cleared (Not Destroyed)83
17:29:55 948B0BA0 LDAP: (127.0.0.1:39779)(0x0001:0x60) Sending
operation result 0:"":"" to connection
0x81c399084 17:29:55 948B0BA0 LDAP:
(127.0.0.1:39779)(0x0002:0x63) DoSearch on connection 0x81c399085
17:29:55 948B0BA0 LDAP: (127.0.0.1:39779)(0x0002:0x63) Search
request:86 base: ""87 scope:1 dereference:0
sizelimit:0 timelimit:0 attrsonly:088 filter:
"(objectclass=*)"89 no attributes90 17:29:55
948B0BA0 LDAP: (127.0.0.1:39779)(0x0002:0x63) Empty attribute list
implies all user attributes91 17:29:55 948B0BA0 LDAP:
(127.0.0.1:39779)(0x0002:0x63) Sending search result entry "o=CORP"
to connection 0x81c399092 17:29:55 948B0BA0 LDAP:
(127.0.0.1:39779)(0x0002:0x63) Sending search result entry
"cn=Security" to connection 0x81c399093 17:29:55
948B0BA0 LDAP: (127.0.0.1:39779)(0x0002:0x63) Sending operation
result 0:"":"" to connection 0x81c399094
17:29:55 B1F1FBA0 LDAP: (127.0.0.1:39779)(0x0003:0x42) DoUnbind on
connection 0x81c399095 17:29:55 B1F1FBA0 LDAP: Connection
0x81c3990 closed
TRACE 3 - Same ldapsearch test by the up1 user, with the environment variable "NDSD_TRY_NMASLOGIN_FIRST=true" set in the ndsd script. The user has a Universal Password policy and a Universal Password password set via iManager by an administrator.
As you can see, this trace is very similar to TRACE 2. This time, the LDAP bind is using NMAS for authentication, but with a Universal Password policy and password. So, the old Universal Password is used for the bind (as shown by line 28: MAF_GetPassword LSM 0x00000007) as
opposed to the MAF_GetNDSPasswordHash LSM 0x00000007 on line 28 of TRACE 2.
1 17:38:32 B4F1FBA0
LDAP: New cleartext connection 0x8583250 from 127.0.0.1:54119,
monitor = 0x944b0ba0, index = 22 17:38:32 B131FBA0 LDAP:
(127.0.0.1:54119)(0x0001:0x60) DoBind on connection 0x85832503
17:38:32 B131FBA0 LDAP: (127.0.0.1:54119)(0x0001:0x60) Bind
name:cn=up1,ou=HQusers,o=corp, version:3, authentication:simple4
17:38:32 B131FBA0 NMAS: 13: Create NMAS Session5 17:38:32
B131FBA0 NMAS: 13: CheckIfLocalUser: client supplied user DN
CN=up1.OU=HQusers.O=CORP6 17:38:32 B131FBA0 NMAS: 13:
CheckIfLocalUser: checking actual user DN CN=up1.OU=HQusers.O=CORP7
17:38:32 B131FBA0 NMAS: 13: Create thread request8 17:38:32
B131FBA0 NMAS: 13: Using thread 0x817ee209 17:38:32 B131FBA0
NMAS: 13: Server thread started10 17:38:32 B131FBA0 NMAS: 13:
NMAS_CanDo StartClientSession 011 17:38:32 B131FBA0 NMAS: 13:
ClientPut: message size=8 queue Size 012 17:38:32 B131FBA0 NMAS:
13: ClientPut: message size=7 queue Size 813 17:38:32 B131FBA0
NMAS: 13: NMAS_CanDo sendMessage 014 17:38:32 B131FBA0 NMAS: 13:
ClientGet: message size=8 queue Size 015 17:38:32 950B0BA0 NMAS:
13: Pool thread 0x817ee20 awake with new work16 17:38:32 950B0BA0
NMAS: 13: ServerGet: message size=8 queue size 1517 17:38:32
950B0BA0 NMAS: 13: ServerGet: message size=7 queue size 718
17:38:32 950B0BA0 NMAS: 13: CanDo19 17:38:32 950B0BA0 NMAS: 13:
updateLoginStatistics configured failed login delay 320 17:38:32
950B0BA0 NMAS: 13: Found default login sequence NDS for
up1.HQusers.CORP21 17:38:32 950B0BA0 NMAS: 13: Sequence Selected
== "NDS"22 17:38:32 950B0BA0 NMAS: 13: Login Method
0x0000000723 17:38:32 950B0BA0 NMAS: 13: MAF_GetAttribute LSM
0x00000007 AID: 124 17:38:32 950B0BA0 NMAS: 13: MAF_Begin LSM
0x0000000725 17:38:32 950B0BA0 NMAS: 13: ServerPut: message
size=8 queue size 026 17:38:32 950B0BA0 NMAS: 13: ServerPut:
message size=5 queue size 827 17:38:32 950B0BA0 NMAS: 13:
MAF_GetAttribute LSM 0x00000007 AID: 3928 17:38:32 950B0BA0 NMAS:
13: MAF_GetPassword LSM 0x0000000729 17:38:32 950B0BA0
NMAS: 13: MAF_Write LSM 0x0000000730 17:38:32 950B0BA0 NMAS: 13:
ServerPut: message size=8 queue size 1331 17:38:32 950B0BA0 NMAS:
13: ServerPut: message size=40 queue size 2132 17:38:32 950B0BA0
NMAS: 13: MAF_XWrite LSM 0x0000000733 17:38:32 950B0BA0 NMAS: 13:
ServerPut: message size=8 queue size 6134 17:38:32 950B0BA0 NMAS:
13: ServerPut: message size=36 queue size 6935 17:38:32 950B0BA0
NMAS: 13: MAF_XRead LSM 0x0000000736 17:38:32 950B0BA0 NMAS: 13:
ServerGet: message size=8 queue size 037 17:38:32 B131FBA0 NMAS:
13: ClientGet: message size=5 queue Size 9738 17:38:32 B131FBA0
NMAS: 13: NMAS_CanDo getMessage 039 17:38:32 B131FBA0 NMAS: 13:
NMAS_CanDo disassembleDoPacket 040 17:38:32 B131FBA0 NMAS: 13:
MAF_Begin LCM 0x0000000741 17:38:32 B131FBA0 NMAS: 13:
MAF_GetAttribute LCM 0x00000007 AID: 642 17:38:32 B131FBA0 NMAS:
13: MAF_GetAttribute LCM 0x00000007 AID: 143 17:38:32 B131FBA0
NMAS: 13: MAF_Read LCM 0x0000000744 17:38:32 B131FBA0 NMAS: 13:
ClientGet: message size=8 queue Size 9245 17:38:32 B131FBA0 NMAS:
13: ClientGet: message size=40 queue Size 8446 17:38:32 B131FBA0
NMAS: 13: MAF_XRead LCM 0x0000000747 17:38:32 B131FBA0 NMAS: 13:
ClientGet: message size=8 queue Size 4448 17:38:32 B131FBA0 NMAS:
13: ClientGet: message size=36 queue Size 3649 17:38:32 B131FBA0
NMAS: 13: MAF_XWrite LCM 0x0000000750 17:38:32 B131FBA0 NMAS: 13:
ClientPut: message size=8 queue Size 051 17:38:32 B131FBA0 NMAS:
13: ClientPut: message size=56 queue Size 852 17:38:32 B131FBA0
NMAS: 13: MAF_XRead LCM 0x0000000753 17:38:32 B131FBA0 NMAS: 13:
ClientGet: message size=8 queue Size 054 17:38:32 950B0BA0 NMAS:
13: ServerGet: message size=56 queue size 5655 17:38:32 950B0BA0
NMAS: 13: MAF_XWrite LSM 0x0000000756 17:38:32 950B0BA0 NMAS: 13:
ServerPut: message size=8 queue size 057 17:38:32 950B0BA0 NMAS:
13: ServerPut: message size=32 queue size 858 17:38:32 950B0BA0
NMAS: 13: MAF_Read LSM 0x0000000759 17:38:32 950B0BA0 NMAS: 13:
ServerGet: message size=8 queue size 060 17:38:32 B131FBA0 NMAS:
13: ClientGet: message size=32 queue Size 3261 17:38:32 B131FBA0
NMAS: 13: MAF_Write LCM 0x0000000762 17:38:32 B131FBA0 NMAS: 13:
ClientPut: message size=8 queue Size 063 17:38:32 B131FBA0 NMAS:
13: ClientPut: message size=12 queue Size 864 17:38:32 B131FBA0
NMAS: 13: MAF_End LCM 0x0000000765 17:38:32 B131FBA0 NMAS: 13:
ClientPut: message size=8 queue Size 2066 17:38:32 B131FBA0 NMAS:
13: ClientGet: message size=8 queue Size 067 17:38:32 950B0BA0
NMAS: 13: ServerGet: message size=12 queue size 2068 17:38:32
950B0BA0 NMAS: 13: MAF_End LSM 0x00000007 successful69 17:38:32
950B0BA0 NMAS: 13: ServerGet: message size=8 queue size 870
17:38:32 950B0BA0 NMAS: 13: WhatNext71 17:38:32 950B0BA0 NMAS:
13: Successful login72 17:38:32 950B0BA0 NMAS: 13: ServerPut:
message size=8 queue size 073 17:38:32 950B0BA0 NMAS: 13:
ServerPut: message size=4 queue size 874 17:38:32 B131FBA0 NMAS:
13: ClientGet: message size=4 queue Size 475 17:38:32 B131FBA0
NMAS: 13: ClientPut: message size=8 queue Size 076 17:38:32
B131FBA0 NMAS: 13: ClientGet: message size=8 queue Size 077
17:38:32 950B0BA0 NMAS: 13: ServerGet: message size=8 queue size 878
17:38:32 950B0BA0 NMAS: 13: ServerPut: message size=8 queue size 079
17:38:32 950B0BA0 NMAS: 13: Server thread exited80 17:38:32
950B0BA0 NMAS: 13: Pool thread 0x817ee20 work complete81 17:38:32
B131FBA0 NMAS: 13: Client Session Destroy Request82 17:38:32
B131FBA0 NMAS: 13: Local Session Cleared (Not Destroyed)83
17:38:32 B131FBA0 LDAP: (127.0.0.1:54119)(0x0001:0x60) Sending
operation result 0:"":"" to connection
0x858325084 17:38:32 B131FBA0 LDAP:
(127.0.0.1:54119)(0x0002:0x63) DoSearch on connection 0x858325085
17:38:32 B131FBA0 LDAP: (127.0.0.1:54119)(0x0002:0x63) Search
request:86 base: ""87 scope:1 dereference:0
sizelimit:0 timelimit:0 attrsonly:088 filter:
"(objectclass=*)"89 no attributes90 17:38:32
B131FBA0 LDAP: (127.0.0.1:54119)(0x0002:0x63) Empty attribute list
implies all user attributes91 17:38:32 B131FBA0 LDAP:
(127.0.0.1:54119)(0x0002:0x63) Sending search result entry "o=CORP"
to connection 0x858325092 17:38:32 B131FBA0 LDAP:
(127.0.0.1:54119)(0x0002:0x63) Sending search result entry
"cn=Security" to connection 0x858325093 17:38:32
B131FBA0 LDAP: (127.0.0.1:54119)(0x0002:0x63) Sending operation
result 0:"":"" to connection 0x858325094
17:38:32 B1F1FBA0 LDAP: (127.0.0.1:54119)(0x0003:0x42) DoUnbind on
connection 0x858325095 17:38:32 B1F1FBA0 LDAP: Connection
0x8583250 closed
TRACE 4 - ldapsearch test by the noup1 user, with the environment variable "NDSD_TRY_NMASLOGIN_FIRST=true" set in the ndsd script. The user has a Universal Password policy but has not yet established a Universal Password password.
This trace is slightly longer than the previous traces. This makes sense, since more will happen in this situation. In this trace, the NDS Password is used for this authentication (line 39: MAF_GetNDSPasswordHash LSM 0x00000007), but the password entered by our user is also used to create their Universal Password (line 76: Successful set password for CN=noup1.OU=HQusers.O=CORP).
1 17:56:23 B4F1FBA0
LDAP: New cleartext connection 0x8583250 from 127.0.0.1:35017,
monitor = 0x944b0ba0, index = 22 17:56:23 B6F1FBA0 LDAP:
(127.0.0.1:35017)(0x0001:0x60) DoBind on connection 0x85832503
17:56:23 B6F1FBA0 LDAP: (127.0.0.1:35017)(0x0001:0x60) Bind
name:cn=noup1,ou=HQusers,o=corp, version:3, authentication:simple4
17:56:23 B6F1FBA0 NMAS: 15: Create NMAS Session5 17:56:23
B6F1FBA0 NMAS: 15: CheckIfLocalUser: client supplied user DN
CN=noup1.OU=HQusers.O=CORP6 17:56:23 B6F1FBA0 NMAS: 15:
CheckIfLocalUser: checking actual user DN
CN=noup1.OU=HQusers.O=CORP7 17:56:23 B6F1FBA0 NMAS: 15: Create
thread request8 17:56:23 B6F1FBA0 NMAS: 15: No free threads in
pool. Creating a new thread.9 17:56:23 B6F1FBA0 NMAS: 0: Created
thread 0x829af48, handle -179443824010 17:56:23 B6F1FBA0 NMAS:
15: Created a new thread. Pool contains 1 free threads, 0 running
threads11 17:56:23 B6F1FBA0 NMAS: 15: Using thread 0x829af4812
17:56:23 B6F1FBA0 NMAS: 15: Server thread started13 17:56:23
B6F1FBA0 NMAS: 15: NMAS_CanDo StartClientSession 014 17:56:23
B6F1FBA0 NMAS: 15: ClientPut: message size=8 queue Size 015
17:56:23 B6F1FBA0 NMAS: 15: ClientPut: message size=7 queue Size 816
17:56:23 B6F1FBA0 NMAS: 15: NMAS_CanDo sendMessage 017 17:56:23
B6F1FBA0 NMAS: 15: ClientGet: message size=8 queue Size 018
17:56:23 950B0BA0 NMAS: 15: Pool thread 0x829af48 awake with new
work19 17:56:23 950B0BA0 NMAS: 15: ServerGet: message size=8
queue size 1520 17:56:23 950B0BA0 NMAS: 15: ServerGet: message
size=7 queue size 721 17:56:23 950B0BA0 NMAS: 15: CanDo22
17:56:23 950B0BA0 NMAS: 15: updateLoginStatistics configured failed
login delay 323 17:56:23 950B0BA0 NMAS: 15: Found default login
sequence NDS for noup1.HQusers.CORP24 17:56:23 950B0BA0 NMAS: 15:
Sequence Selected == "NDS"25 17:56:23 950B0BA0 NMAS:
15: Login Method 0x0000000726 17:56:23 950B0BA0 NMAS: 15:
MAF_GetAttribute LSM 0x00000007 AID: 127 17:56:23 950B0BA0 NMAS:
15: MAF_Begin LSM 0x0000000728 17:56:23 950B0BA0 NMAS: 15:
ServerPut: message size=8 queue size 029 17:56:23 B6F1FBA0 NMAS:
15: ClientGet: message size=5 queue Size 030 17:56:23 950B0BA0
NMAS: 15: ServerPut: message size=5 queue size 031 17:56:23
B6F1FBA0 NMAS: 15: NMAS_CanDo getMessage 032 17:56:23 B6F1FBA0
NMAS: 15: NMAS_CanDo disassembleDoPacket 033 17:56:23 B6F1FBA0
NMAS: 15: MAF_Begin LCM 0x0000000734 17:56:23 B6F1FBA0 NMAS: 15:
MAF_GetAttribute LCM 0x00000007 AID: 635 17:56:23 B6F1FBA0 NMAS:
15: MAF_GetAttribute LCM 0x00000007 AID: 136 17:56:23 B6F1FBA0
NMAS: 15: MAF_Read LCM 0x0000000737 17:56:23 B6F1FBA0 NMAS: 15:
ClientGet: message size=8 queue Size 038 17:56:23 950B0BA0 NMAS:
15: MAF_GetAttribute LSM 0x00000007 AID: 3939 17:56:23 950B0BA0
NMAS: 15: MAF_GetNDSPasswordHash LSM 0x0000000740 17:56:23
950B0BA0 NMAS: 15: MAF_Write LSM 0x0000000741 17:56:23 950B0BA0
NMAS: 15: ServerPut: message size=8 queue size 042 17:56:23
B6F1FBA0 NMAS: 15: ClientGet: message size=40 queue Size 043
17:56:23 950B0BA0 NMAS: 15: ServerPut: message size=40 queue size
044 17:56:23 B6F1FBA0 NMAS: 15: MAF_XRead LCM 0x0000000745
17:56:23 B6F1FBA0 NMAS: 15: ClientGet: message size=8 queue Size 046
17:56:23 950B0BA0 NMAS: 15: MAF_XWrite LSM 0x0000000747 17:56:23
950B0BA0 NMAS: 15: ServerPut: message size=8 queue size 048
17:56:23 B6F1FBA0 NMAS: 15: ClientGet: message size=36 queue Size
049 17:56:23 950B0BA0 NMAS: 15: ServerPut: message size=36 queue
size 050 17:56:23 B6F1FBA0 NMAS: 15: MAF_XWrite LCM 0x0000000751
17:56:23 B6F1FBA0 NMAS: 15: ClientPut: message size=8 queue Size 052
17:56:23 B6F1FBA0 NMAS: 15: ClientPut: message size=56 queue Size
853 17:56:23 B6F1FBA0 NMAS: 15: MAF_XRead LCM 0x0000000754
17:56:23 B6F1FBA0 NMAS: 15: ClientGet: message size=8 queue Size 055
17:56:23 950B0BA0 NMAS: 15: MAF_XRead LSM 0x0000000756 17:56:23
950B0BA0 NMAS: 15: ServerGet: message size=8 queue size 6457
17:56:23 950B0BA0 NMAS: 15: ServerGet: message size=56 queue size
5658 17:56:23 950B0BA0 NMAS: 15: MAF_XWrite LSM 0x0000000759
17:56:23 950B0BA0 NMAS: 15: ServerPut: message size=8 queue size 060
17:56:23 B6F1FBA0 NMAS: 15: ClientGet: message size=32 queue Size
061 17:56:23 950B0BA0 NMAS: 15: ServerPut: message size=32 queue
size 062 17:56:23 B6F1FBA0 NMAS: 15: MAF_Write LCM 0x0000000763
17:56:23 B6F1FBA0 NMAS: 15: ClientPut: message size=8 queue Size 064
17:56:23 B6F1FBA0 NMAS: 15: ClientPut: message size=12 queue Size
865 17:56:23 B6F1FBA0 NMAS: 15: MAF_XWrite LCM 0x0000000766
17:56:23 B6F1FBA0 NMAS: 15: ClientPut: message size=8 queue Size 20
67 17:56:23 B6F1FBA0 NMAS: 15: ClientPut: message size=14 queue Size
2868 17:56:23 B6F1FBA0 NMAS: 15: MAF_Read LCM 0x0000000769
17:56:23 B6F1FBA0 NMAS: 15: ClientGet: message size=8 queue Size 070
17:56:23 950B0BA0 NMAS: 15: MAF_Read LSM 0x0000000771 17:56:23
950B0BA0 NMAS: 15: ServerGet: message size=8 queue size 4272
17:56:23 950B0BA0 NMAS: 15: ServerGet: message size=12 queue size
3473 17:56:23 950B0BA0 NMAS: 15: MAF_XRead LSM 0x0000000774
17:56:23 950B0BA0 NMAS: 15: ServerGet: message size=8 queue size
2275 17:56:23 950B0BA0 NMAS: 15: ServerGet: message size=14 queue
size 1476 17:56:23 950B0BA0 NMAS: Successful set password for
CN=noup1.OU=HQusers.O=CORP77 17:56:23 950B0BA0 NMAS: 15:
MAF_SetPassword LSM 0x0000000778 17:56:23 950B0BA0 NMAS: 15:
MAF_Write LSM 0x0000000779 17:56:23 950B0BA0 NMAS: 15: ServerPut:
message size=8 queue size 080 17:56:23 B6F1FBA0 NMAS: 15:
ClientGet: message size=12 queue Size 081 17:56:23 950B0BA0 NMAS:
15: ServerPut: message size=12 queue size 082 17:56:23 B6F1FBA0
NMAS: 15: MAF_End LCM 0x0000000783 17:56:23 B6F1FBA0 NMAS: 15:
ClientPut: message size=8 queue Size 084 17:56:23 B6F1FBA0 NMAS:
15: ClientGet: message size=8 queue Size 085 17:56:23 950B0BA0
NMAS: 15: MAF_End LSM 0x00000007 successful86 17:56:23 950B0BA0
NMAS: 15: ServerGet: message size=8 queue size 887 17:56:23
950B0BA0 NMAS: 15: WhatNext88 17:56:23 950B0BA0 NMAS: 15:
Successful login89 17:56:23 950B0BA0 NMAS: 15: ServerPut: message
size=8 queue size 090 17:56:23 B6F1FBA0 NMAS: 15: ClientGet:
message size=4 queue Size 091 17:56:23 950B0BA0 NMAS: 15:
ServerPut: message size=4 queue size 092 17:56:23 B6F1FBA0 NMAS:
15: ClientPut: message size=8 queue Size 093 17:56:23 B6F1FBA0
NMAS: 15: ClientGet: message size=8 queue Size 094 17:56:23
950B0BA0 NMAS: 15: ServerGet: message size=8 queue size 895
17:56:23 950B0BA0 NMAS: 15: ServerPut: message size=8 queue size 096
17:56:23 B6F1FBA0 NMAS: 15: Client Session Destroy Request97
17:56:23 B6F1FBA0 NMAS: 15: Local Session Cleared (Not Destroyed)98
17:56:23 B6F1FBA0 LDAP: (127.0.0.1:35017)(0x0001:0x60) Sending
operation result 0:"":"" to connection
0x858325099 17:56:23 B371FBA0 LDAP:
(127.0.0.1:35017)(0x0002:0x63) DoSearch on connection 0x8583250100
17:56:23 B371FBA0 LDAP: (127.0.0.1:35017)(0x0002:0x63) Search
request:101 base: ""102 scope:1 dereference:0
sizelimit:0 timelimit:0 attrsonly:0103 filter:
"(objectclass=*)"104 no attributes105 17:56:23
B371FBA0 LDAP: (127.0.0.1:35017)(0x0002:0x63) Empty attribute list
implies all user attributes106 17:56:23 B371FBA0 LDAP:
(127.0.0.1:35017)(0x0002:0x63) Sending search result entry "o=CORP"
to connection 0x8583250107 17:56:23 B371FBA0 LDAP:
(127.0.0.1:35017)(0x0002:0x63) Sending search result entry
"cn=Security" to connection 0x8583250108 17:56:23
B371FBA0 LDAP: (127.0.0.1:35017)(0x0002:0x63) Sending operation
result 0:"":"" to connection 0x8583250109
17:56:23 B3B1FBA0 LDAP: (127.0.0.1:35017)(0x0003:0x42) DoUnbind on
connection 0x8583250110 17:56:23 B3B1FBA0 LDAP: Connection
0x8583250 closed
Universal Password Settings
Policy Summary | Password Policy Summary:
Universal Password | Advanced Password Rules (1 of 2):
Universal Password | Advanced Password Rules (2 of 2):
Universal Password | Configuration Options:
Disclaimer: As with everything else at Cool Solutions, this content is definitely not supported by Novell (so don't even think of calling Support if you try something and it blows up).
It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test, test, test before you do anything drastic with it.
Related Articles
User Comments
Incorrect change recommendation for ndsd script
Submitted by aburgemeister on 7 March 2011 - 9:49am.
This change should NOT be set in /etc/init.d/ndsd directly as that file is owned by a package. The reason this is a problem is that subsequent eDirectory patches which include that package (most of them) will undo the setting leaving you in the situation where you were before making the change. To properly set things like this you should use the pre_ndsd_start script which is "sourced" before the ndsd script starts eDirectory.
- Be the first to comment! To leave a comment you need to Login or Register








1