FAQ – Changes to User Creation and Password Policy

[Bill.Howard]

What improvements to user email verification, password policy, and account resources were completed in v21.11 and how do they affect me?

In our efforts to better serve our customers, we’ve implemented several enhancements designed to improve security and set a foundation for streamlining user management capabilities for system administrators.

In this article…

What changed?	When did this change happen?
How do these changes affect user creation?	Will this impact my current users? What if my new user fails to verify their account? What if I add a user who is already in the Account Management Portal (under User Management)?  What if I create new users through an API or third-party provider?
Security	Will this impact my SSO policies for new users? What will the new password policy be? Can an administrator create a password for a new user? Can I use a username other than email address? What if I want to add an AppDynamics employee for support?

---

What changed?

As of release v21.11, AppDynamics has completed upgrades to our user creation process and password policy—a process that began in v21.2. To date, the following changes have been rolled out to all customer SaaS accounts:

New user email verification	When a new user is created, they must verify their account via email prior to logging into your Controller. This will require administrators to provide an accurate email when creating the new user.
Improved password policy	As part of completing their email verification, users will receive a notification to “activate their account”.  During this process, the new user is required to create a password, and it will have to adhere to a mandatory “strong” password policy designed to improve account security.
Access to Controller and account resources	When a new user activates their account, they will be able to access the Controller accounts to which they have been assigned as well as the resources of the Account, such as Community and University.

When did this change happen?

We began a staged rollout of these changes starting with v21.2. As of v 21.11, all customer SaaS Controllers have these capabilities. 

Back to Table of Contents

---

How do these changes affect user creation?

Will this impact my current users?

No, current users will not be impacted by this change. The new features only impact users created with the new flow implemented for everyone in v21.11.

NOTE | This is the first phase in a series of enhancements to improve security and overall ease of use for our user management capabilities.

We highly recommend adding accurate email addresses when making any updates to an existing user’s account, as this will be a requirement in the future. 

What if my new user fails to verify their account?

When a new user is created, they will be designated a “pending” status until they complete the email verification process. The verification email will expire after 7 days of inactivity. 

At that time an administrator can opt to:

• Ask the user to invoke the reset password flow, which will resend the activation email for a pending user. To do so:
1. Direct them to either your Controller login or the Accounts login page:
2. Click the “Reset Password” link
   The reset password link, below the "Next" button on the Sign-in screen
   

• Delete the pending user if they no longer require access

What if I add a user who is already in the User Management section of the Account Management Portal?

If you add a user to your Controller account using the email address of a user already found in the user management section of the Account Management Portal: 

• The user will automatically be able to use their Accounts username (as email address) and password to access the Controller account. 
• The user will receive an email notifying them of their access to the Controller account, including a link to the account for access.  
• The Account Management Portal’s user management section will show the user as a “tenant user” of the Controller account, making it clear that they can access the Controller directly using that identity.

What if the user resets their password?

When a user can’t remember the password they set, they can click reset password from the Controller account login page or from the login.appdynamics.com login page.

They will receive an email with a link to reset their password. Once reset, the user will be able to use the new password with their username (as email address) in all related Controller accounts and AppDynamics Accounts experiences.

What if I add the same user’s email address to another Controller account?

Whenever a local user is added to a Controller account using their email address, we match that email account with other existing user accounts using that email address and ensure that it’s the same user credentials that are used for the account.

What does this mean for the user? The user will be able  to access all Controller accounts to which they have been added with the same AppDynamics identity (username and password).

What if I create new users via an API or third-party provider?

Even if a user is created via an API script or a third-party integration, the user will still need to complete the email verification process.

If the new user fails to verify their email within 10 days of receiving the notification, they can obtain another activation email using the reset password flow from the login screen.

Back to Table of Contents

---

Security

Will this impact my SSO policies for new users?

There is no impact for SSO policies at all. This change only applies to SaaS customers whose users are authenticated by AppDynamics, or so-called “local users”.  SAML or LDAP users and the associated security provider settings are not impacted. 

What is the new password policy?

• Minimum length: 8 characters
• Contain both upper-case and lower-case letters
• Contain at least one number (i.e., 0-9)
• Contain at least one special non-alphanumeric character (e.g., !$%^&*)

Can an administrator create a password for a new user?

No, administrators will no longer be able to set the password when creating a new user. The new user will be required to create their password during the email verification process.

Can I use a username other than an email address?

No.  In order to ensure uniqueness, email is the chosen username format. With email as username, we can ensure that users have a means of receiving operational communications from AppDynamics as well as ensure that the user can access all AppDynamics resources using a single identity.

What if I want to add an AppDynamics employee for support?

Easy. Just add the AppDynamics employee using their email address. The employee will be able to log in to your account securely. Should they leave AppDyamics, they will be unable to access your account further.

Back to Table of Contents

[Jennifer.Pechloff]

Hi,

Quick question. If a customer uses the same email address for more than one user account will this cause any issue?

Thanks,

Jennifer

[Bill.Howard]

Hi Jennifer,   

Thank you for the question.  With these changes, we have begun the necessary work of providing our users a single identity for all their interactions with AppDynamics.   The result will be a better overall experience as well as a more secure system for these user accounts.  Email address will be used as their unique identifier and as such, each distinct user must have their own email address.  For now, the change is only being applied to newly created users when the customer has chosen to use AppDynamics as their identity provider (the "local" user option).    In the near future, however, we will migrate existing local users to this system requiring these existing users to have their own unique email address.

As always, we recommend that customers adopt SAML wherever possible as this ensures that the customer's systems are the identity systems of record for their users, allowing the customer to control the use of their user attributes.    As noted, these changes won't impact a customer's SAML/SSO users.

Bill

[Vidya.Gurumurthy]

Hi,

The changes outlined above seems to have overlooked the fact that the agents themselves need user credential to connect to the controller. In our case, we are using Cluster Agent to monitor our K8s cluster and this agent needs a username & password configured to be able to connect to the controller. Obviously, these agents are not going to have an email of their own in the system and this is forcing us to use fictional email addresses for these agents.

Seems like a key design defect to me.

A support ticket has been raised for this in Jan (ticket # 311910 ) but not seeing a way forward on this.

Appreciate it if this could be looked into.

Regards,

Vidya G

[Ryan.Paredez]

Hi @Vidya.Gurumurthy,

Thank you for sharing your feedback. We are looking into this and will follow up when we have a bit more info for you. 

[Patrick.McDonald]

Hi,

So how do we create / manage local user accounts for non-humans, a.k.a. "service accounts", where there is no email address nor any email functionality for the "user" itself?  I'm specifically asking about typical service accounts, where the local account is tied to an automated integration / process / whatever which is non-human.  So there isn't ever anyone to answer emails, "setup their account", "create a password", etc. 

What is the new procedure for the company admin to manage their system integration "service accounts" on the SaaS controllers for situations where no email addresses exist?

Also these "service accounts" are typically for integration from system <-> system, and should not have portal.appdynamics.com access to the account info, downloads, etc.  It is an account that needs to be restricted to the SaaS controller itself, and have no access nor privileges to anything else within AppD.

So what prevents an automated procedure's local account details on a SaaS controller,  from being used to access other things within AppD besides the Controller?

Thank you,

Patrick

[Bill.Howard]

Hi @Patrick.McDonald , thanks for the question.  It's a good one.  Generally, service accounts for integrations are not recommended as they will utilize basic authentication, which is inherently less secure.  Our recommendation, instead, is to use API clients for integrations that are system to system and are isolated to the SaaS controller account.   API clients are an OAUTH based mechanism that have been supported since version 4.5 of the controller.  Docs can be found here.    In the event that the integration is unable to support the use of tokens, then, unfortunately, an email based user is the only current solution.  We are currently researching other solutions.  Should you need additional help, please raise a support ticket and we can engage on that forum to see what can be done for your specific case.  

[Claudia.Landivar]

Hello, Everyone:

Just a note that the changes on 7/8/22 were for formatting corrections subsequent to our recent Community redesign. There was no substantive change to content.

Claudia Landivar
Community Manager & Editor

[Simon.Parish]

Is there anymore of an update on the service accounts as having API tokens that expire after hours doesn't really cut it as we use this for creating suppressions within Appd.  We need a more robust long term solution like we had with the 'service account' so that our command centre don't have to request a token as well

[Bill.Howard]

Hi @Simon.Parish ,  

For security reasons, we still don't have plans to introduce service accounts.  They typically utilize basic auth as the authentication scheme, which is a direction the industry is moving away from generally.  Instead, API Clients, that use OAUTH, are recommended.   As far as API tokens that expire, this should be able to be handled in the code.  API client tokens can be automatically generated from the client ID and secret whenever needed.  If a token has become invalid, simply get a new one and use it.   No human interaction is needed.  This should enable your suppression code to be automated completely.  

See the "Generate the token through an API" section of the API Client docs here.

I hope that helps,

Bill

[Sid.Jagannathan]

1. Once an account is created will the user be able to login even if accounts.appdynamics.com is down or temporarily inaccessible?

2. is there a way to turn this off so we can transition to the new model in an orderly way instead of having the rug pulled under our feet after our last upgrade?

3. When we moved to SaaS we worked with our organisation's risk and cyber controls. We agreed to create local accounts only for specific rare cases. Now we have to redo our assessment. Why was this not communicated to us ahead of time?

4. How do we ensure only our org email are used. Right now it seems I can create any random gmail or hotmail email as users?

5. Do tools like Config Exporter, Dexter, Config Assessment tool work with the new accounts?

[Bill.Howard]

hi @Sid.Jagannathan , thanks for your questions.   Answers below:

1. Yes, users can continue to sign into the controller.  Our identity platform is distinct from the accounts.appdynamics.com experience.
2. It is possible for us to turn the use of our global identity platform off, temporarily, for your account.  However, once that happens, any of those users will be unable to login (as their password is no longer in the controller account itself) and they will need to set a password (forgot password flow) to login.   I'd like to speak with you directly to understand your concerns.
3. To be clear, this is only for users that are "local users".  Only these local users will have their accounts created in our new identity system.  All other users remain as is.  So, this applies only to those specific rare cases that you have agreed with you security team on.  This change enables us to create stronger controls for "local" type users.  If you have some specific requirements, please let me know and we may be able to accommodate.  As to the question of advance notice, please see that this FAQ was published December of 2020.   As I want to ensure to improve our processes, please do message me with suggestions for improving so that we don't catch you unaware in the future. 
4. This is an interesting question and one I'd like to explore some.  For now it is not limited, by design, as many customers want to add users from other domains (like partners or vendors).  We have discussed adding a domain "allow list" that admins can control to prevent users from other domains, but that hasn't been prioritized.   Only administrators of the controller account can add users.  This, at least, limits the list of users that can be added to those individuals.  
5. Yes, those tools work.  The only thing that's changed is how certain user records are authenticated. 

Thanks again for your questions.  Happy to discuss further.  Feel free to private message me here and we can discuss your specific needs.
Bill