사용자 이름 표준 모범 사례 : 문제 방지

표준 사용자 이름에 대한 사람들의 경험이 무엇인지 알아 내고 싶습니다. 나는 항상 {firstInitial} {lastname} (때로는 길이 제한이있는) 을 사용한 장소에 있었습니다 . 이제 {firstname}. {lastname} 을 (를) 원하는 사용자가 있습니다. 이제 기간에 문제가 발생할 수 있습니다.

구체적으로 :

• 모든 사용에서 호환성을 유지하기 위해 사용할 수있는 최상의 사용자 이름 길이 제한은 무엇입니까?
• 어떤 캐릭터를 피해야합니까?

업데이트 : 구체적인 내용을 언급하지 않은 이유는 앞으로 올 수있는 모든 것을 처리 할 수 ​​있기를 원했기 때문입니다. 그러나 그것은 요구 사항에 너무 일반적 일 수 있습니다 (아무것도 일어날 수 있습니까?).

현재 환경은 다음과 같습니다. 우분투 서버 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 미래.

업데이트 : 나는 이 질문 (내 질문에 대답하지는 않았지만) 과이 웹 게시물을 보았고 (완전하게) 언급해야 하며 둘 다 매우 유익했습니다.

이는 이기종 시스템을 서로 연결하려는 대규모 Identity Management 시스템에서 발생하는 심각한 문제입니다. 항상 가장 낮은 공통 분모로 제한되며 데이터 센터의 창 어딘가에있는 유닉스 계열 시스템으로 인해 8 자 ASCII 영숫자 제한으로 너무 자주 제한됩니다. 이 멋진 현대 시스템은 임의의 길이를 취할 수 있습니다. UTF8 사용자 이름은 사용되지 않을 것입니다.

나는 고등 교육 기관에서 7 년을 보냈으며 매년 5000 명의 신입생을위한 8 자리 사용자 이름을 찾아야했습니다. 우리는 내가 떠날 때까지 15 년 동안 학생들의 고유 한 이름을 생각해 냈습니다. 이 일을 할 수 있습니다, smitj510

인생을 훨씬 더 쉽게 만들어 줄 것 :

• 최저 공통 분모가 무엇인지 파악하십시오. 여기에서 ID 관리 시스템의 모든 부분을 분석하여 한계가 무엇인지 알아 내야합니다.
  • 이 오래된 Solaris 7 시스템은 8 자로 제한됩니다.
  • 신원 데이터를 사용하는 중요한 응용 프로그램에는 고려해야 할 고유 한 제한이 있습니다.
    • 아마도 그들은 LDAP의 사용자 데이터가 고유 한 '표준'을 준수 할 것으로 기대합니다.
    • 이들이 사용하는 인증 데이터베이스는 특정 형식의 데이터 만 처리 할 수 ​​있습니다.
• 대체 ID의 유사 항목 firstname.lastname또는 다른 항목을 나열하는 링크 / 필드와 함께 하나의 고유 식별자 (8 자리 계정 이름) 목록이있는 데이터베이스 테이블이 있어야 합니다.
  • 상용 소프트웨어는 계정 이름에 숫자 ID를 사용하거나 프로필 데이터를 기반으로 계정 ID를 자동 생성하는 것과 같이 정말 이상하고 IDM에 익숙하지 않은 작업을 수행 할 수 있습니다. 이것도 데이터베이스 테이블에 들어갑니다.
  • 이것은 또한 Harry O'Neil과 같은 이름에 비 [az | 0-9] 문자를 가진 사람들이나 Alžbêta와 같은 비 ASCII 문자를 가진 사람들을 돕습니다.
• 계정 동기화 프로세스를 구축 할 때 해당 데이터베이스 테이블을 활용하여 올바른 계정이 올바른 업데이트를 받고 있는지 확인하십시오. 이름이 바뀌면 (결혼, 이혼 등) 그 변경 사항이 올바른 장소로 전파되기를 원합니다.
  • 가능한 경우 로컬 변경을 방지하기 위해 실제 ID 데이터베이스 자체를 구성하고, 불가능한 경우에는이를 방지하기 위해 비즈니스 프로세스를 구성하십시오. 가능한 모든 것을 중앙 계정 동기화 프로세스에 의존하십시오.
• 이메일과 같이 가능한 모든 곳에서 별칭 시스템을 활용하십시오.
• 해당 필드를 변경하면 계정을 다시 작성해야하므로 IT 직원들 사이에 많은 고통을 유발할 수 있으므로 8 자리 ID 불변을 고려하십시오.
  • 결혼 / 이혼 / 법정 명령은 시간이 지남에 따라 이름 데이터를 변경할 수 있기 때문에 이름 데이터에서 파생 되지 않은 계정 ID를 제안합니다 .
• 항상 일부가 있으므로 예외를위한 시스템을 마련하십시오.
  • 끔찍한 이혼과 이름 데이터로 생성 된 8 문자 UID는 입력 할 때마다 기억에 남는 추억을 선사합니까? 사용자에게 친절하고 이러한 변경에 대한 메커니즘을 허용하지만 조용히 유지하십시오.
• 옵션 인 시스템에서 여러 개의 사용자 이름 로그인을 허용 할 수있는 작업을 수행하십시오.
  • 8 문자 uid를 좋아하는 사람도 있고 firstname.lastname@example.com과 같은 사람도 있습니다. 융통성 있고 친구를 사귀십시오.
  • 때로는 CAS 와 같은 싱글 사인온 (SSO) 프레임 워크로 웹 기반 시스템을 관리해야합니다 . 이와 같은 SSO 프레임 워크를 지원할 수있는 선반 시스템의 수에 놀랄 것이므로 권장하지 마십시오.

다시 말해서 데이터 베이 싱 문제처럼 취급하십시오. 그것이 바로 그것이 기 때문입니다. 시스템 (최대 8 자)과의 최대 호환성을 위해 기본 키를 선택하고, 시스템이 로컬 ID를 기본 키로 변환 할 수 있도록 조회 테이블을 작성하고, 다양한 ID를 처리하도록 데이터 동기화 시스템을 엔지니어링하십시오.

당신의 질문은 구체적으로 :

• 모든 사용에서 호환성을 유지하기 위해 사용할 수있는 최상의 사용자 이름 길이 제한은 무엇입니까?

그런 것은 없습니다. 향후 사용을 포함 할 수있는 "귀하의"용도 만 있습니다. 우리는 그것이 무엇인지 전혀 모른다.

• 어떤 캐릭터를 피해야합니까?

이것은 처리중인 컴퓨터 시스템에 따라 다릅니다. 예를 들어, Windows는 사용자 이름의 마침표에 문제가 없습니다. 실제로 UPN은 전자 메일 주소와 같이 형식이 지정되어 마침표를 사용할 수 있습니다.

내 추가 생각 :

• 사용자에게 묻지 말고 표준이 무엇인지 말하고 요구 사항 변경에 따라 표준 변경을 요청하는 비즈니스 (개별 사용자 아님)에게 공개하십시오.
• 표준에서 "예외 정책"을 작성하면 부통령을 관여시키지 않고도 가난한 Susan Penington과 Mary Utt (위의 의견으로부터)를 도울 수 있습니다. IT를 좋아 보이게합니까?

제 경험은 충분히 큰 기업의 경우 결정에 항상 문제가 있다는 것입니다. 오늘날에도 작동하더라도 항상 이전 표준에 문제가있는 시스템 (길이 문제, 문자 문제 등)이 있습니다.

Firstname.Lastname에 대한 푸시가 전자 메일과 관련이 있으며 반드시 로그인 이름이 아닌지 확인하십시오. 사용자가 로그온 할 때 "jsmith"대신 "John.Smith"를 입력하고 싶다고 생각하기는 어렵지만 "John.Smith@company.com을 원한다는 생각에 훨씬 더 많이 팔렸습니다. "을 그의 이메일 주소로 @Mfinni가 지적했듯이 사용자는 여러 전자 메일 별칭, 전달 등을 가질 수있는 옵션이 항상 있습니다. 사용자에게 전자 메일 주소에서 사용자 이름을 분리하는 옵션이 있음을 알리면 요청의 역학이 바뀔 수 있습니다.

유닉스와 리눅스 시스템의 경우, {firstInitial} {LASTNAME은}입니다 분명 이상적입니다.

...

이 계정과 관련된 이름에서 분명한 이유가 있습니다.

여러 플랫폼에서 명명 표준을 설정할 때주의해야 할 사항은 Linux (및 기타 Unix OS)의 ps에서 특정 외관상의 문제입니다. 당신은 이것에 대해 걱정할 수도 있고 그렇지 않을 수도 있습니다 (그러나 그것을 기대하지 않는 누군가에게 경고 할 수 있습니다 ... 나는 이것에 대해 보안 담당자를 had습니다).

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]

예 : 이름이 빌 게이츠 인 경우 ' biga00 '또는 bilgat000을 사용할 수 있습니다

다음 빌 게이트가 오면 'biga01'또는 bilgat001이됩니다.

운영, 관리 및 유지 관리 (OAM) 관점에서 보면 사용자 이름을 쉽게 구별 할 수 있어야합니다. 그러나 비즈니스 관점에서 볼 때 사용자 이름 (a / k / a 이메일 별칭)은 다른 사람이 쉽게 기억하거나 기억해야합니다.

다음과 같을 수 있습니다.

• first.last.index@domain
• first (초기) .last.index @ domain