OpenVPN ਵਿੱਚ LDAP ਪ੍ਰਮਾਣਿਕਤਾ ਕੰਮ ਕਰਦੀ ਹੈ ਪਰ ਸਮੂਹ ਜਾਂਚ ਫੇਲ੍ਹ ਹੁੰਦੀ ਹੈ: ਕਿੱਥੇ ਵੇਖਣਾ ਹੈ

ਪ੍ਰਮਾਣਿਕਤਾ ਪਾਸ ਹੋ ਸਕਦੀ ਹੈ ਜਦੋਂ ਕਿ ਸਮੂਹ ਜਾਂਚ ਸਾਰਿਆਂ ਨੂੰ ਰੱਦ ਕਰਦੀ ਹੈ। Authorization ਬਲਾਕ, ਮੈਂਬਰਸ਼ਿਪ ਗੁਣ ਅਤੇ ਡਾਇਰੈਕਟਰੀ ਐਂਡਪੌਇੰਟ ਇੱਕ-ਇੱਕ ਕਰਕੇ ਵੇਖੋ।

ਕ੍ਰੈਡੈਂਸ਼ੀਅਲ ਪਾਸ ਹੁੰਦੇ ਹਨ, ਟਨਲ ਉੱਪਰ ਆਉਣਾ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਸੈਸ਼ਨ ਪਾਸਵਰਡ ਬਾਰੇ ਨਹੀਂ ਸਗੋਂ ਸਮੂਹ ਬਾਰੇ ਸੁਨੇਹੇ ਨਾਲ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ। ਇਹ ਸੰਜੋਗ ਫੇਲ੍ਹਤਾ ਨੂੰ LDAP ਪਲੱਗਇਨ ਦੇ ਕੰਮ ਦੇ ਦੂਜੇ ਅੱਧ ਵਿੱਚ ਰੱਖਦਾ ਹੈ: ਬਾਈਂਡ ਅਤੇ ਪਾਸਵਰਡ ਜਾਂਚ ਸਫਲ ਹੋਈ, ਅਤੇ ਉਸ ਤੋਂ ਬਾਅਦ ਵਾਲਾ ਮੈਂਬਰਸ਼ਿਪ ਫੈਸਲਾ ਨਹੀਂ ਹੋਇਆ। ਦੋਵੇਂ ਅੱਧ ਇੱਕੋ ਕਨਫਿਗਰੇਸ਼ਨ ਬਲਾਕ ਵਿੱਚੋਂ ਪੜ੍ਹਦੇ ਹਨ, ਇਸ ਲਈ ਇੱਕ ਥਾਂ ਦੀ ਸੋਧ ਦੂਜੇ ਨੂੰ ਅਛੂਤਾ ਛੱਡ ਸਕਦੀ ਹੈ। ਜਿਸ ਲੌਗ ਲਾਈਨ ਵਿੱਚ ਕਦਮ ਦਾ ਨਾਮ ਹੈ ਉੱਥੋਂ ਸ਼ੁਰੂ ਕਰੋ, ਉਸ ਖਾਤੇ ਤੋਂ ਨਹੀਂ ਜਿਸ ਨਾਲ ਤੁਸੀਂ ਸੰਜੋਗ ਨਾਲ ਜਾਂਚ ਕਰ ਰਹੇ ਹੋ।

ਰੱਦ ਕਰਨ ਨੂੰ ਅਧਿਕਾਰ ਦਾ ਜਵਾਬ ਮੰਨੋ

ਪਲੱਗਇਨ ਸੇਵਾ ਬਾਈਂਡ ਕਰਦਾ ਹੈ, ਖਾਤਾ ਲੱਭਦਾ ਹੈ, ਦਿੱਤਾ ਪਾਸਵਰਡ ਪ੍ਰਮਾਣਿਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਪੁੱਛਦਾ ਹੈ ਕਿ ਕੀ ਉਹ ਖਾਤਾ ਕਿਸੇ ਮਨਜ਼ੂਰ ਸਮੂਹ ਦਾ ਹੈ। ਇਹ ਚਾਰ ਵੱਖਰੇ ਕੰਮ ਹਨ, ਅਤੇ ਸਿਰਫ਼ ਆਖਰੀ ਸਮੂਹਾਂ ਬਾਰੇ ਹੈ। ਇਸ ਲਈ ਸਫਲ ਬਾਈਂਡ ਤੋਂ ਬਾਅਦ ਆਉਣ ਵਾਲਾ ਰੱਦ ਪਾਸਵਰਡ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ, ਭਾਵੇਂ ਕਲਾਇੰਟ ਆਮ ਪ੍ਰਮਾਣਿਕਤਾ ਗਲਤੀ ਦਿਖਾਏ। ਕਨਫਿਗਰੇਸ਼ਨ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਪਲੱਗਇਨ ਦਾ ਲੌਗ ਪੱਧਰ ਵਧਾਉਣਾ ਹੀ ਆਉਟਪੁੱਟ ਵਿੱਚ ਉਨ੍ਹਾਂ ਚਾਰਾਂ ਨੂੰ ਵੱਖ ਕਰਦਾ ਹੈ।

ਸਮੂਹ ਮੁਲਾਂਕਣ ਆਪ ਲੱਭੋ। ਜਦੋਂ ਕੋਈ ਸਮੂਹ ਕਵੈਰੀ ਬਿਲਕੁਲ ਨਹੀਂ ਦਿਸਦੀ, ਤਾਂ ਅਧਿਕਾਰ ਬਲਾਕ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਿਆ ਜਾਂਦਾ, ਜਿਸ ਦਾ ਆਮ ਅਰਥ ਹੈ ਕਿ ਕੋਈ ਨਿਰਦੇਸ਼ ਆਪਣੇ ਮਾਲਕ ਬਲਾਕ ਤੋਂ ਬਾਹਰ ਹੈ ਜਾਂ ਲਾਜ਼ਮੀ ਵਿਕਲਪ ਗੁੰਮ ਹੈ। ਜਦੋਂ ਕਵੈਰੀ ਦਿਸਦੀ ਹੈ ਅਤੇ ਕੁਝ ਨਹੀਂ ਮੋੜਦੀ, ਤਾਂ ਐਂਡਪੌਇੰਟ ਜਾਂ ਫਿਲਟਰ ਤੁਹਾਡੇ ਭਾਵ ਨਾਲੋਂ ਵੱਖਰੇ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦੇ ਰਿਹਾ ਹੈ।

ਫੈਸਲਾ ਕਰੋ ਕਿ ਮੈਂਬਰਸ਼ਿਪ ਫਿਲਟਰ ਵਿੱਚ ਰਹਿੰਦੀ ਹੈ ਜਾਂ ਸਮੂਹ ਬਲਾਕ ਵਿੱਚ

ਦੋ ਸਮਰਥਿਤ ਰੂਪ ਹਨ, ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਮਿਲਾਉਣਾ ਹੀ ਉਹ ਤਰੀਕਾ ਹੈ ਜਿਸ ਨਾਲ ਚੱਲਦੀ ਕਨਫਿਗਰੇਸ਼ਨ ਚੱਲਣਾ ਬੰਦ ਕਰ ਦਿੰਦੀ ਹੈ। ਪਹਿਲਾ ਯੂਜ਼ਰ ਆਬਜੈਕਟ ਉੱਤੇ ਗੁਣ ਮੰਗ ਕੇ ਮੈਂਬਰਸ਼ਿਪ ਨੂੰ ਯੂਜ਼ਰ ਖੋਜ ਵਿੱਚ ਧੱਕਦਾ ਹੈ; ਦੂਜਾ ਯੂਜ਼ਰ ਖੋਜ ਨੂੰ ਉਵੇਂ ਛੱਡਦਾ ਹੈ ਅਤੇ ਪਲੱਗਇਨ ਨੂੰ ਬਾਅਦ ਵਿੱਚ ਸਮੂਹ ਆਬਜੈਕਟ ਲੱਭਣ ਦਿੰਦਾ ਹੈ। ਹਰ ਤੈਨਾਤੀ ਲਈ ਇੱਕ ਚੁਣੋ ਅਤੇ ਲਿਖੋ ਕਿ ਕਿਹੜਾ ਚੁਣਿਆ।

<Authorization>
    BaseDN       "OU=People,DC=example,DC=org"
    SearchFilter "(&(sAMAccountName=%u)(memberOf=CN=VPN Access,OU=Groups,DC=example,DC=org))"
    RequireGroup false
</Authorization>

ਉਸ ਰੂਪ ਵਿੱਚ ਫਿਲਟਰ ਸਭ ਕੁਝ ਤੈਅ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ RequireGroup false ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਨਹੀਂ ਤਾਂ ਪਲੱਗਇਨ ਉਸ ਸਮੂਹ ਆਬਜੈਕਟ ਨੂੰ ਲੱਭਣ ਜਾਂਦਾ ਹੈ ਜਿਸਦਾ ਫਿਲਟਰ ਨੇ ਕਦੇ ਜ਼ਿਕਰ ਨਹੀਂ ਕੀਤਾ। ਫਿਲਟਰ ਵਿੱਚਲਾ ਗੁਣ ਯੂਜ਼ਰ ਆਬਜੈਕਟ ਉੱਤੇ ਹੋਣਾ ਅਤੇ ਭਰਿਆ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਜੋ ਸਮੂਹਾਂ ਦੇ ਨੈਸਟਡ ਹੋਣ ’ਤੇ ਯਕੀਨੀ ਨਹੀਂ।

ਦੂਜਾ ਰੂਪ ਖੋਜ ਨੂੰ ਸਾਦਾ ਰੱਖਦਾ ਹੈ ਅਤੇ ਉਸ ਤੋਂ ਬਾਅਦ ਸਮੂਹ ਖੋਜ ਜੋੜਦਾ ਹੈ। ਸਮੂਹ ਆਬਜੈਕਟ ਦਾ ਸਪੱਸ਼ਟ ਨਾਮ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਪਲੱਗਇਨ ਯੂਜ਼ਰ ਦੀ ਤੁਲਨਾ ਉਨ੍ਹਾਂ ਮੈਂਬਰਾਂ ਨਾਲ ਕਰਦਾ ਹੈ ਜੋ ਡਾਇਰੈਕਟਰੀ ਉਸ ਲਈ ਮੋੜਦੀ ਹੈ। ਯੂਜ਼ਰ ਫਿਲਟਰ ਵਿੱਚ ਕੁਝ ਨਹੀਂ ਬਦਲਦਾ, ਜਿਸ ਨਾਲ ਇਹ ਰੂਪ ਤਦ ਜਾਂਚਣਾ ਸੌਖਾ ਹੋ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਸਮੂਹ ਕੋਈ ਹੋਰ ਟੀਮ ਸੰਭਾਲਦੀ ਹੈ।

<Authorization>
    BaseDN       "OU=People,DC=example,DC=org"
    SearchFilter "(sAMAccountName=%u)"
    RequireGroup true
    Group        "CN=VPN Access,OU=Groups,DC=example,DC=org"
</Authorization>

ਅੰਨ੍ਹੀ ਥਾਂ ਸਾਂਝੀ ਹੈ: ਸਾਦੀ ਮੈਂਬਰਸ਼ਿਪ ਤੁਲਨਾ ਨੈਸਟਡ ਸਮੂਹਾਂ ਨੂੰ ਫੈਲਾਉਂਦੀ ਨਹੀਂ, ਇਸ ਲਈ ਜਿਸ ਖਾਤੇ ਦੀ ਪਹੁੰਚ ਮਾਪੇ ਸਮੂਹ ਰਾਹੀਂ ਆਉਂਦੀ ਹੈ ਉਹ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਕਿ ਕੰਸੋਲ ਅਜੇ ਵੀ ਮੈਂਬਰਸ਼ਿਪ ਦਿਖਾਉਂਦਾ ਹੈ। Active Directory ਸਮੂਹ ਉੱਤੇ member ਪ੍ਰਗਟ ਕਰਦਾ ਹੈ, ਹੋਰ ਸਕੀਮਾਂ uniqueMember ਵਰਤਦੀਆਂ ਹਨ, ਅਤੇ ਗਲਤ ਗੁਣ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਨ ’ਤੇ ਗਲਤੀ ਦੀ ਥਾਂ ਖਾਲੀ ਨਤੀਜਾ ਆਉਂਦਾ ਹੈ।

ਉਹ ਐਂਡਪੌਇੰਟ ਚੁਣੋ ਜੋ ਸਮੂਹ ਆਬਜੈਕਟ ਰੱਖਦਾ ਹੈ

URL ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਪਲੱਗਇਨ ਕਿਹੜੀ ਡਾਇਰੈਕਟਰੀ ਨੂੰ ਪੁੱਛਦਾ ਹੈ, ਅਤੇ 389 ਪੋਰਟ ਉੱਤੇ ਡੋਮੇਨ ਕੰਟਰੋਲਰ ਸਿਰਫ਼ ਆਪਣੇ ਨਾਮਕਰਨ ਸੰਦਰਭ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ। 3268 ਪੋਰਟ ਉੱਤੇ ਗਲੋਬਲ ਕੈਟਾਲਾਗ ਪੂਰੇ ਜੰਗਲ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਸਿਰਫ਼-ਪੜ੍ਹਨ ਅਤੇ ਅੰਸ਼ਕ ਗੁਣ ਸੈੱਟ ਨਾਲ। ਜਦੋਂ ਖਾਤੇ ਇੱਕ ਡੋਮੇਨ ਵਿੱਚ ਹੋਣ ਅਤੇ VPN ਸਮੂਹ ਦੂਜੇ ਵਿੱਚ, ਤਾਂ ਇੱਕ-ਡੋਮੇਨ ਕਵੈਰੀ ਯੂਜ਼ਰ ਲੱਭ ਕੇ ਵੀ ਮੈਂਬਰਸ਼ਿਪ ਖੁੰਝਾ ਸਕਦੀ ਹੈ। URL ਨੂੰ ਕੈਟਾਲਾਗ ਪੋਰਟ ’ਤੇ ਲਿਜਾਣ ਨਾਲ ਰੱਦ ਹੱਲ ਹੁੰਦਾ ਹੈ ਉਹ ਇਹੀ ਸਥਿਤੀ ਹੈ, ਅਤੇ ਲੋਕ ਬਹੁਤ ਜ਼ਿਆਦਾ ਸਧਾਰਨਕਰਨ ਕਰਦੇ ਹਨ ਉਹ ਵੀ ਇਹੀ ਸਥਿਤੀ ਹੈ।

ਅੰਸ਼ਕ ਗੁਣ ਸੈੱਟ ਹੀ ਹੱਦ ਹੈ: ਜਿਸ ਗੁਣ ਨੂੰ ਕੈਟਾਲਾਗ ਨਹੀਂ ਰੱਖਦੀ ਉਸ ’ਤੇ ਫਿਲਟਰ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ, ਇਸ ਲਈ ਉਹੀ ਬਦਲਾਅ ਇੱਕ ਤੈਨਾਤੀ ਚਲਾ ਸਕਦਾ ਹੈ ਅਤੇ ਦੂਜੀ ਕੁਝ ਨਾ ਮੋੜੇ। ਬਲਾਕ ਦੁਬਾਰਾ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਐਂਡਪੌਇੰਟ ਅਸਲ ਯੂਜ਼ਰ ਅਤੇ ਸਮੂਹ ਲਈ ਸੱਚਮੁੱਚ ਕੀ ਮੋੜਦਾ ਹੈ। ਰੈਫਰਲ ਅਤੇ TLS ਫਿਰ ਵੱਖਰੇ ਵਿਸ਼ੇ ਹਨ, ਕਿਉਂਕਿ ਰੈਫਰਲ ਦਾ ਪਿੱਛਾ ਕਰਨਾ ਪੈਂਦਾ ਹੈ ਅਤੇ TLS ਮੰਗਣ ਵਾਲੇ ਐਂਡਪੌਇੰਟ ਨੂੰ ਮਿਲਦੀਆਂ ਟਰੱਸਟ ਫਾਈਲਾਂ ਚਾਹੀਦੀਆਂ ਹਨ।

ਖਾਤੇ ਦੀ ਸਥਿਤੀ ਅਤੇ ਖੋਜ ਘੇਰਾ ਆਪਣੇ-ਆਪਣੇ ਖੇਤਰਾਂ ਵਿੱਚ ਰੱਖੋ

ਨਿਸ਼ਕਿਰਿਆ ਝੰਡਾ ਫਿਲਟਰ ਵਿੱਚ ਆਉਂਦਾ ਹੈ, ਸਮੂਹ ਜਾਂਚ ਵਿੱਚ ਨਹੀਂ। Active Directory ਵਿੱਚ ਇਹ userAccountControl ਦਾ ਦੂਜਾ ਬਿੱਟ ਹੈ, ਅਤੇ ਉਸ ਸ਼ਰਤ ਤੋਂ ਬਿਨਾਂ ਵੈਧ ਪਾਸਵਰਡ ਵਾਲਾ ਨਿਸ਼ਕਿਰਿਆ ਖਾਤਾ ਪ੍ਰਮਾਣਿਤ ਹੁੰਦਾ ਹੈ ਅਤੇ ਫਿਰ ਸਮੂਹ ਕਦਮ ’ਤੇ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ, ਜੋ ਅਧਿਕਾਰ ਗਲਤੀ ਵਰਗਾ ਲੱਗਦਾ ਹੈ। ਖੋਜ ਘੇਰਾ ਅਧਾਰ DN ਵਿੱਚ ਆਉਂਦਾ ਹੈ, ਕਿਉਂਕਿ ਡੋਮੇਨ ਰੂਟ ਤੋਂ ਸ਼ੁਰੂ ਕਰਨਾ ਹੌਲੀ ਹੈ ਅਤੇ ਤੁਸੀਂ ਜਿਸ ਸੰਗਠਨਾਤਮਕ ਇਕਾਈ ਨੂੰ ਢਕਣਾ ਚਾਹੁੰਦੇ ਸੀ ਉਸ ਤੋਂ ਬਾਹਰਲੀਆਂ ਵਸਤੂਆਂ ਨਾਲ ਮੇਲ ਖਾ ਸਕਦਾ ਹੈ।

ਬਾਈਂਡ ਖਾਤੇ ਦੇ ਅਧਿਕਾਰ ਵੀ ਤੰਗ ਰੱਖੋ। ਵਿਸ਼ਾਲ ਡਾਇਰੈਕਟਰੀ ਅਧਿਕਾਰ ਗਲਤ ਕਨਫਿਗਰ ਕੀਤੇ ਫਿਲਟਰ ਨੂੰ ਸਫਲ ਕਵੈਰੀ ਬਣਾ ਦਿੰਦੇ ਹਨ ਅਤੇ ਕੋਈ ਖਾਤੇ ਦਾ ਆਡਿਟ ਨਾ ਕਰੇ ਜਦ ਤੱਕ ਗਲਤੀ ਲੁਕਾਉਂਦੇ ਹਨ। ਮੈਂਬਰਸ਼ਿਪ ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ ਹੀ ਬਦਲੋ, ਕਦੇ ਵੀ ਸਥਾਨਕ ਅਪਵਾਦ ਸੂਚੀ ਵਿੱਚ ਨਹੀਂ, ਤਾਂ ਜੋ ਪਹੁੰਚ ਹਟਾਉਣ ਲਈ ਖਾਤਾ ਨਿਸ਼ਕਿਰਿਆ ਕਰਨਾ ਹੀ ਕਾਫ਼ੀ ਹੋਵੇ। ਜੇ ਸਮੂਹ ਕੋਈ ਹੋਰ ਟੀਮ ਸੰਭਾਲਦੀ ਹੈ, ਤਾਂ ਉਸ ’ਤੇ ਫਿਲਟਰ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਉਸ ਗੁਣ ’ਤੇ ਸਹਿਮਤ ਹੋਵੋ ਜੋ ਉਹ ਭਰਦੇ ਹਨ।

ਤਿੰਨ ਖਾਤਿਆਂ ਨਾਲ ਨਤੀਜਾ ਸਾਬਤ ਕਰੋ

ਕਨਫਿਗਰੇਸ਼ਨ ਨੂੰ ਤਿੰਨ ਪਛਾਣਾਂ ’ਤੇ ਚਲਾਓ: ਮਨਜ਼ੂਰ ਮੈਂਬਰ, ਸਮੂਹ ਤੋਂ ਬਾਹਰ ਵੈਧ ਖਾਤਾ, ਅਤੇ ਨਿਸ਼ਕਿਰਿਆ ਕੀਤਾ ਖਾਤਾ। ਜੇ ਤਿੰਨੇ ਰੱਦ ਹੋਣ, ਬਾਈਂਡ ਜਾਂ ਸਮੂਹ ਕਵੈਰੀ ਟੁੱਟੀ ਹੈ; ਜੇ ਤਿੰਨੇ ਸਵੀਕਾਰ ਹੋਣ, ਕੋਈ ਸਮੂਹ ਸ਼ਰਤ ਲਾਗੂ ਹੀ ਨਹੀਂ ਹੋ ਰਹੀ। ਮਿਸ਼ਰਤ ਨਤੀਜਾ ਹੀ ਇੱਕੋ ਨਤੀਜਾ ਹੈ ਜੋ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਕਨਫਿਗਰੇਸ਼ਨ ਤੁਹਾਡੇ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹਾਲਾਤਾਂ ਨੂੰ ਵੱਖ ਕਰਦੀ ਹੈ।

ਪਲੱਗਇਨ ਨੂੰ ਦੋਸ਼ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਉਹੀ ਤਿੰਨ ਜਵਾਬ ਸਿੱਧੇ ਡਾਇਰੈਕਟਰੀ ਵਿੱਚੋਂ ਪੜ੍ਹੋ। ਪਹਿਲੀ ਕਵੈਰੀ ਉਹ ਸਮੂਹ ਗੁਣ ਦਿਖਾਉਂਦੀ ਹੈ ਜਿਸ ’ਤੇ ਫਿਲਟਰ ਨਿਰਭਰ ਹੈ, ਅਤੇ ਦੂਜੀ ਖਾਤਾ-ਨਿਯੰਤਰਣ ਮੁੱਲ ਦਿਖਾਉਂਦੀ ਹੈ। ਆਪਣਾ ਅਧਾਰ DN, ਖਾਤਾ ਅਤੇ ਐਂਡਪੌਇੰਟ ਭਰੋ:

ldapsearch -H ldap://dc01.example.org:3268 -x -D "[email protected]" -W -b "DC=example,DC=org" "(sAMAccountName=alice)" memberOf
ldapsearch -H ldap://dc01.example.org:3268 -x -D "[email protected]" -W -b "DC=example,DC=org" "(sAMAccountName=bob)" userAccountControl

ਜਿਸ ਯੂਜ਼ਰ ਦਾ memberOf ਖਾਲੀ ਮੁੜਦਾ ਹੈ ਉਹ ਡਾਇਰੈਕਟਰੀ ਦਾ ਤੱਥ ਹੈ, ਪਲੱਗਇਨ ਦੀ ਗਲਤੀ ਨਹੀਂ, ਅਤੇ ਨਿਸ਼ਕਿਰਿਆ ਕਰਨ ਤੋਂ ਬਾਅਦ ਵੀ ਪ੍ਰਮਾਣਿਤ ਹੋਣ ਵਾਲਾ ਖਾਤਾ ਦੱਸਦਾ ਹੈ ਕਿ ਫਿਲਟਰ ਵਿੱਚ ਖਾਤਾ-ਨਿਯੰਤਰਣ ਸ਼ਰਤ ਗੁੰਮ ਹੈ। ਪਹਿਲਾਂ ਉਹ ਸਬੂਤ ਠੀਕ ਕਰੋ, ਫਿਰ ਤਿੰਨ-ਖਾਤਾ ਪਰਖ ਦੁਬਾਰਾ ਚਲਾਓ। ਫੇਲ੍ਹ ਹੋਏ ਕਦਮ ਦਾ ਨਾਮ ਦੱਸਣ ਵਾਲੀ ਲੌਗ ਲਾਈਨ ਕਨਫਿਗਰੇਸ਼ਨ ਬਦਲਾਅ ਦੇ ਕੋਲ ਰੱਖੋ, ਤਾਂ ਜੋ ਅਗਲਾ ਵਿਅਕਤੀ ਖੋਜ ਦੁਹਰਾਏ ਬਿਨਾਂ ਅਧਿਕਾਰ ਨੂੰ ਪ੍ਰਮਾਣਿਕਤਾ ਤੋਂ ਵੱਖ ਕਰ ਸਕੇ।

ਸੰਬੰਧਿਤ ਲੇਖ