Several customers are deploying the latest version of the excellent Evolution payroll service-bureau software from iSystems, and the new management interface is web based via SSL. This is a major improvement over the previous version that required interaction with the server via a logged-in user.
But the web certificate used by the vendor is self-signed, which means that Internet Explorer users visiting the management interface are greeted with an untrusted-certificate message:
Though it's not difficult to dispense with this message - one can accept the certificate with a few clicks - all users on all workstations must go through this, and we'd prefer to avoid it. Fortunately, we can capture and deploy the certificate with Group Policy throughout the enterprise. It's worked really well.
Note - this Tech Tip is intended to be used generally for any kind of certificate deployment, but we're using the specific example of Version 6 ("Garfield") of Evolution. Our server platform is SBS2003 with XP/SP2 workstations. We've not investigated this process for any browser other than IE.
Disclaimer - We'll also note that we are not even remotely approaching PKI or Group Policy experts, and we have mainly muddled through several of the choices offered on the road to something that appears to work well. We'd certainly welcome input from those who actually know this stuff.
Getting a copy of the certificate into a file
Ultimately we need a copy of the public certificate into a file so that it may be imported into Group Policy, and though some vendors may publish this certificate on a website, it's easy to use the browser itself and export the cert to a file.
Begin the process by loading IE, visiting the website of interest, and provoking the security warning. It may be necessary to exit all instances of IE if the certificate had previously been accepted, but once visible, click the [View Certificate] button.
There is lots of information about this certificate, and we want the [Details] tab which confirms that the certificate is from who we think it's from. Click the [Copy to File] button:
Here we're offered quite a few choices of certificate format, and we have chosen Cryptographic Message Syntax Standard (PKCS #7) for no particularly good reason - we know that it imports correctly into the Group Policy editor. We don't think the certificate path matters.
Clicking [Next] prompts for a filename, and it should be of the form vendorcert.p7b (the .p7b extension matters). The file should then be somehow moved to the Windows Server with the Group Policy Management.
Deploying the Certificate with Group Policy
With vendorcert.p7b now on the server, we're ready to deploy the certificate.
Launch the Group Policy Manager and navigate to a suitable object: we prefer the Default Domain Policy because there is no harm in deploying this certificate throughout the entire enterprise. Right-click on that object and select Edit:
In the Group Policy Object Editor, navigate down to: Computer Configuration
» Windows Settings
» Security Settings
» Public Key Policies
» Trusted Root Certification Authorities
Then right-click and select Import.
In the Certificate Import Wizard, browse to the location of the file; here we're looking for vendorcert.p7b. Click [Next].
With the file selected, we're shown the Certificate Store dialog that selects the target location for the cert. We've seen only one choice available with all the rest grayed out. Click Next.
In the wizard completion dialog, review the settings: they should all be familiar. Click Finish.
Finished! The certificate has been imported, and it appears in the Group Policy object. The next time a user logs in, these settings will be applied and the certificate will be trusted by Internet Explorer.
Multiple (and unrelated) certificates may be deployed in the same way, so that as other systems enter production with self-signed certs, they may be included in the same Group Policy object.
We should note, however, that this procedure is intended for intionally self-signed certificates that are known to be trusted, and it's not meant to ameliorate browsing sites with broken certs (expired, wrong server name, etc.). Please keep in mind that SSL certificates are a security measure, and bypassing it thoughtlessly may lead to unpleasant surprises.
아니면 시작 메뉴 검색 창에 cmd 입력 후 Ctrl + Shift + Enter 를 입력하는 방법
그런데 관리자 권한의 CMD 창을 자주 띄우는 편이라면, 작업 표시줄에 아이콘을 고정시켜 두는건 어떨까요? 물론 Administrator 계정을 사용하거나, 저처럼 UAC를 끄고 사용하는 분들의 경우 CMD 창이 항상 관리자 권한으로 실행됩니다만, 보안을 이유로 UAC를 끄지 않고 사용하는 분들에게는 이 방법이 도움이 될 듯 합니다.
우선 CMD 창을 하나 띄운 다음 우클릭 해서 작업 표시줄에 고정시켜주세요.
그런 다음 CMD 창을 닫고, 작업 표시줄에 고정된 아이콘에 Shift + 우클릭 합니다. 그리고 속성을 눌러주세요.
그러면 바로가기 탭에 고급 버튼이 하나 보이는데, 눌러주세요.
고급 속성 창이 뜨면, 관리자 권한으로 실행 부분에 체크를 해줍니다.
이렇게 하시면 작업 표시줄에 고정시켜둔 CMD 아이콘은 항상 관리자 권한으로 실행됩니다.
그런데 이렇게 했을 때 나타나는 기본 경로 C:\Windows\System32 폴더가 불편하지 않으신가요? 뭐 불편하지 않으시다면 제가 할 말은 없습니다만... 만약 불편하시다면 기본 경로를 바꿔봅시다.
왜 불편하냐구요? 짧은 커맨드를 입력할 때는 괜찮은데, 긴 커맨드를 입력해야 하는 경우 다음 줄로 넘어가게 되어 보기에 안 좋더라구요. 물론 CMD 창의 크기 자체를 키워두면 되지만...
아무튼 불편하신 분들은 다음 방법을 활용해봅시다.
아까전에 Shift + 우클릭 해서 속성에 들어갔을 때 보였던 바로가기 탭을 주목해주세요. 대상과 시작 위치가 있는데, 시작 위치를 바꾸면 해결이 될까요? 그렇지 않습니다. 시작 위치는 이미 %HOMEPATH%인데 상관없이 C:\Windows\System32 폴더에서 실행되고 있잖아요. 그래서 제가 CMD 스크립트를 첨부파일과 함께 배포하는 경우 항상 첫 부분에 pushd %~dp0 또는 cd /d %~dp0 를 넣어줍니다. 왜냐하면 UAC가 켜진 사용자가 관리자 권한으로 CMD 스크립트를 실행한 경우 C:\Windows\System32 에서 경로가 시작되기 때문입니다. 그래서 그 경로를 배치파일이 존재하는 위치로 되돌리기 위해서 위 명령어를 스크립트 초반부에 넣습니다.
아무튼 시작 경로를 변경하기 위해서 대상 부분에 다음과 같이 입력해봅시다.
cmd /k cd /d 경로
여기서 cmd 다음에 /k 를 붙이는 이유는 뒤에 나오는 명령을 실행한 뒤 CMD 창을 계속 남아있도록 하기 위함이고, cd 뒤에 /d 를 붙이는 이유는 대상 드라이브가 현재 드라이브와 다른 경우 경로 드라이브 이동이 되지 않기 때문입니다. 즉 C:\Windows\System32 경로가 기본으로 뜨는 상태인데 cd D:\ 하시면 바뀌지 않습니다. cd /d D:\ 해야 바뀝니다.
저는 위에 아무것도 안 나오게, 최대한 깔끔하게 하려고 C 드라이브 루트로 경로를 지정합니다.
cmd /k cd /d C:\
(참고로 이동 대상 경로가 드라이브 루트인 경우 cd /d 없이 바로 cmd /k C: 라고 입력해도 됩니다.)
위에 버전도 안 뜨고, 바로 C 드라이브 루트가 뜨니 깔끔하죠?
만약 바탕화면을 경로로 지정하고 싶다면 아래와 같이 입력해보세요.
cmd /k cd %homepath%\desktop
참고로 여기서는 제가 cd 뒤에 /d 옵션을 넣지 않았습니다. 왜냐하면 HOMEPATH 환경변수 자체가 \Users\사용자 폴더를 가리키는데, 특수한 경우가 아니라면 윈도우가 설치된 드라이브와 동일한 드라이브이기 때문입니다. 물론 /d 옵션을 붙인다고 해서 문제될 것은 없습니다만 타이핑을 조금이라도 덜 하려고 /d 옵션은 붙이지 않았습니다.
참고로 Administrator 계정을 사용하거나, 저처럼 UAC를 끄고 사용하시는 분들은 위 방법대로 하실 필요가 없습니다. 그냥 시작 위치 부분에 바로 원하는 경로를 넣어버리면 그만입니다.
별거 아닌 내용을 가지고 글을 길게 썼는데요, 사실 제가 가장 추천하는 방법은 바로 아래 글입니다.
위 글에서 소개해드린 방법을 사용하시면 정말 편리합니다. 언제 어디서든 마우스 우클릭 만으로 해당 위치에 바로 관리자 권한의 CMD 창을 열 수 있습니다. 굳이 작업 표시줄에 아이콘을 고정시켜둘 필요가 없습니다. 특히 다운로드 받은 파일에 옵션 붙여가며 관리자 권한으로 커맨드를 날려야 할 경우 딱 좋습니다. 바탕화면이든 어디든 파일이 있는 곳에서 바로 마우스 우클릭으로 관리자 권한의 CMD 창을 띄울 수 있으니까요.
실컷 써놓고 보니 결국 예전에 올렸던 글을 추천하게 되었는데, 아무튼 작업 표시줄이든 마우스 우클릭이든 각자 취향에 맞고 편하게 느껴지는 방법을 선택하시면 되겠습니다.
디스크 관리 => diskmgmt.msc 네트워크 연결 => ncpa.cpl 사용자 계정 => netplwiz.exe 로컬 사용자 및 그룹 => lusrmgr.msc 프로그램 및 기능 => appwiz.cpl 서비스 => services.msc 이벤트 뷰어 => eventvwr.msc IIS 관리자 => inetmgr.exe Windows 방화벽 => firewall.cpl 고급 보안이 포함된 Windows 방화벽 => wf.msc 시스템 속성 => sysdm.cpl 원격 데스크톱 => mstsc.exe 장치 관리자 => devmgmt.msc 로컬 그룹 정책 편집기 => gpedit.msc 성능 모니터 => perfmon.msc 컴퓨터 관리 => compmgmt.msc iSCSI 초기자 => iscsicpl.exe Active Directory 사용자 및 컴퓨터 => dsa.msc
기본적으로 터미널 서버와 Windows 2000 터미널 서비스는 클라이언트 연결에 TCP 포트 3389를 사용합니다. 이 값은 변경하지 않는 것이 좋지만, 이 포트를 변경해야 할 경우에는 다음 지침을 따르십시오.
경고: 레지스트리 편집기를 잘못 사용하면 심각한 문제가 발생할 수 있으며 문제를 해결하기 위해 운영 체제를 다시 설치해야 할 수도 있습니다. Microsoft는 레지스트리 편집기를 잘못 사용함으로써 발생하는 문제에 대해 해결을 보증하지 않습니다. 레지스트리 편집기의 사용에 따른 모든 책임은 사용자에게 있습니다.
터미널 서버에서 만든 새로운 모든 연결에 대한 기본 포트를 변경하려면 다음과 같이 하십시오.
"PortNumber" 하위 키를 찾아 값이 (3389)의 16진수 값인 00000D3D인지 확인합니다. 16진수로 포트 번호를 수정하고 새 값을 저장합니다.
참고: Terminal Server 4.0에서 대체 포트 사용이 완전히 구현되지 않았기 때문에 Microsoft는 "합당한 노력"을 기울여 지원할 것이지만 문제가 발생하는 경우 포트를 3389로 다시 설정해야 할 수 있습니다.
클라이언트 쪽에서 포트를 변경하려면
클라이언트 연결 관리자를 엽니다.
파일 메뉴에서 새 연결을 누른 다음 새 연결을 만듭니다. 마법사를 실행하면 마법사에 새 연결이 표시됩니다.
새 연결이 선택되어 있는지 확인하고 파일 메뉴에서 내보내기를 누릅니다. 파일을 name.cns로 저장합니다.
메모장에서 .cns 파일을 편집하여 "Server Port=3389"를 "Server Port=xxxx"로 변경합니다. 여기서 xxxx는 터미널 서버에서 지정한 새 포트입니다.
이제 클라이언트 연결 관리자로 파일을 다시 가져옵니다. 이름이 같은 파일이 있으면 해당 파일을 덮어쓸 것인지 묻는 메시지가 나타날 수 있습니다. 계속 진행하여 파일을 덮어씁니다. 이제 클라이언트의 포트 설정이 변경된 터미널 서버 설정과 일치합니다.
참고 Windows 2000 터미널 서버 ActiveX 클라이언트는 TCP 포트 3389에만 연결됩니다. 이 구성은 변경할 수 없습니다. Microsoft Windows XP와 Microsoft Windows Server 2003에서 사용할 수 있는 터미널 서버 ActiveX 클라이언트는 포트 설정을 수정하는 기능을 지원합니다. 자세한 내용은 Microsoft 기술 자료의 다음 문서를 참조하십시오.
326945(http://support.microsoft.com/kb/326945/ ) Windows Terminal Server 웹 클라이언트에서 수신 대기 포트를 변경하는 방법
참고: 새 수신 대기 포트가 활성화되기 전에 터미널 서버를 다시 시작하거나 터미널 서비스 구성을 통해 RDP 수신기를 다시 만들어야 합니다.
