> ## Documentation Index > Fetch the complete documentation index at: https://docs.oleria.com/llms.txt > Use this file to discover all available pages before exploring further. # TeamCity > Connect a TeamCity Cloud or TeamCity On-Premises server to Oleria to discover users, groups, project and server roles, access tokens, build agents, stored CI secrets, and audit log activity, and take remediation actions directly from Oleria. TeamCity is JetBrains' CI/CD server. Connect a TeamCity server to Oleria to see who has an account, which groups they're in, which roles they hold on the server and on each project, and which tokens, build agents, and stored secrets can act on your builds. Oleria reads this data from the TeamCity REST API with an access token, or a username and password. You can then review over-provisioned access and take action directly from Oleria. One Oleria integration covers one TeamCity server, either a TeamCity Cloud instance or a TeamCity On-Premises server. To connect another server, add another integration. ## What Oleria discovers Once connected, Oleria continuously discovers and maps the following from your TeamCity server: * **Server** - the server itself, with whether it's TeamCity Cloud or On-Premises, its version and build number, its authorization mode, whether guest login is on, and its enabled login modules. Oleria also shows which sign-in methods the server offers: password, access token, or SSO through a module such as SAML, LDAP, or a GitHub, GitLab, or Google login. * **Accounts** - every user, with name, username, email, and when they were last active. When the audit log has the user's creation event, Oleria also shows when the user was created and by whom. * **Administrators** - a user is marked as an administrator when a server-wide role they hold, directly or through a group, includes an administrative permission, such as managing roles, users, authentication settings, or server settings. The user's highest server-wide role is shown as their account role. * **MFA** - a user with TeamCity two-factor authentication turned on is shown with MFA required. Other users are shown with MFA not required. * **SSO** - a user linked to an external login module, such as SAML, LDAP, or a GitHub or Google login, is shown with SSO. If the user has no TeamCity password, SSO is shown as required. * **Authentication methods** - password, two-factor authentication, SSO, and access token, for users who own an access token that hasn't expired. * **Guest** - when guest login is on, anonymous visitors appear as one **Guest (anonymous)** account. * **Groups** - every user group, with its members, its parent groups, and the roles assigned to it. The built-in **All Users** group contains every user, so roles granted to it apply to everyone. When the audit log has the group's creation event, Oleria also shows when the group was created and by whom. * **Roles** - one role for each role and scope that's in use: a server-wide role is shown for **All projects**, and a project role is shown for that project and its subprojects. Each assignment shows the role's permissions, including the permissions of roles it includes, and roles that include other roles are linked to them. Oleria also lists every role defined on the server, and marks custom roles. * **Non-human identities (NHIs)**: * **Access tokens** - every access token of every user, shown as a personal access token linked to the user who owns it. Each token shows its creation date and expiry. A token that's limited per project shows its projects and permissions. Expired tokens are shown as disabled. * **Build agents** - every agent, including agents that are disconnected, disabled, or not yet authorized, with its pool, IP address, host, version, registration date, last activity, and who authorized it. An agent is shown as enabled only when it's both authorized and enabled. JetBrains-hosted agents on TeamCity Cloud are shown as system accounts. * **Project SSH keys** - every uploaded SSH key, with its key type, fingerprint, and whether it's encrypted. A key is listed once, under the project that owns it. * **VCS root passwords** - VCS roots that sign in to the repository with a password or personal access token, with the VCS type, username, and repository host. When the audit log has the root's creation event, Oleria also shows when the root was created and by whom. * **Connections** - project connections that hold a secret, with their provider type and client ID. Connections that hold AWS access keys are shown as access keys, with the access key ID and region. JetBrains-managed connections on TeamCity Cloud are shown as system accounts. * **Cloud profiles** - cloud agent profiles that hold a secret, such as AWS access keys. A disabled profile is shown as disabled. * **Password parameters** - password-type parameters defined on a project or build configuration. Inherited parameters are listed only where they're defined. Oleria never reads secret values. TeamCity returns only the names of secure values. * **Activity** - events from the TeamCity audit log, including actions TeamCity takes itself, such as: * users created, changed, or deleted, and role and group changes for users and groups * roles created, deleted, or changed * access tokens created or deleted, two-factor authentication changes, and users signed out of all sessions * authentication setting changes * build agents authorized, unauthorized, enabled, disabled, or deleted * VCS root, project, and build configuration changes * SSL certificate and encryption key changes, plugin changes, build approvals, and settings committed to or loaded from version control Each event shows who made it and the objects it affected. Events TeamCity makes itself have no user, so they're shown without an actor. Events Oleria doesn't recognize are kept as custom events. Oleria refreshes users, groups, roles, and NHIs on its [regular sync schedule](/integrations/overview.md#sync-model). > [!NOTE] > > Oleria doesn't import projects, build configurations, or builds as resources. Oleria reads projects and build configurations only to name role scopes and to find stored secrets. ## Prerequisites * A TeamCity Cloud instance, or a TeamCity On-Premises server reachable from the internet over HTTPS on port 443. See [Known limitations](#known-limitations). * A TeamCity user that Oleria connects as, with **System Administrator** on TeamCity On-Premises, or a member of **Cloud Instance Administrators** on TeamCity Cloud. * Admin access to the Oleria workspace. > [!WARNING] > > TeamCity has no service accounts. Every access token belongs to a user, and an administrator can't create a token for another user. The integration acts as the user who owns the token. If that user is deleted, or the token expires or is deleted, discovery stops until you update the integration. Create a dedicated TeamCity user for Oleria that signs in with a TeamCity password, rather than using an employee's account or an account that signs in through SSO. ### Permissions Oleria checks the connection user's server-wide TeamCity permissions. The **System Administrator** role grants all of them on TeamCity On-Premises. On TeamCity Cloud, **Cloud Instance Administrators** grants all of them except `change_user`. See [Remediation actions](#remediation-actions). | Permission | Used for | | :- | :- | | `view_user_profile` | Users, groups, roles, and access tokens. Required. `change_user` also satisfies it. | | `view_project` | Roles and secrets stored in projects. Without it, project roles can't be named, project secrets aren't synced, and the integration's **Capabilities** tab shows roles as not readable. | | `view_audit_log` | Optional. Activity, when and by whom users, groups, and VCS roots were created, and who created access tokens. | | `view_agent_details` | Optional. Build agents. | | `view_build_configuration_settings` | Optional. Password parameters on build configurations. | | `manage_authentication_settings` | Optional. Guest login and the authorization mode, so Oleria can show the guest account and the grants of simple authorization mode. | When you connect, Oleria rejects a user that has neither `view_user_profile` nor `change_user`. A missing optional permission doesn't block the connection, and Oleria skips the data it couldn't read. ## Set up access in TeamCity **1. Create a dedicated user** Sign in to TeamCity as an administrator and create a user for Oleria, such as `oleria`, with a TeamCity password. On TeamCity On-Premises, assign the user the **System Administrator** role. On TeamCity Cloud, add the user to the **Cloud Instance Administrators** group. **2. Create an access token** Sign in as the new user. Select your avatar -> **Profile** -> **Access Tokens** -> **Create access token**. Then fill in the form: * **Name** - enter `Oleria`. * **Expiration** - choose an expiry that fits your rotation policy. Discovery stops when the token expires. * **Permissions scope** - select **Same as current user**, so the token carries all of the user's permissions. **3. Copy the token** Create the token and copy its value. TeamCity shows it only once. > [!NOTE] > > Access tokens work only when token-based authentication is enabled on the server. To connect with a username and password instead, skip the token steps, and make sure the server accepts HTTP basic authentication for the user. The TeamCity interface changes over time. If these steps don't match what you see, refer to TeamCity's [Managing access tokens](https://www.jetbrains.com/help/teamcity/configuring-your-user-profile.html#Managing+Access+Tokens) documentation. ## Connect TeamCity to Oleria **1. Open the integration** Sign in to your Oleria workspace, navigate to **Integrations**, and select **TeamCity**. **2. Complete the connection form** Fill in the connection form: | Field | Notes | | :- | :- | | Server URL | Required. For TeamCity Cloud, `https://.teamcity.com`. For TeamCity On-Premises, the server's address, including any context path, such as `https://ci.example.com/teamcity`. Must use HTTPS on port 443. | | Authentication Method | **Access token** (default) or **Username and password**. | | Access token | Required for **Access token**. The access token you created. | | Username | Required for **Username and password**. The dedicated user's username. | | Password | Required for **Username and password**. The dedicated user's password. | **3. Authenticate** Select **Authenticate**. Oleria checks that it can reach the server, that the credential is valid, and that the user has the required permissions before it saves the integration. The integration is named after your server, for example `TeamCity (acme.teamcity.com)`. ### Edit the connection You can replace the **Access token** or **Password** of an existing integration, for example when you rotate it, or switch the **Authentication Method**. Leave the field blank to keep the stored value. When you switch the method, enter the new method's credentials. The **Server URL** can't be changed. To connect a different TeamCity server, add a new integration. ## Verify the integration Confirm the TeamCity integration appears on the **Connected** tab of your Oleria **Integrations** page with a status of **Healthy**. After the first sync completes, check that users, groups, roles, and NHIs appear in your Oleria workspace, and that System Administrators are marked as administrators. > [!NOTE] > > When the access token expires or is deleted, discovery stops. Create a new token as the same user and enter it by editing the integration. ## Remediation actions Oleria runs actions as the integration's TeamCity user. Before an action runs, Oleria checks that the user holds the action's permissions server-wide. | Action | What it does | Revert | | :- | :- | :- | | Delete user | Deletes the user, because TeamCity users have no disabled state. If the user no longer exists, the action fails with a user-not-found error. | Not supported - TeamCity can't restore a deleted user, its tokens, or its two-factor setup. | | Add user to role | Assigns the role to the user at the role's scope, either all projects or one project. | Supported - removes the assignment, unless it was already removed. | | Remove user from role | Removes the user's direct assignment of the role at that scope. If the user holds the role only through a group or a broader grant, nothing changes and Oleria reports where the role comes from. | Supported - assigns the role again, unless it was already assigned. | | Add user to group | Adds the user to the group directly. | Supported - removes the user from the group, unless they were already removed. | | Remove user from group | Removes the user's direct membership of the group. | Supported - adds the user back, unless they were already added. | | Revoke user sessions | Signs the user out of all their TeamCity sessions. | Not supported - the user signs in again to start a new session. | | Disable NHI accounts - access token | Deletes the access token. | Not supported - TeamCity can't restore a deleted token. The user creates a new one. | | Disable NHI accounts - build agent | Unauthorizes the agent with the comment `Disabled by Oleria`, so it can't run builds. | Supported - authorizes the agent again, if the action unauthorized it and the agent still exists. | | Create user | Creates a TeamCity user with the username, email address, and name you provide, and the password you provide or a generated one, in the groups you choose. Oleria checks that every group exists before it creates the user. TeamCity users have no inactive state, so the new user is active right away, even if the request doesn't ask to activate it. If the username is already taken or a group doesn't exist, the action fails and nothing is created. | Supported - deletes the user the action created, unless it was already deleted. | | Create group | Creates an empty group with the name you provide. Oleria derives the group's key from the name: upper case, with every character other than a letter or digit replaced by an underscore. If a group with that name or key already exists, the action fails and nothing is created. | Supported - deletes the group the action created, unless it was already deleted. | Each action needs these TeamCity permissions: | Action | Required permissions | | :- | :- | | Delete user | `view_user_profile`, `delete_user` | | Add user to role, Remove user from role | `view_user_profile`, `change_user_roles_in_project` | | Add user to group, Remove user from group | `view_user_profile`, `assign_users_add_subgroups` | | Revoke user sessions | `view_user_profile`, `change_user` | | Disable NHI accounts - access token | `view_user_profile`, `change_user` | | Disable NHI accounts - build agent | `view_agent_details`, `authorize_agent`, or `authorize_agent_for_project` instead of `authorize_agent` | | Create user | `create_user`, and `assign_users_add_subgroups` when the request lists groups. Reverting it needs `delete_user`. | | Create group | `create_usergroup`. Reverting it needs `delete_usergroup`. | > [!WARNING] > > TeamCity Cloud doesn't grant `change_user` to Cloud administrators. On TeamCity Cloud, **Revoke user sessions** and revoking access tokens report a missing permission, and the integration's **Capabilities** tab shows **Disable NHI accounts** as missing a permission, because it checks the permissions of every kind of NHI it can disable. Oleria refuses these actions and sends no change to TeamCity: * Deleting, changing the roles or groups of, or signing out the user this integration connects as, or deleting that user's access tokens. Oleria also refuses these actions when it can't confirm which user the integration connects as. * Adding users to, or removing them from, the **All Users** group, because every user is always a member. **Create user** also refuses **All Users** in its list of groups. * Running user actions on the guest account or an NHI. * Unauthorizing a JetBrains-hosted agent on TeamCity Cloud, because JetBrains manages it. * Disabling project SSH keys, VCS root passwords, connections, cloud profiles, or password parameters. See [Known limitations](#known-limitations). Keep these points in mind: * For role, group membership, and build agent actions, if the target is already in the requested state, the action succeeds without making a change, and there's nothing to revert. * Role and group actions change only direct assignments and memberships. A user can still hold a role through a group, or through a role granted to **All Users**. * TeamCity won't let a user delete another user who has permissions the deleting user lacks, so **Delete user** fails for such a user. ## Known limitations * **The connection is tied to one person.** See [Prerequisites](#prerequisites). TeamCity has no OAuth sign-in for third-party REST API clients. The OAuth sign-in in TeamCity 2026.1 and later is for TeamCity's own command-line tool and AI agent integrations, and issues a token tied to the signed-in user. Oleria connects with an access token or a username and password. * **No sign-in events or IP addresses.** TeamCity's audit log doesn't record sign-ins, failed sign-ins, IP addresses, or user agents, and doesn't say which access token made a change. Changes Oleria makes through remediation actions appear as changes by the integration's user. * **Activity history is limited.** Oleria imports at most the last 90 days of earlier activity. TeamCity keeps audit records indefinitely unless server clean-up is enabled, which removes nonessential records after one year. Creation dates of users, groups, and VCS roots come from the audit log, so they're missing for older objects and when the user lacks `view_audit_log`. * **Users can't be disabled.** TeamCity has no disabled state for users, so every user is shown as enabled, and **Delete user** is the only way to remove access. Deletion can't be reverted. * **No password-change or token last-used dates.** TeamCity's API doesn't report when a user last changed their password or when an access token was last used. * **Server-wide two-factor settings aren't known.** TeamCity's API shows whether each user has two-factor authentication on, but not whether the server makes it optional or mandatory. MFA enforced by an external login provider isn't visible. * **Authorization mode affects roles.** In simple authorization mode, Oleria adds TeamCity's documented default grants: **All Users** holds **Project Developer** for all projects, and the guest account holds **Project Viewer** for all projects. In per-project authorization mode, the guest account's roles are configured only in the TeamCity interface and aren't readable, so the guest account is shown with no roles. * **JetBrains-hosted agents are temporary.** On TeamCity Cloud, JetBrains-hosted agents exist only while they run a build. Oleria shows them only if they exist when it syncs, and can't disable them. * **SSH keys and stored secrets can't be disabled.** TeamCity can only delete a project SSH key, which destroys the private key and breaks every VCS root that uses it. VCS root passwords, connections, cloud profiles, and password parameters have no disabled state. Manage them in TeamCity instead. * **Agent authentication tokens aren't inventoried.** Oleria doesn't read each build agent's own authentication token or agent pool tokens. * **TeamCity Cloud limits remediation.** TeamCity Cloud administrators can't hold `change_user`, so Oleria can't revoke access tokens or sign users out on TeamCity Cloud. * **Operator access isn't visible.** On TeamCity Cloud, JetBrains' own access to the server doesn't appear in any API. On TeamCity On-Premises, the super user, which signs in with a token written to the server log, doesn't appear in any API, so Oleria doesn't show it. * **On-premises servers must be reachable.** Oleria can connect to TeamCity Cloud (`*.teamcity.com`) hosts. A TeamCity On-Premises server must be reachable from the internet over HTTPS on port 443. If TeamCity listens on another port, publish it on 443 through a reverse proxy or load balancer first. Addresses that resolve to private or loopback IP addresses are refused. Contact [support@oleria.com](mailto:support@oleria.com) to allow your server's host before you connect. ## Contact us For questions about this integration, contact us at [support@oleria.com](mailto:support@oleria.com). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.