2013年12月1日日曜日

2013年11月25日月曜日

PMシンポジウム2013 参戦レポート

Posted on 11/25/2013 by  with No comments
ブログに書くまでがイベントです（キリッ
というわけで、2013年11月21日～22日の PMシンポジウム2013 に参加してきたので、簡単に所感などをまとめることとする。
Posted in 

2013年11月8日金曜日

Windows のオブジェクトのアクセス権を操作するコマンド subinacl が便利だった

Posted on 11/08/2013 by  with No comments
Windows のファイル、レジストリ、SAMオブジェクト（ユーザー、グループ）等のアクセス権を操作する MS 製ツール "subinacl" が便利だったのでメモっておく。
当記事ではファイル/フォルダのアクセス権操作についてのみ言及する。

2013年11月1日金曜日

『ログオン後のNumLock状態はレジストリで制御できる』という大嘘

Posted on 11/01/2013 by  with No comments
当記事はWindows7を対象に書いているので、他のバージョンでは動作に差異があるかもしれません。あらかじめご了承ください。
「NumLock状態を制御したい」という要件
ITインフラの（というか社内OA構築系の）仕事をしていると、顧客から「端末のNumLockは全台一律(On|Off)にしてよ」という要件が出ることがたまにある。
で、その方法をググると、「レジストリの値を変更すれば良い」という情報が山ほど出てくる。ところが、得られる情報は半分は正しくて、半分は嘘である。

2013年10月28日月曜日

VDI環境でフォルダリダイレクトの中身がぶっ飛んだ話

Posted on 10/28/2013 by  with No comments
先日、客先のVDI環境で掲題の大障害を踏んだのでメモ。
客先本番環境でのみ発生し、切り分けのために構築した検証環境では再現していないため、詳しい発生条件が分かっていないが、二度と同じ障害を踏まないために記録として残しておくこととする。
まずは環境の説明
特定されなそうな範囲で書くと、本番環境は、下記の構成である。
・VMware Horizon View。
・自動デスクトッププール。
・ADはWindows Server 2008 R2。
　ユーザー認証用のドメインというかフォレスト（以下「フォレストA」）は元からあって、Viewのコンピュータアカウントを入れるために新規に別フォレスト（「以下フォレストB」）を構築。2つのフォレストで双方向信頼関係を結んでいる。
・移動ユーザープロファイル。
・デスクトップとドキュメントをファイルサーバにフォルダリダイレクト。

2013年7月27日土曜日

2013年7月18日木曜日

階層構造になっているセキュリティグループ内のユーザーを再帰的に検索するLDAPフィルタ

Posted on 7/18/2013 by  with No comments
"LDAP_MATCHING_RULE_IN_CHAIN"。非常に有益な機能だと思うが、日本語の情報がほとんど無かったので記事にしておく。
普通のLDAP検索フィルタは、ネストしたセキュリティグループに対応不可

Active Directory環境では、セキュリティグループのメンバーにセキュリティグループを入れるというネスト（入れ子）構造をよく使うと思う。セキュリティグループは会社組織と対応付けされることが多いので、例えば○○部のセキュリティグループの下に●●課のセキュリティグループと▲▲課のセキュリティグループを入れるといった具合だ。
ところが、このような構造において、「○○部に所属するユーザを全員取り出す」といったLDAP検索フィルタを書こうとすると難儀することになる。
Figure.1 ネストしたセキュリティグループ

上図のような構造で、GroupAに属するユーザーを取り出すLDAPフィルタを書く場合、単純に考えると
(&(objectClass=user)(memberOf=CN=GroupA,DC=example,DC=com))
と書けばよさそうだが、これではUser1しかヒットしない。memberOf句はグループのネストに対応していないので、指定したグループ(GroupA)の直下にいるメンバーしか見つけてくれないのだ。
AD独自の演算子で、ネストしたセキュリティグループを再帰的に検索
実はADのLDAPには、この問題を解決してくれる独自の演算子が用意されている。
Search Filter Syntax (Windows)
に紹介されている"LDAP_MATCHING_RULE_IN_CHAIN"がそれだ。
具体的には下記のように記述すればよい。
(&(objectClass=user)(memberOf:1.2.840.113556.1.4.1941:=CN=GroupA,DC=example,DC=com))
このフィルタなら、GroupAの下にあるGroupBのメンバーも再帰的に検索してくれるので、User1、User2の両方がヒットする。  "1.2.840.113556.1.4.1941"がLDAP_MATCHING_RULE_IN_CHAINのOIDなのだそうな。
手っ取り早く試すなら、ldifdeコマンドで
ldifde -f export.ldf -r "(&(objectClass=user)(memberOf:1.2.840.113556.1.4.1941:=CN=GroupA,DC=example,DC=com))"
とか書いてみるとよい。
登録: 投稿 (Atom)