TeamCity 2020.2 ヘルプ

認証設定を構成する

TeamCity は、内部データベースを介してユーザーを認証することも、システムに統合して、Windows ドメイン、LDAP、Git ホスティングプロバイダーなどの外部認証ソースを使用することもできます。

認証の設定

認証は管理 | 認証ページで構成されます。現在使用されている認証モジュールも表示されます。

TeamCity は、最も一般的な使用例をカバーするために、いくつかの事前構成された認証オプション(プリセット)を提供します。プリセットは、TeamCity でサポートされている認証モジュールの組み合わせです。

TeamCity に最初にサインインすると、組み込みおよび基本 HTTP 認証モジュールを含むデフォルトの認証が有効になります。

既存の設定を変更するには、有効な認証モジュールの説明の横にある編集をクリックします。

別の事前設定されたスキームに切り替えるには、プリセットを読み込むボタンを使用します。

プリセットの使用

事前設定されたモジュールのセットをロードするには、プリセットを読み込むボタンを使用し、必要なオプションを選択して、変更を適用します。次のプリセットを使用できます。

複数の認証モジュールの有効化

TeamCity を使用すると、複数の認証モジュールを同時に有効にできます。

ユーザーがサインインしようとすると、モジュールが 1 つずつ試行されます。それらの 1 つがユーザーを認証すると、ログインは成功します。それらすべてが失敗した場合、ユーザーは TeamCity にサインインできなくなります。

内部認証と外部認証を組み合わせて使用することができます。推奨されるアプローチは、最初に内部従業員用に LDAP の統合を構成してから、外部ユーザー用にビルトイン認証を追加することです。TeamCity 2020.2 以降、OAuth サービスを介した認証を有効にすることもできます。

モジュールを追加するには:

  1. モジュールの追加をクリックし、ドロップダウンメニューからモジュールを選択します。

  2. モジュールの追加ダイアログのチェックボックスを選択して、モジュールで使用可能なプロパティを使用します。

  3. 変更を適用および保存をクリックします。

一般的な認証設定

一般設定ブロックでは、次のことができます。

ユーザー認証設定

TeamCity サーバーがユーザーなし(および管理者なし)で起動するのは初めてなので、最初のユーザーは管理者アカウントの入力を求められます。管理者アカウントの入力を求められない場合は、管理者パスワードを取得する方法で解決策を確認してください。

TeamCity 管理者は、プロファイルページですべてのユーザーの認証設定を変更できます。

ユーザーと認証モジュールの TeamCity リストは、外部資格情報をユーザーにマップするだけです。これは、入力された資格情報が同じ TeamCity ユーザーにマップされている場合、単一の TeamCity ユーザーが異なるモジュールを使用して認証できることを意味します。認証モジュールには、外部ユーザーデータを TeamCity ユーザーにマップする方法に関する構成があり、一部のモジュールでは、TeamCity ユーザープロファイルのデータをリンクする外部ユーザーを編集できます。

バンドルされた認証モジュールによるユーザーマッピングの処理

  • 組み込みの認証により、TeamCity が管理する各ユーザーのパスワードが保存されます。

  • Windows ドメイン認証では、デフォルトドメインを指定でき、ドメインアカウント名が TeamCity ユーザーと同じであると想定されます。ドメインアカウントは、ユーザープロファイルページで編集できます。

  • LDAP 統合により、LDAP プロパティを設定して、ユーザーの LDAP エントリから TeamCity ユーザー名を取得できます。

  • Git ホスティングプロバイダーに対応するモジュールを使用すると、管理者はユーザー名によってユーザーを外部アカウントにマッピングできます。各ユーザーは、自分のプロファイルを設定とツール | 一般 | 認証設定の外部 Git ホスティングアカウントに接続できます。

認証設定を変更する場合は注意が必要です。認証モジュールを変更した後、管理者がサインインできない場合があります。
管理者が「jsmith」を持っていたと想像してみましょう。TeamCity ユーザー名であり、デフォルトの認証を使用しました。次に、認証モジュールが Windows ドメイン認証に変更されます(つまり、Windows ドメイン認証モジュールが追加され、デフォルトのモジュールが削除されます)。たとえば、その管理者の Windows ドメインユーザー名が「john.smith」の場合、ユーザーはサインインできなくなります。デフォルトの認証が無効になっているため、または Windows ドメインのユーザー名が無効になっているため Windows ドメイン認証を使用しません。TeamCity ユーザー名と同じです。それでも、解決策は非常に簡単です。管理者は、スーパーユーザーアカウントを使用してサインインし、TeamCity ユーザー名を変更するか、自分のプロファイルページで Windows ドメインユーザー名を指定できます。

特別なユーザーアカウント

デフォルトでは、TeamCity は最大権限を持つスーパーユーザーアカウントと最小権限を持つゲストユーザーアカウントを持っています。これらのアカウントは、特定の人物に関連するものではなく、特別な使用例を目的としているため、変更ページやプロファイル情報などの個人設定はありません。

認証情報認証モジュール

組み込み認証

デフォルトでは、TeamCity は組み込みの認証を使用し、ユーザーとそのパスワードを単独で維持します。

TeamCity に初めてサインインするとき、ユーザーは TeamCity に保存され、認証に使用される TeamCity のユーザー名とパスワードを作成するように求められます。TeamCity をインストールしてサインインした場合、組み込みの認証が有効になり、すべてのユーザーデータが TeamCity に保存されることを意味します。

最初は、ユーザーデータベースは空です。新しいユーザーは TeamCity 管理者によって追加されるか、認証モジュール設定で対応するオプションが有効になっている場合はユーザーが自分で登録します。新しく作成されたすべてのユーザーはすべてのユーザーグループに属し、このグループにすべてのロールが割り当てられています。新しく登録されたユーザーに特定のロールが必要な場合は、これらのロールをすべてのユーザーグループを介して付与する必要があります

デフォルトでは、ユーザーは自分のプロファイルページで自分のパスワードを変更できます。

トークンベース認証

このモジュールを使用すると、ユーザーは自分で作成して無効にできるアクセストークンを介して認証できます。

この認証モジュールはデフォルトで有効になっています。

Windows ドメイン認証

ユーザーが Windows ドメイン名とパスワードを使用してサインインできるようにします。TeamCity は、これらの資格情報をチェックします。サーバーは、ユーザーがサインインに使用するドメインを認識している必要があります。ユーザー名でサポートされている構文は、DOMAIN\user.name または <username>@<domain> です。

ログインフォームを使用してサインインすることに加えて、NTLM HTTP 認証シングルサインオンを有効にすることができます。
「Microsoft Windows ドメイン」プリセットを選択すると、Windows ドメインを介したログインに加えて、基本 HTTP および NTLM 認証モジュールがデフォルトで有効になります。

デフォルトドメインの指定

ユーザーがユーザー名の一部としてドメインを指定せずにログインフォームを使用してシステムに入ることができるようにするには、次の手順を実行します。

  1. 管理 | 認証に移動します。

  2. Microsoft Windows ドメイン認証の説明の横にある編集をクリックします。

  3. デフォルトドメインフィールドに名前を設定します。

  4. 変更を終了および保存をクリックします。

ログイン時に新規ユーザーを登録する

デフォルト設定では、ユーザーはログインページから登録できます。新規ユーザーの TeamCity ユーザー名は、Windows ドメインアカウントと同じになります。
新しく作成されたすべてのユーザーはすべてのユーザーグループに属し、このグループにすべてのロールが割り当てられています。新しく登録されたユーザーに特定のロールが必要な場合は、これらのロールをすべてのユーザーグループを介して付与する必要があります

ログイン時に新規ユーザー登録を無効にするには

  1. 管理 | 認証に移動します。

  2. Microsoft Windows ドメイン認証の説明の横にある編集をクリックします。ログインページからユーザー登録を許可する ボックスをオフにします。

  3. NTLM HTTP 認証の説明の横にある編集をクリックします。ログインページからユーザー登録を許可する ボックスをオフにします。

Linux 固有の設定

TeamCity サーバーが Linux で実行されている場合、Windows ドメインのログインには JCIFS ライブラリが使用されます。これは、SMB(SMBv1)が有効になっている Windows ドメインサーバーのみをサポートします。SMB2 はサポートされていません。
ライブラリは、<TeamCity Data Directory>/config/ntlm-config.properties ファイルで指定されたプロパティを使用して構成されます。ファイルへの変更は、サーバーを再起動しなくてもすぐに有効になります。

実行時に変更できない JCIFS ライブラリ設定、または HTTP NTLM 設定に影響を与える設定は、-Djcifs.properties JVM オプションを介して渡されるプロパティのファイルを介してのみ設定できます。

ご使用の環境でデフォルト設定が機能しない場合は、使用可能なすべての構成プロパティについて JCIFS(英語) を参照してください。
ライブラリが認証対象のドメインコントローラーを見つけられない場合は、WINS サーバーのアドレスを使用して jcifs.netbios.wins プロパティを ntlm-config.properties ファイルに追加することを検討してください。プロパティを見つける他のドメインサービスについては、JCIFS(英語) を参照してください。

LDAP 認証

専用ページをご参照ください

HTTP/SSO 認証モジュール

基本 HTTP 認証

基本 HTTP 認証の詳細については、HTTP によるサーバーへのアクセスを参照してください。

NTLM HTTP 認証

専用ページをご参照ください

Bitbucket クラウド

バージョン 2020.2 以降、ユーザーは Bitbucket クラウドアカウントを使用して TeamCity にサインインできます。

このモジュールを有効にする前に、ルートプロジェクトの設定で Bitbucket クラウド接続を構成し、Bitbucket で専用アプリケーションを構成する必要があります。

サインインするには、ログインフォームの上にある Bitbucket アイコンをクリックし、リダイレクト後、TeamCity アプリケーションを承認します。Bitbucket メールのユーザーが登録され、このメールが TeamCity と Bitbucket の両方で確認された場合、この Bitbucket アカウントはそれぞれの TeamCity ユーザーにマッピングされ、サインインします。それ以外の場合、TeamCity は新しいユーザープロファイルを作成します。このオプションは無効になっています *。既存の TeamCity ユーザーを Bitbucket クラウドプロファイルにマッピングすることも可能です。

設定 説明

* 最初のログインで新しいユーザーの作成を許可する

デフォルトで有効になっています。
無効にすると、提供された外部メールが認識されない場合、TeamCity は新しいユーザーを作成しません。これは、公開されている TeamCity サーバーを使用していて、そのサーバーへのアクセスを制限する場合に役立ちます。

認証を制限する

ワークスペース(英語)の ID のコンマ区切りのリスト。

このリストは、Bitbucket クラウドアカウントを使用して TeamCity に登録または認証できるユーザーのセットを制限します。有効になっている最初のログイン時に新しいユーザーの作成を許可するオプションとともに、これにより、不明なユーザーを自動的に登録する機能が残りますが、プロジェクトで作業するユーザーに制限されます。

空のままにして、すべての Bitbucket クラウドユーザーが TeamCity サーバーにアクセスできるようにします。

GitHub.com

バージョン 2020.2 以降、ユーザーは GitHub.com アカウントで TeamCity にサインインできます。

このモジュールを有効にする前に、ルートプロジェクトの設定で GitHub.com 接続を構成し、GitHub で専用アプリケーションを構成する必要があります。

サインインするには、ログインフォームの上にある GitHub アイコンをクリックし、リダイレクト後、TeamCity アプリケーションを承認します。GitHub メールを使用するユーザーが登録され、このメールが TeamCity と GitHub の両方で確認された場合、この GitHub アカウントはそれぞれの TeamCity ユーザーにマッピングされ、ログインします。それ以外の場合、TeamCity は新しいユーザープロファイルを作成します。このオプションは無効になっています *。GitHub.com プロファイルを使用して既存の TeamCity ユーザーをマッピングすることもできます。

設定 説明

* 最初のログインで新しいユーザーの作成を許可する

デフォルトで有効になっています。
無効にすると、提供された外部メールが認識されない場合、TeamCity は新しいユーザーを作成しません。これは、公開されている TeamCity サーバーを使用していて、そのサーバーへのアクセスを制限する場合に役立ちます。

認証を制限する

組織(英語)の ID のコンマ区切りのリスト。

このリストは、GitHub アカウントを使用して TeamCity に登録または認証できるユーザーのセットを制限します。有効になっている最初のログイン時に新しいユーザーの作成を許可するオプションとともに、これにより、不明なユーザーを自動的に登録する機能が残りますが、プロジェクトで作業するユーザーに制限されます。

空のままにして、すべての GitHub ユーザーが TeamCity サーバーにアクセスできるようにします。

GitHub Enterprise

バージョン 2020.2 以降、ユーザーは GitHubEnterprise アカウントで TeamCity にサインインできます。

このモジュールを有効にする前に、ルートプロジェクトの設定で GitHubEnterprise 接続を構成し、GitHub で専用アプリケーションを構成する必要があります。

サインインするには、ログインフォームの上にある GitHub アイコンをクリックし、リダイレクト後、TeamCity アプリケーションを承認します。GitHub メールを使用するユーザーが登録され、このメールが TeamCity と GitHub の両方で確認された場合、この GitHub アカウントはそれぞれの TeamCity ユーザーにマッピングされ、ログインします。それ以外の場合、TeamCity は新しいユーザープロファイルを作成します。このオプションは無効になっています *。既存の TeamCity ユーザーを GitHubEnterprise プロファイルにマッピングすることもできます。

設定 説明

* 最初のログインで新しいユーザーの作成を許可する

デフォルトで有効になっています。
無効にすると、提供された外部メールが認識されない場合、TeamCity は新しいユーザーを作成しません。これは、公開されている TeamCity サーバーを使用していて、そのサーバーへのアクセスを制限する場合に役立ちます。

認証を制限する

組織(英語)の ID のコンマ区切りのリスト。

このリストは、GitHub アカウントを使用して TeamCity に登録または認証できるユーザーのセットを制限します。有効になっている最初のログイン時に新しいユーザーの作成を許可するオプションとともに、これにより、不明なユーザーを自動的に登録する機能が残りますが、プロジェクトで作業するユーザーに制限されます。

空のままにして、すべての GitHub ユーザーが TeamCity サーバーにアクセスできるようにします。

GitLab.com

バージョン 2020.2 以降、ユーザーは GitLab.com アカウントで TeamCity にサインインできます。

このモジュールを有効にする前に、ルートプロジェクトの設定で GitLab.com 接続を構成し、GitLab で専用アプリケーションを構成する必要があります。

サインインするには、ログインフォームの上にある GitLab アイコンをクリックし、リダイレクト後、TeamCity アプリケーションを承認します。GitLab メールを使用するユーザーが登録され、このメールが TeamCity と GitLab の両方で確認された場合、この GitLab アカウントはそれぞれの TeamCity ユーザーにマッピングされ、ログインします。それ以外の場合、TeamCity は新しいユーザープロファイルを作成します。このオプションは無効になっています *。既存の TeamCity ユーザーを GitLab.com プロファイルでマッピングすることも可能です。

設定 説明

* 最初のログインで新しいユーザーの作成を許可する

デフォルトで有効になっています。
無効にすると、提供された外部メールが認識されない場合、TeamCity は新しいユーザーを作成しません。これは、公開されている TeamCity サーバーを使用していて、そのサーバーへのアクセスを制限する場合に役立ちます。

認証を制限する

グループ(英語)の ID のコンマ区切りのリスト。

このリストは、GitLab アカウントを使用して TeamCity に登録または認証できるユーザーのセットを制限します。有効になっている最初のログイン時に新しいユーザーの作成を許可するオプションとともに、これにより、不明なユーザーを自動的に登録する機能が残りますが、プロジェクトで作業するユーザーに制限されます。

空のままにして、すべての GitLab ユーザーが TeamCity サーバーにアクセスできるようにします。

GitLab CE/EE

バージョン 2020.2 以降、ユーザーは GitLab CE/EE アカウントで TeamCity にサインインできます。

このモジュールを有効にする前に、ルートプロジェクトの設定で GitLab CE/EE 接続を構成し、GitLab で専用アプリケーションを構成する必要があります。

サインインするには、ログインフォームの上にある GitLab アイコンをクリックし、リダイレクト後、TeamCity アプリケーションを承認します。GitLab メールを使用するユーザーが登録され、このメールが TeamCity と GitLab の両方で確認された場合、この GitLab アカウントはそれぞれの TeamCity ユーザーにマッピングされ、ログインします。それ以外の場合、TeamCity は新しいユーザープロファイルを作成します。このオプションは無効になっています *。既存の TeamCity ユーザーを GitLabCE/EE プロファイルでマッピングすることも可能です。

設定 説明

* 最初のログインで新しいユーザーの作成を許可する

デフォルトで有効になっています。
無効にすると、提供された外部メールが認識されない場合、TeamCity は新しいユーザーを作成しません。これは、公開されている TeamCity サーバーを使用していて、そのサーバーへのアクセスを制限する場合に役立ちます。

認証を制限する

グループ(英語)の ID のコンマ区切りのリスト。

このリストは、GitLab アカウントを使用して TeamCity に登録または認証できるユーザーのセットを制限します。有効になっている最初のログイン時に新しいユーザーの作成を許可するオプションとともに、これにより、不明なユーザーを自動的に登録する機能が残りますが、プロジェクトで作業するユーザーに制限されます。

空のままにして、すべての GitLab ユーザーが TeamCity サーバーにアクセスできるようにします。