ਇੱਕ ਮਹੀਨਾ ਆਫ਼ਲਾਈਨ ਰਹਿਣ ਤੋਂ ਬਾਅਦ ਡੋਮੇਨ ਟਰੱਸਟ ਫੇਲ? ਪਹਿਲਾਂ ਜਾਂਚੋ

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

ਗਲਤੀ ਟਰੱਸਟ ਵਰਗੀ ਲੱਗਦੀ ਹੈ, ਪਰ ਤਿੰਨ ਅਵਸਥਾਵਾਂ ਇੱਕੋ ਜਿਹੀਆਂ ਹਨ

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

AD ਰੈਪਲਿਕੇਸ਼ਨ ਸਿਹਤ ਚੌਥਾ ਨਿਰੀਖਣ ਹੈ, ਅਤੇ ਇਹ ਇਸ ਵਰਕਸਟੇਸ਼ਨ ਬਾਰੇ ਬਿਲਕੁਲ ਨਹੀਂ ਹੈ। ਇਹ ਡੋਮੇਨ ਕੰਟਰੋਲਰਾਂ ਵਿਚਕਾਰ ਸਹਿਮਤੀ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ, ਅਤੇ ਸਿਹਤਮੰਦ ਰੈਪਲਿਕੇਸ਼ਨ ਡੈਸ਼ਬੋਰਡ ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ ਕਿ ਇਸ ਮਸ਼ੀਨ ਦਾ ਸਥਾਨਕ ਸੀਕ੍ਰੇਟ ਇਸਦੇ ਕੰਪਿਊਟਰ ਖਾਤੇ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ।

ਜਾਣਿਆ-ਪਛਾਣਿਆ 30 ਦਿਨਾਂ ਦਾ ਡਿਫ਼ਾਲਟ ਇੱਕ ਤਬਦੀਲੀ ਨੀਤੀ ਹੈ, ਆਫ਼ਲਾਈਨ ਸਮਾਪਤੀ ਦੀ ਸਮਾਂ-ਸੀਮਾ ਨਹੀਂ। Microsoft ਦਾ ਮਸ਼ੀਨ-ਖਾਤਾ ਪਾਸਵਰਡ ਬਾਰੇ ਸਪੱਸ਼ਟੀਕਰਨ ਤਾਲਮੇਲ ਵਾਲੀ ਤਬਦੀਲੀ ਪ੍ਰਕਿਰਿਆ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ, ਅਤੇ ਸੰਸਥਾ ਵੱਖਰਾ ਅੰਤਰਾਲ ਸੰਰਚਿਤ ਕਰ ਸਕਦੀ ਹੈ।

VPN ਆਈਕਨ ਸੁਰੱਖਿਅਤ ਚੈਨਲ ਬਾਰੇ ਕੁਝ ਵੀ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ

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

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

nltest /dsgetdc:corp.example.com
Test-ComputerSecureChannel -Verbose

DNS ਸਰਵਰ, ਹੱਲ ਕੀਤਾ ਕੰਟਰੋਲਰ ਅਤੇ ਗਲਤੀ ਦਾ ਸਹੀ ਪਾਠ ਲਿਖੋ। ਕਨੈਕਟਡ ਹੋਣ ਦੀ ਰਿਪੋਰਟ ਕਰਨ ਵਾਲਾ VPN ਕਲਾਇੰਟ ਦੱਸਦਾ ਹੈ ਕਿ ਸੁਰੰਗ ਮੌਜੂਦ ਹੈ, ਇਹ ਨਹੀਂ ਕਿ ਡੋਮੇਨ ਮਾਰਗ ਕੰਮ ਕਰਦਾ ਹੈ। Kerberos ਪੋਰਟ 'ਤੇ ਜਵਾਬ ਦੇਣ ਵਾਲਾ ਪਰ ਡਾਇਰੈਕਟਰੀ ਪੋਰਟ 'ਤੇ ਨਾ ਦੇਣ ਵਾਲਾ ਕੰਟਰੋਲਰ ਫਾਇਰਵਾਲ ਦਾ ਨਤੀਜਾ ਹੈ, ਟਰੱਸਟ ਦਾ ਨਹੀਂ।

ਸੁਧਾਰਨ ਤੋਂ ਪਹਿਲਾਂ ਸਦੱਸ ਦੀ ਜਾਂਚ ਕਰੋ

ਅਧਿਕਾਰਤ Windows ਡੋਮੇਨ ਸਦੱਸ 'ਤੇ, Test-ComputerSecureChannel -Verbose ਮਸ਼ੀਨ ਅਤੇ ਡੋਮੇਨ ਵਿਚਕਾਰ ਚੈਨਲ ਦੀ ਸਿਰਫ਼-ਪੜ੍ਹਨ ਜਾਂਚ ਹੈ। ਇਸਨੂੰ ਉਸ ਮਸ਼ੀਨ ਦੇ ਸੰਦਰਭ ਵਿੱਚ ਚਲਾਓ ਜਿਸਦੀ ਤੁਸੀਂ ਜਾਂਚ ਕਰ ਰਹੇ ਹੋ, ਡੋਮੇਨ ਕੰਟਰੋਲਰ ਤੋਂ ਨਹੀਂ, ਕਿਉਂਕਿ ਉਸਦੀ ਭੂਮਿਕਾ ਅਤੇ ਰਿਕਵਰੀ ਨਿਯਮ ਵੱਖਰੇ ਹਨ। ਪਾਸ ਜਾਂ ਫੇਲ ਸ਼ਬਦ ਦੀ ਥਾਂ ਆਉਟਪੁੱਟ ਅਤੇ ਐਗਜ਼ਿਟ ਸਥਿਤੀ ਸੰਭਾਲੋ। ਜੇ ਉਸ ਬਿਲਡ ਵਿੱਚ cmdlet ਨਹੀਂ ਹੈ, ਤਾਂ ਮਾਡਿਊਲ ਵੱਖਰੀ ਸਮੱਸਿਆ ਹੈ।

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

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

ਸਿਰਫ਼ ਉਹੀ ਸੰਬੰਧ ਸੁਧਾਰੋ ਜੋ ਤੁਸੀਂ ਸਾਬਤ ਕੀਤਾ

ਇੱਕ ਵਾਰ ਕਨੈਕਟੀਵਿਟੀ ਸਥਿਰ ਹੋ ਜਾਵੇ ਅਤੇ ਪ੍ਰਸ਼ਾਸਕ ਪੁਸ਼ਟੀ ਕਰ ਦੇਵੇ ਕਿ ਸੁਧਾਰ ਢੁਕਵਾਂ ਹੈ, ਤਾਂ ਅਧਿਕਾਰਤ ਪ੍ਰਮਾਣ-ਪੱਤਰਾਂ ਨਾਲ cmdlet ਦਾ -Repair ਮੋਡ ਸਦੱਸ ਵਰਕਸਟੇਸ਼ਨ ਲਈ ਇੱਕ ਸਮਰਥਿਤ ਕਾਰਵਾਈ ਹੈ। ਇਹ ਸੰਬੰਧ ਬਦਲਦਾ ਹੈ, ਅਤੇ ਇਹ ਹੋਰ ਸਿਰਫ਼-ਪੜ੍ਹਨ ਜਾਂਚ ਨਹੀਂ ਹੈ।

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

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

ਫੇਲ ਹੋਣ 'ਤੇ ਕੀ ਜਾਂਚਣਾ ਹੈ

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

ਅਸਥਾਈ ਤੌਰ 'ਤੇ ਸਫਲ ਰੀਸੈਟ ਲਾਭਦਾਇਕ ਰਿਕਵਰੀ ਸਬੂਤ ਹੈ, ਪਰ ਇਹ ਸਬੂਤ ਨਹੀਂ ਕਿ ਰੁਕ-ਰੁਕ ਕੇ ਚੱਲਣ ਵਾਲੇ VPN ਨੇ ਮੂਲ ਅਸੰਗਤੀ ਪੈਦਾ ਕੀਤੀ। ਕਾਰਨ ਕਦੇ ਹਟਾਇਆ ਗਿਆ ਜਾਂ ਨਹੀਂ, ਇਹ ਅਗਲੀ ਘਟਨਾ ਦੱਸੇਗੀ।

ਕੰਟਰੋਲਰ, DNS ਸਰਵਰ ਅਤੇ ਜਾਂਚ ਦਾ ਆਉਟਪੁੱਟ ਟਿਕਟ ਵਿੱਚ ਲਿਖੋ। ਉਹੀ ਰਿਕਾਰਡ ਅਸਲ ਟਰੱਸਟ ਫੇਲ ਨੂੰ ਡੋਮੇਨ ਨਾ ਲੱਭ ਸਕਣ ਵਾਲੇ ਲੈਪਟਾਪ ਤੋਂ ਵੱਖ ਕਰਦਾ ਹੈ।