Odd issue. LDAP is enabled and is working fine on the main application. CA SDM 17.0 running on 12R2.
The problem occurs when attempting to run pdm_ldap_import or pdm_ldap_sync. The following response is given:
See the variable by nx_env command is what sdm process got.
Have you defined the variable editing the nx.env or defined in the GUI ?
Please set the variable by this command line method, it update the nx.env and the Options
pdm_options_mgr -b -s LDAP_MAX_FETCH -v 100 -a pdm_option.inst
pdm_options_mgr -b -s LDAP_DN -v "cn=administrator,cn=Users,dc=sd,dc=local" -a pdm_option.instpdm_options_mgr -b -s LDAP_ENABLE -v Yes -a pdm_option.inst
..adapt the LDAP_DN to your context and define also your other LDAP variables by this method
I'm not sure what you mean when you say "LDAP is enabled and is working fine on the main application". Do you mean it's working on a particular server but not in another? Or is it working in another environment but not in this environment?
Can you please share the @NX_LDAP* parameters from your NX.env file. (@NX_LDAP_ENABLE=, @NX_LDAP_ENABLE_AUTO=, @NX_LDAP_ENABLE_GROUPS=, etc)
What happens when you run the command 'pdm_ldap_test' on the Primary or BG server?
This is the test environment. Conventional installation.
I mean that certain functions of LDAP appear to be working. Such as contact merge. But LDAP sync/import are not. This is all within the same environment.
Requested variables (certain variables have been edited to comply with our security policies):
Running pdm_ldap_test returns the following:
NUM_LDAP_AGENTS option is not installed by default, I'm wondering if that's the case you have here. You'd have to install that option too to enable the LDAP agents to connect to LDAP.
usp_contact and ca_contact are couple of tables you'd want to backup as Mahesh mentioned earlier.
Is the CASM 17 installation was successful or were there any error messages? Is this a test / Dev environment? If so could you run the pdm_ldap_sync command to check the behavior?
Note: Please take a backup of your ca_contact table so that if there is any unwanted data corruption we can always replace the original data from the backup.
CA SDM installation to 17.0 completed without any issue. Test environment.
pdm_ldap_sync returns the same error message as posted above as well as pdm_ldap_test
We can do whatever with this environment not a problem.
Please check the Options MDB database table and verify that the LDAP options have the same values as specified in the NX.ENV file.
Perhaps the Options table and the NX.ENV file are out of sync?
Hi Paul ...
Review of dbo.options reveals:
That the values that were deinstalled earlier are also shown as deinstalled via the value col
All other values appear to be the same between the GUI and the NX and the table
Please, could you try after deinstall the 2 options related to group ? I mean:
After deinstall these options (used for ldap group import too) you will need to restart the ServiceDesk service.
Please, let us know if this helps.
Also, if problem persists after this, let us know if you have any ldap.mod under your site/mods folder and if any additional error in the stdlog files (see TEC370303 for ldap troubleshooting basics).
Deinstalled the two fields as suggested. No change when running pdm_ldap_test still receive the following:
No ldap.mod file is present in the site/mods.
I do not see anything specific in STDLOG ... general shutdown and startup of all the functions during the service restart. But no errors are present.
I have tested the behavior in house without any LDAP configuration and I noted the same error message.
"LDAP is not enabled".
Could you confirm if you are able to access the LDAP host name from the SDM server? check if the port is listening?
Do you note any socket_port error message in stdlogs?
Try a recycle / reboot of this machine for clean connectivity and check the behavior once again?
Test of the ldap_host results in a ping response (reply) that checks out normal.
Netstat -ano|findstr on both 389/and LDAPS 636 show as listening on the test environment.
There are a number of socket_port errors within STDLOG but none since 09/10. Which is (pre) a number of these tests. But...
09/10 11:15:44.57 WTDHSWEBL18 slump_nxd 2772 ERROR socket_port.c 1335 SLUMP server: Couldn't write redirect (WSAECONNRESET (10054))
09/10 11:12:44.88 WTDHSWEBL18 bpebr_nxd 6020 ERROR socket_port.c 1616 Got invalid TCP/IP header - dropping SOCKET_PORT(0x0132DD10) description = socket port port_name = status = 0 ip address = 188.8.131.52 compression = 1 extra_flags = 0 file descriptor = 344 write pending = 0 handler type = DATA read count = 0 write count = 0 socket = 0
Attempted complete reboot of the machine. Attempted pdm_ldap_test:
_R (Update from Raghu)
I can attempt this. However the pdm_ldap commands work fine on our production environment. This environment does not have this option installed either.
It is strange ldap integration working from the web interface and not working for pdm_ldap_..... commands. This could happen if NX.env has been updated and sd service not restarted yet, or an option has been modified in option manager and service not restarted yet, or the options in the mdb table not in sync ... this has been already pointed and the service has been already restarted .... so, perhaps may be worth to check if there is another NX.env file being taken only by the pdm_ldap_... commands instead of the correct NX.env file in the servicedesk root directory (check in Primary and Secondary)
Just in case it helps ....
I show only one NX file within the root directory... these is no primary and secondary on the test environment (conventional).
Could try a pdm_configure?...
The system has already been restarted which should resolve most of the other options that are currently on that list.
From the discussion and test done, we may be in this situation.
The nx.env in servicedesk root directory state ldap_enable=yes@NX_LDAP_ENABLE=Yes
But servicedesk seems to not use it
We have this side effect to take account
We are expecting servicedesk use NX_ROOT\nx.env , but when c:\nx.env exist , it will be used
execute nx_env at the command prompt to see the current value
If you have nx.env on the root of the drive, stop sdm, move the c:\nx.env to another folder , restart sdm and test again
Here are my results:
The issue you described does not appear to be a problem within this environment.
For any reason you are no seeing the ldap_enable variable definition.
Note that nx_env command display all the servicedesk environment variables and then if you run following command you should see the ldap_enable definition as:
If nx_env is not displaying the ldap_enable variable (check if just running nx_env command it is displaying the rest of NX_LDAP_ .... variables and the rest of servicedesk environment variables) , it could be, as already pointed, that at command line, the NX.env file being accessed is not the one you think. To be sure about this, if you do any modification in any of the servicedesk environment variables, the nx_env command should display the modification.
I hope this helps ...
Looking above. It seems to me that nx_env might be a spelling error?
As if I do ...
Which is correct to the changes that were previously made. Unless, I'm following incorrectly.
I wonder if the following tracing will reveal more information in the SDM STDLOGs and LDAP logs
pdm_logstat -f ldap_sync.c VERBOSE
Done. Tested to get error and found the functionality was working.
I see in your screen shot c:\program file(x86)...
Please verify you have 8.3 activated
Some features and commands from SDM doesn't works if 8.3 not active
we should have PROGRA~2nxcd should change to a folder with PROGRA~2
I think we are good ...
Our system above.
Not sure which step above resolved the problem. I'm thinking this section of commands was the change point ...
pdm_options_mgr -b -s LDAP_MAX_FETCH -v 100 -a pdm_option.instpdm_options_mgr -b -s LDAP_DN -v "cn=administrator,cn=Users,dc=sd,dc=local" -a pdm_option.instpdm_options_mgr -b -s LDAP_ENABLE -v Yes -a pdm_option.inst
But upon re-attempt of the command. I'm not getting a response from system:
Thank you all for your help!
Retrieving data ...