Unsolved
This post is more than 5 years old
178 Posts
0
661
Login to sudo taking long time with 7.1.x
Hello,
We are currently running on OneFS 7.1.0.5. Recently upgraded from 7.0.1.3. After upgraded to 7.1.x verison, we started seeing issues with sudo access with LDAP user.
On 7.0.1.3, after login to cluster with LDAP user, sudo su - or commands run with sudo took max 15 to 20 seconds before prompts for password. But after upgraded to 7.1.x version, sudo su - or commands prefixed with sudo taking anywhere between 2 to 4 minutes before prompt for password.
Could any experienced similar issue? Please help on this.
Thank you.
arthur.r.olivei
11 Posts
0
November 13th, 2014 12:00
Hi, I've experienced a similar situation with the code 7.1.0.3 and 7.1.0.4, but with executions with about 30 seconds. That customer have an OpenLDAP instance with ~200K accounts and nested containers (OU within OU's).
In that time I've opened an SR# to EMC², and they team did a great job with the troubleshooting steps and simulations on their Lab environment. They concluded that:
"The object queries are cached, however the group queries are not. This causes the commands to spend most of their time waiting for the groups to be resolved."
The the optimal configuration, for a OpenLDAP instance without nested containers, should be replace the query types to base and onelevel (Cluster Management > Access Management > LDAP > View Details > Group Query Settings and change the query type).
Unfortunately, for my customer the conclusions was:
"Sudo speed for this environment should improve when caching LDAP group information is implemented. There is no timeframe for this implementation as it is currently under research and subject to changes."
We are waiting for a fix at this point of time.
Kind regards,
cadiletta
106 Posts
0
November 17th, 2014 08:00
When running sudo - it is true that permission processes run to verify the LDAP user has the permission to perform administrative tasks. To do this it will make a request for all identity information for the user, including group information. If there are delays in gathering this information it could cause the issues that you are seeing.
We are assuming of course that if you log in as root to perform administrative tasks there are no such delays in command output.
Would it be fair to say that the LDAP environment a group structure is fairly complex in your configuration? This certainly does sound like permission lookup delays - and caching would have a profound impact here. In order to confirm, we could grab a packet capture of a sudo command request and watch the queries to LDAP for large group exchanges. If you would like to confirm this behavior - I would recommend working with support to identify the issue.
Having multiple support cases to indicate a pattern of LDAP group lookups affecting workflows will help call attention to the importance of developing improvements in this area.