다음을 통해 공유

[Tip. 1] 비 정상적으로 AD에서 없어진(Disjoin된) 컴퓨터계정을 자동으로 삭제시키는 방법

  • 아티클

AD 환경에서 정상적으로 제거(Disjoin)하지 않은 컴퓨터가 그대로 AD에 남아 있는 경우가 있습니다, 이런 경우 일일이 확인해서 제거하는 것도 번거로운 일인데요.

일정 기간 동안 로그온 하지 않은 컴퓨터 리스트를 Query해서 그 기간 동안 로그온 하지 않은 컴퓨터는 Disjoin된 컴퓨터로 판단하고 제거 하는 방법이 있습니다 그러나 실수로 원하지 않는 계정을 삭제하게 될 수도 있으므로 dsrm 명령은 신중히 고려하신 후, 실행하시기 바랍니다.

*아래와 같이 dsquery를 이용합니다.

dsquery computer -inactive 4 | dsrm -noprompt

(예: 지난 4주 동안 비활성 상태인 모든 컴퓨터를 찾고 디렉터리에서 제거합니다, 자세한 설명은 dsquery /? 를 실행하여 참고하시기 바랍니다.)

1. 일반적으로 dsquery computer -inactive 4 를 실행해 지난 4주간 로그온 하지 않은 컴퓨터를 확인 합니다.
2. 만약 해당 컴퓨터 모두 AD에서 없어진 컴퓨터라고 판단 되면 추가로 dsrm -noprompt를 붙여서 4주간 로그온 하지 않은 컴퓨터를 제거 합니다.
3. 4주는 제가 임으로 설정한 값이고 5, 6, 7 ... 으로 늘릴 수 있습니다. 출장이나 장기 휴가 같은 경우를 예상해서 잘(?) 설정 하시기 바랍니다.

모두 가을을 만끽하세요~

Comments

  • Anonymous
    January 01, 2003
    아무래도 첨부터 설명 드려야겠네요 ^^
  1. 먼저 처음 댓 글 달아주신 내용 중에서 '암호 변경 주기의 2배수가 지나면 Secure Channel(나그네임이 표현하신 ‘트러스트’)가 깨져 확실할 제거 대상이'라고 말씀 하셨는데 30일 컴퓨터 계정 암호 변경 주기가 넘어도 Secure Channel은 깨지지 않습니다, 그 이유로 깨지지 않습니다(보통 정전이나 동일 컴퓨터이름이 존재시 Broken이 발생합니다). 만약 30일이 지나도 DC와 클라이언트가 연결되지 않는 상황이 되된다 하더라도 DC에서는 해당 클라이언트의 컴퓨터 계정 패스워드를 보존하고 있고 클라이언트가 30일이 지난 후에 AD 네트워크에 연결되면 그때 다시 동기화를 합니다, 이는 기본 Mechanism 입니다. Secure Channel의 컴퓨터 암호 변경 주기는 사람의 암호 변경 정책과 처럼 암호를 보호하기 위한 Mechanism 입니다. 그러므로 암호 변경주기 30일이 지나 Secure Channel(앞에서 '트러스트'라고 표현하신)이 깨져서 확실한 삭제 대상이라고 하신 말씀은 맞지 않습니다.
  2. netdom.exe를 이용한 방법이 '내부적으로는 탈퇴 후 재가입하는 형태'로 알고계시는데 netdom으로 SecureChannel을 복구하는 것은 말씀하신것 같은 rejoin(탈퇴 후 재가입)이 아닙니다. 아래 설명을 보시기 바랍니다. *Netdom을 실행하면 아래와 같은 Process가 일어 납니다.
  1. 클라이언트에서 Domain Admin 권한으로 netdom reset을 실행한다.
  2. netdom reset 요청을 받은 DC는 다시 클라이언트에게 새로운 패스워드를 제안할 것을 요구하는 응답을 보낸다.
  3. 클라이언트는 새로운 패스워드를 생성해 DC에게 보낸다
  4. DC는 해당 패스워드를 적용하고 클라이언트와 Secure channel을 맺는다.
  1. Reset(Secure channel 복구를 말씀하신 거지요?) 만으로 Secure channel로 인한 모든 문제가 해결되는 것이 아니라고 말씀하셨는데요, Secure Channel이 깨진 건 단순히 클라이언트 컴퓨터 패스워드가 DC가 가지고 있는 데이타와 일치하지 않아 생긴 문제입니다, 그러므로 둘간에 컴퓨터 계정 패스워드 동기화(Reset)만으로 해당 이슈는 모두 해결 됩니다. 말씀하신 여러 상황(프로파일 같은)과는 아무 관련 없습니다.
  2. 쓰레기 계체 삭제에 대한 부정적인 의견은 감사합니다 그러나 이것을 이용하고 안하고의 판단은 관리자의 몫입니다. 참고로 삭제가 필요할 만한 단순한 예를 말씀드리면, 만약 AD 개체를 이용하는 어플리케이션이 있는데 어떤 Request를 전체 컴퓨터에 보냈는데 없어진 컴퓨터 개체가 응답하지 않아 Performance에 영향을 줄 수도 있겠죠? 근데 만약 그런 컴퓨터 개체가 수십대 이상이라면? 다시 말씀드리면 환경과 상황에 따라 해당 작업이 필요할 수 있습니다.
  3. 생각나는 몇가지 방법이 있다고 하셨는데 혼자만 아시지 말고 알려주시면 좋겠네요, 궁금합니다 ^^ 좋은 정보라면 모든 분들이 공유하면 좋지 않을까요?
  • Anonymous
    January 01, 2003
    먼저 답변 늦어 죄송합니다. ^^; -해당 KB에서 이야기 하는 두 번 변경 주기가 바꿔도 패스워드가 동기화를 하지 못하면 반듯이 Secure Channel이 Broken된다라는 의미가 아니라 Broken 될 수도(May) 있다고 이야기 하고 있습니다, 어디까지나 있을 수도 있는 문제의 가능성(Known issue)을 예제로 가정해서 이야기 한 것이지 이것이 항상 문제를 일으키는 원인이라는 의미가 아닙니다. 문장에서 May에 주목해 주십시오 ‘the computers involved may not be able to communicate’라고 되어 있습니다, 잘 아시겠지만 MAY는 대단히 신중한 표현입니다. KB쓴 저자도 글을 쓸 당시에도 예외상황 임을 알고 있기 때문에 MAY라고 쓴 것으로 보입니다. 즉, 이 KB의 언급한 내용은 Secure Channel이 비정상적으로 Broken 될 수도 있는 문제의 가능성(possibility) 중 하나를 예제로 설명했다고 보시는 것이 맞습니다.
  • SCCM/SMS와 국내 자산 관리 시스템의 차이에 대해서 저도 제가 이해한 맥락에서 동감 합니다, 개인적으로 이런 차이 역시 환경과 Needs를 고려한 고객의 선택인 것 같습니다. -말씀하신 여러 시나리오 잘 보았습니다, 좋은 의견 감사 드립니다. 그런데 한가지 마치 제가 삭제가 최고의 선택이라고 주장하는 것처럼 받아 들이시는 것 아닌가 해서 조금 당혹스럽습니다 ^^; (처음에 해당 글을 게시할 때도 그렇게 전달되지 않도록 하려고 그리도 조심했는데요..), 처음부터 앞에서 계속 말씀 드린 것처럼 100% 옳은 길이 없는 상황에 필요하면 여러 Workaround중 하나를 선택해서 사용하면 되는 것이고 또 더 좋은 방법이 있으면 그걸 사용하면 될 것입니다, 그러나 본건은 어떤 것이 더 좋다 나쁘다라고 판단하기는 어려운 문제 같습니다.
  • 그리고 정중히 부탁 드립니다만 앞에서 말씀 드렸듯이 Tip은 Tip으로 받아 들여 주십시오 그리고 컴퓨터 개체 삭제에 대한 의견은 꼭 고객/엔지니어/관리자로 분리해서 Yes or No로 판단하지 마시고 모두가 필요할 수 있음을 오픈된 마음으로 받아 들여 주셨으면 합니다.
  • 저도 많은 분들이 토론 하시면서 지식과 간접 경험을 높여 갈수 있는 토론문화 중요하다고 생각합니다. 그러나 제 블로그는 전파력이나 토론할 만한 인터페이스가 부족합니다 또 사실은 제가 답변할 시간도.., 이해 부탁 드립니다. 그럼 좋은 하루 되십시오.

  • Anonymous
    January 01, 2003
    의견 감사드립니다 ^^ 말씀하신 트러스트라는 것이 혹시 Secure Channel을 말씀하시는 것이지요? 네, 삭제 대상이 될 수 있죠 그렇다고 Secure channel이 Broken된 컴퓨터라고 모두 '확실한' 삭제 대상으로 잡기는 무리가 있을 듯하네요, 필요하면 Secure channel은 Reset하면 될것인데, 만약 장기 출장 다녀오니 내 컴퓨터가 복구(Reset)의 여지도 없이 아예 AD에서 삭제 됐다면... ㅜㅜ 말씀하신 것처럼 쓰레기 개체를 꼭 제거할 필요는 없겠지요, 그런데 만약 컴퓨터 Account가 200~300개 이상이 되는 네트워크라면? 이 작업은 AD를 관리하는 관리자의 판단입니다. ^^ 다른 더 좋은 방법을 말씀하셨는데 말씀하신 다른 방법 제게도 알려주시겠어요? 기대하고 있겠습니다~ ^^

  • Anonymous
    January 01, 2003
    먼저 제 답변에 마음이 상하셨다면 사과 드립니다, 다만 제 생각은 댓 글이라도 부정확한 정보를 그냥 두면 다른 방문지분들께서 그대로 받아 들이시지 않을까 하는 걱정이 있어 다른 방문자 분들을 위해 정확히 말씀 드려야 할게 있어서 몇 가지 말씀 드리겠습니다.

  1. 위 제가 답변 드린 댓 글의 의미가 충분히 전달 되지 못한 것 같습니다, 다시 설명 드리겠습니다, 나그네님께서는 컴퓨터 계정 패스워드 변경 시기가 지나면 Secure Channel이 깨진다고 알고 계시는데 아닙니다, 동기화 기간이 지났다 할지라도 Secure Channel은 깨지지 않습니다. If member machine has been shut down over 30 days, it keeps trying to send a change request whenever it boot. DC will accept this request at every time. [컴퓨터 계정 패스워드 변경 과정]
  1. 컴퓨터 계정 패스워드 변경 시기(기본 30일)가 온다, DC는 클라이언트에게 패스워드 변경 요청을 보낸다.
  2. 클라이언트 컴퓨터는 AD에 연결 할 수 없어 패스워드 변경을 할 수 없다.
  3. DC는 클라이언트의 패스워드를 그대로 간직하고 있는다, 이때 클라이언트는 패스워드를 변경하지 못한 상태이므로 역시 가지고 있는 패스워드를 그대로 간직한다.
  4. 30일건 300일이건(30일의 두배건/세배건) 나중에 클라이언트가 DC와 통신을 할 수 있는 상황이 되면 클라이언트와 DC는 이전에 동일한 패스워드 정보를 가지고 있기 때문에 다시 통신할 수 있다. 위와 같은 매커니즘을 가지기 때문에 컴퓨터 계정 패스워드 변경 시기가 지났다고 이때 Secure Channel이 깨지지 않습니다. *Secure Channel이 Broken 되는 것은 아래와 같은 이슈입니다. 1.Unexpected power off on the member machine or DC 2.Electronic storm or Magnet close to the machine 3.A computer is joined to a domain with a name that already exists. 4.The name of the domain member was recently changed.   5.The Emergency Repair Disk was used, but it contained old information.   6.The domain member computer account was removed. 7.Multiple DCs and they are not synchronized.
  1. netdom reset 작업은 어디(DC, 클라이언트, 혹은 제3의 PC)에서 해도 관계 없습니다.
  2. 프로파일 이야기는 제가 문맥을 혼돈 한 것 같습니다, 혹시 프로파일을 ‘( )’로 표시한 것에 대해서 마음이 상하셨다면 사과 드립니다.
  3. Rejoin은 함부로 하지 않기를 권장합니다, Secure Channel이 깨졌을 때는 Reset하는 것이 첫 번째 Step입니다. 재가입(Rejoin)은 특별한 이슈가 있지 않는 한 마지막 방법으로 선택하실 것을 권장합니다. [Rejoin시 발생가능 한 문제 시나리오]
  1. Kim이라는 사용자가 사용하는 A라는 이름의 컴퓨터가 장기간 네트워크에 연결되지 못하거나 Turn On을 하지 못하고 있다.
  2. Kim의 A 컴퓨터를 사라진 컴퓨터로 판단하고 AD 관리자가 AD에서 제거 한다.
  3. Lee라는 사용자가 A라는 이름의 컴퓨터로 AD에 가입 한다.
  4. Kim이 돌아와 A라는 이름으로 도메인에 접속하려 하나 자신의 컴퓨터와 다른(GUID정보 등이 다른) Lee의 컴퓨터이기 때문에 도메인 Access 할 수 없다.
  5. Kim은 A라는 이름으로 AD에 재가입(Rejoin)한다. 이때 도메인에 있는 A라는 컴퓨터 정보 그리고 컴퓨터 계정 패스워드 등이 모두 Kim의 A 컴퓨터로 재생성 된다.
  6. Lee가 도메인에 접속하려고 한다. 그러나 이미 AD에 있는 A라는 컴퓨터의 정보는 Lee의 컴퓨터가 아닌 Kim의 정보로 변경되었으므로 접속 되지 않는다. 제3의 피해자 발생.
  1. 그 문제의 응용프로그램이 잘못됐다는 말씀은 적극 동감 합니다, 하지만 정치가 되었건 사람이 되었건 간에 어쩔 수 없이 엉뚱한 곳에서 뒷수습해야 하는 상황도 있을 수 있지요. (갑자기 아주 오래 전 아픈 기억이.. ㅜㅜ)
  2. 말씀하고자 하시는 핵심인 삭제 기준에 대한 말씀과 함께 여러 긴 의견 감사합니다, 말씀 중에 언제 이런 작업이 필요하겠느냐고 하셨는데 단순하게라도 일반 고객 분들 입장에서는 쓰레기 개체가 보기 싫으실 수 있습니다, 그래서 삭제 요청하실 수도 있는 것이고요, 만약 어떤 Impact가 없고 고객이 원하시는 것이라면 지원해 드리는 게 엔지니어의 도리가 아닌가 싶습니다. 고객의 상황과 요청 그리고 그분들께서 필요로 하신 상황은 언제나 다양합니다, 고객의 요청도 없고 가뭄에 콩나듯 들어오는 문의를 나그네님께서 생각하시는 것처럼 제가 방문자 분들에게 문제의 가능성을 드리면서 까지 글을 게시 하지는 않았을 것입니다.
  3. 말씀 하신 바대로 사라진 PC제거는 완벽한 방법은 없지요, 없으니까 요청이 있을 때 사용해야 할 Workaround가 필요한 것이 아닐까요? Workaround는 여러 가지가 있을 것이고 자신이 선택하면 되는 것입니다, 그 가장 일반적으로 권장해 드리는 Tip을 말씀 드린 것인데, 그것 때문에 격론(?)이 되지 않았으면 합니다.
  • 사라진 PC를 판단하도록 도와주는 솔루션이 SMS/SCCM의 경우 PC Health(정확한 명칭이 기억이)은 있는데 이것은 주기적으로 Ping을 보내 응답 없는 PC에 대한 통계로 PC의 존재 여부를 판단할 수 있도록 도와줍니다, 어차피 이것도 시나리로 기반으로 한 방법이기 때문에 한계가 있는 방법입니다.
  1. 나그네님의 이 말씀하신 좋은 정보가 있으시다면 나그네님 블로그에 올려주세요, 그냥 댓글 로만 쓰이기에는 아깝잖아요? 제가 널리 홍보 하도록 하겠습니다. ^^ 마지막으로 혹 불쾌한 부분이 있으셨다면 다시 한번 사과 드리며 좋은 하루 되십시오. 감사합니다.

  • Anonymous
    August 28, 2008
    컴퓨터 계정에 대한 암호 변경 주기의 2배수가 지나고 난 이후에는 이미 트러스트가 깨진 상태라서 해당 컴퓨터 개체가 AD 도메인에 남아있는 것이 무의미하므로 확실한 삭제 대상이 될 수 있다는 생각이 드네요. 하지만 제 개인적으로는 쓰레기 개체를 찾아 삭제할 필요가 있나 하는 생각이 드네요. 물론 정리가 필요한 것은 당연하지만 AD의 컴퓨터 개체 수를 가지고 자산관리라는 명목으로 관리하는 경우는 없으니까요. 또, 그렇다 하더라도 다른 방법을 이용하는 것이 더 나을 것 같네요. 흠.. 말이 길어질 것 같아.. 여기까지만...

  • Anonymous
    September 18, 2008
    reset --> 이건 이를테면 netdom.exe을 실행하는 것일 수 있겠네요. 근데 아마도 이 방법 역시 내부적으로는 탈퇴 후 재가입하는 형태인 것으로 압니다. reset이라는게 AD 상의 컴퓨터 개체에 대해서만 떨렁 리셋했다고 끝나는 작업은 아닌거니까요. 컴퓨터 개체가 그대로 남아있다고 보안 채널이 깨진 상태에서 사용자가 멀쩡하게 로그온하진 못하겠죠. Cached domain logon이 아니고서는 안되는게 당연하겠죠. 그렇다고 한다면 해당 컴퓨터 개체가 삭제돼있는 경우랑 별반 다를게 없다고 보여집니다. 강제탈퇴 후 재가입하면 결과적으로는 마찬가지란 얘기가 되겠죠. 이렇게 한다고 기존 사용자 프로파일이 날라가는 일은 없으니까요. 행여라도 날라갔다고 한다면 그건 다른 문제로 인한 것일테죠. 어쨌든, 전 개체 삭제 자체에 대해 다소 부정적인 생각을 가집니다. 삭제작업은 그게 무엇이 됐든 한번의 실수로 대형 사고를 칠 수도 있는 작업이기 때문에 특히나 AD에 대해 잘 이해하지 못하는 거의 대부분의 관리자들에게는 정말 위험하고 하지 말아야 하는 작업이라고 생각합니다. 그리고 더 좋은 방법에 대한 의견을 물으셨는데 물론 저도 몇가지 생각하는 방법이 있습니다만 아시다시피 AD는 기본 인프라일 뿐 거기에서 제공하는 도구나 기능 역시 기본적인 것이기 때문에 좋고 나쁘고를 따질 꺼리는 아니라고 봅니다. 별도의 개발이나 솔루션이 아니고서는 더 좋아질 수는 없겠지요. 감사합니다.

  • Anonymous
    September 24, 2008
    The comment has been removed

  • Anonymous
    October 02, 2008
    뭐, 기분이 좋을 것은 없었습니다만 제가 언급하지 않은 내용을 제가 언급한 것 처럼 말씀하신 것이 좀 억울했을 뿐입니다. 잘못된 내용을 바로 잡아야 한다는 취지는 저 역시 동의합니다. 엔지니어한테는 그게 제일 중요한 점이니까요. 저도 일부 오해가 있던 것에 대해 사과드립니다. 그리고 엔지니어라면 사소한 이유라 하더라도 고객(?)이 원한다면 그게 좋은 방법이든 그렇지 않든 원하는대로 최대한 해주는 것이 맞는 것이라고 저도 그렇게 생각합니다. 어쨌든, 설명해주신 내용에서 제가 동의하지 못하는 내용이 하나 있어 추려봤는데요, 그 내용은 다음과 같습니다. --

  1. 30일건 300일이건(30일의 두배건/세배건) 나중에 클라이언트가 DC와 통신을 할 수 있는 상황이 되면 클라이언트와 DC는 이전에 동일한 패스워드 정보를 가지고 있기 때문에 다시 통신할 수 있다. -- 이 내용은 틀린게 아닌지 모르겠습니다. 다음 KB에 보면 이런 내용이 있습니다. 즉, Windows-based 컴퓨터는 현재 암호와 이전 암호 이렇게 두개의 암호를 가지고 있고 암호 변경 주기가 2번을 초과하여 동기화되지 않았을 경우 문제가 된다는 얘기입니다. http://support.microsoft.com/kb/325850 -- Each Windows-based computer maintains a machine account password history that contains the current and previous passwords that are used for the account. When two computers try to authenticate with each other and a change to the current password is not yet received, Windows relies on the previous password. If the sequence of password changes exceeds two changes, the computers involved may not be able to communicate, and you may receive error messages. For example, you may receive "Access Denied" error messages when Active Directory replication occurs. .. 이하 생략 -- 물론, 이게 secure channel과 아무 상관이 없는 문제인지는 모르겠지만 제가 얘기했던 것은 컴퓨터 계정에 대한 암호 변경 주기였고 이것은 앞서 KB에서 언급돼있는 내용을 토대로 저는 얘기했던 것이죠. 제가 제대로 해석을 못한 것이 아니라면 적어도(?) 컴퓨터 암호 변경은 두번을 초과해서 변경되지 못할 경우 로그온을 할 수 없게 되는게 맞지 않나요? 즉, 컴퓨터 암호 변경 주기는 설정된 변경 주기의 두배수를 초과해서 동기화되지 못하면 문제가 되는 것이 맞는게 아니냐 하는 것입니다. 이게 앞서 말씀하신 것과 다른 내용인지 궁금하네요. 그리고 사견입니다만, 컴퓨터 계정에 대한 암호가 AD 상의 컴퓨터 개체와 서로 맞지 않는 경우라면 단순히 암호가 서로 안맞을 뿐이지만 이것 역시 secure channel이 깨진 상태로 보는 것이 맞지 않을까 하는 생각입니다. 왜냐하면 암호가 맞지 않아 secure channel을 생성하지 못했다면 이건 secure channel이 깨진 것과 다르지 않다고 생각하기 때문입니다. 물론 이건 제 주관적인 견해일 뿐이지만 말이죠. -- 그 외, SCCM/SMS 이것은 제가 알기로 클라이언트 에이전트 설치할 때 외에는 push할 수 없는 것으로 압니다. 즉, 주기적으로(아마 기본값이 60분이죠?) pull 방식(?) 그러니까 서버를 통해 확인하고 내려받을 것이 있으면 그때 가져가서 설치하던가 하는 형태인 것으로 알구 있구요. 아마도 국내 자산관리 시스템 관련 제품들이 서버에서 한방에 밀어넣는다던가 하는 비효율적인 방법을 채택하는 경우가 있는 것으로 압니다. 물론 그게 또 고객 요구사항이기도 하고 어찌보면 그런식의 배포(?) 방법이 관리상 여러모로 알기 쉽고 편리하기 때문이긴 하겠지만 말이죠. 그리고 마지막으로, 재가입하는 형태와 관련해서 언급하신 시나리오의 경우는 AD 설계, 그중에서도 컴퓨터 이름 규칙 관련 설계 문제가 아닐까 합니다. 보통 자산번호라던가 별도 이름 규칙을 통해 물리적인 컴퓨터마다 고유하게 컴퓨터 이름을 부여하는 형태로 이름 설계가 잘 돼있다면 그런 경우는 발생하지 않을 것으로 봅니다. 중소규모 사업장에서 컴퓨터 하드웨어(?)에 매치되는 고유한 컴퓨터 이름 규칙을 부여하지 않고 임의적인 규칙으로 그때그때 붙여서 만든다면 말씀하시는 그런 문제가 많이 발생할 우려가 있긴 하겠죠. 결론적으로 전 컴퓨터 개체를 삭제하기 보다는 차리라 "사용 안 함" 상태로 잠궈버리는 편이 낫지 않을까 하는 생각도 듭니다. 사람에 따라 보기 싫다는 식의 이유로도 삭제하고 싶어할 수 있겠습니다만 절대적인(?) 그리고 완벽한 삭제 기준이 존재할 수 없기 때문에 더더욱 삭제하지 않는 것이 나아보인다는 엔지니어 입장에서의 소견일 뿐입니다. 고객이나 관리자 뭐 그런 사람들의 입장이 아닌 엔지니어의 입장으로 봤을 때를 기준으로 말씀드렸던거죠. 제가 블로그 같은 것을 운영하지 않아 말씀하시는 그런 내용들에 대해 어디 올리거나 혹은 여기에 의견을 계속 게제한다거나 하긴 어려울 것 같습니다. 그냥 저를 시작으로 많은 사람들이 "엔지니어" 관점에서의 어떤 토론 문화를 좀 만들었으면 하는 생각이 듭니다. 말씀하시는 고객이나 관리자 등의 요구 사항을 충족시켜주기 위한 스킬도 필요하니 이런 내용이 충분히 유용하겠지만 그런 고객 응대에 대한 것 보다는 엔지니어의 관점으로 해석해보는 것도 좋지 않을까 합니다.