Now you’ve enabled SSO and User Provisioning with your IdP, it’s time to select the first team you want to onboard to StrongDM. In order to make the process repeatable and scalable for the rest of your organization, we recommend you start by picking a single team to onboard first. That way we can demonstrate the value to your users and leadership quickly, in turn creating advocates who can help drive the wider rollout.
Things to consider when selecting the first team:
- Think about teams who could benefit most from StrongDM, where there’s likely a clear mandate for change - address the largest pain points first
- Look for teams of no more than 30-50 people if possible. The rollout and training will be simpler & the feedback loop quicker
- Identify teams where we can move all the resources they need access to behind StrongDM & cut off alternate access methods. Having them working only through StrongDM by the end of onboarding will be the clearest path to proving value or identifying gaps quickly
Once you’ve decided on the team, here are our recommendations for the next steps:
- Confirm all environments that the team needs access to through StrongDM
- Determine which environments are relevant for the team in question: Production/Staging/Development/Sandbox etc.
- It’s critical to ensure that the team can access all their required resources through StrongDM, so you can fully evaluate the success or otherwise of the onboarding phase against your buying goals
- Having a team working half in StrongDM, and half outside StrongDM typically makes it difficult to truly measure success
- Within those environments, what resources do they access?
- Start with specific resource families - k8s, databases, SSH, RDP, HTTP, etc.
- Then drill down into specific protocols
- Database types (MySQL vs PostgreSQL)
- Plain Kubernetes vs AWS Elastic Kubernetes Service
- Similarly, narrow down to desired/required authentication type for the resources in question
- PostgreSQL username/password authentication vs PostgreSQL mTLS authentication
- SSH Public Key authentication vs SSH Certificate authentication
- This should create a list of all resources you want to add to StrongDM as part of the onboarding phase
- Plan your access model structure for the chosen pilot resources and provision the necessary credentials that correspond to that access model on the end resources to register with StrongDM
- For example, a common StrongDM model would be to provision 3 sets of credentials/accounts for a single database for different access levels. These will be registered and reflected as separate resources in StrongDM:
- 1 Read-only credential
- 1 Read/Write credential
- 1 Full CRUD credential
- Along the same lines, a common model for SSH servers would be to register a sudo user and a non-sudo user as two separate resources in StrongDM to provide options for least privilege, and higher privileged resources.
- Consider using automation to register these resources for resource creation and registration with StrongDM. This is available via both StrongDM SDKs and the StrongDM Terraform Provider (more information on this in the next section)
