# Get started with SSO

> Configure an identity provider, test single sign-on, and keep local administrator access available.

Single sign-on (SSO) lets people sign in to Buttons through your organization's identity provider instead of using a separate local password. Buttons supports Google, Microsoft Entra ID, GitHub, Okta, Generic OIDC, and LDAP / Active Directory. Before you begin An Enterprise license. Permission to manage SSO settings. A local administrator account that you have tested and can use if SSO fails. SSO settings do not disable local password sign-in. You can still select sign in with password when the login page opens in the SSO view. Configure your provider Open Settings → SSO . Select Add provider . Configure the connection. See Connect a generic OIDC provider or Connect LDAP or Active Directory for details. If the provider should assign roles, configure role mappings that match its claims or groups. For LDAP, select Test connection . This checks the directory connection, not a complete user sign-in. GitHub does not support role mappings. Assign roles manually to give GitHub users access. Its optional Required Organization setting restricts who can sign in, but does not assign roles. Enable and test SSO Keep Default login set to Local username and password while testing. Enable the provider connection. Turn on SSO login . In a separate browser session, sign in through the provider. Verify that the test user has the roles and access they need. After the test succeeds, optionally set Default login to SSO provider . Enabling SSO makes enabled providers available to users immediately. Keeping local login as the default does not limit SSO to administrators. Default login changes which sign-in view appears first. It does not disable password sign-in. Optional: restrict email domains Before enabling SSO, set Allowed email domains if you want to restrict new email-based accounts to specific domains. Leave it empty to allow any domain. This restriction also applies when Buttons automatically links an SSO identity to an existing local account by email. That link requires a verified email claim from the provider. Changing the allowlist does not block identities already linked to a provider. LDAP username-based account creation does not use this restriction. If SSO fails Select sign in with password and use your local administrator credentials. Correct the connection settings or turn off SSO login in Settings → SSO . If you lose the System Administrator password, follow the administrator password recovery instructions . Problem What to check No SSO providers appear on the login page. SSO login must be on, and at least one provider connection must be enabled. A user signs in but has no access. Check the user's roles and any matching role mappings . For GitHub, assign roles manually. A user authenticates with the provider but cannot create or link an account. Check Allowed email domains . Automatic email-based linking also requires a verified email claim. Where to go next Connect a generic OIDC provider Connect LDAP or Active Directory Map identity claims to roles