Troubleshoot connection error 80011 InfoSphere Information Server DataStage Troubleshoot connection error 80011 This presentation will discuss how to troubleshoot the InfoSphere™ Information Server DataStage® client connection error 80011. Objectives Objectives What does the error 80011 mean What problems will cause this error to occur How to troubleshoot the problem How to resolve the error The objectives of this presentation are to discuss the meaning of the 80011 error, the different scenarios that can cause this issue, steps necessary to troubleshoot the problem, and how to resolve the issue. What is error 80011? What is error 80011? Failed to connect to DataStage server: , project: (User name and/or password incorrect (80011)). This error indicates that the login to the DataStage server failed Many things can cause this error to occur Does not necessarily mean the password is incorrect What does the error 80011 mean? The full error message that you will see from the DataStage login screen is: Failed to connect to DataStage server: , project: (User name and/or password incorrect (80011)). This error indicates that the login to the DataStage server failed. It can be something as simple as the user name or password being incorrect but it can also occur for many other reasons. Some of these reasons may not be the user name or password at all. What can cause an 80011 error? What can cause an 80011 error? On all operating systems: Username or password, or both are incorrect User ID has expired or is locked User mapping has the incorrect user name or password On Windows® The user may not have the correct user rights assigned On UNIX®/Linux®: dsrpcd daemon is not running as the root user PAM not configured properly on the DataStage server DataStage is not configured properly to use PAM DataStage 8.1 does not have FP1 loaded Required libraries missing or incorrect There are several scenarios that can cause an error 80011 to occur. On all operating systems, the user name and password may be wrong, the operating system login may be locked or the password may have expired, or the Information Server registry is set to “Not Shared” and there may be an issue with the credential map. On Windows, the user may not have the correct user rights assigned to their user or group. On UNIX and Linux systems, the dsrpcd daemon may not be running as the root user, PAM and DataStage may not be configured correctly, Fix Pack 1 for 8.1 may not have been installed, or the PAM libraries being used may be missing or incorrect. Problem with user’s login Problem with user’s login DataStage is setup to use Local OS Authentication Check if the Information Server Registry is shared or not shared Check if username and password is incorrect Check if user needs to change their password on first login Check if user ID has expired or is locked on the DataStage server Check that user can login to the DataStage server machine with same username and password On UNIX and Linux: DataStage set to use PAM authentication also requires user to be able to login When DataStage is set to use local OS authentication, which is the default setting on a UNIX and Linux machines and the only setting for windows, the client will only be able to connect to the DataStage Server if the username and password is a valid and working local username and password on the DataStage server. You need to check the Information Server Registry to see if your user registry is Shared or Not Shared. If it is Shared then the username and password that you are using for the DataStage login must exist at the operating system level. If the registry is Not Shared, then you need to check the user’s credential mapping and be sure the user and password used for the credential map is a valid user name and password on the DataStage server. Test this by attempting to login to the DataStage server using this same user name and password. If the login fails, you will need to take corrective actions to fix the user’s login. Remember, if you can’t login to the DataStage server, neither can the DataStage client. Issues with the login that will cause problems connecting include a username that does not exist on the DataStage server or an incorrect password. When an account is locked or has expired or a new user is required to change their password the first time they login will also cause problems connecting. If you attempt to login outside of DataStage, you should be able to easily see the exact error. On UNIX and Linux operating systems, if DataStage is configured to use PAM authentication, you need to be sure that the LDAP or Active Directory user can login to the DataStage server. User mapping has incorrect username or password (1 of 2) User mapping has incorrect username or password (1 of 2) Information Server User Registry set to “Not Shared” Check if user has an individual user credentials assigned When the Information Server User Registry is set to “Not Shared” in the Information Server Web Console, check the username and password for the user’s DataStage Credential Map. To check this, open the Information Server Web Console, click Administration. Click Domain Management. Click DataStage Credentials and select your DataStage server and click Open User Credentials. Check to see if the user you are trying to login with is listed on the left side. If the user is there, this indicates that the user has an individual map set for their user credentials. If this is the case, check the user you are working with on the left side and then retype the username and password that you want to map them to on the right side and click apply. If the user is not listed, either add the user by clicking the browse button on the bottom or look at the default user credentials that are used for all users without an individual map set to be sure the username and password there are correct. User mapping has incorrect username or password (2 of 2) User mapping has incorrect username or password (2 of 2) Check default user credentials If your user does not have an individual user map set, you will need to check the username and password for the default DataStage and QualityStage™ Credentials. To check this, under DataStage Credentials, select your DataStage server and click Open Configuration. Check that the user name is valid and retype the password to be sure it is correct. Click Apply. Incorrect user rights assignment - Windows Incorrect user rights assignment - Windows All users must have the “Log On Locally” Check setting in the Local Security Policy in the control panel All users that are going to login to the DataStage server on Windows must have the User Rights Assignment “Log on locally” in order to connect. If the user’s user ID or group does not have this user right set, they will receive an 80011 error when they try to connect to DataStage. To check if your user has this user right set, open the control panel, click Administrative Tools and go into “Local Security Policy”. Click “User Rights Assignment” and double click Log On Locally to see what users and groups have been assigned this right. If your user or group is not listed here, they must be added. dsrpcd daemon not running as root user – UNIX/Linux (1 of 2) dsrpcd daemon not running as root user – UNIX/Linux (1 of 2) Client connections are done through the dsrpcd daemon process If Impersonation Mode is turned on, the daemon must be running as root Run “ps –ef|grep dsrpcd” to check who owns the dsrpcd process $ ps -ef |grep dsrpcd dsadm 25056 1 0 Sep10 ? 00:00:00 /opt/IS810/IBM/InformationServer/Server/DSEngine/bin/dsrpcd If it is running as any other user, check Impersonation Mode $ cd $DSHOME $. ./dsenv $ bin/smat –t | grep –i impersonation IMPERSONATION = 1 If IMPERSONATION = 1 and the dsrpd is not running as root, check permission in $DSHOME/bin All DataStage client connections are done through the dsrpcd daemon. The daemon is responsible for doing the authentication. If Impersonation mode is turned on, then the dsrpcd daemon must be running as root. If it is not running as root, it will not have the proper permissions to do the authentication and an error 80011 is returned. If you see that the dsrpcd is not running as root, as in the example, you will need to check what the Impersonation mode is set to. To check this, cd to your $DSHOME (read as “dollar DSHOME”) directory and source the dsenv file by typing . ./dsenv (read as “dot space dot slash dsenv” where dsenv is spelled out). Next run “bin/smat –t | grep –i impersonation” to check what the Impersonation mode is set to. If it is set to 1 and the dsrpcd is running as a non-root user, you will need to check the permissions in the $DSHOME/bin directory. dsrpcd daemon not running as root user – UNIX/Linux (2 of 2) dsrpcd daemon not running as root user – UNIX/Linux (2 of 2) Change directories to the $DSHOME/bin directory Check the permissions $ ls -l |grep rws -rws--x--x 1 root dsadm 54912 Sep 4 2008 DBsetup -rwsr-x--x 1 root dsadm 1318396 Sep 4 2008 dsdlockd -rwsr-x--x 1 root dsadm 1287944 Sep 4 2008 dslictool -rws--x--x 1 root dsadm 6952 Sep 4 2008 dstskup -rwsr-x--x 1 root dsadm 1299916 Sep 4 2008 list_readu -rwsr-x--x 1 root root 1290580 Sep 9 15:02 load_NLS_shm -rwsr-x--x 1 root dsadm 44452 Sep 4 2008 uv Fix permissions and stop and restart DataStage Change directories into the $DSHOME/bin directory. There are seven programs in here that must be owned by root and have the uid bit set. If you do not get the list of the seven programs shown here, or if they are not owned by root, you must change the owner back to root. You must also set the UID bit in order for the dsrpcd daemon to start as root. Once you fix these settings, you will need to stop and restart DataStage and ensure that it now starts as root. PAM not configured properly on DataStage Server – UNIX/Linux PAM not configured properly on DataStage Server – UNIX/Linux DataStage authenticates against the local operating system by default DataStage can be configured to authenticate using PAM DataStage Server must be configured to use PAM Be sure LDAP users can login to the DataStage server Check if there is a username in /etc/passwd with the same username Test with a user that is not in /etc/passwd If you want your DataStage users to be authenticated against an LDAP or Active Directory server on a UNIX or Linux server, you need to be sure that your DataStage server has PAM properly configured. Make sure that the LDAP or Active Directory user can login to the DataStage server. You will also want to check to see if there is a local username in the /etc/passwd file that matches the LDAP or Active Directory user. For testing purposes, make sure you test with an LDAP user that does not have an identical local os user. PAM can be configured to check both the local os and the LDAP or Active directory server. You want to be sure the authentication is truly taking place against the LDAP server and not the local operating system. If the user cannot login, you need to take corrective actions to fix your PAM configuration. DataStage not configured properly for PAM – UNIX/Linux DataStage not configured properly for PAM – UNIX/Linux DataStage needs to be configured to use PAM authentication Check uvconfig AUTHENTICATION setting $ cd $DSHOME $. ./dsenv $ bin/smat –t | grep –i authentication AUTHENTICATION = 1 Check that the dsepam file/entries created Review DataStage and PAM configuration at: http://publib.boulder.ibm.com/infocenter/iisinfsv/v8r1/topic/com.ibm.swg.im.iis.found.admin.common.doc/topics/wsisinst_config_pam.html http://publib.boulder.ibm.com/infocenter/iisinfsv/v8r1/topic/com.ibm.swg.im.iis.found.admin.common.doc/topics/wsisinst_config_pam_exp.html If you are on AIX®, also see tech note 1398309 http://www-01.ibm.com/support/docview.wss?uid=swg21398309 By default, DataStage uses Local OS authentication on UNIX and Linux servers. If you want DataStage to use PAM authentication, you need to be sure that DataStage is configured properly to use PAM. First you need to be sure that the DataStage AUTHENTICATION parameter is set to 1. To check this set, change directories to the $DSHOME (read as dollar DSHOME) directory, source the dsenv file (read this by spelling out dsenv), and run “bin/smat –t | grep –i authentication”. The authentication should be set to 1 to use PAM authentication. If you have determined that the authentication parameter is set correctly, the next step is to check that the PAM entries for DataStage have been correctly entered in the pam.config file or the dsepam file. The name of this file is platform dependent. If you need assistance setting this up, see the InfoCenter and technote pages listed on this slide. Fix Pack 1 for 8.1 not installed – UNIX/Linux Fix Pack 1 for 8.1 not installed – UNIX/Linux At 8.1 Solaris, HPUX, and Linux will require JR31215 JR31215 included in 8.1 FP1 There is an issue at 8.1 on all UNIX and Linux platforms except AIX where the wrong PAM library is being called. This will cause the DataStage PAM authentication to fail with an 80011 error even if everything is configured correctly. You will need to either install Fix Pack 1 to correct the problem or install the patch for JR31215 if you do not want to install Fix Pack 1. Required PAM libraries missing or incorrect – UNIX/Linux Required PAM libraries missing or incorrect – UNIX/Linux Check that the path for PAM libraries for the dsepam entries are correct Be sure that PAM and DataStage libraries have the same bitness (32bit versus 64 bit) Example: $ file $DSHOME/bin/uvsh /u2/IS810/IBM/InformationServer/Server/DSEngine/bin/uvsh: 64-bit XCOFF executable or object module not stripped $ file /usr/lib/security/64/pam_aix /usr/lib/security/64/pam_aix: 64-bit XCOFF executable or object module not stripped When DataStage is configured to use PAM authentication on UNIX and Linux servers, ensure the library paths you specified in the dsepam entries are correct and that the PAM libraries are the same bitness as the DataStage libraries. For example, if your DataStage installation is 64 bit then the PAM libraries must be 64 bit as well. The easiest way to tell is to use the “file” command against the DataStage uvsh program and against the PAM library you have used for the dsepam entries. In this example both libraries are 64 bit. Run truss or strace against dsrpcd process – UNIX/Linux Run truss or strace against dsrpcd process – UNIX/Linux Run truss or strace against the dsrpcd to check where the failure is occurring Get process ID (pid) of the dsrpcd process: ps –ef|grep dsrpcd Attach the truss or strace to the running process You must be root to do this strace –fae –p 2> /tmp/strace.out Try the connection again Check /tmp/strace.out for errors Example of strace output: [pid 22171] close(5) = 0 [pid 22171] futex(0xc4c06c, FUTEX_WAKE_PRIVATE, 2147483647) = 0 [pid 22171] open("/usr/lib/libpam.so", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 22171] select(5, NULL, [4], [4], NULL) = 1 (out [4]) If you are on a UNIX or Linux server and all of the configuration and passwords appear to be correct, the last step is to attach truss or strace to the running dsrpcd process to find the error. Do a “ps –ef | grep dsrpc” to obtain the process id, or pid, of the dsrpcd process. Once you have the proper pid, type in:strace –fae –p pid 2> /tmp/strace.out Where “pid” is the process ID from the previous ps command. The syntax for truss is the same. You must be root to attach to the dsrpcd process. If it is done correctly, you will not get a prompt back after hitting the enter key, it will sit and wait. Next, attempt the connection again. Once you receive the 80011 error message from the client, type Control C in the strace window to stop the strace. Now view the output and look for errors. In the example above, DataStage was looking for the /usr/lib/libpam.so library and it cannot be found. The issue in this case is that there should be a link from /usr/lib/libpam.so to /lib/libpam.so. The link is missing and once the link is re-created, everything works. Feedback Feedback Your feedback is valuable You can help improve the quality of IBM Education Assistant content to better meet your needs by providing feedback. Did you find this module useful? Did it help you solve a problem or answer a question? Do you have suggestions for improvements? Click to send email feedback: mailto:iea@us.ibm.com?subject=Feedback_about_Error80011.ppt This module is also available in PDF format at: ../Error80011.pdf You can help improve the quality of IBM Education Assistant content by providing feedback. Trademarks