ブログに書くまでがイベントです（キリッ
というわけで、2013年11月21日～22日の PMシンポジウム2013 に参加してきたので、簡単に所感などをまとめることとする。
というわけで、2013年11月21日～22日の PMシンポジウム2013 に参加してきたので、簡単に所感などをまとめることとする。
2013年11月25日月曜日
2013年11月8日金曜日
Windows のオブジェクトのアクセス権を操作するコマンド subinacl が便利だった
Windows のファイル、レジストリ、SAMオブジェクト（ユーザー、グループ）等のアクセス権を操作する MS 製ツール "subinacl" が便利だったのでメモっておく。
当記事ではファイル/フォルダのアクセス権操作についてのみ言及する。
当記事ではファイル/フォルダのアクセス権操作についてのみ言及する。
2013年11月1日金曜日
『ログオン後のNumLock状態はレジストリで制御できる』という大嘘
当記事はWindows7を対象に書いているので、他のバージョンでは動作に差異があるかもしれません。あらかじめご了承ください。
で、その方法をググると、「レジストリの値を変更すれば良い」という情報が山ほど出てくる。ところが、得られる情報は半分は正しくて、半分は嘘である。
「NumLock状態を制御したい」という要件
ITインフラの（というか社内OA構築系の）仕事をしていると、顧客から「端末のNumLockは全台一律(On|Off)にしてよ」という要件が出ることがたまにある。で、その方法をググると、「レジストリの値を変更すれば良い」という情報が山ほど出てくる。ところが、得られる情報は半分は正しくて、半分は嘘である。
2013年10月28日月曜日
VDI環境でフォルダリダイレクトの中身がぶっ飛んだ話
先日、客先のVDI環境で掲題の大障害を踏んだのでメモ。
客先本番環境でのみ発生し、切り分けのために構築した検証環境では再現していないため、詳しい発生条件が分かっていないが、二度と同じ障害を踏まないために記録として残しておくこととする。
・VMware Horizon View。
・自動デスクトッププール。
・ADはWindows Server 2008 R2。
ユーザー認証用のドメインというかフォレスト（以下「フォレストA」）は元からあって、Viewのコンピュータアカウントを入れるために新規に別フォレスト（「以下フォレストB」）を構築。2つのフォレストで双方向信頼関係を結んでいる。
・移動ユーザープロファイル。
・デスクトップとドキュメントをファイルサーバにフォルダリダイレクト。
客先本番環境でのみ発生し、切り分けのために構築した検証環境では再現していないため、詳しい発生条件が分かっていないが、二度と同じ障害を踏まないために記録として残しておくこととする。
まずは環境の説明
特定されなそうな範囲で書くと、本番環境は、下記の構成である。・VMware Horizon View。
・自動デスクトッププール。
・ADはWindows Server 2008 R2。
ユーザー認証用のドメインというかフォレスト（以下「フォレストA」）は元からあって、Viewのコンピュータアカウントを入れるために新規に別フォレスト（「以下フォレストB」）を構築。2つのフォレストで双方向信頼関係を結んでいる。
・移動ユーザープロファイル。
・デスクトップとドキュメントをファイルサーバにフォルダリダイレクト。
2013年7月27日土曜日
イメージファイト2周目備忘録
イメージファイトリハビリ中につき、自分用メモ。
2013年7月18日木曜日
階層構造になっているセキュリティグループ内のユーザーを再帰的に検索するLDAPフィルタ
"LDAP_MATCHING_RULE_IN_CHAIN"。非常に有益な機能だと思うが、日本語の情報がほとんど無かったので記事にしておく。
Active Directory環境では、セキュリティグループのメンバーにセキュリティグループを入れるというネスト（入れ子）構造をよく使うと思う。セキュリティグループは会社組織と対応付けされることが多いので、例えば○○部のセキュリティグループの下に●●課のセキュリティグループと▲▲課のセキュリティグループを入れるといった具合だ。
ところが、このような構造において、「○○部に所属するユーザを全員取り出す」といったLDAP検索フィルタを書こうとすると難儀することになる。
上図のような構造で、GroupAに属するユーザーを取り出すLDAPフィルタを書く場合、単純に考えると
Search Filter Syntax (Windows)
に紹介されている"LDAP_MATCHING_RULE_IN_CHAIN"がそれだ。
具体的には下記のように記述すればよい。
手っ取り早く試すなら、ldifdeコマンドで
普通の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))"とか書いてみるとよい。
2013年6月27日木曜日
自己学習による元手ゼロのPDU申請（Cat C: Self-Directed Learning）
PMPホルダーにとってPDU稼ぎは頭痛の種であるが、この度、セミナー等を受講しなくても無料でPDUを取得できる"Cat C: Self-Directed Learning"の申請にチャレンジし、無事受理されたので、3年後の自分のためにもメモを残しておく。
※PMIのサイトは頻繁に仕様変更をするので、近い将来、当記事とは申請方法が変わっているかもしれない。これは2013年6月末時点での手順であることをお断りしておく。
※PMI Code of Ethicsには「PMIのサイトのスクリーンショットを他所で使ってはならない」とは書いてないっぽいので当記事は問題ないと思っておりますが、もし何らかの規約に抵触しているようであれば、ご指摘いただけると幸甚です。
※PMIのサイトは頻繁に仕様変更をするので、近い将来、当記事とは申請方法が変わっているかもしれない。これは2013年6月末時点での手順であることをお断りしておく。
※PMI Code of Ethicsには「PMIのサイトのスクリーンショットを他所で使ってはならない」とは書いてないっぽいので当記事は問題ないと思っておりますが、もし何らかの規約に抵触しているようであれば、ご指摘いただけると幸甚です。
登録:
投稿 (Atom)
