1. vCD 5.1.2 (latest patches) with simple LDAP authentication and AD usersimported.
2. Change LDAP authentication from Simple to Kerberos.
3. Under Admin / Users: Remove test vCD user (right-click and disable, then right-click and delete).
4. Add same test user back again. User shows up simply as "testuser".
5. Test user can no longer login.
6. With setting to Kerberos, add (import) a different LDAP test user #2.
7. Test User #2 shows up as "email@example.com".
8. Login works for Test User #2.
The issue appears to be that when an LDAP user is deleted from vCD users, it isn't really deleted from the database. That is, adding that user back in reuses the same database entry. I suspect this is due to the unique identifier (such as "objectGuid") being retained on the underlying database to identify this imported LDAP user
This is a problem because, under Kerberos, the user is always "firstname.lastname@example.org". Under simple LDAP the same user is just "user" (no realm).
The net effect is that I am unable to switch to Kerberos because then my existing imported LDAP users will fail to login even after I delete / re-import them. This is also occurring even if I run the "Synchronize LDAP" option from the LDAP settings screen.
ldap users cannot be purged from the DB if they own objects (vapps, networks, etc).
for Kerberos authentication, you typically use the 'userPrincipalName' value of the system (email@example.com) ... not sAMAccountName (testuser).
This is because you need to dictate a kerberos realm when logging in, and the userPrincipalName has that and sAMAccountName does not.
You'll also notice this switch in teh LDAP schema in the config page when you switch between Kerberos and non-Kerberos.
Just for the record...even under Simple LDAP I used userPrincipalName rather than sAMAccountName. Use userPrincipalName with Simple LDAP and imported users are displayed with just the shortname. With Kerberos the name includes the realm. Tomorrow when I try the revised test below I'll paste in the screenshot for Simple LDAP with UPN as the user name.
However, certainly the user I was testing with does own objects in vCD. In the morning I will try creating a brand new user under Simple LDAP for admin login. Then I will switch to Kerberos, delete that new user and add back in. If I can login successfully I'll mark the answer as correct.
The other constraint is the 'Name in source' ... which for Active Directory = ObjectGUID ... so you need to have that be unique between your users ... so no username & firstname.lastname@example.org if they are in fact the same account since their GUID would be the same.
Just saw that vilONE had updated his answer. I agree that in the database the objectGUID is not unique. However, the bug is that - apparently - it is impossible to delete a user from vCloud Director admin users. Please note that this bug also applies to *AD groups* - once added under LDAP simple, can't change it to Kerberos.
Now this is what I had been working on earlier this morning...
OK - this appears to be an actual bug
First - vilONE was right that switching to Simple changes the schema...silly me I had not bothered to scroll down to check. Changing to Simple automatically uses sAMAccountName and changing to Kerberos uses userPrincipalName.
However...the initial problem still appears: 1) user created under Simple LDAP; 2) delete user; 3) change LDAP type to Kerberos; 4) re-import admin user; 5) no login!
I attached a PDF with all the steps and screenshots..
Net effect: *choose carefully* the authentication method for LDAP. Evidently with vCloud Director 5.1.2 it is not possible to switch and still allow existing LDAP users to login. Bummer.
Hope we can get an answer from VMware and maybe a patch to vCloud Director.
NOTE: Also just verified that bug is in effect the other way as well. 1) Set to Kerberos LDAP; 2) Add user; 3) Delete user; 4) Set LDAP to Simple; 5) Import same user again; 6) Just like above...unable to login (and the user displays with UPN).
Message was edited by: andybrucecsc
Hi Iam - I'm on an eval so I can't submit as a normal support request. From VMware Support: "If you do not have an active support agreement and you want to alert us to a product defect, please post the issue to the appropriate product community".
Could I impose on you to report this if you agree with me that it is a bug? Or should we just leave it here in the community forum? Certainly this is not a showstopper...I am working now and my vAppDir is working, vApps are running, blueprints are deploying, etc.
The sinister thing: my initial vCloud Director screenshots show that I had always configured "Kerberos" from the beginning. Also I had been using UPN to login. At some point after applying vCD updates that stopped working but when I switched to "Simple" everything worked (I could login).
However, that statement above is not something I can back up without quite a bit of work: I'd have to install a new vCD using my initial screenshots and the RTM build I had, then follow the processing so I could *prove* that applying the vCD update actually broke something instead of it being just a PEBKAC. (Even to me - the above certainly sounds like a user error!)
I'm looking to you for guidance...thanks so much for your time!