none
ad 로그인 질문 드립니다. RRS feed

  • 질문

  •  

    1.도메인 가입 후  A라는 사용자가 dc@dc.com의 계정으로 자신의 pc에 로그인 합니다.

     

    질문:  pc에 타 계정의 사용자가 로그인 하지 못하게 하는 방법이 궁금합니다.

     

     

    2.2003 서버에서 두대의 DC를 운영중 입니다.

      2003에서는 메인 DC의 구분이 없다고 하는데...

    질문: 만약 메인(PDC)가 하드웨어적으로 복구가 블능이 되었을때 백업 DC로 복구가 가능한지 알고 싶습니다.

             이때 FSMO와의 관련이 어떻게 되는지도 궁금합니다.

     

    읽어 주셔서 감사합니다.

     

     

     

    2008년 1월 23일 수요일 오전 3:35

답변

  • 2번에서 Seize를 하는것은 완전히 더이상 복원이 불가능할때 하는 방법입니다.

     

    무작정 Seize를 진행하게 되면 RID Master의 RID DB나 Infrastructure Master, Domain Naming Master 등의 정보가 초기화 되므로, 1개 도메인의 아주 작은 네트워크는 큰 문제가 안될지 모르지만, 표준 복원 작업은 아닙니다.

     

    표준 복원 작업은 일단 다른머신에 장애서버와 같은 컴퓨터이름과 구성으로 DC를 구성하고, 디렉토리 복원모드를 통해서 백업/리스토어를 하는 것입니다.

     

    이후, FSMO를 2nd DC로 옮겨놓으면 나중에 장애서버의 하드웨어 문제를 해결했을 때, 다시 복구시키기도 편하겠지요.

    2008년 1월 24일 목요일 오후 12:40
  • 물론 위의 방법이 틀렸다는 얘기는 아닙니다.

     

    다만, 단독 도메인일 경우는 좋은 방법이 될 수 있으나, 말씀하신것 처럼 Transfer가 되지 않는데 Seize가 된다는 것은 다시 만들기 때문입니다.

     

    FSMO RoleMaster가 동작하지 않는다고, Infrastructure에 대단한 장애가 있지는 않습니다. GC가 RoleMaster에만 있다면 얘기가 좀 달라지겠지요.

    Domain User 인증도 문제가 없구요. Role Master장애가 났는데, 도메인에 새로 조인을 해야한다? 이런 특별한 경우는 별로 없을거라고 봅니다.

     

    하지만, 이것이 만약 Forest레벨로 올라가면 얘기가 전혀 달라집니다.

     

    Forest상에 각 DomainNaming Master들이나, RID Master들의 정보가 초기화 되어버리면, Sites 정보도 다시 살펴줘야 하고 이 작업 시간이 복구시간보다 더 오래걸릴 수 있습니다.

    만약 AD응용프로그램이 있다면 문제가 더 커지겠지요.

     

    그래서 저는 Seize를 하는것이, 말씀하신것 처럼 단독 도메인에서 Downtime을 줄이기 위해서 하는 것이지 표준 복원작업 프로세스가 아님을 말하고자 하는 것입니다.

    그로 인한 Risk가 분명히 존재한다는건 알고 하자는 것이지요.

     

    심지어 61일 이후 표준 프로세스로 하게 되어 있는 NTDS Offline Defragment 같은 경우도, ntds.dit를 다시 만들어서 할 수 도 있습니다. 하지만 속성으로 진행하는 프로세스는 항상 Risk가 있기 마련이지요.

    2008년 1월 25일 금요일 오후 12:56

모든 응답

  • 1.시작 > 실행 > gpedit.msc
      로컬컴퓨터정책 > 컴퓨터구성 > windows설정 > 보안설정 > 로컬정책 > 사용자권한 할당
      하위트리로 이동

       "로컬로 로그온거부" 정책에 거부하고 싶은 계정 추가
     
    2. PDC,BDC 개념은 NT4.0때의 개념입니다.
       FSMO는 NTDS유틸을 이용해서 Seize작업을 진행하면 됩니다..

     

       Active Directory FSMO 작업을 쉽게하기
       http://wishy.net/forum/2470#1

     

       Windows 2000 도메인 컨트롤러에서 FSMO 배치 및 최적화
       http://support.microsoft.com/kb/223346

     

       다른 하드웨어 구성을 사용하여 컴퓨터에서 Active Directory의 장애 복구 복원을 수행하는 방법
       http://support.microsoft.com/kb/263532/ko

      

    2008년 1월 23일 수요일 오전 4:17
  •  

    답변 감사합니다.

     

    죄송하지만.. 다시 정확하게 질문 드리겠습니다.

     

    위 1번 같이 하게되면 정책을 만들기가 어렵습니다.

     

    즉... a 컴에서는 a.@dc.com  계정을 가진 사람과 관리자만이 로그인... b 컴에서는  b@dc.com 로그인 계정을 가진 사람과 관리자만이 로그인을 허용하게 하고 싶습니다.

     

    위와 같이 했을경우.... 특정 사용자를 제한 리스트에 추가해야 하는데 정작...이렇게 하면 전체적으로 컨트롤이 안됩니다

     

    혹 ..다른 방법은 없는지요....

     

    감사합니다.

    2008년 1월 23일 수요일 오전 5:02
  • 0  로그온 허용할 도메인계정을 포함할 도메인 로컬그룹을 하나 만든후

       A,B..등 도메인계정을 포함 합니다.

     

    1. 도메인계정 > 속성 > 계정탭 >  로그온대상 버튼

     

       생성되는 로그온 워크스테이션 창  > 이 사용자의 로그온 대상  

       라디오버튼  "다음 컴퓨터"에 체크

       로그온 허용 가능한  서버명을 추가합니다.

     

       a@dc.com -> a서버명 만 등록

       b@dc.com -> b서버명 만 등록

     

    2. (모든서버) 로컬 users 그룹에 domain users 그룹을 제거하고 
        0번에서 생성한 도메인 로컬그룹을 추가합니다

     

     

    C 서버와 C 도메인유저가 생성되더라도

    동일한 0,1,2 작업만 하면 됩니다.

    변경관리시는 계정속성의 "로그온대상"만 유의하면 되겠죠

    2008년 1월 23일 수요일 오전 5:44
  • 2번에서 Seize를 하는것은 완전히 더이상 복원이 불가능할때 하는 방법입니다.

     

    무작정 Seize를 진행하게 되면 RID Master의 RID DB나 Infrastructure Master, Domain Naming Master 등의 정보가 초기화 되므로, 1개 도메인의 아주 작은 네트워크는 큰 문제가 안될지 모르지만, 표준 복원 작업은 아닙니다.

     

    표준 복원 작업은 일단 다른머신에 장애서버와 같은 컴퓨터이름과 구성으로 DC를 구성하고, 디렉토리 복원모드를 통해서 백업/리스토어를 하는 것입니다.

     

    이후, FSMO를 2nd DC로 옮겨놓으면 나중에 장애서버의 하드웨어 문제를 해결했을 때, 다시 복구시키기도 편하겠지요.

    2008년 1월 24일 목요일 오후 12:40
  • 네 맞습니다^^

     

    하지만  다른 관점으로 보면

    장애발생 후 AD인프라의 DownTime 최소화를
    위해서는 Seize 명령으로 일단 남아있는 DC 에 Role을 이전해
    AD에서 발생될 수 있는 잠재적인 문제를 일단 해결한 후

     

    (서버를 이용할 수 없을때는 NTDSUtil에서
    Transfer명령이 작동되지 않습니다) 

     

    하드웨어장애 서버 관련된 작업을 진행되는것이
    AD 인프라의 DownTime을 줄이는데 도움이 됩니다.

     

    이 작업 없이 진행된 문제난 하드웨어 파트 교체 후 복구 or 대체 서버로 
    의 복구에 대한 시간은 사용자 입장에서는 모두  AD인프라의 장애시간으로

    되어 버리는 문제점이 생기기 때문 입니다

     

     

     

    2008년 1월 25일 금요일 오전 12:48
  • 물론 위의 방법이 틀렸다는 얘기는 아닙니다.

     

    다만, 단독 도메인일 경우는 좋은 방법이 될 수 있으나, 말씀하신것 처럼 Transfer가 되지 않는데 Seize가 된다는 것은 다시 만들기 때문입니다.

     

    FSMO RoleMaster가 동작하지 않는다고, Infrastructure에 대단한 장애가 있지는 않습니다. GC가 RoleMaster에만 있다면 얘기가 좀 달라지겠지요.

    Domain User 인증도 문제가 없구요. Role Master장애가 났는데, 도메인에 새로 조인을 해야한다? 이런 특별한 경우는 별로 없을거라고 봅니다.

     

    하지만, 이것이 만약 Forest레벨로 올라가면 얘기가 전혀 달라집니다.

     

    Forest상에 각 DomainNaming Master들이나, RID Master들의 정보가 초기화 되어버리면, Sites 정보도 다시 살펴줘야 하고 이 작업 시간이 복구시간보다 더 오래걸릴 수 있습니다.

    만약 AD응용프로그램이 있다면 문제가 더 커지겠지요.

     

    그래서 저는 Seize를 하는것이, 말씀하신것 처럼 단독 도메인에서 Downtime을 줄이기 위해서 하는 것이지 표준 복원작업 프로세스가 아님을 말하고자 하는 것입니다.

    그로 인한 Risk가 분명히 존재한다는건 알고 하자는 것이지요.

     

    심지어 61일 이후 표준 프로세스로 하게 되어 있는 NTDS Offline Defragment 같은 경우도, ntds.dit를 다시 만들어서 할 수 도 있습니다. 하지만 속성으로 진행하는 프로세스는 항상 Risk가 있기 마련이지요.

    2008년 1월 25일 금요일 오후 12:56