Kullanıcı Adı Standartlarında En İyi Uygulamalar: Sorunlardan Kaçınmak

İnsanların standart kullanıcı adlarıyla ilgili deneyimlerinin ne olduğunu öğrenmekle ilgileniyorum. Her zaman {firstInitial} {soyadı} (bazen bir uzunluk sınırı olan) kullanan yerlerde bulundum . Şimdi {firstname}. {Soyadı} - isteyen kullanıcılar var ve şimdi dönemin sorunlara neden olabileceği ortaya çıkıyor.

özellikle:

• Tüm kullanımlarda uyumluluğu korumak için kullanılacak en iyi kullanıcı adı uzunluğu sınırı nedir?
• Hangi karakterlerden kaçınılmalı?

GÜNCELLEME: Spesifik özelliklerden bahsetmememin nedeni, gelecekte ortaya çıkabilecek herhangi bir şeyi halledebilecek kadar genel olmak istememdi. Ancak, bu bir gereksinim için çok genel olabilir (herhangi bir şey olabilir, doğru mu?).

Bu bizim çevremiz: Ubuntu Sunucusu Lucid Lynx 10.04 LTS, Red Hat Enterprise Linux 5.6 ve üstü, Windows Server 2003 ve Windows 2000 Server (Windows 2000 Yerel Modunda Active Directory ile), posta için Zimbra 7.x ve yakınlarda OpenLDAP geleceği.

GÜNCELLEME: Bu soruyu (sorulan soruyu cevaplamamasına rağmen) ve aynı zamanda her ikisi de çok bilgilendirici olan bu web yayınını gördüğümden bahsetmeliyim .

Bu, heterojen sistemleri birbirine yapıştırmaya çalışan büyük Kimlik Yönetimi sistemlerinin kronik bir sorunudur. Değişmez bir şekilde, veri merkezinin bağırsaklarının herhangi bir yerinde bulunan bazı (muhtemelen eski) Unix benzeri sistem sayesinde çoğu zaman 8 karakterlik ASCII-alfa-sayısal bir limit olan en düşük ortak payda ile sınırlı kalacaksınız. Bu fantezi modern sistemler keyfi sürebilir UTF8 kullanıcı adlarının kullanılması pek mümkün değildir.

Her yıl 5000 yeni öğrencinin 8 karakterli kullanıcı adını bulmak zorunda kaldığımız bir yükseköğretim kurumunda 7 yıl geçirdim. Ayrıldığımda 15 yaşındaki öğrencilere benzersiz isimler bulmayı başardık. Bu yapılabilir Bay Smitj510

Hayatınızı ölçülemez derecede kolaylaştıracak şeyler:

• Sınırların ne olduğunu keşfetmek için kimlik yönetim sisteminizin her bölümünü analiz etmeyi gerektiren en düşük ortak paydaşınızın ne olduğunu belirleyin.
  • Bu eski Solaris 7 sistemi 8 karakterlik sınırı zorluyor.
  • Kimlik verilerini kullanan kritik uygulamalar, göz önünde bulundurmanız gereken kendi sınırlarına sahiptir.
    • Belki de LDAP'dan gelen kullanıcı verilerinin kendilerine özgü bir 'standart'a uymasını bekliyorlar.
    • Belki de kullandıkları kimlik doğrulama veritabanı sadece belirli formattaki verileri idare edebilir.
• Alternatif ID'lerin benzerlerini firstname.lastnameveya gelebilecek başka şeyleri listeleyen bağlantılar / alanlar içeren One True Identifier (bu 8 karakterlik hesap adı) listesine sahip bir veritabanı tablosuna sahip olun .
  • Hazır yazılım, hesap adı için sayısal bir kimlik kullanmak veya profil verilerine dayalı olarak otomatik olarak hesap kimliklerini oluşturmak gibi bazı garip ve IDM dostu olmayan şeyler yapabilir. Tüm bunlar da veritabanı tablosuna giriyor.
  • Bu aynı zamanda Harry O'Neil gibi adlarında [Az | 0-9] olmayan karakterlere veya Alžbêta gibi ASCII olmayan karakterlere de yardımcı olur.
• Hesap senkronizasyon işlemlerinizi oluştururken, doğru hesapların doğru güncellemeleri aldığından emin olmak için o veritabanı tablosundan yararlanın. İsimler değiştiğinde (evlilik, boşanma, diğerleri), bu değişikliklerin doğru yerlere yayılmasını istersiniz.
  • Mümkün olan yerlerde yerel değişiklikleri önlemek için gerçek kimlik veritabanlarını ve iş mümkün olmadığında bunları kesinlikle engellemek için iş süreçlerini yapılandırın. Yapabileceğiniz her şey için merkezi hesap senkronizasyon sürecine güvenin.
• E-postadaki gibi, diğer ad sistemlerinden yararlanın.
• 8 karakterli kimliği değiştirilemez olarak kabul edin, çünkü bu alanın değiştirilmesi, hesapların yeniden oluşturulması gerektiğinden BT çalışanları arasında bir LOT kalp ağrısını tetikleyebilir.
  • Bu hesap numarası da anlaşılacağı değil zamanla isim verileri değiştirebilir evlilik / boşanma / mahkeme sipariş beri adı verilerden türetilen.
• İstisnalar için bir sisteminiz olsun, çünkü her zaman birileri olacaktır.
  • Korkunç boşanma ve bu 8-char UID ile üretilen isim-veri, her girmeniz gerektiğinde anahtar hatıraları getiriyor? Kullanıcılarınıza iyi davranın ve bu değişiklikler için bir mekanizmaya izin verin, ancak sessiz kalın.
• Bir seçenek olan sistemlerde birden fazla kullanıcı adı girişine izin vermek için elinizden geleni yapın
  • Bazıları 8 karakterli kullanıcı adlarını, bazıları ise firstname.lastname@example.com'u sever. Esnek olun, arkadaş olun.
  • Bazen bu, web tabanlı sistemlerinizin CAS gibi tek oturum açmalı bir çerçeve ile ön yüklemesini gerektirir . Raf sisteminden kaç tanesinin bu gibi SSO çerçevelerini destekleyebileceğine şaşıracaksınız, bu yüzden cesaretiniz kırılmasın.

Söylemek istediğim, onu bir veri tabanı problemi gibi ele alın, çünkü budur. Sistemlerinizle maksimum uyumluluk için bir birincil anahtar seçin (muhtemelen 8 karakter), sistemlerin yerel kimlikleri birincil anahtara çevirmesine izin vermek için bir arama tablosu oluşturun ve çeşitli kimlikleri işlemek için veri senkronizasyon sistemlerinizi geliştirin.

Sorularınız özellikle:

• Tüm kullanımlarda uyumluluğu korumak için kullanılacak en iyi kullanıcı adı uzunluğu sınırı nedir?

Böyle bir şey yok. Gelecekteki kullanımlarınızı içerebilecek yalnızca “kullanımınız” vardır. Bunların ne olduğu hakkında hiçbir fikrimiz yok.

• Hangi karakterlerden kaçınılmalı?

Bu, hangi bilgisayar sistemiyle uğraştığınıza bağlı olacaktır. Örneğin, Windows, kullanıcı adında bir süre ile ilgili herhangi bir sorun yaşamamaktadır. Aslında, UPN bir süre sağlayan bir e-posta adresi gibi biçimlendirilir.

Diğer düşüncelerim:

• Kullanıcılarınızın sormasına izin vermeyin - onlara standardın ne olduğunu söyleyin ve gereksinimler değiştikçe standartta değişiklik yapmalarını isteyen işletmeye açılın (bireysel kullanıcılar değil).
• Standartta bir "istisna politikası" yapın, böylece başkan yardımına dahil olmak zorunda kalmadan kötü Susan Penington ve Mary Utt'a (yukarıdaki yorumlardan) yardımcı olabilirsiniz. BT'nin iyi görünmesini sağlayın, değil mi?

Tecrübelerim, yeterince büyük bir işletme için verdiğiniz kararların her zaman sorun yaşayacağı yönünde olmuştur. Bugün çalışıyor olsa bile, her zaman yarın uyguladığınız önceki standartla ilgili problemleri olan bir sistem vardır (uzunluk sorunları, karakter sorunları, vb.).

Firstname.Lastname için basmanın e-posta ile ilgili olup olmadığını ve mutlaka giriş adlarını belirlediğinden emin olun. Kullanıcının oturum açarken "jsmith" yerine "John.Smith" yazmak istediğine inanmakta zorlanırdım, ancak "John.Smith@company.com" istediği fikrine çok daha fazla satıyorum. "e-posta adresi olarak. @Mfinni'nin belirttiği gibi, kullanıcıların her zaman birden fazla e-posta takma adı, iletme vb. İçin çoklu seçeneklere sahip olma seçeneği vardır.

Unix ve Linux sistemleri için, {firstInitial} {soyadı} açıkça idealdir.

...

Bu hesapla ilişkili addan açıkça anlaşılması gereken sebeplerden dolayı.

Platformlar arasında adlandırma standartlarını belirlerken dikkat edilmesi gereken nokta, ps'deki Linux'taki (ve muhtemelen diğer Unix işletim sistemlerinde) özel bir kozmetik sorun. Bunu umursuyor veya umursamıyor olabilirsiniz (ama bunu beklemeyen birine endişe verici olabilir ... Bu konuda güvenlik görevlileri dolandı).

UID sütunu bir kullanıcı adının yalnızca 8 karakterine kadar gösterecektir. Kullanıcı adı 8 karakterden uzunsa, gerçek sayısal UID'yi yazdırmaya geçecektir. Bunu, KULLANICI alanını içeren özel bir ps sütun formatı alarak, ancak SADECE KULLANICI son sütunsa (deneysel testimden) elde edebilirsiniz.

Çoğu insan muhtemelen bunu umursamıyor, ancak ps çıkış işleminin bir tür işlemini gerçekleştiriyorsanız ve gerçek kullanıcı adlarının görünmesini bekliyorsanız, adınızın uzunluğuna dikkat etmelisiniz (aksi halde kodunuza kesmek zorunda kalacaksınız) ps doğru şeyi yapmak için).

Örneğin:

İşte tam biçim listesi için varsayılan sütun biçimi. Kullanıcı kimliğimin sayısal biçimde olduğunu unutmayın, çünkü kullanıcı adım> 8 karakterdir.

[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

Özel bir sütun biçimi kullanarak yeniden oluşturalım. KULLANICI sütununu eklediğime dikkat edin. Bunun sayısal biçimde de olduğuna dikkat edin.

[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'i satırın sonuna götürelim. "Doğru" çıktıya genişler.

[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

Ancak, sütun listesinin sonuna yeni bir şey eklediğimizde, sayısal forma geri döner.

[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

[adın bazı harfleri] [soyadın bazı harfleri] [nnn]

foreg: Eğer isim Bill Gates ise, ' biga00 ' veya bilgat000 kullanabilirsiniz.

Bir sonraki gişe kapıları gelirse, onun için 'biga01' veya bilgat001 'olacaktır.

Operasyon, İdare ve Bakım (OAM) bakış açısından, kullanıcı adının kolayca ayırt edilmesi gerekir. Bununla birlikte, iş açısından, kullanıcı adı (a / k / a e-posta takma adı) başkaları tarafından kolayca hatırlanmalı veya hatırlanmalıdır.

Gibi olabilir:

• first.last.index@domain
• İlk (ilk) .last.index @ alan