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

ਉਨ੍ਹਾਂ ਪੜਾਵਾਂ ਨੂੰ ਵੱਖਰਾ ਰੱਖਣਾ ਹੀ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਅਜਿਹੇ ਲੈਪਟਾਪ 'ਤੇ ਖ਼ਤਮ ਹੋਣ ਤੋਂ ਰੋਕਦਾ ਹੈ ਜੋ ਸਫਲਤਾਪੂਰਵਕ ਸ਼ਾਮਲ ਹੋ ਗਿਆ ਅਤੇ ਵਰਤਿਆ ਨਹੀਂ ਜਾ ਸਕਦਾ।

ਜੁੜਨ ਤੋਂ ਪਹਿਲਾਂ: ਐਡੀਸ਼ਨ, ਸਥਾਨਕ ਪ੍ਰਸ਼ਾਸਕ, DNS

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

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

ਘੜੀ ਵੀ ਜਾਂਚੋ। Kerberos ਸਮੇਂ ਦੇ ਫ਼ਰਕ ਨੂੰ ਬਰਦਾਸ਼ਤ ਨਹੀਂ ਕਰਦਾ, ਅਤੇ ਇੱਕ ਮਹੀਨਾ ਔਫਲਾਈਨ ਰਿਹਾ ਲੈਪਟਾਪ ਉਲਝਾਉਣ ਵਾਲੀਆਂ ਸ਼ਾਮਲ ਹੋਣ ਦੀਆਂ ਗ਼ਲਤੀਆਂ ਦਾ ਆਮ ਸਰੋਤ ਹੈ।

ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਡੋਮੇਨ ਲੱਭਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਸਿਰਫ਼ ਪਿੰਗ ਨਹੀਂ

ਸ਼ਾਮਲ ਹੋਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਤੋਂ ਪਹਿਲਾਂ ਡੋਮੇਨ ਦਾ LDAP SRV ਰਿਕਾਰਡ ਹੱਲ ਕਰੋ। ad.corp.example ਨਾਂ ਵਾਲੇ ਉਦਾਹਰਨ ਇੱਕ-ਡੋਮੇਨ ਵਾਤਾਵਰਨ ਲਈ, ਕਵੈਰੀ ਇਹ ਹੈ:

Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.ad.corp.example

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

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

ਸ਼ਾਮਲ ਹੋਣਾ ਚਲਾਓ ਅਤੇ ਗ਼ਲਤੀ ਪੜ੍ਹੋ

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

ਜੇ ਉਸੇ ਨਾਂ ਦੀ ਵਸਤੂ ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਹੈ, ਤਾਂ ਇਸ ਨੂੰ ਪ੍ਰਤੀਕਿਰਿਆਵੱਸ ਨਾ ਮਿਟਾਓ। ਇਹ ਪਹਿਲਾਂ ਤੋਂ ਤਿਆਰ ਖਾਤਾ ਹੋ ਸਕਦਾ ਹੈ, ਅਤੇ netjoin ਕਠੋਰਤਾ ਮਾਲਕੀ ਅਤੇ ਨੀਤੀ ਅਨੁਸਾਰ ਕੁਝ ਮੁੜ-ਵਰਤੋਂ ਮਾਮਲਿਆਂ ਨੂੰ ਸੀਮਤ ਕਰਦੀ ਹੈ। ਡਾਇਰੈਕਟਰੀ ਮਾਲਕ ਨੂੰ ਵਸਤੂ ਦੀ ਜਾਂਚ ਜਾਂ ਸੁਧਾਰ ਕਰਨ ਲਈ ਕਹੋ।

ਸਫਲ ਸ਼ਾਮਲ ਹੋਣਾ ਮੱਧ ਬਿੰਦੂ ਹੈ, ਆਖ਼ਰੀ ਰੇਖਾ ਨਹੀਂ। ਅਗਲਾ ਕਦਮ ਉਹ ਹੈ ਜੋ ਵਰਤੋਂਕਾਰ ਅਸਲ ਵਿੱਚ ਜਾਂਚਦਾ ਹੈ।

ਪਹਿਲੇ ਡੋਮੇਨ ਸਾਈਨ-ਇਨ ਦੀ ਯੋਜਨਾ ਬਣਾਓ

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

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

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

ਸਥਾਨਕ ਰਿਕਵਰੀ ਪਹੁੰਚ ਰੱਖੋ

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

ਤੁਸੀਂ ਜੋ ਸਾਬਤ ਕੀਤਾ ਉਹ ਲਿਖੋ: SRV ਹੱਲ, DC ਤੱਕ ਪਹੁੰਚ, ਸ਼ਾਮਲ ਹੋਣ ਦੀ ਗ਼ਲਤੀ, ਪਹਿਲੇ ਲੌਗਆਨ ਦਾ ਤਰੀਕਾ ਅਤੇ ਰਿਕਵਰੀ ਖਾਤਾ। ਉਹ ਰਿਕਾਰਡ ਹੀ ਦੁਹਰਾਉਣ ਯੋਗ ਬਿਲਡ ਅਤੇ ਸਿਰਫ਼ ਦਫ਼ਤਰ ਵਿੱਚ ਕੰਮ ਕਰਨ ਵਾਲੇ ਲੈਪਟਾਪ ਵਿਚਕਾਰ ਫ਼ਰਕ ਹੈ।

ਸੰਬੰਧਿਤ ਲੇਖ