HPE 3PAR LDAP Config

[JayLim77]

I am having trouble configuring LDAP on 3PAR. I have run the process below to configure LDAP, settings have been generalized.

setauthparam -f ldap-server ldap.example.com
setauthparam -f ldap-server-hn ldap.example.com
setauthparam -f kerberos-realm EXAMPLE.COM
setauthparam -f binding sasl
setauthparam -f sasl-mechanism GSSAPI
setauthparam -f accounts-dn OU=YourUsers,DC=example,DC=com
setauthparam -f account-obj user
setauthparam -f account-name-attr sAMAccountName
setauthparam -f memberof-attr memberOf
setauthparam -f super-map CN=YourGroup,OU=YourGroups,DC=example,DC=com

When I run the showauthparam I get below.

storeserv01 cli% showauthparam
Param             ----------------------------------------------Value----------------------------------------------
ldap-server       ldap.example.com
kerberos-realm    EXAMPLE.COM
binding           sasl
sasl-mechanism    GSSAPI
accounts-dn       OU=YourUsers,DC=example,DC=com
account-obj       user
account-name-attr sAMAccountName
memberof-attr     memberOf
super-map         CN=YourGroup,OU=YourGroups,DC=example,DC=com
ldap-server-hn    ldap.example.com

When I run checkpassword command with an Active Directory user that is in the Accounts OU above and in the group of the authorized group I get this error:

storeserv01 cli% checkpassword 3paradm
password: 
+ attempting authentication and authorization using system-local data
+ authentication denied: unknown username
+ attempting authentication and authorization using LDAP
+ using Kerberos configuration file:
        [domain_realm]
                ldap.example.com = EXAMPLE.COM
        [realms]
                EXAMPLE.COM = {
                        kdc = ldap.example.com
                }
+ temporarily setting name-to-address mapping: ldap.example.com -> 10.0.0.10
+ attempting to obtain credentials for "3paradm@EXAMPLE.COM"
+ Kerberos credentials denied: Cannot contact any KDC for requested realm
user 3paradm is not authenticated or not authorized

I have checked with local firewall teams and they can see the authentication packets and that they are properly routed. This is on two disparate 3PARs in completely different parts of the country having the exact same issue.

I can get Pure systems and NetApps to authenticate by LDAP with almost exactly the same settings. Just not sure what I am missing for 3PAR.

[support_s]

System recommended content:

1. HPE 3PAR Command Line Interface - Configuring Account Location Parameters

2. HPE 3PAR Command Line Interface Reference Guide

Please click on "Thumbs Up/Kudo" icon to give a "Kudo".

Thank you for being a HPE valuable community member.

[JayLim77]

These are helpful guides, but don't help with the issue I am currently getting. I did set the ldap-type as below and still no joy.

setauthparam -f ldap-type MSAD

[AnilKT]

Hi JayLim77,

Looks like the LDAP user is not added to the Microsoft Active Directory.
please verify the user is added to the MSAD and also verify the LDAP user credentials.

Also, please verify the following details of the LDAP user configured in the LDAP server.

Account DN:: Enter Account Distinguished name
Kerberos realm:: (value)
LDAP Server::IP address of the LDAP server
LDAP Server Name::LDAP Server name
POrt::389
Authentication Group::super-map
Group DN:: Groups Distinguished name

Note: If you want to configure LDAP using HPE SSMC, please refer to the below link.
https://support.hpe.com/hpesc/public/videoDisplay?videoId=vtc00030151en_us

Do get back to us, if you need any further help.

Regards
Anil

[JayLim77]

I just reviewed the video and followed along and I have the exact same issue.

Also, the user I am using is in Active Directory, I have used it for other LDAP connections on Pure and NetApp to login to their systems over LDAP.

The error states "+ Kerberos credentials denied: Cannot contact any KDC for requested realm". That tells me it is somehow not able to get to KDC in the realm, but my realm is the domain capitalized, which is an issue described in other posts as being the issue.

Is there anything else I am missing from my commands that would cause this?

[Satish04]

Hi JayLim77,

If you are receiving the error message "+ Kerberos credentials denied: Cannot contact any KDC for the requested realm," it indicates that the 3PAR system is unable to contact the Key Distribution Center (KDC) for the specified Kerberos realm.
This error typically occurs when there is an issue with network connectivity or the Kerberos configuration.

Here are some steps to troubleshoot this issue:

1. Ensure that the 3PAR system has proper network connectivity to the KDC. Check network settings, including IP addresses, subnet masks, default gateways, and DNS configuration, to ensure they are correct.
Test network connectivity between the 3PAR system and the KDC using tools like ping or nslookup to verify they can communicate with each other.

2. Verify that there are no firewall rules blocking the communication between the 3PAR system and the KDC.
Ensure that the necessary ports for Kerberos authentication (typically port 88) are open and accessible between the systems.

3. Double-check the Kerberos realm and KDC configuration on the 3PAR system. Ensure that the realm name and KDC settings are correct and match the configuration of the Active Directory environment.
Validate the Kerberos configuration file on the 3PAR system to ensure it contains the correct realm and KDC information.

4. Use network tools to verify if the 3PAR system can establish a connection to the KDC.
For example, you can try using the telnet command to connect to the KDC's IP address and port 88.

5. Ensure that the clocks on both the 3PAR system and the KDC are synchronized.
Time discrepancies between systems can cause Kerberos authentication failures. Consider using Network Time Protocol (NTP) to synchronize the time between the systems.

If the issue persists after following the above steps, it is recommended to reach out to HPE Tesh support for further assistance.

Hope this helps.

Regards,
Satish

[JayLim77]

Hi Satish04,

In 2 and 4 it is mentioned to use ping, nslookup, and telnet to confirm network and firewall are configured properly. Is this built into 3PAR. I can't seem to find a way to do those steps.

I have checked 1, 3, and 5 over and cannot see anything that stands out to me. That is why I am hoping for a way to test as mentioned in 2 and 4.

Thanks

JayLim77

[Satish04]

Hi JayLim77,

Below are some steps to troubleshoot this issue:

4. Use network tools to verify if the 3PAR system can establish a connection to the KDC.

1. Identify the IP address or hostname of the KDC(Kerberos Key Distribution Center).
2. On the 3PAR system, access the command-line interface (CLI) or SSH into the system.
3. Use the ping command to check if you can reach the KDC. For example: ping KDC_IP_Address or ping KDC_Hostname.
4. This command sends ICMP(Internet Control Message Protocol) echo requests to the specified IP address or hostname and checks for responses.
5. If you receive replies, it indicates successful network connectivity between the 3PAR system and the KDC. If not, it suggests a network connectivity issue.

2. Verify that there are no firewall rules blocking the communication between the 3PAR system and the KDC.

1. Identify the IP addresses or hostnames of the 3PAR system and the KDC.
2. Check the firewall configurations on both the 3PAR system and the network infrastructure that sits between the 3PAR system and the KDC (e.g., routers, switches, firewalls).
3. Ensure that the necessary ports and protocols used for Kerberos authentication are allowed through the firewall. By default, Kerberos uses TCP/UDP ports 88 and 464.
4. Verify that the firewall rules allow outgoing traffic from the 3PAR system to the KDC on the required ports.
5. Check if any network address translation (NAT) is being performed that could interfere with the communication between the 3PAR system and the KDC.
6. If you have access to the firewall configurations, review the logs or consult with the network or security team to check for any blocked or denied traffic between the 3PAR system and the KDC.
7. Temporarily disable the firewall or create a temporary rule to allow all traffic between the 3PAR system and the KDC to see if it resolves the authentication issue. If it does, you can then adjust the firewall rules accordingly.

Note: If you are unable to identify and resolve the firewall-related issue, it is recommended to reach out to HPE Tesh support for further assistance.

Regards,
Satish

[Dardan]

Hi @JayLim77 
I've been using LDAP(s) for quite a time now without issues, even wrote an article about the integration steps.
Did you have the chance to look at HPE PRIMERA LDAP ACTIVE DIRECTORY INTEGRATION
Cheers,
Dardan

[Cali]

Just as a consideration.

We moved away from using LDAP a long time ago.

The reason is that if a hacker gets AD rights, he also has access to the storage.

This has already happened to some customers and the Ransomware People delete all the Snapshots.

(Same for Backup Server, Switches, ...)

Cali

[JayLim77]

I am going to open a case with support to review this. From what I can tell networking, firewall, and configuration all work.

Hi @Dardan I went to the Primera site and reviewed the settings, I only seemed to be missing link-type MSAD. I did a clearall and reran the above steps with the link-type. It did not work.

Hi @Cali I appreciate the information, I don't disagree with putting layers of security in to keep outside users out, but LDAP can be securely implemented with only connecting the super-map, and other, authorizations to those that require it. Only certian Admin level accounts are given access and those have more restrictions and password lenght settings than our regular user accounts. I believe the NIST has many hardening guides and LDAP should not be considered insecure, just in the way you implement it.

Thanks All, I will reply to this thread if support can help me determine the issue.