Layer7 API Management

We are attempting to integrated the authentication at the CENTOS level of our API Gateway 9.2 appliance with the customer's LDAP using the SSGCONFIG menu.  We specify all parameters as we know to be correct and yet it fails to authenticate the user.   Network traces show that CENTOS is successfully binding to the LDAP server with DN and password we provided for that purpose, however when it performs the bind request for the user who is trying to login,  we can see that CENTOS is passing the word "INCORRECT" where the password should be?  Looking for ideas

Hi pwhelan81 ,

Is there anything you can find in ssg log? (/opt/SecureSpan/Gateway/node/default/var/logs/ssg_0_0.log)

Regards,

Mark

Nothing can be found in ssg.log as this is NOT integration of the gateway software with LDAP.  This is integration with the underlying CENTOS operating system that is configured via the ssgconfig  menu.

Is this about enabling ldaps authentication for gateway config menu, if so can you check this KB article please to see if it helps

https://www.ca.com/us/services-support/ca-support/ca-support-online/knowledge-base-articles.TEC0000001082.html 

Had already looked at this document.  This is geared toward an active directory integration and did not provide me any insight.  I have it 99% configured and it already is successfully attaching to the LDAP server   I would think that if the openldap stuff is doing something as specific as inserting the term "INCORRECT" where my password would be in the protocol , this would lead to some advice on what might be wrong with the setup....but so far have not been able to find any advice on this.  Googling LDAP and incorrect yields as large set of results as you can imagine

Paul,

Normally when you see the word incorrect is that the attribute uidNumber is missing from the user so it is not able to go through the next step of authentication so it injects "INCORRECT" as the password.

Sincerely,

Stephen Hughes

Director, CA Support

Hi pwhelan81 ,

Did you have a chance to check the uidNumber from the user in question? 

Regards

Seenu Mathew 

I am confused on where this uidNumber should be found?  The UID of the in LDAP is alphanumeric and browsing the ldap record for the user I can see no uidNumber attribute.  The user does not exist on the Linux OS so there is no uidnumber there.  I assume if the account did exist locally it would never go to LDAP to authenticate the user if it found a local user with the loginid being supplied.  Any advice is welcomed.  Set me on the path please!!!!

Good evening,

The uidNumber is the attribute that will be in the LDAP directory not the local OS. In Active Directory, you need to enable these attributes and populate it for the users required (URL that may help: uidNumber and gidNumber - Dependency). For other directory servers, you need to ensure that the posixAccount object class is enabled with the attributes populated.

Sincerely,

Stephen Hughes

Director, CA Support

 The posixAccount objectClass does not exist in this customer’s LDAP nor in their Active Directory.   I have read other internet chats about mapping other ldap attributes (e.g. employeeid) to uidNumber.   However,  I have browsed the full contents of the customer’s user attributes in both LDAP and AD directory and see only one attribute that looks like a unique number that possibly could be mapped to uidNumber.  Unfortunately I have also read that this uidNumber must be between 1000...65533 and so I think I am out of luck there.

I want to quickly explore feasibility of another approach.  The article at https://lists.arthurdejong.org/nss-pam-ldapd-users/2015/msg00053.html starts with the idea about mapping the employeeid as uidNumber but then “hard coding” other values such as gidNumber and loginShell as shown below

map passwd uid uid

map passwd uidNumber employeeid

map passwd gidNumber "1000"

map passwd gecos "${gecos:-$cn}"

map passwd homeDirectory "/home/$uid"

map passwd loginShell "/bin/bash"

I want to take this idea one step further and hardcode the uidnumber and homedirectory as well as shown below.   

map passwd uid uid

map passwd uidNumber "1000"

map passwd gidNumber "1000"

map passwd gecos "${gecos:-$cn}"

map passwd homeDirectory "/home/admin"

map passwd loginShell "/bin/bash"

I only have one class of users allowed to login directly to the API appliance: FULL ADMINISTRATORS.  What I care about is that they authenticate themselves using their own id and password against the customer LDAP.  Then based on some /etc/sudoers file config, they will be able to sudo su -  root or sudo su - ssgconfig without a password.  I can guess what I might lose is auditing given each person that logs in will have the same uidnumber.  However this is better than allowing them to share the passwords for ssgconfig and/or root.   

Thoughts about feasibility of this idea?

Hi Stephen,

From the ssg menu choosing the option LDAP,essentially are connecting to AD?However, I'm interested to integrate with AD.If I configure as per you direction above would this be seamless login or user will be prompted to enter AD credentials of the organization and from ssg it will authenticate the user against the AD? Please advice.

Actually I started doing this AD integration on SSG via option LDAP and i approached our AD team for the password attribute, they suggested me as below. Pls advice.

There is no attribute in AD where password is stored. It is stored in database file in hashed format.