web-dev-qa-db-ja.com

全社的なユーザー名ポリシーと重複の解決に関するベストプラクティスまたは経験

私は、新しい全社的なActiveDirectoryログインスキームに統合する必要があるアプリケーションを使用しているプログラマーです。これは、新しいスキームを使用するようにシステム内のすべてのユーザー名を変更することを意味します。新しいスキームは「最初のイニシャル、姓」であるため、JoeSmithのユーザー名はjsmithになります。 John Smithが採用された場合、彼はjsmith2を取得します。しかし、ジョーが会社を辞めるとすぐに、彼のADアカウントは削除され、jsmithが再び利用可能になります。したがって、ジル・スミスが現在雇用されている場合、彼女はjsmithを取得します。アプリケーションの観点からは、これは私の見解では問題を引き起こします。ジョーに関連するレコードとジルに関連するレコードは、どちらも「jsmith」によって作成されたため、区別がつかなくなる可能性があるためです。

したがって、組織全体のディレクトリ、特に大企業でユーザー名を再利用するというこの問題に対処する標準またはベストプラクティスがあるかどうか疑問に思います。会議で懸念を表明したとき、「[大企業名]が会社を辞めたすべてのユーザーの記録をまだ持っているわけがない」と言われ、それは私を夢中にさせました。それで、ユーザー名を処理するための一般的に受け入れられている解決策はありますか？それとも、すべての企業がそれを作り上げているのでしょうか。

active-directoryldapuser-management
7
Peter

Windowsは、GUIDを使用してすべてのアカウントを識別することでこれに対処します。ユーザー名は単なる装飾です。ユーザー名が同じであっても、古いjsmithと新しいjsmithのGUIDが異なることがわかります。

GUIDをアプリの各アカウントに関連付けることはできますか？それについて考えると、ユーザーのGUIDに到達する方法を説明できます。これは、ActiveDirectory内のユーザーの属性になります。

JR

7
John Rennie

はい、私たちはすべてのユーザーをこれまでに雇用し続けています。 JQPublic1アカウントの数を最小限に抑えるために、通常は最初のイニシャル、ミドルネームのイニシャル、姓をお勧めしますが、ADの観点からは、ユーザーは単なる数字です。このスクリプトを使用すると、任意のアカウントの番号を確認できます。

strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
Set objAccount = objWMIService.Get ("Win32_UserAccount.Name='myusername',Domain='mydomain'")
Wscript.Echo objAccount.SID

無料のボーナスとして、 sidをユーザー名に変換する ：

strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
Set objAccount = objWMIService.Get ("Win32_SID.SID='S-1-5-21-1454471165-1004336348-1606980848-5555'")
Wscript.Echo objAccount.AccountName
Wscript.Echo objAccount.ReferencedDomainName
5
Jim B

他の人が述べているように、ユーザーのActiveDirectoryアカウントのGUID属性を使用することは素晴らしいアイデアです。ただし、人間が読みやすくしたい場合は、-のドキュメントを参照してください。 iADsNameTranslate インターフェイス。ADアカウントのさまざまな可能な名前（GUID、SID、samAccountName、displayName、DNなど）の変換を処理することで、多くのマイレージを得ることができます。

例：

Option Explicit

' Constants for the iADsNameTranslate object. (from http://msdn.Microsoft.com/en-us/library/aa772267(VS.85).aspx)
Const ADS_NAME_TYPE_NT4 = 3
Const ADS_NAME_TYPE_GUID = 7

Const ADS_NAME_INITTYPE_GC = 3

Dim objNameTranslate 
Dim strUserGUID

' Create a nametranslate object and init to talk to a global catalog server
Set objNameTranslate = CreateObject("NameTranslate")
objNameTranslate.Init ADS_NAME_INITTYPE_GC, ""

' We're looking for an "NT 4" account name type-- aka a samAccountName
objNameTranslate.Set ADS_NAME_TYPE_NT4, "DOMAIN\username"

' Translate into the user's GUID
strUserGUID = objNameTranslate.Get(ADS_NAME_TYPE_GUID)

WScript.Echo strUserGUID

これはユーザーアカウントだけのものではありません。 AD内のすべてのオブジェクトにはGUIDがあるため、たとえばLDAP検索ベース（またはグループなど）のDNを「記憶」する必要がある場合は、GUID AD内で移動した場合（一部の管理者が離れてOUを再編成したり、グループの名前を変更したりすることを考えてください）、その「ポインター」は壊れません（GUIDは変更されないため） 。

3
Evan Anderson

GUIDは間違いなく進むべき道です。本当に人にわかりやすい形式で人の名前を提示する必要がある場合は、コードでADルックアップを実行するだけです。

1
Maximus Minimus

ActiveDirectoryにはいくつかの命名属性があります。

  • sAMAccountName：これは最大20文字の名前であり、ドメイン内で一意である必要がありますが、フォレスト内では一意である必要はありません。
  • userPrinicipalName：これは通常[email protected]の形式であり、フォレスト内で一意である必要があると思いますが、最初の部分はドメイン内で一意であるため、@ domain.nameが発生するはずです。
  • displayName：ユーザーを見るとADUC MMC）に表示されるもの。
  • DN：ADツリー内のユーザーの実際のLDAPDN。これは、通常、LDAPの観点からユーザーを識別する方法です。

DNは、ユーザーが移動したり名前が変更されたりすると変更されるため、キーオフするのに適していません。 userPrincipalName/sAMAccountName（名前が変更された場合）は正常です。

別のポスターが示唆しているように、ユーザーの本当にユニークな属性はおそらくGUIDであり、残念ながら、人間が読める形式ではありません。

1
geoffc

ピーター、これに関する私自身の経験は、ユーザー名の一意性を保証する方法がない限り、ユーザー名が一意であることを期待しないでください。あなたが言うように、それは実際にはうまくいきません。

アプリは、それが何であれ、他の関連データを使用して、アプリが実行しているコンテキスト内でユーザーを一意にするものを決定する必要があります。たとえば、メールチラシを生成するアプリを作成している場合、一意の住所ごとに複数のチラシを送信することはおそらく望ましくありません。

0
quux

他の人はすでにスクリプトスニペットを投稿しており、通常のコーディングサイトでさまざまな言語のコードスニペットをたくさん見つけることができます。 「usertoguid」、「usertoid」などを検索してみてください。

0
John Gardeniers

IMO、アカウントを削除せず、無効にすることをお勧めします。そうすれば、それらを再利用することはできません。

0
cas