Domain controller limitations: 15 characters for Computer Names and 20 characters for Username. Any means to bypass those limits?

SP2023SP01 With Intouch or OMI.

Last week, 2 users called me they were unabled to connect to HMI during they night shift.

After some thinking, my IT told them to try to truncate their username to 20 characters and surprise!!! It works!

Company naming conventions for computer and username not always compatible with system platform needs. 

It looks a little bit weird to tell someone to truncate his name to succeed logging in the system.

Anyone finds a workaround?

Any development from Aveva on that purpose?

Thanks! 

  • Hi,
    This is one of those quirks that requires digging into the Microsoft ecosystem and its legacy naming conventions.
    The 15-character limit for computer names stems from NetBIOS restrictions, which are still relevant in many environments.

    Specifically, NetBIOS reserves the 16th character to identify the service type running on the device:
    https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/naming-conventions-for-computer-domain-site-ou
    “The 16th character of a NetBIOS computer name is reserved for identifying the functionality that is installed on the registered network device.”

    While some workarounds exist, especially in node-to-node communication scenarios, these limits are deeply embedded in legacy protocols and can’t be easily bypassed. Even if Aveva were to resolve this internally, DNS naming conventions introduce another bottleneck, older domains often cap names at 24 characters, and that’s before considering compatibility with Active Directory and other services in the system.
    So realistically, I don’t believe a sustainable workaround here is likely in the near future.

    The same applies to usernames. Aveva could potentially improve this in future releases, but the current limitations are rooted in legacy authentication protocols. For example:

    • The DOMAIN\username format has a known limit of 20 characters.
    • Switching to username@domain (UPN format) removes that restriction and is generally more flexible.

    That said, authentication isn’t a one-size-fits-all process, Aveva would need to update multiple layers of their stack to fully modernize it.

    Now, I’d also challenge the premise a bit, do you really want usernames longer than 20 characters? From an operator’s perspective, typing out something like richardkohlerstrand every time is a bit of a chore (speaking from personal experience ;) )

    Shorter usernames like rikoh are easier to manage, and you can still display the full name in InTouch/OMI for clarity.

    Even in Windows server 2025 you can not create a local username > 20 characters, also keep in mind that usernames are used to set up a windows profile in the filesystem so here there is the challenge of legacy limits of characters in folder paths that comes in to play.

    Organizations typically resolve duplicate names and length issues by implementing structured naming conventions. For example:
    - Using extended initials (jodoe, rosmi)
    - Combining department codes with usernames (op_jdoe, adm_rsmith)
    - Shortened identifiers for login purposes, while displaying the full name in applications
    This ensures uniqueness, keeps usernames manageable, and avoids the frustration of typing overly long credentials. It also scales better as the organization grows.

    But I also believe that with the modern workforce, new expectations of users and available technologies, Aveva has to adhere to modern ways of improving authentication in the applications. In some sense that is already happening with the cloud connected services such as AVEVA Connect.

    But I welcome the discussion, please elaborate on the possible advantages and use cases, I must admit that I can personally easy get stuck in the "because its always been this way" mentality.

    Fun fact, I had a customer challenging me that passwords over 100 characters were not working, but that opens up a whole different discussion, right? 

  • Thanks for feeding this post! 

    Sincerely, I prefer short name, short username and short password. We use our login so many times!!!! But standards are forced by IT teams and as you certainly know, technology evolves faster in IT development than in automation software technologies. In bigger enterprises, teams often choose, deploy and then talk to automation people because this or that are not compatible...

    A coworker ask me if EntraID could be used instead of Active Directory ! Personally, I prefere local system to get better response time and not depend of clouds techno. But could it be a solution?

    I see the "Authentication Providers" radio button in the Galaxy security settings. I didn't have time to look at what it corresponds to. (My next step!)

    I'm curious of what people of this forum have tried: success and failed.

  • Your next steps relates to your coworkers question!

    Microsoft EntraID is the rebranded name for Microsoft Azure Active Directory, (Cloud based Active Directory) witch is supported by Aveva as an authentication provider.

    So its absolutely a way forward, and would give your users a way of authenticating using their email address (UPN format).

    As mentioned this is Aveva's path forward in modernizing authentication. The Connect services adds on this to link licenses to a user in a 'Microsoft O365' style where the cloud user brings context with them when authentication to Aveva software and can effect both runtime and development.