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

Question

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

具体的には：

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

UPDATE：私が詳細に言及しなかった理由は、将来発生する可能性のあるすべてを処理するのに十分一般的なものになりたかったからです。しかし、それは要件の一般的すぎるかもしれません（何かが起こる可能性がありますよね？）。

これは私たちの環境です。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未来。

UPDATE：私が見た（完全性のために）この質問（それは私の質問に答えませんでしたが）について言及する必要がありますまた、これは web post であり、どちらも非常に有益でした。

sysadmin1138 · Answer

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

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

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

最小公分母が何であるかを理解します。これには、ID管理システムのすべての部分を分析して、制限とは何かを発見する必要があります。
- その古いSolaris 7システムは、8文字の制限を強制しています。
- IDデータを使用する重要なアプリケーションには、考慮しなければならない独自の制限があります。
  - おそらく、彼らはLDAPからのユーザーデータがそれらに固有の「標準」に準拠することを期待しています。
  - おそらく、彼らが使用する認証データベースは、特定のフォーマットされたデータしか処理できません。
  - おそらく、Windows互換システムがSAMAccountNameを使用してから20年経った今でも、それはよい考えではなくなっています。
One True Identifier（その8文字のアカウント名）のリストを含むデータベーステーブルを用意し、firstname.lastnameなどの代替IDやその他の考えられるものをリストしたリンク/フィールドを含めます。
- 市販のソフトウェアでは、アカウント名に数値IDを使用したり、プロファイルデータに基づいてアカウントIDを自動生成したりするなど、非常に奇妙でIDMに適さない処理を実行できます。データベーステーブルにもすべてが入ります。
- これは、名前に[a-z | 0-9]以外の文字をHarry O'Neilのように使用している人や、Alžbêtaのように非ASCII文字を使用している人にも役立ちます。
アカウント同期プロセスを構築するときは、そのデータベーステーブルを活用して、適切なアカウントが適切な更新を取得していることを確認します。名前が変わったとき（結婚、離婚など）、それらの変更を適切な場所に反映させたいと考えています。
- 可能な場合はローカルでの変更を防止するように実際のIDデータベース自体を構成し、それが不可能な場合はビジネスプロセスでそれを強く阻止します。できる限りのことは、中央のアカウント同期プロセスに依存します。
電子メールなど、可能な限りエイリアスシステムを活用します。
アカウントを再作成する必要があるため、このフィールドを変更するとITスタッフの間で多くの心痛を引き起こす可能性があるため、8文字のIDは不変であると考えてください。
- Marriage/divorce/court-orderは時間の経過とともに名前データを変更する可能性があるため、これは名前データから派生したアカウントIDではないことを示唆しています。
例外は常に存在するため、例外のためのシステムを用意してください。
- 恐ろしい離婚とその名前データで生成された8文字のUIDは、入力しなければならないたびに悲惨な思い出をもたらしますか？ユーザーに優しく、これらの変更のメカニズムを許可しますが、静かにしてください。
それがオプションであるシステムで複数のユーザー名ログインを許可するためにできることをしてください
- 8文字のuidが好きな人もいれば、firstname.lastname @ example.comが好きな人もいます。柔軟になり、友達を作る。
- [〜＃〜] cas [〜＃〜] のような single-sign-on フレームワークを使用するか、 saml 。このようなSSOフレームワークをサポートする既製のシステムがいくつあるかに驚かれるので、がっかりしないでください。

つまり、それがデータベーシングの問題のように扱われるということです。システムとの互換性を最大にするために主キーを選択し（おそらく8文字）、システムがローカルIDを主キーに変換できるようにルックアップテーブルを作成し、データ同期システムを設計してさまざまなIDを処理できるようにします。

mfinni · Answer

特にあなたの質問：

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

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

避けるべきキャラクターは？

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

私のさらなる考え：

ユーザーに尋ねないでください-標準とは何かを伝え、要件の変更に応じて標準の変更を要求するビジネス（個人ユーザーではない）に開放してください。
標準で「例外ポリシー」を作成してください。そうすれば、副大統領を関与させることなく、貧弱なスーザンペニントンとメアリーアット（上記のコメントから）を助けることができます。 ITの見栄えを良くしますか？

Evan Anderson · Answer

私の経験では、十分に大規模な企業の場合、あなたが下す決定には常に問題があります。それが今日機能する場合でも、以前の標準に問題がある（長さの問題、文字の問題など）明日実装するシステムは常に存在します。

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

Robert Oot · Answer

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

...

このアカウントに関連付けられた名前から明らかである必要がある理由。

Travis Campbell · Answer

プラットフォーム間で命名基準を設定する際に注意する必要があることの1つは、Linux（および場合によっては他のUnix OS）のpsにおける表面的な問題です。あなたはこれを気にしてもしなくてもかまいません（しかし、それを期待していない誰かにとっては憂慮すべきことかもしれません...私はこれについてセキュリティ担当者Twitchを抱えていました）。

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