基盤系インフラSE 4年目 技術備忘録 派遣社員(特定派遣)

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
  1. --/--/--(--) --:--:--|
  2. スポンサー広告|
  3. トラックバック(-)|
  4. コメント(-)

サービスアカウント

就業先でサービスアカウントのパスワード変更で手こずっている。(他人事)
Active Directory でサービスアカウントのパスワードを変更後、
関連するクライアント鯖に入っていちいちパス変をしなければならない。


これが、WinSV2012からは、gMSAが実装されて一括変更できるっぽいが、
2008R2は、MSAしかないようだ。2012でもSQL Serverは個別にやらないといけないっぽい?

2008R2
Can be used on multiple computers in the a domain? → NO

http://social.technet.microsoft.com/wiki/contents/articles/391.managed-service-accounts-msas-versus-virtual-accounts-in-windows-server-2008-r2.aspx

1コンピュータで1サービスアカウントというクソ仕様で御座いました、本当に使えねえ


Windows Server 2008 R2の新機能として、「管理されたサービス アカウント」と「仮想アカウント」の 2 種類の新しいサービス アカウントを使用できるようになりました。

管理されたサービス アカウント

ここでのポイントは3の自分で作成するサービスアカウントのことを指しています

例えば今までは、ドメインアカウント(もしくはローカルアカウント)を使用してサービスアカウントにしますが、ユーザー権限の割り当てを使用して最低限のセキュリティ設定を行う必要がありました。更に、パスワードの問題がありました。それはサービスアカウントのパスワード変更には多大な労力が発生していたことです。仮にサービスアカウントのパスワードを変更しようと思うと、ADのユーザー設定からパスワードを変更し、サービスの画面からサービスアカウントのパスワードを変更する必要がありました。そのようなことがあるので、多くの場合は無期限パスワードにしていた経緯があります。しかし、これはセキュリティの面から考えると脅威として認識しておく必要がありました。

今回の新機能である、「管理されたサービス アカウント」を使用すると、パスワードは定期的に自動変更されます。このメリットとして、ADのユーザーアカウントとサービスのパスワードの変更が自動的に反映されることになります。さらに対話的なWindows ログオンに使用することができないので、セキュリティ的にも強固になります。

作成方法

ADユーザーとコンピューターを使用して作成することはできません。このアカウントはPowerShellを使用する必要があります。

具体的なコマンドとしては

New-ADServiceAccount <アカウント名>

プロパティを見るには

Get-ADServiceAccount <アカウント名>

オブジェクトはADユーザーとコンピューターのManaged Service Accountコンテナに存在します。

このアカウントをドメインメンバーで使用するためには

Install-ADServiceAccount –Identity ‘<アカウント名>’

を使用してインストールする必要があります。そして、通常のユーザーオブジェクトと同様に設定することができます。その際のパスワードはNull(空欄)にする。

仮想アカウント

参考URLを読むと次のように記載がありました。

以下抜粋

仮想アカウントを使用すると、パスワード管理を行わなくても済み、ドメイン環境内のコンピューターのアカウントの資格情報を使用してサービスがネットワークにアクセスできるようになるため、サービス管理が簡単になります。

ここまで

これって、何を言っているの?ということで、よくわからないのでいろいろ調べてみると・・・・以下のようなことがわかりました。

Windows7とWindows Server 2008 R2では仮想アカウントというアカウントが導入された。

このアカウントは、ビルトインの「Network Service」アカウントを使用するサービスのログを追跡できるようにすることを目的としたものである。

「Network Service」アカウントはW2003で導入された。このアカウントは従来の「LocalSystem」アカウントに代わるものとして使用され、ローカルマシンに対しては完全なローカルシステム権限を持ち、ネットワークアクセスに関してはコンピュータアカウントの資格情報を使用する。

ところで、「Network Service」アカウントを使用するサービスが、数多くマシン上に構成されている場合、各サービスが実際何のリソースにアクセスし、何の操作を実行しているのか追跡することはほぼ無理である。なぜなら、それらすべてのサービスが「Network Service」アカウントを使用しているため、どのサービスのログか区別できないからである。

仮想アカウントは、サービスのインスタンスごとに一意となる「Network Service」アカウントの作成をエミュレートする。つまり、同じサービスであっても別インスタンスであれば、それぞれ別の「Network Service」アカウントとなる形である。これによりサービスごとの監査やログ追跡が容易になる。

ということになりますね。

システム要件

Windows Server 2008 R2 にドメインコントローラーがインストールしてあること。ただし、必ずしも最新のドメイン機能レベルでなくてもよい。ポイントとしてはR2の新機能が使用できるようにスキーマ拡張が行われていればよい。

*例外としてはDCがR2以外で、R2のスキーマ拡張が行われている場合は「管理されたサービスアカウント」を使用することはできるが、定期的なパスワード変更などは行われないので手動で行う必要があるとあるが、これって無理では(DCで変更されたパスワードが判らないと思う)・・・

まとめ

「管理されたサービスアカウント」は、自分で作成するサービスアカウントのセキュリティ機能向上を目的として使用され、「仮想アカウント」はNetwork Serviceアカウントの監査やログ追跡を容易にさせる目的で使用される

http://mctjp.com/2010/03/29/%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9%E3%82%A2%E3%82%AB%E3%82%A6%E3%83%B3%E3%83%88%E3%81%AE%E6%96%B0%E6%A9%9F%E8%83%BD/



Managed Service Account とは、Windows Server 2008 R2 からできた新しいアカウントのカテゴリです。パスワードが自動的に管理されるユーザー アカウントとして利用できるため、各種 Windows サービスのサービス アカウントとして利用すると、管理者がそのサービス アカウントのパスワードの管理から解放されるという素敵な代物です。
スキーマー的には msDS-ManagedServiceAccount が利用されます。作成・定義は PowerShell からしかできません。作成した Managed Service Account はデフォルトでは Managed Service Account コンテナ内に作成されますが、作成先の指定はできる模様です。
Service Accounts Step-by-Step Guide
New-ADServiceAccount
サービス アカウントを AD DS 上に作成する。
Install-ADServiceAccount
作成されたサービス アカウントのパスワードを、コマンドを実行したコンピューター上で管理できる状態にする。
reset-ADServiceAccountPassword
サービス アカウントのパスワードをリセットする。Install-ADServiceAccount コマンドでインストールされていないと利用できない。
これらの CmdLet は Import-Module ActiveDirectory で利用できます。すなわち Active Directory Domain Service 用の PowerShell を利用したいコンピューターにインストールする必要があるということです。なので、Windows Server 2008 R2 もしくは Windows 7 でしか Managed Service Account を利用できません。

2w.png



就業先でトラブっているのは?
サービスアカウントパス変後に、vCenterからDBにODBC接続で疎通確認が取れなくてパスを切り戻しした、ということだが、
これ自体の問題はわたしの中で解決している。(誰にも話していない)

問題だったのは、DBのSPNがADに登録されなかったためにケルベロス認証ができていなかった。
登録されなかった原因は不明(MSからは正規の方法でDBのパス変を行わなかった点を指摘されたがわたしはそう思わなかった。)
で、前記事で納得した。

就業環境は、ケルベロス認証を諦めてNTLM認証で行っている。(SPN重複しまくってるから)
が、ADでケルベロス認証を行う設定になっていた(規定)ので、毎度ケルベロス認証→失敗→NTLM認証している。
失敗しているタイミングで疎通確認を取ろうとしたから、vCenterから疎通は取れなかった。

はじめから、ケルベロス認証しないにするまたはNTLM認証されるのを待っていたら、vCenterから接続自体はできたはずで、
どうせAD介さないんだから、SPNは一切関係ない。

↓検証してない(推測)
なら、ケルベロス設定を切ればいいのだがこれだけでは不十分?かもしれない。
クライアント鯖は、サービスアカウントパスが正しいか定期的にADと確認を行っているようで、
AD自体にやはり登録されなかったサービスアカウントを紐付ける必要があるかもしれない。(コマンド一行)
現時点で動いているということは、おそらくそういうこと。

  1. 2015/11/16(月) 00:52:33|
  2. WindowsServer|
  3. トラックバック(-)|
  4. コメント:0

コメント

コメントの投稿

管理者にだけ表示を許可する

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。