728x90

SYSVOL is a folder shared by domain controller to hold its logon scripts, group policies and other items related to AD. All the domain controllers in network will replicate the content of SYSVOL folder. The default path for SYSVOL folder is %SystemRoot%\SYSVOL. This folder path can define when you install the active directory. 
Windows Server 2003 and 2003 R2 uses File Replication Service (FRS) to replicate SYSVOL folder content to other domain controllers. But Windows server 2008 and later uses Distributed File System (DFS) for the replication.  DFS is more efficient than FRS. Since windows server 2003 is going out of support, most people already done or still looking for migrate in to latest versions. However migrating FSMO roles WILL NOT migrate SYSVOL replication from FRS to DFS. Most of the engineers forget about this step when they migrate from windows 2003 to new versions. 
For FRS to DFS migration we uses the Dfsrmig.exe utility. More info about it available on https://technet.microsoft.com/en-au/library/dd641227(v=ws.10).aspx
For the demo I am using windows server 2012 R2 server and I migrated FSMO roles already from a windows server 2003 R2 server. 
In order to proceed with the migration forest function level must set to windows server 2008 or later. So if your organization not done this yet first step is to get the forest and domain function level updated. 
You can verify if the system uses the FRS using dfsrmig /getglobalstate , To do this
1)    Log in to domain controller as Domain admin or Enterprise Admin
2)    Launch powershell console and type dfsrmig /getglobalstate. Output explains it’s not initiated DFRS migration yet. 


Before move in to the configurations we need to look into stages of the migration. 
There are four stable states going along with the four migration phases. 
1)    State 0 – Start
2)    State 1 – Prepared
3)    State 2 – Redirected 
4)    State 3 – Eliminated 
State 0 – Start
With initiating this state, FRS will replicate SYSVOL folder among the domain controllers. It is important to have up to date copy of SYSVOL before begins the migration process to avoid any conflicts. 
State 1 – Prepared
In this state while FRS continues replicating SYSVOL folder, DFSR will replicate a copy of SYSVOL folder. It will be located in %SystemRoot%\SYSVOL_DFRS by default. But this SYSVOL will not response for any other domain controller service requests. 
State 2 – Redirected
In this state the DFSR copy of SYSVOL starts to response for SYSVOL service requests. FRS will continue the replication of its own SYSVOL copy but will not involve with production SYSVOL replication.
State 3 – Eliminated
In this state, DFS Replication will continue its replication and servicing SYSVOL requests. Windows will delete original SYSVOL folder users by FRS replication and stop the FRS replication. 
In order to migrate from FRS to DFSR its must to go from State 1 to State 3.
Let’s look in to the migration steps.
Prepared State
1.    Log in to domain controller as Domain admin or Enterprise Admin
2.    Launch powershell console
3.    Type dfsrmig /setglobalstate 1 and press enter



4.    Type dfsrmig /getmigrationstate to confirm all domain controllers have reached prepared state


Redirected State

1.    Log in to domain controller as Domain admin or Enterprise Admin
2.    Launch powershell console
3.    Type dfsrmig /setglobalstate 2 and press enter


4.    Type dfsrmig /getmigrationstate to confirm all domain controllers have reached redirected state


Eliminated State

1.    Log in to domain controller as Domain admin or Enterprise Admin
2.    Launch powershell console
3.    Type dfsrmig /setglobalstate 3 and press enter



4.    Type dfsrmig /getmigrationstate to confirm all domain controllers have reached eliminated state


This completes the migration process and to confirm the SYSVOL share, type net share command and enter.


Also make sure in each domain controller FRS service is stopped and disabled.

728x90
728x90

Password reset for AD users is a common call, ticket for the help desk. This is sometime negatively affecting company operations. Because users will not have access to systems and applications until the password reset by help desk engineers. What if we can allow end users to reset their passwords them self in a secure manner?
Yes Azure AD is now gives opportunity to enable self-service password reset for the end-users. Also the password resets can sync with on-premises AD.
This feature is disabled by default. In this demo I will explain how to enable this feature and configure. 
On the demo setup I am using have Azure AD instance which is sync with on-premises windows server 2016 TP4 AD.
1)    Log in to the Azure Portal and load the Azure AD Instance
2)    Then in Dashboard, under configure services you can find option “Self Service Password Reset” By default it’s disabled. Click on “Configure” to proceed with configuration. 



3)    Then in next page under User Password Reset Policy select option “Yes” next to “Users enabled for password reset”


4)    Now it will give you options to configure the policy for the password reset. Let’s look in to  some of these options and understand what they do. 
Restrict access to password reset – Using this option password reset can only allow for a security group instead of allowing it for every user in the instance. Any member of allowed security group will get option to do a self-service password reset. 
Authentication Methods Available to Users – its allow you to use following options to select with. We can allow to use any selected authentication methods for users.  
Number of Authentication Methods Required – In this option we can choose how many methods required for successful password reset


Require users to register when signing in? – When this option is enabled users can register their own authentication method when sign up. 

Write back passwords to on-premises active directory – with this option if a user reset password using self-service portal it will write back to the on-premises AD too.
In order to get this write back option work, it need to be enabled in Azure AD connect in on-premises AD. 


5)    In demo I am configuring “Security Questions” as authentication method. With that option you can define the different security questions, as well as the number of questions required to answer. 


6)    Once options are configure click on save to apply the changes.


7)    Let’s see how it works in user end.  I am trying to log in to azure portal as standard user. In first login it’s ask additional information to setup for password reset. Click on setup to provide the additional info.



8)    Now all the additional info is saved. Let’s see how it works. I am going to log in with wrong password to simulate it. As soon as I done it, it ask if you need to reset the login. 


9)    Clicked on “Forgot your password ?” option


10)    As first check it’s asking to enter the characters in picture. Click next to continue


11)    Then it ask which option to use for the password reset, according to the policy. Select the option you like to use. 


12)    Then it’s ask for the second authentication. As per the policy.


13)    Once authentication success, it’s ask to submit the new password. 


14)    Once its finish you can successfully login with new password. 

.

728x90
728x90

1. Application Gateway의 암호화

2. Application Gateway를 통한 트래픽 암호화 로직

3. Application Gateway의 TLS Termination

3.1 Backend Server TLS 암호화

4. Application Gateway의 TLS Termination 구성

4.1 SSL Certificate 만들기

4.1.1 회원 가입

4.1.2 Certificate 생성

4.1.3 도메인 인증

4.1.4 Certificate Download

4.1.5 SSL Certificate 포맷 변환 (.crt → .pfx)

4.2 Application Gateway에 Certificate 업로드

4.2.1 수신기 생성 및 Certificate 업로드

4.2.2 규칙 생성

4.3 HTTPS를 사용하여 Application 접근

            SSL/TLS란? 
https://sundlscha.tistory.com/11

 

SSL/TLS 알아 보기
1. SSL와 TLS란? SSL(Secure Socket Layer; 보안 전송 계층) 암호화 기반 인터넷 보안 프로토콜로 웹사이트와 브라우저 사이 또는 두 서버 사이에 전송되는 데이터를 암호화하여 인터넷 연결을 보호하기
sundlscha.tistory.com


 
1. Application Gateway의 암호화
먼저 Application Gateway의 암호화에 대해 정리해 보았습니다.  

Application Gateway Flow (https://learn.microsoft.com/ko-kr/training/modules/end-to-end-encryption-with-app-gateway/2-application-gateway-and-encryption)



Application Gateway는 전송 중 데이터 암호화를 위해 인증 기관에서 인증서를 구매하여 서버로 들어오고 나가는 메시지를 암호화할 수 있습니다. 이러한 암호화를 통해 전송 중인 메시지를 권한 없는 사용자가 가로채서 그 안에 있는 정보를 볼 수 없게 됩니다. 
Application Gateway는 HTTP 트래픽 로드 밸런싱, WAF 방화벽 및 데이터의 SSL 암호화 지원과 같은 기능을 제공합니다. 또한 사용자와 Application Gateway 간의 트래픽, Application Server와 Application Gateway 간의 트래픽 암호화를 지원합니다. 

기본적으로 SSL Termination 수행 시 사용자와 Application Gateway 간의 트래픽은 HTTPS로 암호화되고 Application Gateway와 Backend Server 간의 트래픽은 HTTP로 통신이 이루어집니다. 
만일, Application Gateway에서 Backend Server로 가는 트래픽 역시 HTTPS로 암호화하여 구성하고 싶을 경우 Application Gateway에서 지원하는 End-to-End TLS 암호화를 구성하면 됩니다. End-to-End TLS Encryption 설명 

(https://learn.microsoft.com/en-us/azure/application-gateway/ssl-overview#end-to-end-tls-encryption)




Application Gateway에서 SSL Termination을 수행할 경우 서버에 인증서를 설치하고 SSL을 구성할 필요가 없어집니다. 

 
2. Application Gateway를 통한 트래픽 암호화 로직
Application Gateway를 통한 트래픽이 암호화 되는 방식에 대해 좀 더 알아보겠습니다.
Application Gateway 구성 요소

 (https://learn.microsoft.com/ko-kr/training/modules/end-to-end-encryption-with-app-gateway/2-application-gateway-and-encryption)



트래픽은 Frontend의 포트를 통해 들어오고 수신기를 거쳐 규칙에 맞게 수신 요청을 Backend Pool에 전달합니다. 
수신기 (Listener)

특정 호스트, 특정 IP 주소의 특정 포트를 수신 대기하도록 설정된 리소스로 SSL 인증서를 사용하여 Application Gateway로 들어오는 트래픽을 암호 해독 할 수 있습니다. 
수신기가 지원하는 포트 (여러 포트 open 가능)는 다음과 같습니다.


3. Application Gateway의 TLS Termination
그렇다면 TLS Termination 구성의 장점은 무엇일까요?
(https://learn.microsoft.com/ko-kr/azure/application-gateway/ssl-overview#tls-termination에 대해서 읽어보시는 것을 권장 드립니다.)

●TLS 암호 해독 시 성능에 가장 부하를 주는 것은 초기 Handshake이기 때문에 Application Gateway에서 TLS Termination을 수행할 경우, Client의 모든 요청에 대해 캐시된 값을 사용할 수 있습니다. cf) Backend Server에서 TLS Termination 수행할 경우, Client의 요청이 다른 Server로 갈 때마다 Client가 다시 인증을 해야 하는 번거로움이 발생합니다. 
● SSL/TLS 통신 시 CPU 사용률이 높으며 SSL/TLS 통신 시 사용하는 키의 크기가 커짐에 따라 이 사용률은 더 증가하고 있습니다. 그렇기 때문에 Backend Server에서 이 작업을 하지 않을 경우 Server는 데이터를 가장 효율적으로 전달할 수 있는 방식에 대해서만 집중할 수 있게 됩니다.
● Application Gateway가 트래픽의 암호를 해독할 때 헤더, URI 등에 액세스 할 수 있기 때문에 이를 활용하여 요청을 지능적으로 라우팅할 수 있습니다.
● Application Gateway에만 Certificate를 설치하면 되기 때문에 시간과 비용을 절약할 수 있습니다. 

✅ TLS Termination을 구성하기 위해서는 TLS/SSL Certificate가 반드시 수신기에 구성되어 있어야 합니다.
✅ Application Gateway에 제공된 인증서는 개인키와 공개키를 모두 포함하는 PFX(개인 정보 교환) 형식이어야 합니다.
❌ Application Gateway는 새 인증서를 만들거나 인증 기관에 인증서 요청을 보내는 기능을 제공하지 않습니다.

 



 
이를 통해 Application Gateway는 들어오는 트래픽을 해독하고 Client에 대한 response 트래픽을 암호화할 수 있습니다. 
 
3.1 Backend Server TLS 암호화
※ 이번 포스팅에서는 이 부분에 대한 테스트를 다루고 있지는 않습니다.

  Backend Server로 전달되는 트래픽을 암호화하여 보내고자 할 경우 Application Gateway의 End-to-End TLS 암호화 기능을 사용하면 됩니다. 
  End-to-End TLS는 백 엔드 설정에서 백 엔드 프로토콜을 HTTPS로 변경하여 사용 가능합니다. 



 
4. Application Gateway의 TLS Termination 구성
4.1 SSL Certificate 만들기
4.1.1 회원 가입


  SSL Certificate를 무료로 발급할 수 있는 사이트(ex. https://www.sslforfree.com/) 접속한 후 회원 가입을 진행합니다.





Certificate 관련 메일이 수신되기 때문에 사용하는 메일을 이용해야 합니다.

4.1.2 Certificate 생성
[New Certificate] 클릭


Certificate를 발급 받고자 하는 도메인을 입력합니다.


[90-Day Certificate]를 선택합니다.



 
4.1.3 도메인 인증

실제로 도메인을 소유하고 있는지 여부를 확인하기 위한 단계로 제공하는 3가지 방법 (Email Verification, DNS(CNAME), HTTP File Upload) 중 가능한 방법으로 인증하면 됩니다. 
※ 본 테스트에서는 DNS(CNAME)을 사용하였습니다. 
 


Name, Point To, TTL을 각각 복사하여 DNS Provider에 CNAME Record를 추가합니다.




가비아에서 구매한 도메인에 대해 Azure DNS의 Name Server를 사용하도록 설정해 두었기 때문에 Azure Portal에 접속하여 해당 DNS Zone에 Record를 등록해야 합니다. 





 


4.1.4 Certificate Download

[Download Certificate (.zip)] 버튼을 클릭합니다. 


zip 파일을 압축 해제 합니다.



 
 
4.1.5 SSL Certificate 포맷 변환 (.crt → .pfx)

Win64 OpenSSL Command Prompt 실행한 후 다운로드 받은 폴더로 Directory를 변경합니다. 


pfx 파일로 변환하기 위해 하기와 같은 명령어를 입력합니다.

pkcs12 -export -out hyein-certificate.pfx -inkey private.key -in certificate.crt -certfile ca_bundle.crt


상기 명령어 실행 시 “Enter Export Password” 문구가 출력되면 Certificate의 암호로 사용할 password를 입력합니다.


변환된 Certificate를 확인합니다.



 
4.2 Application Gateway에 Certificate 업로드
4.2.1 수신기 생성 및 Certificate 업로드



 

프로토콜 : HTTPS
포트 : 443 # 기존에 수신기가 이미 존재할 경우, 그 수신기와 겹치지 않는 포트 기입 필요
PFX 인증서 파일 : # pfx 파일로 변환한 Certificate 업로드
암호 : # pfx 형식의 Certificate 생성 시 입력한 암호 입력

 
4.2.2 규칙 생성

[수신기] 선택


[백 엔드 대상] 선택



 
4.3 HTTPS를 사용하여 Application 접근

https://hyein.<domain name>을 입력하면 아래와 같이 정상적으로 Application에 접근이 가능한 것을 확인할 수 있습니다.





하기와 같이 주소창 옆  [사이트 정보 보기] 버튼을 클릭한 후 "이 연결은 안전합니다."라는 항목을 클릭할 시, 아래와 같이 인증서와 관련된 정보를 확인할 수 있습니다.

728x90

+ Recent posts