Home > Case Post Mortems, vRealize Automation > vRealize Automation 6.2 stuck indefinitely on additional tenant login

vRealize Automation 6.2 stuck indefinitely on additional tenant login

December 27th, 2014 Leave a comment Go to comments

I had a customer a while ago who was unable to log in into the additional created tenant in vCloud Automation Center 6.0.1. The same issue can be reproduced in vRealize Automation as well. Logins to the default tenant would succeed without any issues and a very similar test environment did work without any issues at all for logins.

The interesting part for this login issue was that no error was visible at all in the GUI it would just grey out the login fields and be stuck indefinitely until the browser was restarted/reloaded.

Capture

As we are on the Identity Appliance splash screen a failure there is most likely. Matching the login timestamp with the most recent touched files clearly got a winner on where to look.

vraid:/var/log/vmware/sso # ls -ltr | grep “15:16”
-rw——- 1 root root 139247 Dec 27 15:16 vmware-sts-idmd.log
-rw——- 1 root root 27327 Dec 27 15:16 localhost.2014-12-27.log
-rw——- 1 root root 148692 Dec 27 15:16 localhost_access_log.2014-12-27.txt
-rw——- 1 root root 1857642 Dec 27 15:16 websso.log
-rw——- 1 root root 1874196 Dec 27 15:16 vmware-identity-sts-perf.log
-rw——- 1 root root 13335309 Dec 27 15:16 vmware-sts-idmd-perf.log

We can see that the authentication actually does succeed but something is wrong in the actual vmdir schema.

[vmware-sts-idmd.log]

[2014-12-27 14:16:18,942 GSS c219233a-aa25-4662-95c1-e23ffa5c7dd9 INFO ] [IdentityManager] Authentication succeeded for user [fbuechsel@vcac.local] in tenant [GSS] in [3] milliseconds
[2014-12-27 14:16:18,981 GSS 3fe879f8-3ee1-4032-8909-ae279fae6593 ERROR] [IdentityManager] Failed to get attributes for principal [fbuechsel@vcac.local] in tenant [GSS]
[2014-12-27 14:16:18,981 GSS 3fe879f8-3ee1-4032-8909-ae279fae6593 ERROR] [ServerUtils] Exception ‘java.lang.IllegalArgumentException: Attribute mapping is null.’
java.lang.IllegalArgumentException: Attribute mapping is null.
at com.vmware.identity.idm.server.provider.ldap.LdapWithAdMappingsProvider.getAttributes(LdapWithAdMappingsProvider.java:401)
at com.vmware.identity.idm.server.IdentityManager.getAttributeValues(IdentityManager.java:2702)
at com.vmware.identity.idm.server.IdentityManager.getAttributeValues(IdentityManager.java:8242)
at sun.reflect.GeneratedMethodAccessor28.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322)
at sun.rmi.transport.Transport$1.run(Transport.java:177)
at sun.rmi.transport.Transport$1.run(Transport.java:174)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:173)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:556)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:811)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:670)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)

We took an ldif export from both schemas for the test and production environment to see the differences and it turns out that the error in the log is pretty clear. When looking into the actual schema the “AttributesMap” for the tenant provider was missing. Note that the port to connect to when using the Identity Appliance is 389 and 11711 when using vCenter Single Sign-On.

Capture2

When copying the AttributesMap subtree from the vsphere.local tree back into the GSS tree everything is working just fine again.

Capture3

 

Unfortunately the current logging for vmdir does not log delete operations so it was not possible to determine the actual root cause of the subtree vanishing from the vmdir. This is currently being looked into for improvement in a future version.