ADFSを使ったSAML連携のための環境構築手順

はじめに

こんにちは。グロービスにてGLOPLA LMSのバックエンド開発を担当している山下です。

一つ前の記事ではKeycloakを使ってローカルにSAMLのIdPサーバーを立てる方法について解説しましたが、今回はAWS上にADFSサーバーを構築し、それを使ってSAMLのIdPとして認証を行うまでの手順について書いていきたいと思います。

おことわり

• SAML連携の検証環境構築を目的としているので本番環境を想定したセキュリティは意識していません
• 個人のAWSアカウントを使って簡素なネットワーク上に構築しています。もしかすると企業内の本番構成だとうまく行かないケースもあると思いますので、そういった場合はインフラの有識者の方と一緒にデバッグされることをお勧めします

0. 前提

• AWSアカウントは取得しておいてください
• 無料の範囲では構築できません
• AWSそのものについての話やインフラの細かい説明は割愛します

1. AWSにインフラを準備する

URLに使用するドメインを取得する

※ すでに使用可能なドメインを持っている場合はこの手順は不要です

今回の検証では立ち上げたサーバーに外からアクセスするためのドメインを設定する必要があります。任意の文字列で取得しましょう。

こちらの手順を参考にしてください。

https://blog.serverworks.co.jp/route53-domain-registration

WindowsServerのAMIを使ってEC2を立てる

カタログAMIから、以下の設定でEC2のインスタンスを作ってください。

• Windows Server 2012 R2 を選択
• インスタンスサイズ: t2.xlarge (もしくは同等スペック。メモリが小さいと動作が不安定になります。largeでもトライしてみたんですが不安定だったのでやめた方がいいです)
• ボリューム (EBS) : 60GB以上
• VPC、セキュリティグループ等はデフォルトでOK
• 作成時にキーペアの保存を促されるので保存する (後で使います)

設定確認し問題なければ作成しましょう。

セキュリティグループを変更する

HTTP/HTTPS, RDP, DNS, LDAPに対応したポートが空いていれば問題ないはずです。(検証のため雑な設定になっていますが、本来はもっと整理されていた方が良さそう)

参考

EC2のIPとDNSを紐付ける

インスタンスの設定 → ネットワーキング → ElasticIPの割り当て を行いEC2とIPを紐付け、Route53からはそのIPとDNSのAレコードを関連づけます。

参考: https://zenn.dev/banana/articles/96b5373114b3d1

インフラの設定はここまでで完了です。続いて、WindowsServerに設定を追加していくためにまずはリモートデスクトップでログインしてみましょう。

こちらの記事を参考に、先ほど立てたEC2へリモートデスクトップ接続を行います。

https://dev.classmethod.jp/articles/mac-ec2-windows-rdp-connect/

ログインできたら、設定を進めていきます。

2. AD DSを構成する

Webサーバーのインストール

1. サーバーマネージャーを起動して[役割と機能の追加]をクリックし、[役割と機能の追加ウィザード]を起動します。
2. [インストールの種類の選択]画面で「役割ベースまたは機能ベースのインストール」を選択します。
3. [対象サーバーの選択]画面で「サーバープールからサーバー選択」を選択し、インストール先となるサーバーを選択します。
4. [サーバーの役割選択]画面で、「Webサーバー(IIS) 」を選択します
5. 以降はデフォルトのチェックのまま進めてインストールを完了してください

重要
(ここから先は、「5. SAML連携のための設定」 までほぼ下記の内容で進めていくので、適宜参照しながら作業することをお勧めします https://support.createwebflow.jp/doc/files/saml_adfs.pdf )

AD DSのインストール

1. サーバーマネージャーを起動して[役割と機能の追加]をクリックし、[役割と機能の追加ウィザード]を起動します。
2. [インストールの種類の選択]画面で「役割ベースまたは機能ベースのインストール」を選択します。
3. [対象サーバーの選択]画面で「サーバープールからサーバー選択」を選択し、インストール先となるサーバーを選択します。
4. [サーバーの役割選択]画面で、「Active Directoryドメインサービス」を選択します。ダイアログがポップするので[機能の追加]をクリックし、機能を追加します。
5. AD DSを利用する上での注意事項が表示されます。[次へ]をクリックします。
6. 以降はデフォルトのチェックのまま進めてインストールを完了してください。

AD DSの設定

1. サーバーマネージャーの上部フラッグに警告マークが表示されているので、クリックします。

2. 表示されたメニュー、展開後の構成から[このサーバーをドメインコントローラーに昇格する]をクリックし、Active Directoryドメインサービス構成ウィザードを起動します。

3. [配置構成]画面でドメインコントローラーの配置を設定します。今回は新しいフォレストを作成するので、以下を設定して[次へ]をクリックします。

   • 新しいフォレストを追加する: チェックを入れる
   • ルートドメイン名: Route53で取得したドメイン

4. [ドメインコントローラーオプション]画面でドメインコントローラーとして機能レベルや、ディレクトリサービス復元モードのパスワードを設定します。以下を設定して[次へ]をクリックします。

   • フォレストの機能レベル: Windows Server 2012 R
   • ドメインの機能レベル: Windows Server 2012
   • ドメインネームシステム(DNS)サーバー: チェックを入れる
   • グローバルカタログ: デフォルトでチェック済み
   • DSSMのパスワード: 任意のパスワード

5. [DNSオプション]画面では、設定できる項目はないため、[次へ]をクリックします。

6. [追加オプション]画面でNetBIOSドメイン名を設定します。(自動でも入力されますが、何かわかりやすい名前を設定しておくと良さそうです ADDS-SERVER とか)

7. [パス]画面でAD DSが利用するデータベースフォルダーや、ログファイル、SYSVOLフォルダのパスを設定します。ここでは自動的に設定された値のまま[次へ]をクリックします。

8. [オプションの確認]画面で設定した内容の確認が表示されます。確認後、問題なければ[次へ]をクリックします。

9. [前提条件のチェック]画面では、警告が３つほど表示されますが、[すべての前提条件のチェックに合格しました。] というメッセージが表示されていれば問題ないため、 [インストール] をクリックします。

10. 構成が完了すると「このサーバーはドメインコントローラーとして正常に構成されました」というメッセージと再起動を促す画面が表示されます。[閉じる]をクリックして、再起動を行います。

動作確認

1. 再起動後、リモートデスクトップ接続で同様にログインし、ユーザー名が設定した「NetBIOS名¥ユーザー名」になっていることを確認します。
2. アプリ画面を表示し、AD DSの管理ツールがインストールされていることを確認します。

3. AD FSの導入

.NET Framework 3.5 Featuresのインストール

1. サーバーマネージャーを起動して[役割と機能の追加]をクリックし、[役割と機能の追加ウィザード]を起動します。
2. [インストールの種類の選択]画面で「役割ベースまたは機能ベースのインストール」を選択します。
3. [対象サーバーの選択]画面で「サーバープールからサーバー選択」を選択し、インストール先となるサーバーを選択します。

[機能の選択]画面で「.NET Framework 3.5 Features」にチェックを入れ、[次へ]をクリックします。[インストール]をクリックします。

(※ この作業はもしかするとWebサーバーのインストール時に完了しているかもしれません。その場合スキップしてOKです。)

SSL証明書の作成

AD FSの構成ではSSLサーバ証明書が必要なため AD CSを使用して自己証明書を作成します。

AD CSのインストール

1. サーバーマネージャーを起動して[役割と機能の追加]をクリックし、[役割と機能の追加ウィザード]を起動します。[次へ]をクリックします。
2. [インストールの種類の選択]画面で「役割ベースまたは機能ベースのインストール」を選択して、[次へ]をクリックします。
3. [対象サーバーの選択]画面で「サーバープールからサーバー選択」を選択し、インストール先となるサーバーを選択します。[次へ]をクリックします。
4. [サーバーの役割選択]画面で、「Active Directory証明書サービス」を選択します。 [次へ]をクリックします。
5. [機能の選択]画面では何も選択せず、[次へ]をクリックします。
6. [役割サービスの選択]画面で「証明機関」を選択して、[次へ]をクリックします。
7. [インストール]をクリックします。

AD CSの構成

1. サーバーマネージャーの上部フラッグに警告マークが表示されているので、クリックします。
2. 表示されたメニュー、展開後の構成から[対象サーバーにActiveDirectory証明書サービスを構成する]をクリックし、AD CSの構成ウィザードを起動します。
3. [資格情報]画面で証明書サービスを構成するための管理者アカウントを指定して、[次へ]をクリックします。
4. [役割サービス]画面で「証明機関」を選択して[次へ]をクリックします。
5. [セットアップの種類]画面で「エンタープライズCA」を選択して[次へ]をクリックします。
6. [CA種類]画面で「ルートCA」を選択して[次へ]をクリックします。
7. [秘密キー]画面で「新しい秘密キーを作成」を選択して[次へ]をクリックします。
8. [CAの暗号化]画面で「SHA256」を選択し、[次へ]をクリックします。
9. [CAの名前]画面で共通名を任意で変更し、[次へ]をクリックします。
10. [有効期間]画面で証明機関の有効期限を入力し、[次へ]をクリックします。
11. [CAデータベース]画面でデータベースの場所を任意で指定し、[次へ]をクリックします。
12. [確認]画面で設定した内容の確認が表示されます。確認後、問題なければ[構成]をクリックします。
13. [閉じる]をクリックしてAD CSの構成ウィザードを閉じます。

証明書テンプレートの作成

1. サーバーマネージャーの[ツール]メニューから[証明機関]を選択します。
2. 証明機関が起動したら、[証明書テンプレート]を右クリックして[管理]をクリックします。
3. [証明書テンプレートコンソール]が起動するので、テンプレートの一覧から[Webサーバー]を右クリックして[テンプレートの複製]をクリックします。
4. [新しいテンプレートのプロパティ]画面で以下を設定し、[OK]をクリックします。

タブ	設定	設定値
全般	テンプレート表示名	任意の表示名
要求処理	秘密キーのエクスポートを許可する	チェックを入れます。
セキュリティ	グループ名またはユーザー名	[追加]をクリックし、証明書の発行を許可するサーバーを追加します。（※）
セキュリティ	アクセス許可	追加したサーバーを選択した状態で、[登録]をチェックします。

※[セキュリティ]タブ-[グループ名またはユーザー名]の設定については、以下の手順で行います。

① [新しいテンプレートのプロパティ]画面で[追加]をクリックし、[ユーザー、コンピューター、サービスアカウントまたはグループの選択]画面を表示します。
② [オブジェクトの種類]をクリックし、[オブジェクトの種類]画面が表示されたら、「コンピューター」にチェックし、[OK]をクリックします。
③ [ユーザー、コンピューター、サービスアカウントまたはグループの選択]画面で、「選択するオブジェクト名を入力してください」の項目にコンピューター名を入力し、[名前の確認]をクリックします。
④ コンピューターが検索され、コンピューター名に下線が付いたら、[OK]をクリックします。
⑤ [新しいテンプレートのプロパティ]画面にコンピューター名が登録されていることを確認します。

1. [証明書テンプレートコンソール] を閉じます。
2. [証明機関]コンソールで[証明書テンプレート]を右クリックして[新規作成]から[発行する証明書テンプレート]を選択します。
3. 先ほど作成したテンプレートを選択し、[OK]をクリックします。
4. 証明機関コンソールの証明機関テンプレート一覧に作成したテンプレートが表示されていることを確認します。

証明書の発行

1. [ファイル名を指定して実行] (Winキー + R)で「MMC」を入力し、コンソールを起動します。

2. [ファイル]メニューから[スナップインの追加と削除]をクリックします。

3. [利用できるスナップイン]から[証明書]を選択し、[追加]をクリックします。

4. [証明書スナップイン]画面で[コンピューターアカウント]を選択し、[次へ]をクリックします。

5. [ローカルコンピューター]を選択して[完了]をクリックします。

6. [スナップインの追加と削除]画面で[OK]をクリックします。

7. [個人]を右クリックして[すべてのタスク]から[新しい証明書の要求]をクリックします。

8. [証明書の登録]画面で[次へ]をクリックします。

9. [証明書の登録ポリシーの選択]画面で「Active Directory登録ポリシー」が選択された状態で[次へ]をクリックします。

10. [証明書の要求]画面で作成した証明書テンプレートをチェックし、 [この証明書を登録するには情報が不足しています。設定を構成するには、ここをクリックしてください]をクリックします。

11. [証明書のプロパティ]画面の[サブジェクト]タブで以下を追加し、[OK]をクリックします。

    設定	種類	値
    サブジェクト名	共通名	Route53で取得したドメイン
    別名	DNS	Route53で取得したドメイン

12. [証明書の要求]画面で作成した証明書テンプレートが選択されていることを確認して、[登録]をクリックします。

13. 証明書の登録が完了すると、 [証明書インストールの結果]画面に「状態：成功」と表示されます。[完了]をクリックし画面を閉じます。

サービスアカウントの作成

AD FSを使用するには、実行するためのサービスアカウントが必要になります。ここで作成するサービスアカウントは「Group Managed ServiceAccount(以下gMSA)」と呼ばれるもので、ドメイン内で共通で使用することができます。

KDSルートキーの作成

gMSAのパスワードを生成するために必要なKDSルートキーを作成します。
PowerShell アイコンを右クリックで「管理者として実行」から起動し、以下のコマンドを実行します。

Add-KdsRootKey –EffectiveTime ((get-date).addhours(-10))

gMSAの作成

PowerShell アイコンを右クリックで「管理者として実行」から起動し、以下のコマンドを実行します。

New-ADServiceAccount <サービスアカウント名> DNSHostName <Route53で設定したドメイン> ServicePrincipalNames <サービス プリンシパル名 (SPN名) >

※<サービスアカウント名>は任意ですが、後の作業で使うため、必ずメモしておいてください

(実行例)

New-ADServiceAccount AdfsGmsa DNSHostName xxxx.foobar.com ServicePrincipalNames http/xxxx.foobar.com

4. AD FSのセットアップ

AD FSのインストール

1. サーバーマネージャーを起動して[役割と機能の追加]をクリックし、[役割と機能の追加ウィザード]を起動します。[次へ]をクリックします。
2. [インストールの種類の選択]画面で「役割ベースまたは機能ベースのインストール」を選択し、[次へ]をクリックします。
3. [対象サーバーの選択]画面で「サーバープールからサーバー選択」を選択し、インストール先となるサーバーを選択します。[次へ]をクリックします。
4. [サーバーの役割選択]画面で、「Active Directory Federation Services」を選択し、[次へ]をクリックします。
5. [サーバーの機能]画面で何も選択せず、[次へ]をクリックします。
6. AD FSを利用する上での注意事項が表示されます。[次へ]をクリックします。
7. インストールオプションの確認が表示されます。確認後、問題がなければ[インストール]をクリックします。
8. AD FSのインストールが完了すると、「構成が必要です。(マシン名)でインストールが正常に完了しました」と表示されます。[閉じる]をクリックして[役割と機能の追加ウィザード]を閉じます。

AD FSの構成

1. サーバーマネージャーの上部フラッグに警告マークが表示されているので、クリックします。

2. 表示されたメニュー、展開後の構成から[このサーバーにフェデレーションサービスを構築します]をクリックし、Active Directoryフェデレーションサービス構成ウィザードを起動します。

3. 今回は新しいフェデレーションサーバーを作成のため、「フェデレーションサーバーファームに最初のフェデレーションサーバーを作成します。」を選択します。[次へ]をクリックします。

4. [Active Directory ドメインサービスへの接続]画面で、AD DSのドメイン管理者のアクセス許可をもっているアカウントを指定します。

5. [サービスのプロパティの指定]画面で以下を設定し、[次へ]をクリックします。

   設定	設定値
   SSL証明書	「4.2 SSL証明書の作成」で作成したSSL証明書
   フェデレーションサービス名	証明書の登録後に自動的に設定されます。
   フェデレーションサービスの表示名	任意の文字列。わかりやすい命名をお勧めします

6. [サービスアカウントの指定]画面で「既存のドメインユーザーアカウントまたはグループ管理されたサービスアカウントを使用してください」を選択し、「サービスアカウントの作成」で作成したgMSAを設定します。[次へ]をクリックします。

7. [構成データベースの指定]画面で、「Windows Internal Databaseを使用してサーバーにデータベースを作成します。」 を選択します。 [次へ] をクリックします。

8. [オプションの確認]画面で設定した内容の確認が表示されます。確認後、問題なければ[次へ]をクリックします。

9. [前提条件のチェック]画面では、警告が表示されますが、「すべての前提条件のチェックに合格しました。」というメッセージが表示されていれば問題ないため、 [構成] をクリックします。

10. [閉じる]をクリックしてAD FS構成ウィザードを閉じます。

(補足: ADFSの起動にはかなり時間がかかります (30分程度)。心配になりますが慌てず待ちましょう。)

ここまでの作業で、認証機構の振る舞いを持ったWebサーバーが立ち上がりました。
次のセクションでは実際にSAML認証を行うための具体的なSP/IdPに関連した設定を行います。

5. SAML連携のための設定

立ち上げたADFSをIdPとして、SPと連携するための設定を追加していきます。

証明書利用者の構成

1. [AD FSの管理] コンソールを開きます。
2. ナビゲーション ウィンドウで、[信頼関係] を展開、[証明書利用者信頼]フォルダをク リックし、右側のウィンドウで、[証明書利用者信頼の追加] をクリックします。これに より、AD FS 2.0 構成ウィザードが開きます。
3. 証明書利用者信頼の追加ウィザードの最初のページで、[開始] をクリックします。
4. 「証明書利用者についてのデータを手動で入力する」を選択し、[次へ]をクリックします。
5. [表示名の指定] ページで、[表示名]に名前を入力し、[メモ]にこの証明書利用者の説明を入力して、[次へ]をクリックします。
6. AD FS プロファイルを選択し、[次へ]をクリックします。
7. 証明書の構成 は暗号化証明書を使う場合は設定します。なければ何も入力せず次へ。
8. [URL の構成] ページで、SAML 2.0 WebSSO プロトコルのサポートを有効にする をチェックし、Service ProvidorのログインURLを入力してください。( https://xxxx.hoge.co.jp/login からログインが始まり、今回のADFSでログインを行なって、再度 https://xxxx.hoge.co.jp/ に戻ってくるという挙動の場合、 https://xxxx.hoge.co.jp/login をここに入力します)
9. [識別子の構成] ページで、この証明書利用者の識別子を 1 つ以上指定し、[追加] をクリックして一覧に追加したら、[次へ] をクリックします。 (例 urn:fuga:hogehoge:1234567 )
10. 「現時点ではこの証明書利用者信頼に多要素認証を構成しない」を選択し[次へ] をクリックします。
11. 「すべてのユーザーに対してこの証明書利用者へのアクセスを許可する」 を選択します。 [次へ] をクリックします。
12. [信頼の追加の準備完了] 画面で、[次へ] をクリックします。
13. [完了]画面で 「ウィザードの終了時にこの証明書利用者信頼の要求規則の編集ダイア ログを開く」にチェックを入れ、 [閉じる] をクリックします。要求規則の編集コンソー ルが表示されますので、次の手順「要求規則の構成」に進んでください。

要求規則の構成

1. [発行変換規則] タブで、[規則の追加] をクリックします。

2. [規則テンプレートの選択] 画面で、「LDAP 属性を要求として送信」を選択し、 [次へ] をクリックします。

3. [要求規則の構成] 画面で、 [要求規則名] フィールドに要求規則の名前を入力します。
   [属性ストア] ドロップダウン リストから、「Active Directory」 を選択します。
   [LDAP 属性の出力方向の要求の種類への関連付け] セクションの [LDAP属性] で「E-Mail-Addresses」 を選択し、[出力方向の要求の種類]には「Name ID」を設定します。

4. [完了]、[OK] の順にクリックします。

エンドポイントの作成

AD FSでのログイン結果をSPが受け取るためのエンドポイント(SAMLアサーションコンシューマー)を設定します。

1. [AD FSの管理] コンソールを開きます。

2. ナビゲーション ウィンドウで、[信頼関係] を展開、[証明書利用者信頼]フォルダをクリックし、「6.3 証明書利用者の構成」で作成した証明書利用者信頼の設定をダブルクリックします。

3. [エンドポイント]タブをクリックし、[SAMLの追加]をクリックします。

4. [エンドポイントの追加]で以下のように設定し、[OK]をクリックします。

   設定	設定値
   エンドポイントの種類	SAMLアサーションコンシューマー
   バインディング	POST
   信頼されたURL	SPのコールバックURL (ACS URLと言われるもの)

※ 作成後にプロパティを開き、エンドポイントタブに SPのログインURLと今回のコールバックURLの２つが設定されていればOKです。

(補足: ログアウトのエンドポイントを設定するかはサービスの利用の仕方によって異なるためここでは扱いません。基本的には設定しなくとも挙動に影響はないはずです。)

トークン証明書のエクスポート

1. [AD FSの管理] コンソールを開きます。
2. ナビゲーションウィンドウで[サービス] を展開し[証明書] フォルダをクリックします。
3. [トークン署名] のプライマリトークン証明書をクリックします。
4. 右側のウィンドウで[証明書の表示] をクリックし、証明書のプロパティを表示します。
5. [詳細] タブをクリックし、[ファイルにコピー] をクリックします。証明書のエクスポートウィザードが起動します。
6. [証明書のエクスポート ウィザードの開始] 画面で、[次へ] をクリックします。
7. [エクスポート ファイルの形式] 画面で、「DER encoded binary X.509(.CER)」を選択し、[次へ] をクリックします。
8. [エクスポートするファイル] 画面で、エクスポートするファイルの名前と場所を入力し、[次へ] をクリックします。
9. [証明書のエクスポート ウィザードの完了] 画面で、[完了] をクリックします。

重要
ここでの証明書が一般にSAMLのSPで使われる署名証明書と呼ばれるものになります。
SPにはこの証明書と、IdPでのログインURLとして https://{Route53で取得したドメイン}を共有し、設定するよう依頼してください。

6. SAML連携の動作確認

ユーザーを作成する

ログイン可能なユーザーを作成します。

1. [サーバーマネージャー] - [ツール] - [Active Directory ユーザーとコンピューター] を開きます。
2. 左ペインのツリーから [Users] を右クリックして、[新規作成] - [ユーザー] を選択します。
3. 新規登録したいユーザーの姓名やユーザーログオン名等を入力します。
4. ユーザーの初期パスワードを設定します。 ([次回ログオン時にパスワード変更が必要] は、外しておいた方が確認が容易です。)
5. ここで要注意なのですが、この時点ではログインのための情報しか設定されていないため、ADFSのログイン用の情報としてメールアドレスを設定していてもそれがSAMLのレスポンスとして返る設定になっていないため、追加で設定する必要があります。
6. 今作成したユーザーをダブルクリックしてプロパティを開きます。
7. 全般 タブの Eメール にSAMLResponseのアサーションに含めたいEmailアドレスを設定します。
8. OKで閉じます。

ログイン確認

ここまでの連携が全てうまくいっていると、

SPのログイン画面からログインを開始 → ADFSのログイン画面で、作成したユーザーでログイン → SPのログイン後画面に遷移

という挙動が実現できるようになっていると思います。

トラブルシュート

試験環境でSP, ADFS共に自分で立てた際には以上のフローで確認ができたのですが、本番環境でお客様との接続試験をした際には以下のような問題に対処しました。

• ADFS側の設定を行う際にSPで発行したメタデータで連携したところ、設定されていないURLがあった
  • (今回の手順では記載していますが、ログインURLとコールバックURLの両者を設定する必要があります)
• SAMLResponseへの署名の設定でメッセージとアサーションの両方に署名を入れるという設定をする必要があった
  • 詳しくはこちら
    • https://learn.microsoft.com/en-us/powershell/module/adfs/set-adfsrelyingpartytrust?view=windowsserver2019-ps#-samlresponsesignature

いずれも元々運用していたサーバーの固有の問題かもしれませんが、トラブルの際の参考になればと思います。

おわりに

今回も前回同様、「認証に関する情報はたくさんあるけど、なかなか自分に合うものがヒットしない」という課題感から、あまりテックブログらしからぬ内容ではありますが記事にしてみました。

おそらく今の時代にはADFSをわざわざ立ち上げてサービス開発していくようなことはなく、この記事が役に立つのは「既に長く運用されているADFSと連携することになり、どうしても事前に環境を作る必要がある」といったユースケースかなとは思います。私はまさにこの状況で、検証環境を作るのは大変だったけど実際やっておいてよかったなというのが本心です。
こういった機構を扱うこと自体の苦労を体感することでお客様の立場で考える一助になり、また事前に「こうすればできそう」を把握しておくことで上記のようなトラブル発生時にも原因の特定が容易に行えました（もしやっていなかったらお互いに原因追求し合う平行線のままだったかもしれません)。

そんなわけで、この記事もどなたかの困りを解決する力になればよいなと思っています。(もちろん、困らないで済めばそれが一番ではありますが。笑)

最後にいつものやつです。

グロービスではBE/FE問わず広く採用を行なっています。本記事で取り上げたような大きな企業との認証連携や、社会人教育というドメインを通じたエンドユーザーへの価値提供など、さまざまなissueと日々向き合っていますので、ご興味のある方はぜひ下記のリンクからお問い合わせください。https://recruiting-tech-globis.wraptas.site

カジュアルな面談も行なっていますのでぜひお気軽に！