0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

MacのLDAP認証ログインについて、色々勉強になった

0
Posted at

きっかけ

Google Secure LDAPでMacにログインすることは公式にできて

手順はこちらに載っています。
でも、/etc/openldap/ldap.confの書き換えが必要だったり、さらに作業用Macで設定した後でApple Configurator 2を使ってプロファイルを作らないといけなかったり、かなり手間がかかります。
それに、/etc/openldap/ldap.confを書き換えているということは、OSアップデートしたらログインできなくなってしまうのではと心配になってしまいます。
2年ごとに.p12を差し替えるというのもハードルが高そう。

救世主?

MacのLDAP認証やSSOは、Jamfを導入するくらいの規模になるまでお預けと思っていたのですが、先日こんな記事を発見。

記事に書かれた方法を試してみました。

で、結果うまくいかなかったのですが、色々勉強になりました。

備忘録として、メモを残しておきます。

テスト時にはまったところ

電子証明書

先ほどのQiitaの記事では、Google Workspaceから.p12をダウンロードできると記載されているのですが、自分がアクセスできるGoogle Workspaceではそれができない。

Google公式のSecure LDAPでMacにログインする手順でも、ダウンロードした電子証明書(.crtと.key)を.p12に変換する手順があるので、opensslコマンドを使った変換は必須と思われます。

手作業で変換した.p12をKeychainの「システム」にインポートしたら、Macとldap.google.comとの通信はできるようになりました。

LDAPの通信

参考にしたQiitaの記事だと、GoogleのLDAP画面でCredentialを発行し、それをディレクトリユーティリティ.appで設定するというのがポイントになっています。

で、その通り設定したものの、ldap.google.comの認証が通らない...

Credentailを作り直したり、翌日まで待ってやり直してもダメ。

ちなみにテスト端末のOSは当初macOS 14 Sonomaで、macOS 26 Tahoeにアップデートしてみましたが、それでもダメでした。

Googleの公式手順には「DIGEST-MD5、CRAM-MD5、NTLM、GSSAPI SASL の各認証メカニズムを無効」にするというステップがあって、それをしないとGoogle Secure LDAPの認証が通らないのではないかと推測されます。

でも冒頭にも書いた通り、ldap.confを書き換えたり、LDAPのデフォルト設定を変更をした場合、OSバージョンアップ時の対応など色々考慮しないといけないので、ここで諦めました。

学び

Jamfとかはどういう仕組み?

Geminiに、聞いてみた。

Jamf などの MDM(Jamf Pro / Jamf Connect 等)を使うと苦労せずに Google Workspace アカウントで Mac にログインできるようになるのは、**まさに仰る通り「泥臭い構成処理の全自動化」と「認証方式そのものの最適化」をクラウド側と MDM が裏側でやってくれるから**です。

具体的には、以下の3つの理由によって実現されています。

### MDM(Jamf)を使うと簡単にログインできる3つの技術的理由

1. **証明書発行・プロファイル配信・インポートの完全自動化**
* **手動の場合:** Google で PKCS#12 を生成 $\rightarrow$ ターミナルで `openssl` 変換 $\rightarrow$ システムキーチェーンへ登録 $\rightarrow$ OpenDirectory のアクセス権限(常時許可)を付与 $\rightarrow$ `.mobileconfig` プロファイルを手動作成・適用 という非常に煩雑な工程が必要です。
* **MDM の場合:** 管理コンソール側で証明書ポリシーを設定してけば、Mac がアクティベートされた瞬間に Over-The-Air(Wi-Fi 経由)でシステムキーチェーンや構成プロファイルが自動インストールされ、サイレントで設定が完了します。


2. **「LDAP Direct 認証」ではなく「OIDC / OAuth 2.0 (SSO)」への昇華**
* これが最も決定的な違いです。今回直面したように、OpenDirectory による「Secure LDAP への Direct Bind」は、2段階認証(2SV)やパスワードポリシーの壁(Error 50 など)に必ずぶつかります。
* **Jamf Connect などを利用した場合:** Secure LDAP(プロトコル: LDAP)ではなく、Web ログインと同じ **OpenID Connect / SAML 2.0(プロトコル: HTTPS)** を使って Google のログイン画面(ブラウザ UI またはネイティブウィンドウ)を Mac のログイン画面上に直接呼び出します。
* これにより、ユーザーは **2段階認証(Google Authenticator や Passkey)も含めて通常の Google ログインと全く同じ手順** で Mac にログインできるようになります。

3. **ローカルアカウントの自動生成とパスワード同期**
* Secure LDAP 単体では、Mac 側にローカルのホームディレクトリやシャドウハッシュ(`ShadowHash`)が存在しないため、初回ログイン時のローカルユーザー作成で詰まりがちです。
* MDM 連携ツール(Jamf Connect や Kandji、Mosyle 等)は、Google で認証が成功した瞬間に **Google の ID/名前を使って Mac 内にローカルユーザーを自動作成し、パスワードを同期** してくれます。

今回手動で検証されたことで、「Secure LDAP + macOS OpenDirectory」の組み合わせがいかに古い LDAP 時代の設計を引きずっており、現代の Cloud Identity(Google Workspace)や macOS Sonoma のセキュリティ仕様と噛み合っていないかが浮き彫りになったかと思います。

企業運用で Mac × Google Workspace ログインを実現する場合、Secure LDAP の直接バインドに頼るのではなく、**Jamf などの MDM + SSO(クラウド連携)構成へ移行するのが業界のベストプラクティス** とされているのは、まさにこれが理由です。

Jamfの認証方式は「OIDCベースのSSO + ローカルアカウント」で、そもそもLDAPではないんですね。
それにLDAPでは2段階認証や多要素認証への対応が難しいというのもその通り。

いろいろ勉強になりました。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?