LDAP नीति

Apigee Edge दस्तावेज़ देखा जा रहा है.
Apigee X दस्तावेज़ पर जाएं.
जानकारी

यह क्या है

एलडीएपी नीति से यह सुविधा मिलती है:

  • पुष्टि करना: अनुरोध में दिए गए उपयोगकर्ता क्रेडेंशियल की पुष्टि, LDAP की सेवा देने वाली कंपनी के क्रेडेंशियल के हिसाब से की जाती है. LDAP नीति से आपको पुष्टि करने में काफ़ी मदद मिलती है. इससे आपको पासवर्ड के साथ किसी भी डीएन वैल्यू का इस्तेमाल करने की सुविधा मिलती है. चाहे आपकी पसंद की डीएन वैल्यू, अनुरोध में न हो. उदाहरण के लिए, मान लें कि पुष्टि करने के लिए आपको ईमेल / पासवर्ड का इस्तेमाल करना होगा. इसके लिए, ये विकल्प इस्तेमाल किए जा सकते हैं:
    • अगर ईमेल अनुरोध में है, तो उस ईमेल पते को LDAP पुष्टि के पासवर्ड के साथ इस्तेमाल किया जा सकता है.
    • अगर ईमेल, अनुरोध में नहीं है, लेकिन कोई दूसरा डीएन एट्रिब्यूट (जैसे कि फ़ोन नंबर) है, तो आपके पास LDAP से ईमेल पाने के लिए फ़ोन नंबर का इस्तेमाल करने का विकल्प है. इसके बाद, पुष्टि करने के लिए ईमेल / पासवर्ड का इस्तेमाल करें.
  • खास नाम (डीएन) वाली खोज: पुष्टि करने के अलावा, अनुरोध में किसी उपयोगकर्ता के एट्रिब्यूट की पहचान करने के लिए, LDAP नीति का इस्तेमाल किया जा सकता है, जैसे कि ईमेल. साथ ही, ऐसी क्वेरी भी की जा सकती है जो उस उपयोगकर्ता के लिए, LDAP से अन्य डीएन एट्रिब्यूट को फिर से हासिल करती हो. वापस पाया गया डीएन, वैरिएबल में सेव होता है.

LDAP नीति का इस्तेमाल तब करें, जब सुरक्षित संसाधनों का ऐक्सेस आपके LDAP प्रोवाइडर—जैसे कि आपके एडमिन उपयोगकर्ताओं, संगठन के उपयोगकर्ताओं, और डेवलपर तक सीमित होना चाहिए—खास तौर पर तब, जब OAuth टोकन का ऐक्सेस या तो ज़रूरी न हो या बहुत ज़्यादा वज़न का हो. इस नीति को एपीआई प्रॉक्सी फ़्लो में इस्तेमाल करने के लिए, डोमेन नेम का मेटाडेटा फिर से पाने के लिए भी बनाया गया है.

उदाहरण के लिए, आपके पास एपीआई कॉल को सिर्फ़ तब एक्ज़ीक्यूट करने की सुविधा होती है, जब एलडीएपी के लिए किसी उपयोगकर्ता की पुष्टि हो जाती है. इसके बाद, पुष्टि करने के बाद, उपयोगकर्ता के लिए डीएन (डोमेन नेम) एट्रिब्यूट का वैकल्पिक तौर पर डेटा हासिल किया जा सकता है.

ज़्यादा जानकारी के लिए, देखें:

सैंपल

उपयोगकर्ता नाम/पासवर्ड की पुष्टि करना

<Ldap name="4GLdapPolicy">
   <LdapResource>ldap1</LdapResource>
   <Authentication>
       <UserName ref="request.header.username"/>
       <Password ref="request.header.password"/>
       <Scope>subtree</Scope>
       <BaseDN ref="apigee.baseDN"></BaseDN> <!-- default is dc=apigee,dc=com -->
    </Authentication>
 </Ldap>

यह नमूना LDAP की सेवा देने वाली कंपनी के लिए पुष्टि करता है. यह नीति पुष्टि के लिए, अनुरोध वाले उपयोगकर्ता नाम और पासवर्ड को LDAP के पास भेजती है.

DN एट्रिब्यूट की पुष्टि करना

<Ldap name="LdapPolicy">
   <LdapResource>ldap1</LdapResource>
   <Authentication>
       <Password ref="request.header.password"/>
       <SearchQuery>mail={request.header.mail}</SearchQuery>
       <Scope>subtree</Scope>
       <BaseDN ref="apigee.baseDN"></BaseDN> <!-- default is dc=apigee,dc=com -->
    </Authentication>
 </Ldap>

यह नीति, अनुरोध के हेडर में मौजूद ईमेल के साथ उपयोगकर्ता का डीएन हासिल करती है. इसके बाद, अनुरोध के हेडर में दिए गए पासवर्ड से, LDAP के ज़रिए उपयोगकर्ता की पुष्टि की जाती है.

LDAP खोजा जा रहा है

<Ldap name="LdapPolicy">
    <!-- using a custom LDAP provider -->
    <LdapConnectorClass>com.custom.ldap.MyProvider</LdapConnectorClass>
    <LdapResource>MyLdap</LdapResource>
    <Search>
        <BaseDN ref="apigee.baseDN"></BaseDN> <!-- default is dc=apigee,dc=com -->
        <SearchQuery>mail={request.header.mail}</SearchQuery>
        <Attributes>
            <Attribute>address</Attribute>
            <Attribute>phone</Attribute>
            <Attribute>title</Attribute>
        </Attributes>
        <Scope></Scope> <!-- default is ‘subtree’ -->
    </Search>
</Ldap>

इस नीति में पसंद के मुताबिक LDAP प्रोवाइडर का रेफ़रंस दिया गया है. यह उपयोगकर्ता की पहचान करने के लिए, अनुरोध के हेडर में मौजूद ईमेल पते का इस्तेमाल करता है. इसके बाद, LDAP से उपयोगकर्ता के पता, फ़ोन, और टाइटल हासिल कर लेता है. वापस लाई गई डीएन एट्रिब्यूट किसी वैरिएबल में स्टोर किए जाते हैं. "नीति के हिसाब से वैरिएबल" देखें.

LDAP को खोजने और डीएन एट्रिब्यूट को वापस पाने के लिए, अनुरोध में एडमिन के क्रेडेंशियल शामिल होने चाहिए.

एलिमेंट का रेफ़रंस

LDAP नीति के एलिमेंट और एट्रिब्यूट के बारे में जानकारी नीचे दी गई है.

एलिमेंट

ब्यौरा

Ldap

पैरंट एलिमेंट के साथ नाम वाला एट्रिब्यूट जोड़ें, ताकि आप नीति का नाम डाल सकें.

LdapConnectorClass

किसी पसंद के मुताबिक LDAP प्रोवाइडर (यह सुविधा Apigee की नहीं है) के साथ LDAP नीति का इस्तेमाल करते समय, पूरी तरह क्वालिफ़ाइड LDAP कनेक्टर क्लास के बारे में बताएं. आपने इसी क्लास में Apigee का ExternalLdapConProvider इंटरफ़ेस लागू किया है.

LdapResource

LDAP संसाधन के एनवायरमेंट का नाम डालें. ज़्यादा जानकारी के लिए, LDAP संसाधन बनाना देखें.

BaseDN

एलडीएपी का बेस लेवल, जिसके तहत आपका पूरा डेटा मौजूद होता है. उदाहरण के लिए, Apigee के LDAP प्रोवाइडर में, सारा डेटा dc=apigee,dc=com से कम में होता है.

  • ref: इसका इस्तेमाल उस फ़्लो वैरिएबल के बारे में बताने के लिए करें जिसमें BaseDN वैल्यू मौजूद हो, जैसे कि apigee.baseDN. ref को साफ़ तौर पर BaseDN वैल्यू के बजाय प्राथमिकता दी जाती है. अगर ref और वैल्यू, दोनों को शामिल किया जाता है, तो ref को प्राथमिकता दी जाती है. अगर ref से रनटाइम के दौरान समस्या का पता नहीं चलता है, तो वैल्यू का इस्तेमाल किया जाता है.

Scope

  • object: पुष्टि करने या खोज करने की सुविधा सिर्फ़ LDAP के बेस लेवल पर होती है.
  • onelevel: पुष्टि करने या खोज करने की सुविधा, बेस लेवल से एक लेवल नीचे होती है.
  • सबट्री (डिफ़ॉल्ट): पुष्टि करने या खोज करने की सुविधा, बेस लेवल पर होती है और बार-बार आधार के नीचे होती है.

पुष्टि करना

Authentication

पुष्टि करने के आपके लागू किए गए तरीके के लिए पैरंट एलिमेंट.

UserName

खाली एलिमेंट, जो नीचे दिए गए एट्रिब्यूट में से कोई एक एट्रिब्यूट लेता है:

  • ref: अनुरोध में मौजूद उपयोगकर्ता नाम का रेफ़रंस, जैसे कि request.header.username
  • value: उपयोगकर्ता नाम

अगर उपयोगकर्ता नाम से पुष्टि नहीं की जा रही है या उपयोगकर्ता नाम को अनुरोध में शामिल नहीं किया गया है, तो आपको इस एलिमेंट को शामिल करने की ज़रूरत नहीं है.

अगर अनुरोध में उपयोगकर्ता नाम दिया गया है, लेकिन आपको उपयोगकर्ता नाम के अलावा किसी दूसरे DN एट्रिब्यूट से भी पुष्टि करनी है, जैसे कि ईमेल, तो पासवर्ड से जुड़ा ईमेल पता पाने के लिए, SearchQuery शामिल करें. LDAP नीति, उपयोगकर्ता नाम से जुड़े ईमेल पते के लिए LDAP की सुविधा देने वाली क्वेरी के लिए उपयोगकर्ता नाम का इस्तेमाल करती है, जिसका इस्तेमाल पुष्टि करने के लिए किया जाता है.

Password

खाली एलिमेंट, जो नीचे दिए गए एट्रिब्यूट में से कोई एक एट्रिब्यूट लेता है:

  • ref: अनुरोध में पासवर्ड के लिए रेफ़रंस, जैसे कि request.header.password
  • value: खुद एन्क्रिप्ट (सुरक्षित) किया गया पासवर्ड

SearchQuery

अगर आपको ईमेल जैसे उपयोगकर्ता नाम के अलावा, किसी दूसरे डीएन एट्रिब्यूट का इस्तेमाल करके पुष्टि करनी है, तो अनुरोध से डीएन एट्रिब्यूट (जैसे कि उपयोगकर्ता नाम) पाने के लिए, LDAP नीति को कॉन्फ़िगर करें. इसका इस्तेमाल LDAP में उपयोगकर्ता की पहचान करने, ईमेल फिर से पाने, और उपयोगकर्ता की पुष्टि करने के लिए किया जाता है.

उदाहरण के लिए, माना जा रहा है कि LDAP ईमेल पते को स्टोर करने के लिए एक "mail" एट्रिब्यूट के बारे में बताता है:

<SearchQuery>mail={request.header.mail}</SearchQuery>

खोजें

Search

आपके लागू किए गए खोज व्यवहार के लिए पैरंट एलिमेंट.

SearchQuery

अनुरोध या जवाब में मेटाडेटा वाले उपयोगकर्ता की पहचान करके, आप इस एलिमेंट का इस्तेमाल LDAP से उपयोगकर्ता के लिए अतिरिक्त DN एट्रिब्यूट पाने के लिए कर सकते हैं. उदाहरण के लिए, अगर अनुरोध में उपयोगकर्ता का ईमेल शामिल है और आपका LDAP, उपयोगकर्ता के ईमेल पते को सेव करने के लिए mail एट्रिब्यूट तय करता है, तो आप इस सेटिंग का इस्तेमाल करें:

<SearchQuery>mail={request.header.mail}</SearchQuery>

यह क्वेरी, अनुरोध में मौजूद ईमेल से मेल खाने वाले ईमेल के लिए, LDAP की खोज करती है. अब यह नीति, एट्रिब्यूट एलिमेंट के साथ उस उपयोगकर्ता के लिए अतिरिक्त डीएन एट्रिब्यूट हासिल कर सकती है.

Attributes

एक या उससे ज़्यादा <Attribute> एलिमेंट का इस्तेमाल करके, उस DN मेटाडेटा की पहचान करें जिसे आपको उपयोगकर्ता के लिए वापस लाना है. कम से कम एक एट्रिब्यूट का होना ज़रूरी है.

उदाहरण के लिए, SearchQuery से उपयोगकर्ता की पहचान होने के बाद, इस नीति के तहत अब उपयोगकर्ता के लिए डीएन एट्रिब्यूट के डेटा को फिर से हासिल किया जा सकता है. जैसे, पता, फ़ोन नंबर, और उपयोगकर्ता का टाइटल. इसका उदाहरण नीचे दिया गया है.

एट्रिब्यूट की वैल्यू, आपके LDAP में तय किए गए डीएन एट्रिब्यूट के नाम होते हैं.

<Attributes>
  <Attribute>address</Attribute>
  <Attribute>phone</Attribute>
  <Attribute>title</Attribute>
</Attributes>

इस्तेमाल की जानकारी

Private Cloud के लिए Apigee Edge की मदद से, एपीआई कॉल में LDAP की सेवा देने वाली कंपनी का फ़ायदा लिया जा सकता है. LDAP नीति की मदद से, ऐप्लिकेशन LDAP में स्टोर किए गए उपयोगकर्ताओं के क्रेडेंशियल की पुष्टि कर सकते हैं और आप LDAP से अलग-अलग नाम (DN) पा सकते हैं—मेटाडेटा या हर उपयोगकर्ता से जुड़े एट्रिब्यूट, जैसे कि ईमेल, पता, और फ़ोन नंबर. नतीजों में मिले डीएन को वैरिएबल में सेव किया जाता है, ताकि एपीआई प्रॉक्सी उसका इस्तेमाल आगे भी कर सके.

LDAP संसाधन बनाना

LDAP नीति, ऐसे LDAP संसाधन का इस्तेमाल करती है जिसे आपने Apigee Edge में बनाया है. एलडीएपी संसाधन, आपके एलडीएपी रिपॉज़िटरी के लिए कनेक्शन की जानकारी उपलब्ध कराता है.

LDAP संसाधनों को बनाने और मैनेज करने के लिए, नीचे दिए गए एपीआई और पेलोड का इस्तेमाल करें:

API

एक LDAP संसाधन या सूची (GET) बनाएं (POST) सभी LDAP संसाधन:

/v1/organizations/org_name/environments/environment/ldapresources

(GET), अपडेट (POST), और LDAP संसाधन मिटाएं (DELETE) के बारे में जानकारी पाएं:

/v1/organizations/org_name/environments/environment/ldapresources/ldap_resource_name

पेलोड

नीचे इस्तेमाल से जुड़ी टिप्पणियों के साथ एक्सएमएल पेलोड का एक नमूना दिया गया है.

<LdapResource name="ldap1">
  <Connection>
    <Hosts>
      <!-- port is optional: defaults to 389 for ldap:// and 636 for ldaps:// -->
      <Host port="636">foo.com</Host>
    </Hosts>
    <SSLEnabled>false</SSLEnabled> <!-- optional, defaults to false -->
    <Version>3</Version> <!-- optional, defaults to 3-->
    <Authentication>simple</Authentication> <!-- optional, only simple supported -->
    <ConnectionProvider>jndi|unboundid</ConnectionProvider> <!-- required -->
    <ServerSetType>single|round robin|failover</ServerSetType> <!-- not applicable for jndi -->
    <!-- If using a custom LDAP provider, the fully qualified class: -->
    <LdapConnectorClass>com.custom.ldap.MyProvider</LdapConnectorClass>
  </Connection>
  <ConnectPool enabled="true"> <!-- enabled is optional, defaults to true -->
    <Timeout>30000</Timeout> <!-- optional, in milliseconds; if not set, no timeout -->
    <Maxsize>50</Maxsize> <!-- optional; if not set, no max connections -->
    <Prefsize>30</Prefsize> <!-- optional; if not set, no pref size -->
    <Initsize></Initsize> <!-- optional; if not set, defaults to 1 -->
    <Protocol></Protocol> <!-- optional; if not set, defaults to 'ssl plain' -->
  </ConnectPool>
  <Admin>
    <DN>cn=manager,dc=apigee,dc=com</DN>
    <Password>secret</Password>
  </Admin>
</LdapResource>

कर्ल का उदाहरण: LDAP संसाधन बनाना

नीचे दिया गया उदाहरण ldap1 नाम का एक LDAP संसाधन बनाता है.

curl -X POST -H "Content-Type: application/xml" \
  https://api.enterprise.apigee.com/v1/organizations/myorg/environments/test/ldapresources \
  -u apigee_email:password -d \
  '<LdapResource name="ldap1">
    <Connection>
      <Hosts>
      <Host>foo.com</Host>
      </Hosts>
      <SSLEnabled>false</SSLEnabled>
      <Version>3</Version>
      <Authentication>simple</Authentication>
      <ConnectionProvider>unboundid</ConnectionProvider>
      <ServerSetType>round robin</ServerSetType>
    </Connection>
    <ConnectPool enabled="true">
      <Timeout>30000</Timeout>
      <Maxsize>50</Maxsize>
      <Prefsize>30</Prefsize>
      <Initsize></Initsize>
      <Protocol></Protocol>
    </ConnectPool>
    <Admin>
      <DN>cn=manager,dc=apigee,dc=com</DN>
      <Password>secret</Password>
    </Admin>
  </LdapResource>'

रिस्पॉन्स कोड

नीति की सफलता या असफलता के लिए, ये एचटीएमएल रिस्पॉन्स कोड दिखाए जाते हैं:

  • सफल: 200
  • फ़ेलियर: 401

प्राइवेट क्लाउड के लिए, Edge में पसंद के मुताबिक LDAP प्रोवाइडर का इस्तेमाल करना

पसंद के मुताबिक LDAP प्रोवाइडर का इस्तेमाल करना

Private Cloud के लिए Apigee Edge, एलडीएपी की सेवा देने वाली ऐसी कंपनी के साथ आता है जिसे एलडीएपी नीति से इंटरैक्ट करने के लिए, पहले से ही कॉन्फ़िगर किया गया है. हालांकि, अगर आपने पसंद के मुताबिक LDAP प्रोवाइडर का इस्तेमाल किया है, तो आपको उस कंपनी को LDAP नीति के साथ काम करने के लिए चालू करना होगा. इसके लिए, यह तरीका अपनाएं:

  1. अपनी LDAP सेवा देने वाली कंपनी की क्लास में, ExternalLdapConProvider इंटरफ़ेस लागू करें.
    public interface ExternalLdapConProvider {
      void doAuthentication(LdapBean LlapBean, String userDN, String password, String baseDN);
    
      void doSearchAndAuthentication(LdapBean LlapBean, String password, String baseDN, String query, int scope);
    
      Collection<Map<String, String[]>> doSearch(LdapBean LlapBean, String query,
        String baseDN, Collection<String> requiredAttributes, int scope);
    
      void closeConnections();
    }
  2. नीति कॉन्फ़िगरेशन (अगले सेक्शन) के <LdapConnectorClass> में, एलडीएपी की सुविधा देने वाली अपनी पसंद के मुताबिक, पूरी तरह क्वालिफ़ाइड क्लास का नाम जोड़ें.
  3. यह फ़ाइल डाउनलोड करें: custom-ldap.jar_.zip. (शायद आपको राइट-क्लिक करके इस रूप में सेव करें चुनना पड़े.)
  4. इसे अनज़िप करें.
  5. कस्टम-ldap.jar फ़ाइल को अपने एनवायरमेंट में जोड़ें और पक्का करें कि यह आपके क्लासपाथ में मौजूद हो.
  6. अपने LDAP प्रोवाइडर के लिए एक एनवायरमेंट संसाधन बनाएं. एलडीएपी नीति के <LdapResource> एलिमेंट में, एनवायरमेंट के रिसॉर्स का नाम इस्तेमाल किया जाएगा.

Java के लिए UnबाउंडID LDAP SDK का इस्तेमाल करना

LDAP नीति के साथ UnबाउंडID LDAP SDK का इस्तेमाल किया जा सकता है, लेकिन आपको पहले 2.3.1 वर्शन डाउनलोड करना होगा और इसे अपने हर Message प्रोसेसर के क्लासपाथ में जोड़ना होगा.

LDAP नीति के साथ UnबाउंडID LDAP SDK का इस्तेमाल करने के लिए:

  1. ब्राउज़र खोलें और UnबाउंडID LDAP SDK के लिए Sourceforge फ़ाइल रिपॉज़िटरी पर जाएं:
    https://sourceforge.net/projects/ldap-sdk/files/
  2. SDK टूल का 2.3.1 (SE या स्टैंडर्ड वर्शन) वर्शन ढूंढें और उस वर्शन के लिए ZIP फ़ाइल डाउनलोड करें. उदाहरण के लिए, "unबाउंडid-ldapsdk-2.3.1-se.zip" डाउनलोड करें.
  3. SDK टूल की ZIP फ़ाइल से JAR फ़ाइल निकालें, जैसा कि यहां दिए गए उदाहरण में दिखाया गया है:
    unzip -j -d ~/tmp ~/Downloads/unboundid-ldapsdk-2.3.1-se.zip unboundid-ldapsdk-2.3.1-se/unboundid-ldapsdk-se.jar

    यह निर्देश सिर्फ़ JAR फ़ाइल को ~/tmp डायरेक्ट्री में एक्सट्रैक्ट करता है. यह, -j के साथ डायरेक्ट्री स्ट्रक्चर को ड्रॉप करता है. हालांकि, ऐसा करना ज़रूरी नहीं है.

  4. हर मैसेज प्रोसेसर नोड पर:
    1. JAR फ़ाइल को, Message प्रोसेसर की /opt/apigee/edge-gateway/lib/thirdparty डायरेक्ट्री में कॉपी करें.
    2. अगर ज़रूरी हो, तो Apigee को उपयोगकर्ता को JAR फ़ाइल की अनुमति दें, ताकि मैसेज प्रोसेस करने वाली कंपनी उसे ऐक्सेस कर सके.
    3. Edge, /opt/apigee/edge-gateway/lib/thirdparty डायरेक्ट्री में मौजूद तीसरे पक्ष की सभी लाइब्रेरी को क्लासपाथ में जोड़ता है.

    4. मैसेज प्रोसेसर को रीस्टार्ट करें:
      /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

फ़्लो वैरिएबल

SearchQuery से पॉप्युलेट किए गए LDAP नीति वैरिएबल के बारे में यहां बताया गया है.

वैरिएबल

ब्यौरा

ldap.policyName.execution.success

नीति लागू होने के बाद, इस फ़्लो वैरिएबल की वैल्यू "सही" या "गलत" होती है. यह वैल्यू, नतीजे के आधार पर होती है.

ldap.policyName.search.result[index].
  attribute.attrName[index]=value

इस वैरिएबल का सुविधाजनक फ़ॉर्मैट, खास तौर पर इंडेक्स: एक से ज़्यादा एट्रिब्यूट के साथ-साथ कई वैल्यू वाले एट्रिब्यूट को शामिल करता है. इंडेक्स, 1 से शुरू होने वाली संख्या है. अगर कोई इंडेक्स नंबर नहीं दिया गया है, तो डिफ़ॉल्ट इंडेक्स नंबर 1 होता है.

अगर नीति पता, फ़ोन, और ईमेल दिखाती है, तो इन वैरिएबल का इस्तेमाल करके पहला एट्रिब्यूट और वैल्यू फिर से हासिल की जा सकती है:

ldap.policyName.search.result.attribute.address
ldap.policyName.search.result.attribute.phone
ldap.policyName.search.result.attribute.email

अगर आपको खोज के नतीजों में, तीसरे पता वाला एट्रिब्यूट शामिल करना है, तो आपको इसका इस्तेमाल करना होगा:

ldap.policyName.search.result[3].attribute.address

अगर किसी एट्रिब्यूट में एक से ज़्यादा वैल्यू हैं (उदाहरण के लिए, अगर किसी उपयोगकर्ता के पास एक से ज़्यादा ईमेल पते हैं), तो आपको इस तरह के नतीजों से दूसरा ईमेल पता फिर से हासिल करना होगा:

ldap.policyName.search.result.attribute.mail[2]

गड़बड़ी कोड

Edge की नीतियों से मिली गड़बड़ियां, एक जैसे फ़ॉर्मैट में होती हैं जैसा कि गड़बड़ी कोड के रेफ़रंस में बताया गया है.

इस नीति में इन गड़बड़ी कोड का इस्तेमाल किया जाता है:

गड़बड़ी कोड मैसेज
InvalidAttributeName Invalid attribute name {0}.
InvalidSearchBase Search base can not be empty.
InvalidValueForPassword Invalid value for password field. It can not be empty.
InvalidSearchScope Invalid scope {0}. Allowed scopes are {1}.
InvalidUserCredentials Invalid user credentials.
InvalidExternalLdapReference Invalid external ldap reference {0}.
LdapResourceNotFound Ldap resource {0} not found.
BaseDNRequired Base DN required.
OnlyReferenceOrValueIsAllowed Only value or reference is allowed for {0}.
AttributesRequired At least one attribute required for search action.
UserNameIsNull User name is null.
SearchQueryAndUserNameCannotBePresent Both search query and username can not be present in the authentication action. Please specify either one of them.