woluminy, drukarki, kolejki drukowania itd. Posiadają one zazwyczaj ogólne nazwy (Common Name) oznaczane symbolem CN.
Obiekty umieszczane w danej jednostce organizacyjnej (OU) powinny być zgrupowane zgodnie z przynależnością do grupy roboczej, czyli zatrudnionych pracowników i współużywanych przez nich zasobów: drukarek, programów, plików z danymi.
Jak już wspomniano, rozmaite obiekty mogą być umiejscowione w różnych kontenerach, które z kolei mogą się zawierać w innych kontenerach itd. Może się, rzecz jasna, zdarzyć sytuacja, w której istnieć będą dwa obiekty zupełnie od siebie niezależne ale posiadające tę samą nazwę. Na przykład dwóch użytkowników, pracujących w dwóch różnych działach firmy posiada identyfikator TOMASZ. Ponieważ pracują gdzie indziej, administrator umieścił ich w różnych kontenerach, reprezentujących działy (jednostki organizacyjne) firmy: SERWIS i BIURO. Obaj użytkownicy, mimo iż tak samo nazwani, mają określone inne prawa dostępu do plików zawartych w woluminach. Mają też inne prawa do wszystkich pozostałych obiektów NDS, w tym do siebie nawzajem (przykładowo TOMASZ z BIURA może nie wiedzieć o istnieniu drugiego TOMASZA ani nawet kontenera, w którym tamten jest zawarty).
W sytuacji takiej jak w opisanym przykładzie, mamy do czynienia z faktem, że każdy z opisywanych użytkowników znajduje się w innym kontekście. Kontekst to inaczej pozycja obiektu w strukturze hierarchicznej NDS, przy czym dotyczy to nie tylko użytkowników ale także wszystkich pozostałych obiektów. Pojęcie kontekstu jest więc podobne do pojęcia ścieżki w hierarchicznej strukturze katalogów systemu DOS. Tak jak ścieżka w DOS-ie jednoznacznie określa, o który katalog lub plik chodzi, tak kontekst precyzuje, w którym miejscu struktury NDS dany obiekt się znajduje. Odwołanie do obiektu jest poprawne, jeżeli polega na wyspecyfikowaniu jego pełnego kontekstu (tj. ścieżki zawierającej listę wszystkich kontenerów dzielących dany obiekt od [Root]).
Kontekstem bieżącym jest aktualna pozycja w NDS (na tej samej zasadzie jak bieżący katalog w systemie plików). Z pozycji tej dostępne są bezpośrednio inne obiekty NDS (pod warunkiem posiadania prawa dostępu do nich) zawarte w tym samym kontenerze i aby się do nich odwołać nie trzeba podawać pełnej ścieżki; wystarczy podanie nazwy obiektu (czyli adresu względnego).
Wszelkie obiekty istniejące w strukturze NDS muszą mieć swoją nazwę, albo inaczej mówiąc własność Name. Musi być ona obowiązkowo wypełniona wartością już przy tworzeniu obiektu. Zasady nazywania obiektów są dosyć proste. Ich nazwy nie mogą być dłuższe niż 64 znaki (oprócz dwuznakowych nazw kontenera typu Country, które są międzynarodowym skrótem nazwy kraju), w jednym kontenerze nie może wystąpić więcej niż jeden obiekt o tej samej nazwie, a do tworzenia nazwy można użyć dowolnego znaku specjalnego. Małe i duże litery nie są rozróżniane, a znak spacji jest utożsamiany ze znakiem podkreślenia. Dopuszczalne (ale nie zalecane) jest także używanie znaków narodowych.
Nieco bardziej skomplikowana jest zasada odwoływania się do obiektu przez podanie ścieżki do niego. Tutaj analogie z systemem DOS przestają obowiązywać. O ile bowiem w systemie DOS pełna ścieżka zaczyna się od podania "korzenia" czyli szczytu struktury hierarchicznej i dalej katalogów "w dół" tej struktury, tak w NDS specyfikacja kontekstu zaczyna się od nazwy obiektu i dalej wymieniane są kolejne nazwy kontenerów w kierunku szczytu struktury (obiektu [Root] jako ostatniego zazwyczaj nie wymienia się). Dodatkowo przyjęto założenia, że każdy obiekt może być poprzedzony kwalifikatorem typu właściwego dla niego (czyli C, O, OU albo CN) ze znakiem '=', a kolejne nazwy odpowiadające kolejnym poziomom oddziela się znakiem kropki. Jeżeli specyfikacja kontekstu jest pełna, czyli zawiera całą ścieżkę w NDS, to całą