Windows Server 8 Developer Preview (DP) はサーバー OS なので、Active Directory (AD) 環境を構築することができます。
以前の OS と比較して、AD の構築方法が変わっていますので現状のバージョンで AD の構築方法をまとめてみたいと思います。
SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿
Windows Server 8 Developer Preview (DP) はサーバー OS なので、Active Directory (AD) 環境を構築することができます。
以前の OS と比較して、AD の構築方法が変わっていますので現状のバージョンで AD の構築方法をまとめてみたいと思います。
Windows Server 2008 R2 の AD DS では標準で [ldp.exe] を使用することが可能です。
# 2008 も標準だと思います。2003 はサポートツールをインストールすると使用できます。
今回の投稿ではこのツールを使って、グループが所属しているグループを取得してみたいと思います。
AD に参加できない時に見ておいたほうがよさそうなログについてメモを。
今回は
AD DS : Windows Server 2008 R2 SP1
メンバー : Windows Server 2008 R2 SP1
で、検証をしています。
運用で表 LAN (サービス用) / 裏 LAN (バックアップ / 運用監視用) を作る時があるかと思いますがドメインコントローラー (DC) で NIC を 2 枚差していた時の小ネタについてまとめてみたいと思います。
Windows Server 2008 R2 と Windows NT 4.0 のドメインで信頼関係を結ぼうとした際にすこしコツがありますのでまとめてみたいと思います。
ドメイン環境の Windows にはログオンキャッシュがあり、設定に関してはグループポリシーで設定することが可能になっています。
デフォルトの状態では、[ローカル セキュリティ ポリシー] で 10 ログオン分保存されるようになっています。
このログオンキャッシュがどこに保存されているんだろうと思って少し調べてみました。
ログオンキャッシュですが、[LSA : ローカル セキュリティ 機関] に保存されているようです。
Windows のレジストリの、[HKLMSECURITY] ですが、デフォルトの状態では Administrators グループのユーザーでもレジストリを展開できないようになっています。
これは、[SECURITY] のキーのアクセス許可で [Administrators グループ] には読み取りの権限がついていないため、このような表示となっています。
# デフォルトでは、SYSTEM にフルコントロール、Administrators グループは特殊なアクセス許可となっています。
[読み取り] または、[フル コントロール] のアクセス許可を明示的に設定することで、レジストリにアクセスすることが可能です。
# 試すときは自己責任でお願いいたします。
SECURITY キーが展開になると、[Cache] というキーが確認できます。
上の画像では、[NL$3] に値が設定されていることが確認できます。
# ちょっと強引に値を消したりした環境なので、[NL$1] から始まって居ません…。
ネットワークに接続されていない状態ですが、ログオンキャッシュを使ってログオンが可能な状態となっています。
こちらのブログで書かれている、[whoami /fqdn] でログオンキャッシュが使われているかを確認してみます。
# いつも参考にさせていただいている、Always on the clock というブログになります。
参考)
キャッシュされたログオン
ネットワークに接続していないため、ログオンキャッシュが使われエラーとなっていることが確認できます。
このことから現在は、ログオン情報がキャッシュとして残っていることが確認できました。
それでは、先ほどの [NL$3] の情報を [0 でクリア] してみたいと思います。
# 初期の状態と合わせ、一度内容を消して [00A7] まで 0 クリアしています。
ログオンすることができなくなっていることが確認できます。
ログオンキャッシュについては [HKLMSECURITYCache] に保存されているみたいですね。
ちょっと気になったので簡単ではありますが調べてみました。
# 通常、手動でアクセスする必要のない [SECURITY] キーにアクセスをしていますので本内容を自分でも試してみようと思われた方は自己責任でお願いいたします。
今回も軽めの投稿を。
Active Directory でユーザーを作成する場合、GUI から登録することが多いかと思います。
# 人数が多い会社さんですと ID 管理システムやバッチで登録することもあるかと思いますが。
[Active Directory ユーザーとコンピューター] で同一 OU 内に同姓同名のユーザーを登録しようとした場合、注意が必要となります。
?
このようなユーザーが [TEST2] という OUに登録されています。
同じ [TEST2] という OU に [TEST00002] というログオン名で同姓同名のユーザーを作成してみます。
同姓同名のユーザーを同一 OU 内に作成しようとすると以下のエラーとなります。
ユーザーを作成する際、入力した内容が以下のように属性に設定されます。
入力内容 | 属性 | 設定値 |
姓 | sn | 山田 |
名 | givenName | 一郎 |
イニシャル | initials | 今回はブランク |
フル ネーム # デフォルトは [姓 名] |
cn displayName name distinguishedName?? (*) |
山田 一郎 山田 一郎 山田 一郎 CN=山田 一郎,OU=TEST2,DC=2008-domain,DC=local |
ユーザーログオン名 | userPrincipalName?? (*) | TEST00001@2008-domain.local |
ユーザー ログオン名 (Windows 2000 より前) | sAMAccountName??? (*) | TEST00001 |
[userPrincipalName] と [sAMAccountName] は重複できないですが、その他に、[distinguishedName] も重複することができません。
# (*) がついている項目が重複できません。
同一 OU 内に同一の [フル ネーム] のユーザーを作成しようとするると、[distinguishedName] が重複してしまいエラーとなります。
結論から最初に書いてしまいますと [同一のフル ネームのユーザーは登録できませんが、表示名が同一のユーザー] は登録することができます。
同姓同名の表示名のユーザーを同一の OU 内に登録する場合は、一度 [フル ネームを別の名前] に設定します。
対象のユーザーを右クリックして、[名前の変更] をクリックします。
一文字でも文字を修正すると以下のダイアログボックスが表示されます。
名前の変更で変更した内容は [フル ネーム] に反映されます。
フル ネームを変更して [OK] をクリックするとこのようなエラーが。
名前の変更で入力できる項目は以下のように属性に反映されます。
入力内容 | 属性 | 設定値 |
フル ネーム | cn name distinguishedName?? (*) |
山田 一郎 山田 一郎 CN=山田 一郎,OU=TEST2,DC=2008-domain,DC=local |
姓 | sn | 山田 |
名 | givenName | 一郎 |
表示名 | displayName | 山田 一郎_2 |
ユーザーログオン名 | userPrincipalName?? (*) | TEST00002@2008-domain.local |
ユーザー ログオン名 (Windows 2000 より前) | sAMAccountName??? (*) | TEST00002 |
名前の変更で変更ができるフル ネームは [distinguishedName] に設定されますので、重複してしまってエラーとなります。
名前の変更から表示名を変更することはできますので、このような変更であれば設定可能です。
GUI から作成した場合、フル ネームがデフォルトで [姓 + 名]? が設定されるのでそのまま作成してしまうケースが
あるかもしれませんが、OU 内に同姓同名のユーザーが作られる可能性がある場合は、作成の段階でフルネームを一意に
設定するようにしておいた方が良いかと思います。
# 同姓同名の社員が同じ部署に配属されないように人事的な考慮はされると思いますので、拠点や部門で OU を分けている場合
? それほど発生しないとは思いますが。
今回だとこのような形式でしょうか。
# ユーザー作成時にフルネームを [TEST00002] に設定して、名前の変更で表示名を変更しています。?
上記のような設定でユーザー情報を設定しているとこのような形でユーザーを登録することが可能です。
OU が異なれば同一のフルネームのユーザーを登録することが可能です。
[cn] [name] は他の OU のユーザーと同一ですが、OU が異なっているため、[distinguishedName] が変わりますので。
# ログオン名は一意にならないと駄目ですが。?
項目 | TEST00001 | TEST00002 | TEST00003 |
cn | TEST00001 | TEST00002 | TEST00001 |
name | TEST00001 | TEST00002 | TEST00001 |
distinguishedName?? | CN=TEST00001, OU=TEST2, DC=2008-domain, DC=local |
CN=TEST00002, OU=TEST2, DC=2008-domain, DC=local |
CN=TEST00001, OU=TEST3, DC=2008-domain, DC=local |
sn | 山田 | 山田 | 山田 |
givenName | 一郎 | 一郎 | 一郎 |
displayName | 山田 一郎 | 山田 一郎 | 山田 一郎 |
userPrincipalName | TEST00001@2008-domain.local | TEST00002@2008-domain.local | TEST00003@2008-domain.local |
sAMAccountName | TEST00001 | TEST00002 | TEST00003 |
?
専任の管理者がいない会社さんだと初期の Users の下にユーザーを作っていってしまうことがあるかと思いますので、
その時には注意が必要そうですね。
Office 2010 の管理用テンプレートについて少しまとめてみたいと思います。
Office 2010 管理用テンプレートですが Microsoft の日本語サイトからは以下のものがダウンロードできます。
Office 2010 (ベータ リリース) 管理用テンプレート ファイル (ADM、ADMX、または ADML) および Office カスタマイズ ツール
現時点では、日本語サイトからはベータ用のものしかダウンロードができないようです。
RTM 用に関しては英語サイトからダウンロードすることが可能です。
Office 2010 Administrative Template files (ADM, ADMX/ADML) and Office Customization Tool
言語は英語となっているのですが、これには日本語版の管理用テンプレートも含まれています。
32bit 用と、64bit 用の 2 種類がダウンロードできるのですが、これは、管理用テンプレートではなく Office カスタマイズツール (OCT) のビットになるようですね。
管理用テンプレートの適用方法に関しては以下の技術情報に記載されています。
Office 2010 でグループ ポリシーを使用して設定を適用する
ダウンロードしたファイルを展開すると以下のようなディレクトリ構成になっています。
私の検証環境は Windows Server 2008 R2 の AD DS を使っているので [ADMX] ディレクトリのファイルを使用します。
# Admin は Office カスタマイズ ツールになります。
一台構成の AD DS なので特にセントラル ストアに格納しなくても問題はないのですが、[ADMX] フォルダ直下の [.admx] と言語のディレクトリを
[%systemroot%SYSVOLdomainPoliciesPolicyDefinitions] に保存します。
# セントラルストアを使わない場合は、[%systemroot%PolicyDefinitions] にファイルを保存します。
これで、管理用テンプレートが利用可能になります。
[グループ ポリシーの管理] からグループポリシーを編集すると、[管理用テンプレート] に Office 2010 用のポリシーが表示されます。
# セントラル ストアに保存した場合、ローカルセキュリティポリシーの管理用テンプレートに Office 2010 用のポリシーは表示されません。
[%systemroot%PolicyDefinitions] に保存した場合はローカルセキュリティポリシーにも表示されます。
英語サイトからダウンロードするところで少しハマるかもしれませんので、メモとして残しておきたいと思います。
先ほどの環境で一度 AD RMS をアンインストールしてインストールしたところ以下のエラーが。
AD RMS の管理コンソールで接続を使用してもエラーになってしまいます。
きちんとインストールができていないようですね…。
?
■SCP のコンテナの削除
SCP 関係でインストールが失敗しているようなので、ADSI エディターを使って AD RMS の SCP を削除して
再度インストールしてみます。
SCP を削除後にインストールしてみたところ正常にインストールが完了しました。?
■ SCP の登録
AD RMS の管理コンソールを開いて設定を確認してみると SCP が登録されていないみたいですね。
[SCP を変更する] を有効にして SCP を登録してみます。
?
■SCP のコンテナの作成
この現象ですが SCP 用のコンテナが登録されていないので発生しているみたいですね。
ADSI エディターを開いて SCP 用のコンテナを作成します。
[CN=RightsManagementServices] を右クリックして、[新規作成] → [オブジェクト] をクリックします。
オブジェクトの種類に [serviceConnectionPoint] がありますので、これを選択して、
?
SCP のコンテナを再作成した後に SCP の変更をすると正常に登録がされます。
?
私が使っている環境は、手動で SCP を書き換えたりしていたので、必ず発生する現象とは思えませんがメモとして。
そもそもの始まりは AD RMS をインストールするときに内部アドレスの設定を FQDN ではなく
コンピューター名で設定してしまったことから…。
AD RMS で使用する証明書は FQDN で設定していました。
そのため、IRM で文章を保護しようとするとこのようなセキュリティ警告が表示されてしまいます。
# HTTPS 通信時に AD RMS で設定している内部アドレスはコンピュータ名で、証明書は FQDN のため。?
[はい] を選択すれば開けるのですがちょっと面倒ですよね。
この状態で AD RMS の管理コンソールを開くと、こちらも証明書の警告が表示されます。?
AD RMS の管理コンソールをに関しては管理コンソールからスナップインを一度削除して、
[クラスターの追加] でリモートコンピューターとして FQDN でスナップインを追加すれば回避できます。
?
■SCP の設定
クライアントの接続時の接続先は上記のスナップインとはまた別で、AD RMS の [Service Control Point] (SCP) で
設定されている値が使用されます。
インストール時に、[構成した後で、このアドレスまたはポート番号を変更することができません。]と表示されているように
AD RMS の管理コンソールを開いても、この SCP のアドレスは変更ができないようになっています。
この接続の時に使用されているのが SCP のアドレスになるのですが、グレーアウトしています。
SCP のアドレス自体は、[クラスターの URL] の [証明] がベースになっているのですがこちらも同様にグレーアウトしています。
SCP は AD の構成パーティションに設定されていますので、ADSI エディタで直接変更してしまえば、値を修正することはできたりします。
# 構成パーティションの変更ですので [Enterprise Admins] の権限が必要となります。
構成パーティションの [CN=SCP,CN=RightsManagementServices,CN=Services] のプロパティを開くと設定を確認できます。
[serviceBindingInformation] の属性が SCP の URL となっています。
こ値を FQDN に設定することでクライアントのセキュリティ警告は一応回避することができます。
インストール時にアドレスを変更することはできませんと表示されているので、一度役割を削除して
再度追加したほうが良いとは思いますが。
?
■SQL Server に格納されている情報
URL としては、ライセンスの URL もありますがこちらに関しては SQL Server のデータベースに格納されています。
[DRMS_Config_<サーバー名>_443] というデータベースの [dbo].[DRMS_ClusterPolicies] テーブルを SELECT すると
情報を確認することが可能です。
実際に SELECT して確認してみると、[LicensingClusterUrl] に値が設定されているのが確認できますね。?
?
AD RMS をインストールしていてちょっと調べてみたことをまとめてみました。