ユーザー名標準のベストプラクティス：問題の回避

私は、標準的なユーザー名に関する人々の経験が何かを知りたいと思っています。私は常に{firstInitial} {lastname}を使用する場所にいました（長さ制限がある場合もあります）。現在、{firstname}。{lastname}を必要としているユーザーがいます。そして今、その期間が問題を引き起こす可能性があることがわかりました。

具体的には：

• すべての用途で互換性を維持するために使用する最適なユーザー名の長さ制限は何ですか？
• どのキャラクターを避けるべきですか？

更新：詳細に言及しなかった理由は、将来登場する可能性のあるものをすべて処理するのに十分な汎用性を望んでいたからです。ただし、それは要件の一般的すぎる可能性があります（何か起こる可能性がありますよね？）。

これが私たちの環境です。UbuntuServer Lucid Lynx 10.04 LTS、Red Hat Enterprise Linux 5.6以降、Windows Server 2003およびWindows 2000 Server（Windows 2000ネイティブモードのActive Directory）、メール用のZimbra 7.x、および近くのOpenLDAP未来。

更新：（完全を期すために）私はこの質問を見ました（私の質問には答えませんでしたが）と、このWeb投稿にも言及する必要があります。

これは、異種システムを結合しようとする大規模なIdentity Managementシステムの慢性的な問題です。常に、最小公分母に制限されます。これは、データセンターのどこかにある（おそらくレガシーな）Unixライクなシステムのおかげで、ほとんどの場合8文字のASCII英数字制限です。これらの最新のシステムは、UTF8ユーザー名が使用される可能性が低い任意の長さを取ることができます。

私は7年を高等教育機関で過ごし、毎年5000人の新入生の8文字のユーザー名を把握する必要がありました。私が去るまでに、15年間の学生のためにユニークな名前を思いついた。これができる、smitj510氏

あなたの人生を計り知れないほど簡単にするもの：

• 最も低い共通分母が何であるかを把握します。これには、アイデンティティ管理システムのすべての部分を分析して、制限が何であるかを見つける必要があります。
  • その古いSolaris 7システムは、8文字の制限を強制しています。
  • IDデータを使用する重要なアプリケーションには、考慮しなければならない独自の制限があります。
    • おそらく、彼らはLDAPからのユーザーデータがそれらに固有の「標準」に準拠することを期待しています。
    • おそらく、彼らが使用する認証データベースは、特定のフォーマットされたデータのみを処理できます。
• One True Identifier（その8文字のアカウント名）のリストと、代替IDのようなリストfirstname.lastnameまたは出てくる可能性のある他のものをリストするリンクを持つフィールドを持つデータベーステーブルを用意します。
  • 既製のソフトウェアは、アカウント名に数値IDを使用したり、プロファイルデータに基づいてアカウントIDを自動生成したりするなど、IDMにとって非常に奇妙なことを実行できます。データベーステーブルにも含まれます。
  • これは、ハリー・オニールのような名前に非[az | 0-9]文字が含まれる人や、Alžbêtaのような非ASCII文字を持つ人にも役立ちます。
• アカウント同期プロセスを構築するとき、そのデータベーステーブルを活用して、適切なアカウントが適切な更新を取得していることを確認します。名前が変更されたとき（結婚、離婚、その他）、それらの変更を適切な場所に伝播する必要があります。
  • 実際のIDデータベース自体を構成して、可能な限りローカルでの変更を防止し、ビジネスプロセスでは不可能な場合にそれを阻止します。できる限りすべてを中央のアカウント同期プロセスに依存します。
• メールなど、できる限りエイリアスシステムを活用します。
• 8文字のIDは不変であると考えてください。そのフィールドを変更すると、アカウントを再作成する必要があるため、ITスタッフの間で多くの心痛を引き起こす可能性があります。
  • 結婚/離婚/裁判所命令は時間とともに名前データを変更する可能性があるため、これは名前データから派生していないアカウントIDを示唆しています。
• 例外は常に存在するため、例外のためのシステムを用意してください。
  • 恐ろしい離婚とその名前データで生成された8文字のUIDは、入力するたびに苦しい思い出をもたらしますか？ユーザーには親切にして、これらの変更のメカニズムを許可しますが、静かにしてください。
• それがオプションであるシステムで複数のユーザー名ログインを許可するためにできることをしてください
  • 8文字のuidが好きな人もいれば、firstname.lastname @ example.comが好きな人もいます。柔軟に、友達を作りましょう。
  • 場合によっては、CASのようなシングルサインオンフレームワークでWebベースのシステムを前面に配置する必要があります。このようなSSOフレームワークをサポートしている市販のシステムがいくつあるかに驚かれるので、落胆しないでください。

つまり、それがデータベースの問題のように扱われるためです。システムとの互換性を最大限にするためにプライマリキーを選択し（8文字程度）、ルックアップテーブルを構築してシステムがローカルIDをプライマリキーに変換できるようにし、さまざまなIDを処理するようにデータ同期システムを設計します。

具体的な質問：

• すべての用途で互換性を維持するために使用する最適なユーザー名の長さ制限は何ですか？

そのようなことはありません。「あなたの」用途のみがあり、将来の用途が含まれる場合があります。それらが何であるかはわかりません。

• どのキャラクターを避けるべきですか？

これは、使用しているコンピューターシステムによって異なります。たとえば、Windowsでは、ユーザー名のピリオドに問題はありません。実際、UPNは電子メールアドレスのようにフォーマットされているため、ピリオドを使用できます。

私のさらなる考え：

• ユーザーに質問させないでください。標準が何であるかを伝え、要件の変更に応じて標準への変更を要求するビジネス（個々のユーザーではない）に対してオープンにしてください。
• 標準で「例外ポリシー」を作成してください。そうすれば、副社長を巻き込むことなく、貧弱なスーザンペニントンとメアリーアットを支援できます（上記のコメントから）。ITの見栄えを良くしますか？

私の経験では、十分に大規模な企業にとって、あなたが下す決定には常に問題があります。今日動作していても、明日実装するシステムには常に、以前の標準に問題がある（長さの問題、キャラクターの問題など）。

Firstname.Lastnameのプッシュが電子メールに関連しており、必ずしもログイン名に関連していないかどうかを必ず確認してください。ユーザーがログオン時に「jsmith」ではなく「John.Smith」と入力したいとは信じられないでしょうが、「John.Smith@company.com」が欲しいと思うと、もっと売れます。 「彼のメールアドレスとして。@Mfinniが指摘しているように、ユーザーが複数のメールエイリアスや転送などを使用するオプションが常にあります。ユーザーにメールアドレスからユーザー名を切り離すオプションが存在することを知らせるだけで、リクエストのダイナミクスを変更できます。

UnixおよびLinuxシステムの場合、{firstInitial} {lastname}は明らかに理想的です。

...

このアカウントに関連付けられた名前から明らかなはずの理由で。

プラットフォーム間で命名基準を設定する際に注意すべきことの1つは、Linux（および場合によっては他のUnix OS）のpsの特定の表面的な問題です。あなたはこれを気にするかもしれないし、気にしないかもしれません（しかし、それを期待していない人には警戒するかもしれません...私はセキュリティの人々にこれをひきつらせました）。

UID列には、最大8文字のユーザー名のみが表示されます。ユーザー名が8文字より長い場合、実際の数値UIDの印刷に切り替わります。これを回避するには、USERフィールドを含むカスタムps列形式を使用しますが、USERが最後の列である場合にのみ（私の経験的なテストから）。

ほとんどの人はおそらくこれを気にしませんが、ps出力の何らかの処理を行い、実際のユーザー名が表示されることを期待している場合は、名前の長さに注意する必要があります（そうでない場合は、コードにハックを入れますpsに正しいことをさせるには）。

例えば：

完全な形式のリストのデフォルトの列形式は次のとおりです。ユーザー名が8文字を超えているため、UIDは数値形式であることに注意してください。

[tcampbell@tst-agg1 ~]$ ps -f
  UID        PID  PPID  C STIME TTY          TIME CMD
 2108      1368  1367  0 Jan10 pts/3    00:00:00 -bash
 2108     22303  1368  0 12:07 pts/3    00:00:00 ps -f

カスタム列フォーマットを使用して再作成しましょう。USER列を追加したことに注意してください。数値形式でもあることに注意してください。

[tcampbell@tst-agg1 ~]$ ps -o uid,user,c,stime,tty,time,cmd    
  UID USER      C STIME TT           TIME CMD
 2108 2108      0 Jan10 pts/3    00:00:00 -bash
 2108 2108      0 12:05 pts/3    00:00:00 ps -o uid,user,c,stime,tty,time,cmd

USERを行末に移動しましょう。「正しい」出力に展開されます。

[tcampbell@tst-agg1 ~]$ ps -o uid,user,c,stime,tty,time,cmd,user
  UID USER      C STIME TT           TIME CMD                         USER
 2108 2108      0 Jan10 pts/3    00:00:00 -bash                       tcampbell
 2108 2108      0 12:05 pts/3    00:00:00 ps -o uid,user,c,stime,tty, tcampbell

ただし、列リストの最後に何か新しいものを追加するとすぐに、数値形式に戻ります。

[tcampbell@tst-agg1 ~]$ ps -o uid,user,c,stime,tty,time,cmd,user,pid
  UID USER      C STIME TT           TIME CMD                         USER       PID
 2108 2108      0 Jan10 pts/3    00:00:00 -bash                       2108      1368
 2108 2108      0 12:05 pts/3    00:00:00 ps -o uid,user,c,stime,tty, 2108     21756

[名からの手紙] [姓からの手紙] [nnn]

foreg：名前がBill Gatesの場合、 ' biga00 'またはbilgat000を使用できます

次の法案のゲートが来る場合、彼にとっては 'biga01'またはbilgat001 'になります。

さて、運用、管理、およびメンテナンス（OAM）の観点からは、ユーザー名を簡単に区別する必要があります。ただし、ビジネスの観点からは、ユーザー名（a / k / aメールエイリアス）を他の人が簡単に覚えたり思い出したりする必要があります。

次のようになります。

• first.last.index@domain
• first（initial）.last.index @ domain