This post is more than 5 years old
178 Posts
0
6347
Unable to login to VNXe CLI with ldap credentials
Hi,
I have created ldap user and ldap group accounts in vnxe unisphere. I am able to login to unisphere gui with ldapuser account credentials. I am not able to login with users of ldapgroup and also not able to login to CLI with any of ldap accounts except service account
syntax i used : test.domain.com/ldapusername
ldap credentials
Can some one please suggest me where I am getting wrong. Can't we just create ldapgroup and login with users belong to the group?
MarkParenti
19 Posts
0
August 20th, 2012 07:00
khkris,
Some clarifications:
There are two distinct CLI interfaces for the VNXe - UEM CLI and the service CLI. UEM CLI is used to perform typical management operations as would be done via the VNXe GUI. This CLI is typically accessed by installing the UEM CLI client on a local machine (kits are available for a number of operating systems). The user authenticates using the same authentication accounts that can be used in the GUI including LDAP. The syntax for logging in from a remote UEM CLI client via LDAP is as follows:
The service CLI is accessed by using SSH to the management IP address of the VNXe system. This CLI is used to perform service operations (some of which can also be done via the VNXe GUI). The UEM CLI client is installed on the box for use during service operations but you would not typically use that client to perform day-to-day management operations - you would install the UEM CLI client on one your local machines and run it from there as described above. When running the UEM CLI client from an SSH session it is not clear if LDAP authentication is supported. The feedback I get is that it should work but you do not need to authenticate when using the local CLI client (since you already authenticated when logging in via SSH). You can only authenticate via SSH using the service user (since, as I noted, the intent of this access is for service operations). As noted in a previous response, the service password can be set in the Intial Config Wizard or via the GUI.
In short, is there a reason why you cannot run the UEM CLI client on one of your local machines? Running UEM CLI on the box via the service account is not intended for normal management operations (though it does work).
Mark
DynaDin
138 Posts
0
August 17th, 2012 12:00
Do you mean you are trying to logon to SSH session using LDAP? If so.. it is not supported.
The CLI access is meant for service and support purposes only.
Storage administration of VNXe is supposed to be done through GUI only.
If you are using Unisphere CLI (UEMCLI), then it should work. Refer to Unisphere CLI user guide for syntax.
MP_storage
47 Posts
0
August 17th, 2012 13:00
use service credentials which set during initial configuration
khkris
178 Posts
0
August 19th, 2012 12:00
Thank you Dinesh.
Yes, I am tryin loggin to CLI through putty using ssh port 22. After loggin in I am able to execute all UEMCLI commands with ldap user credentials or admin credentials. For example, viewing user accounts, ldap configuration.
syntax I am using for login to cli is test.statefarm.com/user
In unisphere I have created ldapuser and ldapgroup. I am able to login with ldapuser but unable to login with users of ldap group
Is there any way I can login to cli with ldap credentials?
DynaDin
138 Posts
0
August 20th, 2012 06:00
There are no ways to authenticate into CLI using LDAP. As mentioned above, CLI is only for support purposes.
khkris
178 Posts
0
August 20th, 2012 09:00
Thank you very much Mark. One more question
I have created ldapuser and ldapgroup and assigned operator role for both of them. I am successfully able to login with ldapuser ldap credentials but failing to login with users of ldapgroup.
Can you help me why users of ldapgroup are failing to login? I am using same syntax for loggin in
xxx.domain.com/ldapuser1, xxx.domain.com/userofldapgroup
Thanks
MarkParenti
19 Posts
0
August 20th, 2012 13:00
Can you successfully login to the GUI using that LDAP group user? The syntax you are using looks to be correct.
Mark