계정 잠금을 유발하는 ActiveSync 장치


12

어떤 이유로 든 사용자가 자신의 계정 암호를 변경하면 (읽기 : 만료 됨) 이전 암호가 EAS를 통해 연결된 모바일 장치에 저장됩니다. 이렇게하면 AD에 정의 된 잠금 정책에 따라 계정이 거의 즉시 잠금 상태가됩니다. 그 부분을 알아내는 것이 쉬웠습니다. 어려운 부분은 그것이 일어나지 않도록하는 것입니다. 나는 모든 곳을 보았다. 아무것도. 기본적으로 퍼즐에는 EAS 장치, TMG (ISA) 서버, EAS 프로토콜 및 AD의 네 부분이 있습니다. 이들 중 어느 것도 EAS 장치의 인증 실패를 막을 방법이 없습니다. 그래서 나는 영리한 해결 방법을 생각해 내야한다고 생각했습니다. 그리고 내가 할 수있는 유일한 것은 모든 EAS 사용자를위한 그룹을 만들어 잠금 정책에서 제외시키는 것입니다.

질문 : EAS가 계정을 잠그지 못하게하는 다른 방법을 생각할 수 있습니까?

환경 : 대부분 EAS를 통한 iOS 장치. TMG 2010. Exchange 2007. AD 2008 R2.


좋은 질문입니다.
SpacemanSpiff

2
잠금 정책은 Microsoft Security Compliance Manager에 따라 10에서 50 사이 여야합니다. 당신은 무엇으로 설정되어 있습니까?
TristanK

좋은 질문입니다. 가치있는 해결책이 있는지 궁금합니다.
TheCleaner

인증을 시도 할 수있는 포워드 프록시를 구현할 수 있습니다. AFAIK EAS는 HTTPS 기반입니다. closedsrc.org/2010/11/…
Grizly

답변:


3

일반적으로 사용자에게 장치를 "비행"또는 "비행기"모드로 설정하여 암호를 변경할 준비가되면 네트워크 액세스를 차단하고 데스크탑 / 랩톱에서 암호를 변경하면 새 암호를 입력 할 수 있습니다. 장치에 연결하고 네트워크에 다시 연결하십시오.

물론 암호 만료에 대비할 수 있도록 만료 알림을 보냅니다.


좋은 생각이지만 내 경험에 따르면 문제를 해결하기 위해 사용자에 따라 더 많은 문제가 발생합니다. 비밀번호를 잠그지 않고 비밀번호를 변경하는 방법에 대한 절차가 이미 있지만 아무도 따르지 않습니다.
압둘라

추가하는 것을 잊었습니다. 15 분마다 인증이 수행되므로 사용자는 잠그지 않고 비밀번호를 업데이트 할 시간이 있습니다.
압둘라

이것은 "사람"문제이며 기술을 사용하여 해결하려고하면 이상적인 시나리오를 달성 할 방법이 없기 때문에 환경의 보안이 저하됩니다. 이것이 블랙 베리라면 문제가되지 않았을 것입니다 :)
KAPes

1

TMG SP2에는 이제이 문제를 방지하기 위해 계정 잠금 기능이 있습니다. 참조 : 여기 , 여기여기 .


이 이론적으로 질문에 대답 할 수 있습니다 동안, 바람직 할 것이다 여기에 대한 대답의 본질적인 부분을 포함하고 참조 할 수 있도록 링크를 제공합니다.
Scott Pack

TMG 계정 잠금 기능은 많은 사용 사례에 유용하지만 양식 기반 인증에만 적용됩니다. ActiveSync는 양식 기반 인증을 사용하지 않는 것처럼 보이므로 원래 포스터 시나리오에서는 작동하지 않는 것 같습니다.
the-wabbit

1

나는이 질문에 도전했습니다. 심각한 옵션으로 인증서 기반 ActiveSync 인증을 고려하고 있습니다. 모바일 장치 잠금을 해제하기위한 암호 코드를 요구하는 EAS 정책과 함께 이것은 2 단계 인증 (사용자가 가진 것 : 모바일 장치의 인증서, 알고있는 것 : 모바일 장치의 암호 코드)으로 간주됩니다. 이렇게하면 암호가 만료 될 때 문제가 없습니다. 도움이 되었기를 바랍니다. http://blogs.technet.com/b/exchange/archive/2012/11/28/configure-certificate-based-authentication-for-exchange-activesync.aspx


0

인증에 실패했음을 사용자에게 알려주는 것은 장치에 달려 있습니다. 더 나은 대답은 엔터프라이즈 EAS 지원을 제공한다고 생각하는 iOS 장치에서 엔터프라이즈를위한 좋은 메시징과 같은 것을 사용하는 것입니다.


iOS는 비밀번호를 업데이트하라는 팝업 메시지를 표시하지만 계정은 이미 잠겨 있습니다. 좋은 메시지는 지나친 것 같습니다.
압둘라

0

좋은 질문입니다. 불행히도 암호가 업데이트 될 때까지 장치가 인증을 시도하지 못하게하는 방법을 찾지 못했습니다. 비밀번호 정책에서 사용자를 제외하거나 기기에서 비밀번호를 변경하는 방법을 문서화하고 비밀번호가 만료되어 계정을 잠금 해제해야 할 때마다 사용자에게 상기시키는 것이 유일한 방법입니다.

또한 스크립트 나 프로그램을 사용하여 x 일 동안 비밀번호가 만료 될 것임을 사람들에게 이메일로 보내고 전화에서 비밀번호를 변경해야한다는 알림을 포함시킬 수 있습니다.

11 월에 비밀번호 정책을 구현 한 이후로 현재 고용주에게이 문제가있을 것으로 예상되었지만 지금까지 모바일 사용자는 비밀번호를 변경하지 않아도 알 수있을 정도로 정통 해 보입니다.


그러나 사용자를 제외하면 유일한 솔루션처럼 보이지만 그리 좋은 것은 아닙니다. 우리의 사용자는 암호가 만료되기 전에 이미 잠금을 피하기 위해 암호를 올바르게 업데이트하는 방법에 대한 완전한 단계를 통해 알림을 받았지만 아무도 읽지 않습니다. NASA를 위해 일하지 않는 한 정책이 제대로 작동하지 않을 수도 있다고 의심합니다.
Abdullah

0

"항상 최신 정보"기능을 사용하지 않을 때 장치 인증 시도 방식을 테스트 할 수 있습니다. 장치가 항상 최신 날짜를 사용하는 대신 5 분마다 폴링하도록 구성되어 있고 계정 잠금을 트리거하는 인증 실패 비율이 발생하지 않는 경우 이는 가능한 해결책 일 수 있습니다.


TMG 서버는 15 분마다 인증을 요청하도록 구성되었습니다. 다음 인증이 이루어지기 전에 사용자는 비밀번호를 업데이트 할 시간이 있지만 사용자에게 의존 할 수는 없습니다. 또한 iOS가 포기하기 전에 몇 번이나 인증을 시도했지만 애플의 쓸모없는 문서를 테스트하거나 조사하지 않아도 실패한 횟수를 알아 보려고 노력했다.
압둘라

IIS 로그를 검사하여 인증 시도 횟수를 결정하는 것이 매우 간단한 것 같습니다.
Greg Askew

그래, 어제 내 의견을 게시 한 후 정보 로그를 검사 할 수 있음을 깨달았습니다. 내가 찾던 것을 찾지 못했지만 계속 찾을 것입니다.
압둘라

0

이것은 이전의 암호를 잘못 사용하는 iPhone의 장치 문제인 것 같습니다. Apple은 iOS7의 장치에 대한 더 나은 경험을 약속하는이 문제에 대한 기술 노트를 게시했습니다. http://support.apple.com/kb/TS4583


-1

Exchange 서버 앞의 방화벽에서 원래 IP 주소를 차단하십시오.


1
우리는 악의적 인 사용자를 차단하지 않고 현재 비밀번호 메이트를 변경하는 합법적 인 사용자에 대해 이야기하고 있습니다.
Grizly
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.