[Active Directory] Active Directoryドメイン名のベストプラクティス

ちょっと調べる必要があったので、Webで調べた結果と自分の経験を踏まえて表にまとめてみました。ユーザビリティについてはNetBIOS名やUPNの設定次第でユーザーになじみ易い形にできるので、サブドメイン名を使用するのが一番のように思えます。

What's in an Active Directory DNS Name?
Active Directory .local domain design and Office 365.
DNS 名前空間の計画

<Active Directoryドメイン名の比較表>

前提：パブリックなDNSドメイン名がexample.comの場合		パブリックな ドメイン名と 同じドメイン名	サブドメイン名 （MS推奨）	パブリックな 別TLDの ドメイン名	プライベートなTLDの ドメイン名
具体的なADドメイン名		example.com	corp.example.com	example.net	example.local
ユーザ ビリティ	ユーザーにとって覚えやすくなじみ易いドメイン名か →○：YES、×：NO	○	×	×	×
管理性	インターネット用と社内用とでDNSを分け、相互に転送や委任を設定して管理負荷を軽減できるか →○：YES、×：NO	×	○	○	○
名前空間 衝突の 潜在的 リスク	他社と名前空間が重複し、M&A等でADの連携/統合が必要になった場合に障害となる可能性はないか →○：ほぼなし、×：あり	○	○	○/×	×
ドメイン名 確認が できない ことによるリスク	証明書発行等ドメイン名確認が必要な申請が却下されるリスクはないか →○：ほぼなし、×：あり	○	○	○/×	×
備考				○/×の箇所は、ドメイン名を所有していれば○、所有していなければ×

[Active Directory] オブジェクトに対する権限を特定のセキュリティグループに付与するには

Active DirectoryではOUを分割して、そのOUの管理をセキュリティグループに委任するのが一般的です。これに対し、あるOU直下にフラットに格納されているオブジェクトに対して、サブOUに分割することなく、特定のセキュリティグループに権限を付与できないかを調べました。

結果、Windows Server 2008以降で追加されたOWNER RIGHTSというセキュリティプリンシパルで実現できそうなことがわかりました。

AD DS: Owner Rights

やり方は下記の通りです。私の場合、あるセキュリティグループのメンバーに、一部ユーザーアカウントのパスワードリセット権限を付与することが上手くいきました。

1. 権限を付与したいセキュリティグループを、オブジェクトのOwnerとして指定
2. オブジェクトまたは格納先OUのセキュリティ設定で、OWNER RIGHTSを追加し、付与したい権限を指定

OUに権限を委任する場合と異なり、誰が権限を持っているか分かりづらくなるのが欠点ですが、上手く使えばOUの階層を浅く保ちつつ権限を分割することができそうです。

[Office 365] ドメイン名に企業の商標等が含まれていると、StartSSLの無償証明書発行が却下されます

先日の記事で紹介したStartSSLに無償の証明書の発行を申請したところ、却下されてしまいました。却下の理由は下記の通りで、ドメイン名に「office365」が含まれていたことが原因です。ドメイン名は商標等を含まないものにしておいた方が無難ですね。

simply high profile brands and names should be generally avoided, but are not possible in the Class 1 (free) level at all. We can not issue the requested certificate containing office365 (a brand name of Microsoft).

[Office 365] AD FS用証明書を無償or安価で使用する

Office 365のAD FS（Proxy）では、インターネットから利用する場合や、社内からでもOWA以外でExchange Onlineを利用する場合には、Microsoft Federation Gateway（MFG）が信頼しているルートCAが発行した証明書が必要となります。証明書が必要な理由については、下記リンク先が参考になります。

AD FS Proxyの役割 « 日々徒然 

AD FS（AD FS Proxy）で利用するSSL証明書 « 日々徒然

その証明書ですが、無償のものでは以下が使えるようです。StartComの方はMFGが信頼しているCA一覧には載っていないのですが、海外の記事で使えたという報告を見つけました。（2012/7/1追記）FreeSSLも一覧にはありませんが、私個人の検証環境で使えることを確認しました。

Comodo（90日間）

StartCom（1年間）

FreeSSL（30日間）

一方、無償のものはどうしても有効期限があるので、期限がなくできるだけ安価なものを探したところ、Comodo Positive SSLにたどり着きました。Namecheap.comで9ドル/1年で購入可能な上、MFGが信頼しているCA一覧に載っているため、安心して使えそうです。購入の流れは下記リンク先が参考になります。

720円で SSL を導入する方法 | TipsZone

私は当面無償のもので評価しつつ、有効期限が切れたら有償のものにトライしてみたいと思います。

[Windows 8 CP] ワイヤレスネットワークのプロファイルを編集するには

遅まきながら、Windows 8 Consumer Preview版をPCに入れてみました。自宅の無線LANに繋ごうとプロファイルを作成したのですが接続に失敗し、プロファイルを編集しようとしても、編集画面にたどり着けない事態に遭遇。
色々調べたところ、最終的にはTechNet Forumの投稿を参考にして解決することができました。「ファイル名を指定して実行」から以下のコマンドを実行してオープンした画面から、ワイヤレスネットワークのプロファイルを編集することができます。

explorer.exe shell:::{1fa9085f-25a2-489b-85d4-86326eedcd87}

[Windows 8 CP] リモートサーバー管理ツール（タイトルのみ）

Download: RSAT for Windows 8 - Microsoft Download Center - Download Details

[Lync] ADでアカウントが無効化されてもLyncクライアントを使用できてしまうケースについて

海外のブログで興味深い記事を見つけたので紹介します。内容は、ADでアカウントを無効化してもLyncクライアントが使用できてしまう仕様の解説と、その対応方法です。

Disabling a User in AD Does Not Disable the User In Lync

記事の要約は以下の通りです。

• Lync ServerがLyncクライアントを認証する方法には、以下の3つがある。
• Kerberos
• NTLM
• クライアント証明書


• クライアント証明書は、KerberosやNTLMで認証が成功すると生成されて（有効期間：180日）サーバー側DBとクライアント側証明書ストアに格納され、以降の認証の高速化や可用性向上に寄与する。


• ADでアカウントを無効化した場合、KerberosとNTLMによる認証はできなくなるが、クライアント証明書は無効化されない。従って、ADでアカウントが無効化されたユーザーであっても、クライアント証明書を使った認証によってLyncクライアントでサインインし、他のユーザーとコミュニケーションすることができてしまう。


• これを防止するには、ADでアカウントを無効化するだけでなく、Lync Serverでも「Disable-CsUser」コマンドレットを実行し、クライアント証明書の失効とユーザーの無効化を行う必要がある。

なお、元の記事のコメントには、無効化には「Set-CsUser -Enabled $false」の方が属性が削除されず適しているのではないか、というコメントがあります。ただ、以前記事にした通り、「Set-CsUser -Enabled $false」はクライアント証明書を失効させませんので、元の記事にある通り「Disable-CsUser」を実行する必要があります。