Here we are again! Holiday is unfortunately over. Lots seen and done, lovely travel companion and a great time. But yes back again to this crazy little thing called work. Some nice projects to be working on. This week started with the deployment of a Workspace ONE environment.As there are several phases in a EUC project, and I was doing assess and design a lot more often than deploy jobs, I wanted to get back with some hands-on experience outside the lab. I think this a) is good for the overall quality of this consultant, b) aligning the assess, design and deployment phased is part of continual improvement of a EUC solution and c) there will always be this techie inside who likes to brea…. erm build… I mean build stuff. Nice putting together some components and with this blog post some of the current deploy experience gotchas need to be recorded. First up App Volumes.
On with some deploy activities
Within the build a Workspace ONE infrastructure one of the tasks is deploying the App Volumes infrastructure. No problem, get a VM, run the installer and do the initial configuration no iceberg straight ahead. Clicky the click tappy the tap. Stopped at a credentials error on the AD Domains page . Erm what happened here
Ah well, this (ever noticed this is an anagram for shit?) happens, probably some copy past clipboard or whatever. On to the retry mode, result nope. Reset password on AD nope. We are using 32 character passwords and I know some products are limited to 20 (such as SSO), so try with a shorter password. Again failed. What the….When using my oh so personal but available account to test if the connection maybe is borked with this exception, it works. Hey wait a minute. Looking at some results of passing domain names in VMware products (like the authentication adapters within vIDM) I noticed the attribute [email protected] is used for the passing of username credentials here.
The @domainname comes from the first attribute input field you have to set on the App Volumes page. Okay. Username part then.
For the usernames in Active Directory and VMware products we have a variety of attributes to choose from for example some of the most used userPrincipalName, DN and sAMAccountName. The App Volumes documentation is not very clear on the specific requirements of the user and password pair. As long as ASCII characters are used and preferably service accounts do not expire via the default password policy. And o yes have read permissions. In this case also the length of the username. Because the naming scheme include all kinds of identifiers as account type, environment, purpose etc. it was quite a name. When I used the long unlimited userPrincipalName it complained the credentials where not correct.
In this case the sAMAccountName attribute that is used will only supports 20 characters for backwards compatibility (aka the pre-windows 2000 name in DSA.msc).
Why the username field of the form does allow more characters or no example/explanation is done on the interface or documentation I don’t know. It all makes sense afterwards but if you don’t know meh.
After using the sAMAccountName I could finish the installer. Up to the next challenge.
– Happy using the correct usernames in deploying App Volumes!
sources: vmware.com, microsoft.com