Mac의 Kerberos SSO와 VPN: 두 가지 로그인 경로 비교

두 메커니즘은 Mac에서 같은 친숙한 결과를 내지만 내부에서는 전혀 다르게 동작합니다. 하나는 SSO 확장을 통해 Kerberos 티켓을 얻어 참여 애플리케이션에 전달합니다. 다른 하나는 ID 공급자와 브라우저 세션을 유지하고 웹 애플리케이션이 이를 존중하게 합니다. 네트워크에서 필요한 것, 자격 증명의 유효 기간, 터널이 끊기는 순간 무슨 일이 일어나는지가 다릅니다.

두 메커니즘, 하나의 로그인 화면

티켓 기반 경로는 Kerberos 도메인, 키 배포 센터, 그리고 그것과 일치하는 시계에 의존합니다. 브라우저 경로는 접근 가능한 ID 공급자, 쿠키 또는 토큰, 그 발급자를 신뢰하는 애플리케이션에 의존합니다. 둘 다 로그인 시 시작하도록 구성할 수 있어 같은 기능으로 오해받습니다. 애플리케이션이 둘 중 무엇을 받아들일지 결정하며, Mac은 둘을 동시에 정당하게 실행할 수 있습니다.

사용자가 애플리케이션을 열 때 무엇을 확인하는지 물어보며 비교하세요. Kerberos 도메인에 가입한 파일 서비스는 서비스 티켓을 요구하며, 아무리 많은 브라우저 세션도 이를 충족하지 못합니다. 최신 ID 공급자 뒤의 웹 애플리케이션은 그 공급자의 토큰을 요구하고 Kerberos 티켓은 완전히 무시합니다. 어떤 검사가 일어나는지 알면 배포 질문은 일반적이지 않고 구체적이 됩니다.

Kerberos 확장이 네트워크에서 필요로 하는 것

Apple의 Kerberos SSO 확장 가이드는 사전 티켓 획득을 포함한 네이티브 Active Directory 인증을 설명하며, 도메인 바인딩 대신 로컬 계정과 짝을 이룹니다. 할 수 없는 것은 도메인 컨트롤러로 가는 경로를 만들어내는 것입니다. Mac에는 Kerberos 서비스 레코드에 응답하는 리졸버와 승인된 터널을 통해 그곳에 도달하는 경로가 필요합니다. 깨끗하게 설치되는 프로필은 클라이언트에서 도메인을 실제로 검색할 수 있을 때까지 아무것도 증명하지 못합니다.

자격 증명을 확인하기 전에 검색을 확인하세요. Kerberos 도메인의 SRV 레코드가 확인되어야 하고, 반환되는 주소는 VPN이 올라온 뒤 접근 가능해야 합니다. 시간은 접근성만큼 중요합니다. Kerberos는 허용 범위를 벗어난 시계의 요청을 거부하며, 그 오류는 인증 실패처럼 보입니다. 터널이 내려간 동안 시간 원본에 도달하지 못하는 Mac은 터널이 돌아오는 순간 다시 실패합니다. 시간 원본을 사고 대응이 아니라 배포의 일부로 고치세요.

klist
sudo sntp -sS time.apple.com

앱별 VPN이 확장의 작동 가능 여부를 결정한다

전체 터널은 모든 것을 라우팅하고 이 문제를 숨깁니다. 앱별 구성은 VPN 프로필에 명시된 애플리케이션만 라우팅하며, SSO 확장 자체도 티켓을 가져오기 위해 네트워크가 필요한 프로세스입니다. 매핑에 없으면 로컬 로그인은 성공하고 브라우저를 위한 터널은 올라오지만 티켓 획득은 여전히 실패합니다.

VPN 구성을 읽고 포함해야 할 모든 애플리케이션을 나열한 뒤, 번들 식별자를 추측하는 대신 문서화된 매핑 메커니즘을 통해 SSO 구성 요소를 추가하세요. 보이는 클라이언트만 매핑하고 그 뒤의 구성 요소를 매핑하지 않는 것이 이 실수의 전형입니다. 매핑을 확장과 같은 관리 프로필에 유지하여 하나의 변경이 다른 하나를 조용히 무효화하지 않게 하세요. 그 Mac에 한 번도 로그인한 적 없는 사용자로 테스트하세요. 캐시된 티켓이 끊긴 경로를 건강해 보이게 할 수 있기 때문입니다. 그런 다음 암호 변경 후 다시 테스트하세요.

브라우저 ID 세션은 다른 계약

브라우저 세션에는 Kerberos 도메인도, 서비스 티켓도, Kerberos 의미의 시계 허용 오차도 없습니다. 발급자, 토큰 수명, 갱신 경로가 있으며, 실패 방식은 완료되지 않는 리디렉션과 시크릿 창이 버리는 쿠키입니다. 티켓 경로의 대체물로 취급하는 것은 애플리케이션 자체가 그 발급자를 받아들이는 곳에서만 안전합니다. VPN 포털의 인증 응답을 무관한 서비스로 복사하는 것은 아무리 편리해 보여도 통합이 아닙니다.

두 메커니즘이 모두 배포되면 어떤 애플리케이션이 어느 것을 쓰는지 문서화하세요. 지원 대화가 그것에 달려 있습니다. 로그인은 되었지만 파일 공유를 열 수 없다고 보고하는 사용자는 두 시스템을 설명하는 것이며, 답은 티켓 경로가 전혀 실행되지 않았다는 것입니다. 공유는 열 수 있지만 인트라넷 포털은 열 수 없다고 하는 사용자는 그 반대를 설명하며, 티켓에 메커니즘을 적어 두면 질문 한 바퀴를 아낄 수 있습니다.

부분이 아니라 순서를 밟으세요

일반 등록 계정으로 전체 체인을 밟으세요. 로컬 로그인, 터널, 티켓 획득, 그다음 서비스에 대한 실제 작업 하나입니다. 터널이 다시 연결된 뒤와 의도적으로 암호를 바꾼 뒤 반복하세요. 각 경우가 수명 로직의 다른 부분을 훈련시키기 때문입니다. 각 단계가 따로 통과하는 것은 체인이 작동하는 것과 같지 않습니다. 체인이야말로 사용자가 경험하는 것이고, 인수 사례가 다뤄야 할 것입니다.

프로필 소유자, VPN 인증 방식, 도메인 검색 경로, 확장의 애플리케이션 매핑을 한곳에 기록하세요. 그 기록이 플로를 구축하지 않은 사람도 재현할 수 있게 합니다. 그런 다음 가장 만날 가능성이 큰 실패, 터널이 내려간 동안 만료된 티켓을 확인하고, 클라이언트가 재부팅 없이 복구되는지 확인하세요. 콜드 스타트에서만 작동하는 배포는 끝난 것이 아닙니다.

각 단계의 소유자도 기록하세요. 아무도 관리하지 않는 Kerberos 도메인은 낡아집니다. 아무도 설명할 수 없는 체인은 아무도 디버그할 수 없는 체인입니다.