VPN ಪ್ರಮಾಣಪತ್ರ LDAP ಭಾಗವನ್ನು ರಕ್ಷಿಸುವುದಿಲ್ಲ

ಡೈರೆಕ್ಟರಿ ವಿರುದ್ಧ ರುಜುವಾತುಗಳನ್ನು ಪರಿಶೀಲಿಸುವ VPN ಲಾಗಿನ್ ಎರಡು ಪ್ರತ್ಯೇಕ ನೆಟ್‌ವರ್ಕ್ ಸಂಪರ್ಕಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ. ಬಳಕೆದಾರರ ಗೇಟ್‌ವೇ ಸಂಪರ್ಕವು VPN‌ನ ಸ್ವಂತ ಪ್ರಮಾಣಪತ್ರ ಮತ್ತು ಪ್ರೋಟೋಕಾಲ್ ಸಂರಚನೆಯಿಂದ ರಕ್ಷಿಸಲ್ಪಟ್ಟಿದೆ. ಗೇಟ್‌ವೇಯ ಡೈರೆಕ್ಟರಿ ಸಂಪರ್ಕವು ತನ್ನದೇ TLS ಸೆಟ್ಟಿಂಗ್‌ಗಳು, ತನ್ನದೇ ಟ್ರಸ್ಟ್ ಸ್ಟೋರ್ ಮತ್ತು ತನ್ನದೇ ವೈಫಲ್ಯ ವಿಧಾನಗಳನ್ನು ಹೊಂದಿರುವ ಇನ್ನೊಂದು ಸೆಷನ್. ಮೊದಲನೆಯ ಬಗ್ಗೆ ಯಾವುದೂ ಎರಡನೆಯ ಬಗ್ಗೆ ಯಾವುದನ್ನೂ ಖಾತರಿಪಡಿಸುವುದಿಲ್ಲ.

ಈ ಅಸಮಾನತೆಯೇ ಎನ್‌ಕ್ರಿಪ್ಟ್ ಆಗಿರುವಂತೆ ಕಾಣುವ ಮತ್ತು ಆದರೂ bind ಪಾಸ್‌ವರ್ಡ್ ಅನ್ನು ಬಯಲಿನಲ್ಲಿ ಕಳುಹಿಸುವ ಲಾಗಿನ್‌ನ ಹಿಂದಿನ ಕಾರ್ಯವಿಧಾನ.

ಎರಡು ಸಂಪರ್ಕಗಳು, ಎರಡು ನಂಬಿಕೆ ನಿರ್ಣಯಗಳು

ಹೊರ ಸೆಷನ್ ಎಂದರೆ ಬಳಕೆದಾರರು ನೋಡುವುದು: VPN ಹೋಸ್ಟ್‌ಹೆಸರಿಗೆ ಬದ್ಧವಾದ, ಕ್ಲೈಂಟ್‌ನಿಂದ ಮೌಲ್ಯೀಕರಿಸಲ್ಪಟ್ಟ, ದೃಢೀಕರಣದ ವಿನಿಮಯವನ್ನು ಒಯ್ಯುವ ಪ್ರಮಾಣಪತ್ರ. ಒಳ ಸೆಷನ್ ಗೇಟ್‌ವೇಯ ಒಳಗಿನ ಡೈರೆಕ್ಟರಿ ಕ್ಲೈಂಟ್‌ನದ್ದು, ಅದು ತನ್ನದೇ ಸಂಪರ್ಕವನ್ನು ತೆರೆದು TLS ಮಾತುಕತೆ ನಡೆಸುತ್ತದೆ ಅಥವಾ ಇಲ್ಲ. ಪ್ರತಿ ಕಡೆಯೂ ತಾನು ಮಾತನಾಡುವ ಎದುರಾಳಿಯನ್ನು ಬೇರೆ ಸಂರಚನಾ ಫೈಲ್‌ನ ವಸ್ತುವಿನಿಂದ ಮೌಲ್ಯೀಕರಿಸುತ್ತದೆ. ತಪ್ಪಾಗಿ ಸಂರಚಿಸಿದ ಒಳ ಭಾಗವು ಬಳಕೆದಾರರ ಕಡೆಯಿಂದ ಅಗೋಚರವಾಗಿ ಉಳಿಯುತ್ತದೆ, ಏಕೆಂದರೆ ಹೊರ ಭಾಗವು ಉದ್ದೇಶಿಸಿದಂತೆಯೇ ಕೆಲಸ ಮಾಡುತ್ತದೆ.

ಅದಕ್ಕೇ ವೈಫಲ್ಯವು ಗಟ್ಟಿಯಲ್ಲ, ಮೌನವಾಗಿದೆ. ಡೈರೆಕ್ಟರಿಯ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಎಂದಿಗೂ ಪರಿಶೀಲಿಸದ ಗೇಟ್‌ವೇ ಬಳಕೆದಾರರನ್ನು ಸರಿಯಾಗಿಯೇ ದೃಢೀಕರಿಸುತ್ತದೆ; ಅದು ಅವರನ್ನು ಪರಿಶೀಲಿಸದ ಚಾನೆಲ್ ಮೂಲಕ ಮಾತ್ರ ದೃಢೀಕರಿಸುತ್ತದೆ.

StartTLS ಮತ್ತು LDAPS, ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಆಯ್ಕೆಮಾಡಲಾಗಿದೆ

StartTLS ಸಾಮಾನ್ಯ LDAP ಆಗಿ ತೆರೆದು ಅಲ್ಲಿಯೇ ಉನ್ನತೀಕರಿಸಲ್ಪಡುತ್ತದೆ, ಸಾಮಾನ್ಯವಾಗಿ ಪೋರ್ಟ್ 389 ನಲ್ಲಿ. LDAPS ಸಂಪರ್ಕದೊಂದಿಗೇ TLS ಆರಂಭಿಸುತ್ತದೆ, ಸಾಮಾನ್ಯವಾಗಿ 636 ನಲ್ಲಿ. ಎರಡೂ ಕಾನೂನುಬದ್ಧ ಮತ್ತು ಅಡಾಪ್ಟರ್ ಡೈರೆಕ್ಟರಿ ನೀಡುವುದಕ್ಕೆ ಹೊಂದಿಕೆಯಾಗಬೇಕು. StartTLS ಕಡ್ಡಾಯ ಮಾಡುವುದು ಅದನ್ನು ಪ್ರಯತ್ನಿಸಿ ಉನ್ನತೀಕರಣ ವಿಫಲವಾದಾಗ ಮುಂದುವರಿಯುವುದಕ್ಕಿಂತ ಭಿನ್ನ, ಮತ್ತು ಅದೇ ವ್ಯತ್ಯಾಸದಲ್ಲಿ bind ಪಾಸ್‌ವರ್ಡ್ ಹೊರಬರಬಹುದು. ಕಟ್ಟುನಿಟ್ಟಿನ ಮೋಡ್ ಸಂರಚಿಸಿ, ಮತ್ತು ಪಾಸ್‌ವರ್ಡ್ bind ಗೆ ಅಸುರಕ್ಷಿತ ಪರ್ಯಾಯ ಮಾರ್ಗವನ್ನು ಅನುಮತಿಸಬೇಡಿ.

ldapsearch -H ldap://dc1.corp.example -ZZ -x -D "CN=VPN Bind,OU=Service Accounts,DC=corp,DC=example" -W -b "DC=corp,DC=example" "(sAMAccountName=example-user)" dn

-ZZ ಆಯ್ಕೆಯೇ ಪೂರ್ತಿ ವಿಷಯ: ಕ್ವೆರಿ ಉನ್ನತೀಕರಣವಿಲ್ಲದೆ ಮೌನವಾಗಿ ಮುಂದುವರಿಯುವ ಬದಲು ವಿಫಲವಾಗುತ್ತದೆ. ಆ ಸಾಲಿನ ಹೆಸರುಗಳು ಮತ್ತು ಖಾತೆಗಳು ಉದಾಹರಣೆಗಳು. OpenLDAP TLS ದಾಖಲೆ ಅದರ ಹಿಂದಿನ ಟ್ರಸ್ಟ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಒಳಗೊಳ್ಳುತ್ತದೆ.

LDAP ಕ್ಲೈಂಟ್ ಯಾವ ಟ್ರಸ್ಟ್ ಸ್ಟೋರ್ ಓದುತ್ತದೆ?

OpenLDAP ಕ್ಲೈಂಟ್ ಗ್ರಂಥಾಲಯವು ತನ್ನದೇ ಟ್ರಸ್ಟ್ ಸಂರಚನೆಯನ್ನು ಓದುತ್ತದೆ, ಅದು ಸಿಸ್ಟಂ ಫೈಲ್‌ನಿಂದಲೋ ಪ್ಲಗಿನ್-ನಿರ್ದಿಷ್ಟ ಸೆಟ್ಟಿಂಗ್‌ನಿಂದಲೋ ಆಗಿರಲಿ. VPN‌ನ CA ಸೂಚನೆ VPN ಸಹವರ್ತಿಗಳಿಗೆ ಅನ್ವಯಿಸುತ್ತದೆ ಮತ್ತು LDAP ಗ್ರಂಥಾಲಯ ಅದೇ ಫೈಲ್ ಓದುತ್ತದೆ ಎಂಬುದಕ್ಕೆ ಸಾಕ್ಷಿಯಲ್ಲ. ಪ್ರಮಾಣಪತ್ರವು ನಿಜವಾಗಿ ಒಳಗೊಳ್ಳುವ ಡೈರೆಕ್ಟರಿ ಹೋಸ್ಟ್‌ಹೆಸರನ್ನು ಬಳಸಿ, ಜೊತೆಗೆ ಗ್ರಂಥಾಲಯ ನಂಬುವ ನೀಡುವ ಸರಪಳಿಯನ್ನು. Active Directory ನಲ್ಲಿ ಪ್ರದರ್ಶನ ಹೆಸರಿನಿಂದ ಊಹಿಸುವ ಬದಲು ಸರಿಯಾದ ಸರ್ವರ್-ದೃಢೀಕರಣ ಬಳಕೆಯೊಂದಿಗೆ ಡೈರೆಕ್ಟರಿ-ಸೇವಾ ಪ್ರಮಾಣಪತ್ರವನ್ನು ನಿಯೋಜಿಸಿ.

ಪ್ರತಿ ಫೇಲ್‌ಓವರ್ ಗಮ್ಯಸ್ಥಾನವೂ ಅದೇ ಗುರುತು ನೀತಿಯನ್ನು ಪೂರೈಸಬೇಕು. ಪ್ರಾಥಮಿಕವು ಮೌಲ್ಯೀಕರಿಸಲ್ಪಟ್ಟು ದ್ವಿತೀಯಕವು ಇಲ್ಲದ ಪರಿಸರವು ಫೇಲ್‌ಓವರ್ ಇಲ್ಲದ ಪರಿಸರಕ್ಕಿಂತ ಕೆಟ್ಟದು, ಏಕೆಂದರೆ ದುರ್ಬಲ ಮಾರ್ಗವು ಅಡಚಣೆಯ ಸಮಯದಲ್ಲಿ ಮಾತ್ರ ಪತ್ತೆಯಾಗುತ್ತದೆ.

bind ಖಾತೆ ಪ್ರತ್ಯೇಕ ಸಮಸ್ಯೆಯಾಗಿಯೇ ಉಳಿಯುತ್ತದೆ

ಸಾರಿಗೆಯನ್ನು ರಕ್ಷಿಸುವುದು bind ಖಾತೆ ಏನು ಮಾಡಬಹುದು ಎಂಬುದನ್ನು ಕಡಿಮೆ ಮಾಡುವುದಿಲ್ಲ. ಡೈರೆಕ್ಟರಿ ಹುಡುಕಾಟ ವ್ಯಾಪ್ತಿ, ಗುಂಪು ಅಧಿಕಾರ ಮತ್ತು ಸೇವಾ ಖಾತೆಯ ಸವಲತ್ತುಗಳು ಪ್ರತ್ಯೇಕ ನಿರ್ಣಯಗಳು, ಮತ್ತು TLS ಸಕ್ರಿಯವಾದ ಮೇಲೆಯೂ ಅಗಲವಾದ bind ಖಾತೆ ಅಗಲವಾಗಿಯೇ ಉಳಿಯುತ್ತದೆ. ಸಂಯೋಜನೆಗೆ ಬೇಕಾದ ಅತ್ಯಂತ ಸಣ್ಣ ಸೇವಾ ಖಾತೆ ಮತ್ತು ಹುಡುಕಾಟ ಆಧಾರವನ್ನು ಬಳಸಿ, ಮತ್ತು ಎಂಡ್‌ಪಾಯಿಂಟ್, TLS ಮೋಡ್, ಟ್ರಸ್ಟ್‌ನ ಮಾಲೀಕ ಮತ್ತು ನವೀಕರಣ ಪ್ರಕ್ರಿಯೆಯನ್ನು VPN ಸಂರಚನೆಯೊಂದಿಗೆ ದಾಖಲಿಸಿ.

ಪ್ರಮಾಣಪತ್ರದ ಹೊಂದಾಣಿಕೆಯಿಲ್ಲದಿರುವಿಕೆ ಕಂಡುಬಂದಾಗ, ಸರಿಯಾದ ಪ್ರಮಾಣಪತ್ರ ಅಥವಾ ಸರಪಳಿಯನ್ನು ನಿಯೋಜಿಸಿ. ಪರಿಶೀಲನೆಯನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವುದು ಗೋಚರ ಹೊಂದಾಣಿಕೆಯಿಲ್ಲದಿರುವಿಕೆಯನ್ನು ಅಗೋಚರವಾಗಿಸುತ್ತದೆ ಮತ್ತು ಎರಡನೇ ನಂಬಿಕೆ ಸಂಬಂಧವನ್ನು ಪರೀಕ್ಷಿಸದೆ ಬಿಡುತ್ತದೆ.

ಎರಡು ಸಂಪರ್ಕಗಳು, ಎರಡು ಮಾಲೀಕರು, ಎರಡು ನವೀಕರಣ ದಿನಾಂಕಗಳು. ದಾಖಲಾತಿಯಲ್ಲಿ ಅವನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಇಡುವುದೇ ಲಾಗಿನ್ ಅನ್ನು ಪ್ರಾಮಾಣಿಕವಾಗಿ ಇಡುತ್ತದೆ.