Has anyone used AD authentication for ODBC connectivity to Unidata/Uniobjects on Redhat?
Working on a project to migrate from AIX to Redhat Linux. AD authentication for users to login via ssh to the server and run the application is working. But a small subset of the users have ODBC connections from Excel/Access for some critical pieces. Authenticating with a local account works, but for various reasons the goal is to eliminate local accounts on the server and have everything controlled by AD. There's an error when connecting via ODBC that is hard to diagnose - I do see some errors in /var/log/messages that look like a process is core dumping, but nothing in the Unidata logs.
Anyone doing this successfully and have hints about what made it work?
------------------------------
Ian McGowan
Principal Consultant
Rocket Forum Shared Account
------------------------------
Page 1 / 1
Has anyone used AD authentication for ODBC connectivity to Unidata/Uniobjects on Redhat?
Working on a project to migrate from AIX to Redhat Linux. AD authentication for users to login via ssh to the server and run the application is working. But a small subset of the users have ODBC connections from Excel/Access for some critical pieces. Authenticating with a local account works, but for various reasons the goal is to eliminate local accounts on the server and have everything controlled by AD. There's an error when connecting via ODBC that is hard to diagnose - I do see some errors in /var/log/messages that look like a process is core dumping, but nothing in the Unidata logs.
Anyone doing this successfully and have hints about what made it work?
------------------------------
Ian McGowan
Principal Consultant
Rocket Forum Shared Account
------------------------------
Working on a project to migrate from AIX to Redhat Linux. AD authentication for users to login via ssh to the server and run the application is working. But a small subset of the users have ODBC connections from Excel/Access for some critical pieces. Authenticating with a local account works, but for various reasons the goal is to eliminate local accounts on the server and have everything controlled by AD. There's an error when connecting via ODBC that is hard to diagnose - I do see some errors in /var/log/messages that look like a process is core dumping, but nothing in the Unidata logs.
Anyone doing this successfully and have hints about what made it work?
------------------------------
Ian McGowan
Principal Consultant
Rocket Forum Shared Account
------------------------------
A few questions and tips for you on helping to isolate the problem
What version of the ODBC driver are you using. The latest is 7.241.02.9004, downloadable with the latest version of the U2 Clients released yesterday. I would suggest upgrading to that version as a starting point if you have not.
What version of UniData are you using. The latest version is 8.2.4.3001.
Have you tried setting up an ODBC side server log via the ud_database entry with TRACE_LEVEL to 3 to see if the server side log provides provides any information. See https://my.rocketsoftware.com/RocketCommunity/articles/Tech_Note/How-can-you-set-up-a-UniData-ODBC-or-OLEDB-server-log-1478610426287
There is also the ability to turn the debug log for the unirpc process that spawns the odbc process as well although I don't expect that to provide too much in this case. See https://my.rocketsoftware.com/RocketCommunity/articles/Tech_Note/How-can-you-run-unirpcd-daemon-with-debug-mode-on-background-process-1478612188644
You can also turn ODBC logging on the client itself as well.
Hopefully these logs will provide some insight into the problem for you. If they do not help you resolve the issue, these are the same logs we would ask from you in support to look into the problem.
Thanks,
Jonathan
------------------------------
Jonathan Smith
UniData ATS
Rocket Support
------------------------------
Ian,
A few questions and tips for you on helping to isolate the problem
What version of the ODBC driver are you using. The latest is 7.241.02.9004, downloadable with the latest version of the U2 Clients released yesterday. I would suggest upgrading to that version as a starting point if you have not.
What version of UniData are you using. The latest version is 8.2.4.3001.
Have you tried setting up an ODBC side server log via the ud_database entry with TRACE_LEVEL to 3 to see if the server side log provides provides any information. See https://my.rocketsoftware.com/RocketCommunity/articles/Tech_Note/How-can-you-set-up-a-UniData-ODBC-or-OLEDB-server-log-1478610426287
There is also the ability to turn the debug log for the unirpc process that spawns the odbc process as well although I don't expect that to provide too much in this case. See https://my.rocketsoftware.com/RocketCommunity/articles/Tech_Note/How-can-you-run-unirpcd-daemon-with-debug-mode-on-background-process-1478612188644
You can also turn ODBC logging on the client itself as well.
Hopefully these logs will provide some insight into the problem for you. If they do not help you resolve the issue, these are the same logs we would ask from you in support to look into the problem.
Thanks,
Jonathan
------------------------------
Jonathan Smith
UniData ATS
Rocket Support
------------------------------
A few questions and tips for you on helping to isolate the problem
What version of the ODBC driver are you using. The latest is 7.241.02.9004, downloadable with the latest version of the U2 Clients released yesterday. I would suggest upgrading to that version as a starting point if you have not.
What version of UniData are you using. The latest version is 8.2.4.3001.
Have you tried setting up an ODBC side server log via the ud_database entry with TRACE_LEVEL to 3 to see if the server side log provides provides any information. See https://my.rocketsoftware.com/RocketCommunity/articles/Tech_Note/How-can-you-set-up-a-UniData-ODBC-or-OLEDB-server-log-1478610426287
There is also the ability to turn the debug log for the unirpc process that spawns the odbc process as well although I don't expect that to provide too much in this case. See https://my.rocketsoftware.com/RocketCommunity/articles/Tech_Note/How-can-you-run-unirpcd-daemon-with-debug-mode-on-background-process-1478612188644
You can also turn ODBC logging on the client itself as well.
Hopefully these logs will provide some insight into the problem for you. If they do not help you resolve the issue, these are the same logs we would ask from you in support to look into the problem.
Thanks,
Jonathan
------------------------------
Jonathan Smith
UniData ATS
Rocket Support
------------------------------
------------------------------
Ian McGowan
Principal Consultant
Rocket Forum Shared Account
------------------------------
Ian,
A few questions and tips for you on helping to isolate the problem
What version of the ODBC driver are you using. The latest is 7.241.02.9004, downloadable with the latest version of the U2 Clients released yesterday. I would suggest upgrading to that version as a starting point if you have not.
What version of UniData are you using. The latest version is 8.2.4.3001.
Have you tried setting up an ODBC side server log via the ud_database entry with TRACE_LEVEL to 3 to see if the server side log provides provides any information. See https://my.rocketsoftware.com/RocketCommunity/articles/Tech_Note/How-can-you-set-up-a-UniData-ODBC-or-OLEDB-server-log-1478610426287
There is also the ability to turn the debug log for the unirpc process that spawns the odbc process as well although I don't expect that to provide too much in this case. See https://my.rocketsoftware.com/RocketCommunity/articles/Tech_Note/How-can-you-run-unirpcd-daemon-with-debug-mode-on-background-process-1478612188644
You can also turn ODBC logging on the client itself as well.
Hopefully these logs will provide some insight into the problem for you. If they do not help you resolve the issue, these are the same logs we would ask from you in support to look into the problem.
Thanks,
Jonathan
------------------------------
Jonathan Smith
UniData ATS
Rocket Support
------------------------------
A few questions and tips for you on helping to isolate the problem
What version of the ODBC driver are you using. The latest is 7.241.02.9004, downloadable with the latest version of the U2 Clients released yesterday. I would suggest upgrading to that version as a starting point if you have not.
What version of UniData are you using. The latest version is 8.2.4.3001.
Have you tried setting up an ODBC side server log via the ud_database entry with TRACE_LEVEL to 3 to see if the server side log provides provides any information. See https://my.rocketsoftware.com/RocketCommunity/articles/Tech_Note/How-can-you-set-up-a-UniData-ODBC-or-OLEDB-server-log-1478610426287
There is also the ability to turn the debug log for the unirpc process that spawns the odbc process as well although I don't expect that to provide too much in this case. See https://my.rocketsoftware.com/RocketCommunity/articles/Tech_Note/How-can-you-run-unirpcd-daemon-with-debug-mode-on-background-process-1478612188644
You can also turn ODBC logging on the client itself as well.
Hopefully these logs will provide some insight into the problem for you. If they do not help you resolve the issue, these are the same logs we would ask from you in support to look into the problem.
Thanks,
Jonathan
------------------------------
Jonathan Smith
UniData ATS
Rocket Support
------------------------------
We did find an error in /var/log/messages that correlated with each AD login attempt - looks like udsrvd is core dumping in a call to libc. Perhaps some server configuration setting missing. It does work fine with a local login (one that's in /etc/passwd, as opposed to an AD login).
This might be more than the forums are designed to handle. Might be better to open a ticket through the VAR which will eventually make its way to a Rocket ticket, unless there's something obvious that jumps out from this error of course :_)
------------------------------
Ian McGowan
Principal Consultant
Rocket Forum Shared Account
------------------------------
Thanks Jonathan, it was very helpful to be able to see something in the logs to prove that requests were being made. The unirpcd log shows requests coming in, but wasn't able to get the TRACE_LEVEL logs to appear in /tmp.
We did find an error in /var/log/messages that correlated with each AD login attempt - looks like udsrvd is core dumping in a call to libc. Perhaps some server configuration setting missing. It does work fine with a local login (one that's in /etc/passwd, as opposed to an AD login).
This might be more than the forums are designed to handle. Might be better to open a ticket through the VAR which will eventually make its way to a Rocket ticket, unless there's something obvious that jumps out from this error of course :_)
------------------------------
Ian McGowan
Principal Consultant
Rocket Forum Shared Account
------------------------------
We did find an error in /var/log/messages that correlated with each AD login attempt - looks like udsrvd is core dumping in a call to libc. Perhaps some server configuration setting missing. It does work fine with a local login (one that's in /etc/passwd, as opposed to an AD login).
This might be more than the forums are designed to handle. Might be better to open a ticket through the VAR which will eventually make its way to a Rocket ticket, unless there's something obvious that jumps out from this error of course :_)
------------------------------
Ian McGowan
Principal Consultant
Rocket Forum Shared Account
------------------------------
I agree it might be better dealt with via a support call, so we can instruct you how to put a debug version of udsrvd in place and get a meaningful core file for us to look at. What version of UniData are you using I would strongly suggest to use the latest 8.2.4.3001 as it does contain a memory allocation fix for the udsrvd process. I would also suggest upgrading to the latest ODBC drivers.
Thanks,
Jonathan
------------------------------
Jonathan Smith
UniData ATS
Rocket Support
------------------------------
Has anyone used AD authentication for ODBC connectivity to Unidata/Uniobjects on Redhat?
Working on a project to migrate from AIX to Redhat Linux. AD authentication for users to login via ssh to the server and run the application is working. But a small subset of the users have ODBC connections from Excel/Access for some critical pieces. Authenticating with a local account works, but for various reasons the goal is to eliminate local accounts on the server and have everything controlled by AD. There's an error when connecting via ODBC that is hard to diagnose - I do see some errors in /var/log/messages that look like a process is core dumping, but nothing in the Unidata logs.
Anyone doing this successfully and have hints about what made it work?
------------------------------
Ian McGowan
Principal Consultant
Rocket Forum Shared Account
------------------------------
Working on a project to migrate from AIX to Redhat Linux. AD authentication for users to login via ssh to the server and run the application is working. But a small subset of the users have ODBC connections from Excel/Access for some critical pieces. Authenticating with a local account works, but for various reasons the goal is to eliminate local accounts on the server and have everything controlled by AD. There's an error when connecting via ODBC that is hard to diagnose - I do see some errors in /var/log/messages that look like a process is core dumping, but nothing in the Unidata logs.
Anyone doing this successfully and have hints about what made it work?
------------------------------
Ian McGowan
Principal Consultant
Rocket Forum Shared Account
------------------------------
It could also be useful to know the exact authentication method used for AD - I am assuming a standard Windows AD domain. Please confirm if using PAM (Pluggable Authentication Module) and whether there is another authentication layer involved e.g. LDAP or SSSD.
As per Jonathan's advice - I recommend on using the most recent ODBC client software.
Regards,
John Jenkins
------------------------------
John Jenkins
Thame, Oxfordshire
------------------------------
Sign up
Already have an account? Login
Welcome to the Rocket Forum!
Please log in or register:
Employee Login | Registration Member Login | RegistrationEnter your E-mail address. We'll send you an e-mail with instructions to reset your password.
77 4th Avenue
Waltham, MA 02451 USA
