web-dev-qa-db-ja.com

ドメイン管理者のみのアカウントからの移行

Windows環境では、ドメイン管理者は1つのユーザーアカウントしか持っていません。この単一のユーザーアカウントは、日常のワークステーションでの実行を含め、全面的に使用されます。このプラクティスからの移行では、ドメイン管理者を今後どのように設定するかについてのベストプラクティスを探しています。

明らかな最初のステップは、デフォルトで低特権アカウントに設定し、必要に応じてアプリケーションをエスカレーションすることです。この設定に移行するのはこれが初めてであるため、何を探す必要があり、どのような変更を加える必要があるのか​​がわかりません。そして、より広いスケールで、これはSharePoint管理者であることにどのように影響しますか? Office 365管理者?等..

そこにはどのようなリソースがありますか、または提供できますか?

7
Mark

@TheCleanerとは逆の方法を取ります。

これらのドメイン管理者アカウントのパスワードハッシュは、おそらくネットワーク全体に配置されており、ハッシュパスのシナリオを待っているだけです。そのため、これらのアカウントをドメイン管理者からすぐに削除し、制限付きユーザーとして使用を開始することをお勧めします。 (パスワードも変更する必要があります。)

この方法には、プロファイル「voodoo」を必要としないという明確な利点もあり、できれば、ホームディレクトリなどのリソースに対するアクセス許可を変更しないという利点があります。これにより、Excahngeメールボックスもそのまま保持されます。

ドメインコントローラーコンピューターのみに制限されたログオン制限を使用して、新しいドメイン管理者メンバーアカウントを作成します。これらのアカウントは、パスワードハッシュの公開を制限するために、ドメインコントローラーコンピューターへのログオン以外の目的で使用しないでください。

これは困難な移行であり、ユーザーアカウントが暗黙的にローカルの「管理者」グループのメンバーであるという理由だけで、クライアントコンピューターで機能していたものに遭遇することになります。別のグループのネスト(「以前のドメイン管理者」など)を使用してこれらのアカウントにローカル管理者権限を与えることで、このピルを飲み込みやすくすることができます。最終的には、それから離れたいと思うでしょう。

8
Evan Anderson

これが私の簡単な推奨事項です...この時点で簡単に「逆方向」に作業して、必要なものを取得できるためです。

  1. ADの既存のアカウントの名前を「Mark-Admin」のような名前に変更します。表示名とユーザーログオン名(username)を変更します。 SIDは同じままなので、本質的に誰かが乙女から既婚者の名前に変わるのと似ています。あらゆる場所のすべての権限などは同じままです。
  2. それぞれに、現在「マーク」と呼ばれる新しい低特権アカウントを作成します(以前の通常のユーザー名が使用されていたものは何でも)。これらのアカウントに、ホームフォルダへのアクセス許可や、この通常のアカウントがアクセスする必要のあるその他のアクセス許可を付与します。また、Exchange /メールシステム情報(メールアドレスなど)を古いアカウントからこのアカウントに転送する必要もあります。 SSOを使用していない場合は、O365または他のポータルのログイン情報としてそれらの電子メールアドレスが使用される可能性があることに注意してください。
  3. 「Mark-Admin」がアクセスする必要がなくなった権限がある場合は、削除します。
  4. ワークステーションで ForensIT Profile Wizard などのツールを使用して、プロファイルを古いSID(現在はMark-Adminユーザー名)から新しいSID(Mark)に移行します...デスクトップ/プロファイルを元に戻します/等。彼らがいつもそのアカウントでそれを使っていたかのように。
  5. SSOを提供しなかったログオン/認証ポータル(おそらくO365、Sharepointなど)の場合は、これらを何らかの方法で更新する必要があります。たとえば、ADと同期していない場合のO365では、新しいアカウントを作成するか、既存のアカウントの権限を変更して、ADを直接更新する必要があります。これは設定に基づきます。たとえば、現在メールアドレスでサインインしている場合、そのアドレスは明らかに特権の低いアカウント(Mark)に転送されるため、Mark-Adminには別のアドレス設定が必要になります。
  6. 利益
5
TheCleaner