Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Commonly domain user accounts are used as service accounts. With domain user accounts, the username can easily be as long as 64 characters as long as the User Principal Name (UPN) is used to refer to the account, eg longusername@mydomainfqdn.domainsuffix. If you still use the legacy pre-Windows 2000 names (SAM) you have to truncate it to ~20 characters, eg mydomain\truncname.

When using the New-ADServiceAccount PowerShell cmdlet to create a new Group Managed Service Account (gMSA) and a name longer than 15 characters is specified, an error is returned. To specify a longer name, the SAM name must be specified separately, eg:

New-ADServiceAccount -Name longname -SamAccountName truncname ...

To configure a service to run as the new gMSA, I can use the legacy username format mydomain\truncname$ but using usernames with a maximum of 15 characters in 2013 is a smell.

How do I refer to a gMSA using the UPN-style format instead?

I tried the longname$@domainfqdn approach but that didn't work. It also seems that the gMSA object in AD doesn't have a userPrincipalName attribute value specified.

share|improve this question

1 Answer 1

up vote 2 down vote accepted
+100

Commonly domain user accounts are used as service accounts.

Yes, and no. Domain user accounts are commonly used as service logon accounts. This specific use of user accounts is not really the same as a Managed Service Account.


Anyways, the Managed Service Account object class does in fact have a userPrincipalName, but it doesn't seem to get populated by default when you create a new managed service account.

The New-ADServiceAccount cmdlet accepts a parameter called OtherAttributes which allows you to set account attributes by LDAP Display Name:

New-ADServiceAccount -Name longName -sAMAccountName truncname -OtherAttributes @{'userPrincipalName'="longname@my.upn.suffix.com"}
share|improve this answer
    
Adding the userPrincipalName attribute works with Services but it doesn't seem to work with IIS Application Pools unfortunately. Although, I expect this is an IIS limitation. –  Jason Stangroome Jul 16 '13 at 7:32
    
An application pool identity can never be an AD UPN - it's a local account type –  Mathias R. Jessen Jul 16 '13 at 9:48

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.