이번 주, 난 간단한 2 서버 팜에 설치 하는 이끼를 내 팀과 조금 싸 워 왔어. 그것을 통해 간 데, MSDN 포럼에 그리고 다른 곳에서 문제가 사람들이 보고서의 종류에 대 한 큰 감사를가지고.
최종 팜 구성:
- 방화벽 내에 SQL/인덱스/인트라넷 WFE.
- WFE DMZ에.
- DMZ와 내부 서버 간의 방화벽의 일종.
우리는 프로젝트를 시작 하기 전에, 우리는 클라이언트 포트를 열어야 하는 데 필요한 게. 주고받는 동안, 그 동안 이리저리, 우리는 결코 명시적으로 중요 한 두 가지를 말했다:
- SSL은 인증서가 필요한 것을 의미 한다.
- DMZ 서버는 도메인의 일부 여야 합니다..
하루에 한, 우리 MOSS를 설치 하 고 데이터베이스와 이끼에 대 한 도메인 계정을 하지 않았다면 만들어진 배웠습니다.. 것 들을 따라 이동 하, 우리는 서 서 하 고 인트라넷 서버에 로컬 계정이 있는 모든 것을 설치.
이 시점에서, 우리는 SSL 인증서에 혼란을 발견 하 고, 슬프게도, 우리의 인프라 사람이 다시와 서 나중에 그 주 계속 DMZ 서버를 설치 하기로. 평균시에서, 우리 솔루션 건축가 비즈니스 물건 앞으로 이동.
주말가 및 클라이언트 인증서를 가져옵니다..
우리의 인프라가 나타나고 DMZ 서버를 도메인에 가입 되지 않은 발견 (제한 된 신뢰 경계 도메인 또는 인트라넷 도메인). 우리 거의 낭비를 1/2 그 날. 만약 우리가 우리를 수렁 누락 된 SSL 인증서 하지 않았다면, 우리는 발견이 이전. 오 오 잘….
또 다른 하루 패스 및 다양 한 보안 위원회, 관심을 당사자와 (그리) 무고 한 구경꾼 모든 동의 그것 DMZ 서버는 인트라넷 도메인 가입 확인 (이것은 한 POC, 어쨌든, 아니 생산 솔루션).
인프라 남자에 관해서 것 들을 마무리. 우리가 성공적으로 통과 하는이 시간에 다 정하게 "SharePoint 구성 마법사로 알려진 현대 결투." 우리는 중앙 관리에 있는 엿 고 … 유 호! … DMZ 서버 농장에 나열 됩니다.. 우리 조금 가까이 그리고 우리 파산 오픈 샴페인 마이트 조금 일찍 실현. WSS 서비스에 붙어 있는 "시작" 상태.
길고도 짧은 이야기, 그것은 우리가 원래 로컬 계정에서 새 도메인 계정을 중앙 관리를 통해 서비스 계정의 id를 변경 하려면 깜 빡 밝혀. 우리는 그랬다, 구성 마법사 re-ran 봐라! 우리는 사업에 있었다.
</끝>
난 거의 SSL 인증서 문제를 이길 수 있습니다.. 우리가 만든 모든 것을 했다 하 고 SSL로 웹 응용 프로그램 확장을 준비 했다 (포트 리디렉션 80 IIS에서). 관리자는.cer 파일 갈 준비를 했다. IIS에서 적용 하는 옵션 또는 미친 contortions 작동 하지만–사이트는 사이트 모음을 존재 하지 않는 것 처럼 빈 페이지에 항상 표시 됩니다..
머리를 두드리는 많은 후, 우리가 배운이 아니라 해당 서버에서 들어오는 인증서 요청에 의해 발생 했다. 관리자가 단순히 질문 인증서에 대 한 결과 키를 이메일로 했다. 개인 키가 없는, WFE와 브라우저 사이의 SSL 터널 건설 하지 수 없습니다.. 우리가 낭비 1/2 그 날.