Click the Start a free trial link to start a 15-day SaaS trial of our product and join our community as a trial user. If you are an existing customer do not start a free trial.
AppDynamics customers and established members should click the sign in button to authenticate.
- edited on
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.
|How do these changes affect user creation?|
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.
We began a staged rollout of these changes starting with v21.2. As of v 21.11, all customer SaaS Controllers have these capabilities.
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.
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:
Delete the pending user if they no longer require access
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:
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.
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).
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.
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.
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.
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.
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.
Quick question. If a customer uses the same email address for more than one user account will this cause any issue?
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.
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.
Thank you for sharing your feedback. We are looking into this and will follow up when we have a bit more info for you.
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?
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.
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.
Community Manager & Editor
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
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,
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?
hi @Sid.Jagannathan , thanks for your questions. Answers below:
Thanks again for your questions. Happy to discuss further. Feel free to private message me here and we can discuss your specific needs.
Thank you! Your submission has been received!
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form