ਉਹ LDAP ਪਾਸਵਰਡ ਗਲਤੀ ਸ਼ਾਇਦ ਵਰਤੋਂਕਾਰ ਦੇ ਪਾਸਵਰਡ ਦੀ ਨਾ ਹੋਵੇ
bind ਦੀ ਅਸਫਲਤਾ ਸੇਵਾ ਖਾਤੇ ਜਾਂ ਖੋਜ ਖੇਤਰ ਤੋਂ ਆ ਸਕਦੀ ਹੈ, ਵਰਤੋਂਕਾਰ ਤੋਂ ਨਹੀਂ। ਕਿਸੇ ਦਾ ਪਾਸਵਰਡ ਰੀਸੈਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ bind ਨੂੰ ਵੱਖ ਕਰੋ।
ਲੌਗ ਸਿਰਫ਼ ਇਹ ਕਹਿੰਦਾ ਹੈ ਕਿ bind ਨਾਮਨਜ਼ੂਰ ਹੋਇਆ, ਤਾਂ ਵਰਤੋਂਕਾਰ ਦਾ ਪਾਸਵਰਡ ਰੀਸੈਟ ਕਰਨਾ ਪਹਿਲਾ ਗ਼ਲਤ ਕਦਮ ਹੈ। ਡਾਇਰੈਕਟਰੀ ਪਲੱਗਇਨ ਨਾਲ ਇੱਕ ਲੌਗਇਨ ਵਿੱਚ ਇੱਕ ਤੋਂ ਵੱਧ bind ਹੁੰਦੇ ਹਨ, ਅਤੇ ਨਾਮਨਜ਼ੂਰੀ ਉਸ ਸੇਵਾ ਖਾਤੇ ਦੀ ਹੋ ਸਕਦੀ ਹੈ ਜੋ ਖੋਜ ਕਰਦਾ ਹੈ। ਉਸ ਸਥਿਤੀ ਵਿੱਚ ਵਰਤੋਂਕਾਰ ਦੇ ਪ੍ਰਮਾਣ ਰੀਸੈਟ ਕਰਨ ਨਾਲ ਕੁਝ ਨਹੀਂ ਬਦਲਦਾ। ਇਹ ਉਸ ਵਿਅਕਤੀ ਨੂੰ ਵੀ ਬਾਹਰ ਕਰ ਦਿੰਦਾ ਹੈ ਜੋ ਕਦੇ ਸਮੱਸਿਆ ਨਹੀਂ ਸੀ।
ਇੱਕ ਲੌਗਇਨ, ਕਈ bind
ਸਮਰਪਿਤ ਡਾਇਰੈਕਟਰੀ ਖਾਤੇ ਵਾਲਾ ਸੰਰਚਨਾ ਆਮ ਤੌਰ 'ਤੇ ਕ੍ਰਮ ਵਿੱਚ ਚਾਰ ਕਦਮ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਲੌਗਇਨ ਖ਼ਤਮ ਕਰ ਸਕਦਾ ਹੈ।
connect to the directory and establish the configured TLS protection
bind as the configured service account
search for the user entry using the search base and filter
open a second connection and bind as that user, then evaluate groupsਪਲੱਗਇਨ ਆਪਣਾ ਵਰਤੋਂਕਾਰ ਪ੍ਰਮਾਣੀਕਰਨ ਕਨੈਕਸ਼ਨ ਉਸੇ ਸਹਾਇਕ ਰਾਹੀਂ ਬਣਾਉਂਦਾ ਹੈ ਜੋ ਪਹਿਲਾ ਕਨੈਕਸ਼ਨ ਸੰਭਾਲਦਾ ਹੈ, ਇਸ ਲਈ ਉਹ ਸਹਾਇਕ ਕਨੈਕਟ ਕਰਦੇ ਸਮੇਂ, TLS ਗੱਲਬਾਤ ਵੇਲੇ ਜਾਂ ਸੇਵਾ ਖਾਤੇ ਵਜੋਂ bind ਕਰਦੇ ਸਮੇਂ ਅਸਫਲ ਹੋ ਸਕਦਾ ਹੈ। ਪਾਸਵਰਡ ਬਾਰੇ ਉੱਚ-ਪੱਧਰੀ ਸੰਦੇਸ਼ ਬਾਅਦ ਵਿੱਚ ਬਣਦਾ ਹੈ, ਅਤੇ ਇਸ ਵਿੱਚ ਇਹ ਨਹੀਂ ਆਉਂਦਾ ਕਿ ਕਿਹੜੀ ਪਛਾਣ ਸ਼ਾਮਲ ਸੀ। ਇਸ ਲਈ ਸਿਰਫ਼ ਗਲਤੀ ਦਾ ਪਾਠ ਤੁਹਾਨੂੰ ਨਹੀਂ ਦੱਸ ਸਕਦਾ ਕਿ ਵਰਤੋਂਕਾਰ ਨਾਮਨਜ਼ੂਰ ਹੋਇਆ ਜਾਂ ਸੇਵਾ ਖਾਤਾ।
ਸੰਦੇਸ਼ ਤੋਂ ਪਹਿਲਾਂ ਦੀਆਂ ਲਾਈਨਾਂ ਪੜ੍ਹੋ, ਅਤੇ ਅਸਫਲਤਾ ਵਾਪਰਨ ਦਾ ਪਲ ਨੋਟ ਕਰੋ। ਸ਼ੁਰੂ ਵਿੱਚ, ਕਿਸੇ ਵੀ ਵਰਤੋਂਕਾਰ ਦੇ ਆਉਣ ਤੋਂ ਪਹਿਲਾਂ ਨਾਮਨਜ਼ੂਰੀ ਸੰਰਚਿਤ ਖਾਤੇ ਜਾਂ ਅੰਤਿਮ ਬਿੰਦੂ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੀ ਹੈ। ਸਫਲ ਖੋਜ ਤੋਂ ਬਾਅਦ ਸਿਰਫ਼ ਇੱਕ ਵਿਅਕਤੀ ਲਈ ਦਿਖਣ ਵਾਲੀ ਨਾਮਨਜ਼ੂਰੀ ਉਸ ਵਿਅਕਤੀ ਦੀ ਐਂਟਰੀ ਜਾਂ ਖਾਤਾ ਸਥਿਤੀ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੀ ਹੈ।
ਗਲਤੀ ਨੂੰ ਪਛਾਣ ਨਾਲ ਜੋੜੋ
ਵਿਹਾਰਕ ਨਿਯਮ ਇਹ ਹੈ ਕਿ ਤਿੰਨ ਗੱਲਾਂ ਇਕੱਠੀਆਂ ਦਰਜ ਕਰੋ: ਕਦੋਂ ਅਸਫਲ ਹੋਇਆ, ਕਿਹੜਾ ਓਪਰੇਸ਼ਨ ਚੱਲ ਰਿਹਾ ਸੀ ਅਤੇ ਕਿਹੜੀ ਪਛਾਣ ਪੇਸ਼ ਕੀਤੀ ਗਈ। ਉਸ ਤਿੱਕੜੀ ਤੋਂ ਬਿਨਾਂ, ਸਿਰਫ਼ ਆਖਰੀ ਵਾਕ ਰੱਖਣ ਵਾਲੇ ਲੌਗ ਵਿੱਚ ਦੋ ਬਹੁਤ ਵੱਖਰੀਆਂ ਖਰਾਬੀਆਂ ਇੱਕੋ ਜਿਹੀਆਂ ਦਿਖਦੀਆਂ ਹਨ।
| What the log shows | Identity likely refused | First thing to check |
|---|---|---|
| Failure at start-up, no user yet | Service account | DN, password, expiry, lockout |
| Search returns nothing | None, the search scope is wrong | Search base and filter |
| Failure only for one user | That user's entry | Entry state, bind DN, group rules |
ਜੇ ਸੰਰਚਿਤ ਖਾਤਾ ਅਸਫਲ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਕਿਸੇ ਵੀ ਵਰਤੋਂਕਾਰ ਰਿਕਾਰਡ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਉਸ ਖਾਤੇ ਅਤੇ ਕਨੈਕਸ਼ਨ ਦੀ ਜਾਂਚ ਕਰੋ। ਜੇ ਸਫਲ ਖੋਜ ਤੋਂ ਬਾਅਦ ਵਰਤੋਂਕਾਰ ਦਾ bind ਅਸਫਲ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਖੋਜ ਵੱਲੋਂ ਵਾਪਸ ਕੀਤੀ ਐਂਟਰੀ ਦੀ ਜਾਂਚ ਕਰੋ, ਨਾ ਕਿ ਉਸ ਦੀ ਜਿਸ ਦੀ ਤੁਸੀਂ ਆਸ ਕੀਤੀ ਸੀ। ਦੋਵੇਂ ਰਾਹ ਸਿਰਫ਼ ਇੱਕ ਸੰਦੇਸ਼ ਸਾਂਝਾ ਕਰਦੇ ਹਨ। ਲਿਖੋ ਕਿ ਤੁਸੀਂ ਕਿਸ ਨੂੰ ਬਾਹਰ ਰੱਖਿਆ, ਕਿਉਂਕਿ ਅਗਲਾ ਵਿਅਕਤੀ ਬਿਲਕੁਲ ਉਹੀ ਪੁੱਛੇਗਾ।
ਵਿਲੱਖਣ ਨਾਮ ਡੇਟਾ ਹੈ, ਅੰਦਾਜ਼ਾ ਨਹੀਂ
ਨਾਮ ਦਾ ਹਿੱਸਾ ਅਣਪਛਾਤਾ ਲੱਗਣ ਕਰਕੇ ਬਦਲਣਾ ਚੱਲ ਰਹੀ ਸੰਰਚਨਾ ਤੋੜਨ ਦਾ ਆਮ ਤਰੀਕਾ ਹੈ। Active Directory ਵਿੱਚ ਵਰਤੋਂਕਾਰ ਆਬਜੈਕਟ ਦੀ ਡਿਫ਼ਾਲਟ ਥਾਂ Users ਨਾਮ ਦਾ ਕੰਟੇਨਰ ਹੈ, ਅਤੇ ਕੰਟੇਨਰ ਸਮਾਨ ਨਾਮ ਵਾਲੀ ਸੰਗਠਨਾਤਮਕ ਇਕਾਈ ਵਰਗੀ ਉਹੀ ਕਿਸਮ ਦੀ ਆਬਜੈਕਟ ਨਹੀਂ ਹੈ।
ਡਾਇਰੈਕਟਰੀ ਪ੍ਰਬੰਧਕ ਤੋਂ ਖਾਤੇ ਦਾ ਅਸਲ ਵਿਲੱਖਣ ਨਾਮ ਪੁੱਛੋ, ਜਾਂ ਇਸਨੂੰ ਆਬਜੈਕਟ ਤੋਂ ਹੀ ਪੜ੍ਹੋ। ਹੇਠਾਂ ਦਿੱਤੇ ਦੋਵੇਂ ਆਪਣੀ-ਆਪਣੀ ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ ਸਹੀ ਹੋ ਸਕਦੇ ਹਨ, ਇਸ ਲਈ ਕਿਸੇ ਨੂੰ ਵੀ ਯਾਦ ਤੋਂ ਟਾਈਪ ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ।
CN=VPN Bind,CN=Users,DC=corp,DC=example
CN=VPN Bind,OU=Service Accounts,DC=corp,DC=exampleਭੇਜਣਾ ਜਾਂ ਨਾਮ ਬਦਲਣਾ ਉਸ ਮੁੱਲ ਨੂੰ ਬਦਲਦਾ ਹੈ ਜਦੋਂ ਕਿ ਖਾਤਾ ਅਤੇ ਪਾਸਵਰਡ ਵੈਧ ਰਹਿੰਦੇ ਹਨ, ਇਸ ਲਈ ਪਿਛਲੀ ਤਿਮਾਹੀ ਵਿੱਚ ਚੱਲੀ ਸੰਰਚਨਾ ਇਸ ਵਾਰ ਅਸਫਲ ਹੋ ਸਕਦੀ ਹੈ, ਬਿਨਾਂ ਕਿਸੇ ਦੇ ਪ੍ਰਮਾਣ ਛੂਹਣ ਦੇ। ਕਿਸੇ ਵੀ ਮੁੜ-ਸੰਗਠਨ ਤੋਂ ਬਾਅਦ ਸੰਰਚਿਤ ਸਤਰ ਦੀ ਡਾਇਰੈਕਟਰੀ ਦੀ ਮੌਜੂਦਾ ਵਿਸ਼ੇਸ਼ਤਾ ਨਾਲ ਤੁਲਨਾ ਕਰੋ। ਸ਼ਾਂਤ ਮਾਈਗ੍ਰੇਸ਼ਨ ਤੋਂ ਬਾਅਦ ਵੀ ਕਰੋ, ਸਿਰਫ਼ ਰਿਪੋਰਟ ਕੀਤੇ ਰੁਕਾਵਟ ਤੋਂ ਬਾਅਦ ਨਹੀਂ।
ਖੋਜ ਅਧਾਰ ਸੇਵਾ ਖਾਤਾ ਨਹੀਂ ਹੈ
bind ਪਛਾਣ ਅਤੇ ਖੋਜ ਅਧਾਰ ਵੱਖ-ਵੱਖ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦਿੰਦੇ ਹਨ: ਪਲੱਗਇਨ ਕਿਸ ਵਜੋਂ ਪ੍ਰਮਾਣਿਤ ਕਰਦਾ ਹੈ ਅਤੇ ਲੋਕਾਂ ਨੂੰ ਕਿੱਥੇ ਖੋਜਦਾ ਹੈ। ਸਫਲ bind ਤੋਂ ਬਾਅਦ ਕੋਈ ਮੇਲ ਖਾਂਦਾ ਵਰਤੋਂਕਾਰ ਨਾ ਮਿਲਣਾ ਖੇਤਰ, ਫਿਲਟਰ ਜਾਂ ਪੜ੍ਹਨ ਦੀ ਇਜਾਜ਼ਤ ਦੀ ਸਮੱਸਿਆ ਹੈ, ਅਤੇ ਖਾਤੇ ਦਾ ਵਿਲੱਖਣ ਨਾਮ ਵਰਤੋਂਕਾਰਾਂ ਦੇ ਅਧਾਰ ਨਾਲ ਬਦਲਣ ਨਾਲ ਇਸ ਵਿੱਚ ਕੁਝ ਨਹੀਂ ਬਦਲਦਾ।
ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਸੇਵਾ ਨੇ ਤੁਹਾਡਾ ਸੰਪਾਦਿਤ ਸੰਰਚਨਾ ਲੋਡ ਕੀਤਾ ਹੈ ਅਤੇ ਇਸਦਾ ਅੰਤਿਮ ਬਿੰਦੂ, TLS ਭਰੋਸਾ ਅਤੇ ਪ੍ਰਮਾਣੀਕਰਨ ਮੋਡ ਚੱਲ ਰਹੀ ਪ੍ਰਬੰਧਕੀ ਜਾਂਚ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ। ਦੂਜੇ ਖਾਤੇ ਨਾਲ ਜਾਂ ਦੂਜੇ ਡੋਮੇਨ ਕੰਟਰੋਲਰ ਵਿਰੁੱਧ ਹੱਥੀਂ ਖੋਜ ਬਰਾਬਰ ਦਾ ਪ੍ਰਯੋਗ ਨਹੀਂ ਹੈ।
ਸੰਗ੍ਰਹਿਤ ਭੇਦ ਦੀ ਜਾਂਚ ਕਰੋ, ਅਤੇ ਖਾਤਾ ਸਮਰੱਥ, ਮਿਆਦ ਪੁੱਗਿਆ ਜਾਂ ਲਾਕ ਹੈ ਜਾਂ ਨਹੀਂ ਇਹ ਪਾਸਵਰਡ ਕਿਤੇ ਵੀ ਛਾਪੇ ਬਿਨਾਂ ਜਾਂਚੋ। ਮਿਆਦ ਪੁੱਗਣਾ ਖੁੰਝਣਾ ਆਸਾਨ ਹੈ ਕਿਉਂਕਿ ਖਾਤਾ ਉਸ ਦਿਨ ਤੱਕ ਕੰਮ ਕਰਦਾ ਰਹਿੰਦਾ ਹੈ ਜਦੋਂ ਉਹ ਕੰਮ ਕਰਨਾ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ। ਅਸੰਬੰਧਿਤ ਸੇਵਾ ਤੋਂ ਵਿਰਾਸਤ ਵਿੱਚ ਮਿਲਿਆ ਲਾਕ ਵੀ ਉੰਨਾ ਹੀ ਸ਼ਾਂਤ ਹੈ। ਇਹਨਾਂ ਦੋਵਾਂ ਸਥਿਤੀਆਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਸੇਵਾ ਖਾਤੇ ਦਾ ਨਾਮ ਲੈਣ ਵਾਲਾ ਸੰਦੇਸ਼ ਨਹੀਂ ਬਣਾਉਂਦੀ।
ਗਰੁੱਪ ਨਿਯਮ ਆਖਰ ਵਿੱਚ ਆਉਂਦੇ ਹਨ
bind ਸਫਲ ਹੋਣ ਤੋਂ ਬਾਅਦ ਅਧਿਕਾਰ ਚੱਲਦਾ ਹੈ, ਇਸ ਲਈ ਗਰੁੱਪ ਜਾਂਚ bind ਅਸਫਲਤਾ ਦਾ ਕਾਰਨ ਨਹੀਂ ਹੋ ਸਕਦੀ, ਅਤੇ ਗਰੁੱਪ ਲੋੜ ਹਟਾਉਣ ਨਾਲ ਇਹ ਠੀਕ ਨਹੀਂ ਹੋ ਸਕਦੀ। ਜੇ ਲੌਗਇਨ ਹੁਣ ਗਰੁੱਪ ਪੜਾਅ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ, ਤਾਂ ਬਚੀ ਸਮੱਸਿਆ ਮੈਂਬਰਸ਼ਿਪ ਹੈ, ਪ੍ਰਮਾਣ ਨਹੀਂ।
ਗਲਤੀ ਗਾਇਬ ਕਰਨ ਲਈ ਸੇਵਾ ਖਾਤੇ ਨੂੰ ਵਿਆਪਕ ਡਾਇਰੈਕਟਰੀ ਅਧਿਕਾਰ ਦੇਣਾ ਪੂਰੀ ਤੈਨਾਤੀ ਦੀ ਪਹੁੰਚ ਨੀਤੀ ਬਦਲ ਦਿੰਦਾ ਹੈ। ਇਸਨੂੰ ਆਪਣੀ ਸਮੀਖਿਆ ਵਾਲਾ ਸੁਰੱਖਿਆ ਫ਼ੈਸਲਾ ਮੰਨੋ, ਨਾ ਕਿ ਅਜੇ ਕਿਸੇ ਪਛਾਣ ਨੂੰ ਨਾ ਸੌਂਪੇ ਸੰਦੇਸ਼ ਦਾ ਹੱਲ।