Soru LDAP'de tam olarak bir DN DN nedir?


LDAP sunucularına bağlanan ve sorguları çalıştıran çeşitli kod parçaları yazdım ama her zaman bana voodoo olmuştur. Gerçekten anlamadığım bir şey, bir DN DN kavramıdır. İşte bir örnek kullanarak ldapsearch openldap komut satırı aracı. (Kimlik doğrulama eksikliğini dikkate almayın.)

ldapsearch -h 1.2.3.4 -D dc=example,dc=com [query]

Amaç ve işlevi nedir -D dc=example,dc=com bunun bir parçası mı? Neden dizin hiyerarşisindeki belirli bir yere bağlanmamız gerekiyor? Sorgularımın hangi bölümünün başvurması gerekir? Örneğin. dizinin kök düğümü ise dc=comve iki çocuğu var (dc=foo ve dc=bar), belki de sorgularımın dc=foo,dc=com alt ağaç ve değil dc=bar,dc=com alt ağaç?


12
2017-07-30 18:41


Menşei




Cevaplar:


Bağlama DN, yapmaya çalıştığınız şeyi yapmanıza izin vermek için LDAP içinde bağladığınız bir nesnedir. Bazı (birçok?) LDAP örneği, anonim bağlantılara izin vermez veya belirli işlemlerin anonim bağlarla yürütülmesine izin vermez, bu nedenle bu işlemi gerçekleştirmek için bir kimlik elde etmek üzere bir bindDN belirtmeniz gerekir.

Benzer teknik olmayan bir şekilde - ve evet bu bir esnektir - bir banka, içeri girmenize ve herhangi bir kimlik vermeden faiz oranlarına bakmanıza izin verir, ancak bir hesap açmak veya para çekmek için, bildikleri bir kimliğe sahip olmak - bu kimlik, bindDN'dir.


13
2017-07-30 18:48



BindDN her zaman dizindeki bir düğüme karşılık geliyor mu? Ya da keyfi bir dizge olabilir mi? - dirtside
Evet. Bir şifre özniteliği taşıyabilme veya başka bir şekilde doğrulanmasına izin verme yeteneğine sahip olan bir düğüme karşılık gelmelidir. - John


Arasında karıştırmayın BaseDN ve binddn.

BaseDN Bir aramanın başlangıç ​​noktasıdır. Aramaya başlayacağı yer. Oldukça açıklayıcı.

binddn DN temel olarak bir LDAP'ye karşı kimlik doğrulamak için kullandığınız kimlik bilgisidir. Bir bindDN kullanırken, genellikle onunla ilişkili bir şifre ile gelir.

Diğer bir deyişle, bir bindDN belirttiğinizde, LDAP ağacından gitmek için bu nesnenin güvenlik erişimini kullanıyorsunuzdur.

Şimdi dize = örnek, dc = com en iyi değil örnek Bir LDAP ağacı için bir "alan" olduğu için bir bindDN için. dC anlamına gelir etki alanı bileşeni ve her bir LDAP ağacı kendi kökünü dc = string, dc = string, biçiminde bir dizge ile tanımlar ... Ancak bu dizeler, ağacın geri kalanı gibi bir "yol" değildir.

Geçerli örnekler:

  • DC = örnek, dc = com
  • DC EtkiAlanım =
  • DC Avery, dc = uzun, dc = liste, dc = içinde, dc = etki =

Ancak, bu kök unsurlar bölünmezdir. Ağacın geri kalanı gibi bir yolu temsil eden birkaç unsur gibi görünüyorlar, ama onlar değil. Örneğin, son örnekte bir nesne DC = bölgesinin DC = etki mevcut değil.

C: "D: \ my \ folder \" gibi sürücüyü adlandırın. Oradaki her yol, gerçek dosya yolu \ my \ real \ yolunun doğru olması gibi kafa karıştırıcı olacak "D: \ my \ folder \ my \ real \ path" gibi bir şeye benzeyecek. Eh, bir LDAP'nin tabanı (kök), bir dizi dc = element ile aynı şekilde görünüyor.

İlgili bağlantı: http://docs.oracle.com/cd/E19199-01/816-6400-10/lsearch.html


21
2017-07-30 20:50



Bu gereksiz yere kafa karıştırıcı bir tasarıma benziyor, ama açıklamanız mantıklı. - dirtside
Evet katılıyorum. Kökünüzü isimlendirmek de bir yol gibi görünmek en iyi seçim değildir ama sanırım bunun nedenleri olmalı. Artık tüm DN'lerin neden bir dizi dc = bileşenleri ile bittiğini biliyorsunuz. =) - Marcelo