היום נדבר על Azure AD Password Protection אשר מאפשר לנו להגן על זהות המשתמש בענן וגם בסביבה ההיברידית שלנו.
ניתן לבצע בדיקות על סיסמאות מסוימות בשרתים המקומיים ולאכוף סיסמאות בשתי סוגים בעבודה מול Azure AD:
Microsoft Global Banned Passwords - סיסמאות גלובליות שאסור להשתמש בהם עפ"י רשימה קיימת של מייקרוסופט
Custom Banned Passwords – רשימת סיסמאות שאנחנו יכולים לקבוע מהם הסיסמאות שייחסמו
במידה ואנחנו עובדים בתצורה של Cloud Only הכוונה היא שכלל הניהול עצמו נמצא אך ורק דרך O365\Azure AD Portal, ההגדרות נעשות ברמת Azure AD.
בסביבה היברידית, המצב מצריך הגדרה של השירות אל מול שרתי ה-DC בארגון.
דרישות להתקנת השירות :
• שרתי Windows Server 2012 R2 ומעלה ( לטובת התקנת DC+Proxy Agents) .
• AD Functional Level : Windows Server 2012 and Higher
• תמיכה בDFSR בשרתי הDC .
• .NET Framework 4.5 מותקן באותם שרתים .
• Global Admin על מנת לרשום את שירות הProxy עבור AAPP (Azure AD Password Protection) .
• Domain Admin על מנת לרשום את הדומיין שלנו אל מול Azure AD .
• Allow Outbound Traffic TLS 1.2 HTTP Traffic
ראו מטה דוגמה לתצורה של Single Forest Deployment והסבר על התקנת השירותים:
Single AD Forest Deployment
Install and configure the proxy service for password protection
1. Choose one or more servers to host the proxy service for password protection.
o Each such service can only provide password policies for a single forest. The host machine must be joined to a domain in that forest. Root and child domains are both supported. You need network connectivity between at least one DC in each domain of the forest and the password protection machine.
o You can run the proxy service on a domain controller for testing. But that domain controller then requires internet connectivity, which can be a security concern. We recommend this configuration for testing only.
o We recommend at least two proxy servers for redundancy. See High availability.
2. Install the Azure AD Password Protection Proxy service using the AzureADPasswordProtectionProxySetup.exe software installer.
o The software installation does not require a reboot. The software installation may be automated using standard MSI procedures, for example:
AzureADPasswordProtectionProxySetup.exe /quiet
Note
The Windows Firewall service must be running before you install the AzureADPasswordProtectionProxySetup.msi package to avoid an installation error. If Windows Firewall is configured to not run, the workaround is to temporarily enable and run the Firewall service during the installation. The proxy software has no specific dependency on Windows Firewall after installation. If you're using a third-party firewall, it must still be configured to satisfy the deployment requirements. These include allowing inbound access to port 135 and the proxy RPC server port. See Deployment requirements.
3. Open a PowerShell window as an administrator.
o The password protection proxy software includes a new PowerShell module, AzureADPasswordProtection. The following steps run various cmdlets from this PowerShell module. Import the new module as follows:
PowerShellCopy
Import-Module AzureADPasswordProtection
o To check that the service is running, use the following PowerShell command:
Get-Service AzureADPasswordProtectionProxy | fl.
The result should show a Status of "Running."
4. Register the proxy.
o After step 3 is completed, the proxy service is running on the machine. But the service doesn't yet have the necessary credentials to communicate with Azure AD. Registration with Azure AD is required:
Register-AzureADPasswordProtectionProxy
This cmdlet requires global administrator credentials for your Azure tenant. You also need on-premises Active Directory domain administrator privileges in the forest root domain. After this command succeeds once for a proxy service, additional invocations of it will succeed but are unnecessary.
The Register-AzureADPasswordProtectionProxy cmdlet supports the following three authentication modes.
Interactive authentication mode:
PowerShellCopy
Register-AzureADPasswordProtectionProxy -AccountUpn 'yourglobaladmin@yourtenant.onmicrosoft.com'
Note
This mode doesn't work on Server Core operating systems. Instead, use one of the following authentication modes. Also, this mode might fail if Internet Explorer Enhanced Security Configuration is enabled. The workaround is to disable that Configuration, register the proxy, and then re-enable it.
Device-code authentication mode:
PowerShell Copy
Register-AzureADPasswordProtectionProxy -AccountUpn 'yourglobaladmin@yourtenant.onmicrosoft.com' -AuthenticateUsingDeviceCode
To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code XYZABC123 to authenticate.
You then complete authentication by following the displayed instructions on a different device.
Silent (password-based) authentication mode:
PowerShell Copy
$globalAdminCredentials = Get-Credential
Register-AzureADPasswordProtectionProxy -AzureCredential $globalAdminCredentials
Note
This mode fails if Azure Multi-Factor Authentication is required. In that case, use one of the previous two authentication modes.
You don't currently have to specify the -ForestCredential parameter, which is reserved for future functionality.
5. Registration of the proxy service for password protection is necessary only once in the lifetime of the service. After that, the proxy service will automatically perform any other necessary maintenance.
6. Tip
7. There might be a noticeable delay before completion the first time that this cmdlet is run for a specific Azure tenant. Unless a failure is reported, don't worry about this delay.
8. Register the forest.
o You must initialize the on-premises Active Directory forest with the necessary credentials to communicate with Azure by using the Register-AzureADPasswordProtectionForest PowerShell cmdlet. The cmdlet requires global administrator credentials for your Azure tenant. It also requires on-premises Active Directory domain administrator privileges in the forest root domain. This step is run once per forest.
The Register-AzureADPasswordProtectionForest cmdlet supports the following three authentication modes.
Interactive authentication mode:
PowerShellCopy
Register-AzureADPasswordProtectionForest -AccountUpn 'yourglobaladmin@yourtenant.onmicrosoft.com'
Note
This mode won't work on Server Core operating systems. Instead use one of the following two authentication modes. Also, this mode might fail if Internet Explorer Enhanced Security Configuration is enabled. The workaround is to disable that Configuration, register the proxy, and then re-enable it.
Device-code authentication mode:
PowerShellCopy
Register-AzureADPasswordProtectionForest -AccountUpn 'yourglobaladmin@yourtenant.onmicrosoft.com' -AuthenticateUsingDeviceCode
To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code XYZABC123 to authenticate.
You then complete authentication by following the displayed instructions on a different device.
Silent (password-based) authentication mode:
PowerShell Copy
$globalAdminCredentials = Get-Credential
Register-AzureADPasswordProtectionForest -AzureCredential $globalAdminCredentials
Note
This mode fails if Azure Multi-Factor Authentication is required. In that case, use one of the previous two authentication modes.
These examples only succeed if the currently signed-in user is also an Active Directory domain administrator for the root domain. If this isn't the case, you can supply alternative domain credentials via the -ForestCredential parameter.
9. Note
10. If multiple proxy servers are installed in your environment, it doesn't matter which proxy server you use to register the forest.
11. Tip
12. There might be a noticeable delay before completion the first time that this cmdlet is run for a specific Azure tenant. Unless a failure is reported, don't worry about this delay.
13. Registration of the Active Directory forest is necessary only once in the lifetime of the forest. After that, the Domain Controller Agents in the forest will automatically perform any other necessary maintenance. After Register-AzureADPasswordProtectionForest runs successfully for a forest, additional invocations of the cmdlet succeed but are unnecessary.
14. For Register-AzureADPasswordProtectionForest to succeed, at least one domain controller running Windows Server 2012 or later must be available in the proxy server's domain. But the DC Agent software doesn't have to be installed on any domain controllers before this step.
15. Configure the proxy service for password protection to communicate through an HTTP proxy.
If your environment requires the use of a specific HTTP proxy to communicate with Azure, use this method: Create a AzureADPasswordProtectionProxy.exe.config file in the %ProgramFiles%\Azure AD Password Protection Proxy\Service folder. Include the following content:
XMLCopy
<configuration>
<system.net>
<defaultProxy enabled="true">
<proxy bypassonlocal="true"
proxyaddress="http://yourhttpproxy.com:8080" />
</defaultProxy>
</system.net>
</configuration>
If your HTTP proxy requires authentication, add the useDefaultCredentials tag:
XMLCopy
<configuration>
<system.net>
<defaultProxy enabled="true" useDefaultCredentials="true">
<proxy bypassonlocal="true"
proxyaddress="http://yourhttpproxy.com:8080" />
</defaultProxy>
</system.net>
</configuration>
In both cases, replace http://yourhttpproxy.com:8080 with the address and port of your specific HTTP proxy server.
If your HTTP proxy is configured to us an authorization policy, you must grant access to the Active Directory computer account of the machine that hosts the proxy service for password protection.
We recommend that you stop and restart the proxy service after you create or update the AzureADPasswordProtectionProxy.exe.config file.
The proxy service doesn't support the use of specific credentials for connecting to an HTTP proxy.
16. Optional: Configure the proxy service for password protection to listen on a specific port.
o The DC Agent software for password protection on the domain controllers uses RPC over TCP to communicate with the proxy service. By default, the proxy service listens on any available dynamic RPC endpoint. But you can configure the service to listen on a specific TCP port, if this is necessary because of networking topology or firewall requirements in your environment.
To configure the service to run under a static port, use the Set-AzureADPasswordProtectionProxyConfiguration cmdlet.
PowerShellCopy
Set-AzureADPasswordProtectionProxyConfiguration –StaticPort <portnumber>
Warning
You must stop and restart the service for these changes to take effect.
To configure the service to run under a dynamic port, use the same procedure but set StaticPort back to zero:
PowerShellCopy
Set-AzureADPasswordProtectionProxyConfiguration –StaticPort 0
Warning : You must stop and restart the service for these changes to take effect.
17. Note
18. The proxy service for password protection requires a manual restart after any change in port configuration. But you don't have to restart the DC Agent service software on domain controllers after you make these configuration changes.
o To query for the current configuration of the service, use the Get-AzureADPasswordProtectionProxyConfiguration cmdlet:
PowerShell Copy
Get-AzureADPasswordProtectionProxyConfiguration | fl
ServiceName : AzureADPasswordProtectionProxy
DisplayName : Azure AD password protection Proxy
StaticPort : 0
Install the DC Agent service
Install the DC Agent service for password protection by using the AzureADPasswordProtectionDCAgentSetup.msi package.
The software installation, or un-installation, requires a restart. This is because password filter DLLs are only loaded or unloaded by a restart.
You can install the DC Agent service on a machine that's not yet a domain controller. In this case, the service will start and run but remain inactive until the machine is promoted to be a domain controller.
You can automate the software installation by using standard MSI procedures. For example:
msiexec.exe /i AzureADPasswordProtectionDCAgentSetup.msi /quiet /qn
Warning: The example msiexec command here causes an immediate reboot. To avoid that, use the /norestart flag. The installation is complete after the DC Agent software is installed on a domain controller, and that computer is rebooted. No other configuration is required or possible.
דגש חשוב : השירות הנ"ל מצריך גישה אל הכתובות הבאות :
פורסם במקור בפורטל אז'ור
להכרזה הרשמית מפי מייקרוסופט לחצו כאן
מאת : עידן נפתלי | יועץ וארכיטקט תשתיות מחשוב , פתרונות ענן ואבטחת מידע | U-BTech Solutions
היום נדבר על Azure AD Password Protection אשר מאפשר לנו להגן על זהות המשתמש בענן וגם בסביבה ההיברידית שלנו.
ניתן לבצע בדיקות על סיסמאות מסוימות בשרתים המקומיים ולאכוף סיסמאות בשתי סוגים בעבודה מול Azure AD:
Microsoft Global Banned Passwords - סיסמאות גלובליות שאסור להשתמש בהם עפ"י רשימה קיימת של מייקרוסופט
Custom Banned Passwords – רשימת סיסמאות שאנחנו יכולים לקבוע מהם הסיסמאות שייחסמו
במידה ואנחנו עובדים בתצורה של Cloud Only הכוונה היא שכלל הניהול עצמו נמצא אך ורק דרך O365\Azure AD Portal, ההגדרות נעשות ברמת Azure AD.
בסביבה היברידית, המצב מצריך הגדרה של השירות אל מול שרתי ה-DC בארגון.
דרישות להתקנת השירות :
• שרתי Windows Server 2012 R2 ומעלה ( לטובת התקנת DC+Proxy Agents) .
• AD Functional Level : Windows Server 2012 and Higher
• תמיכה בDFSR בשרתי הDC .
• .NET Framework 4.5 מותקן באותם שרתים .
• Global Admin על מנת לרשום את שירות הProxy עבור AAPP (Azure AD Password Protection) .
• Domain Admin על מנת לרשום את הדומיין שלנו אל מול Azure AD .
• Allow Outbound Traffic TLS 1.2 HTTP Traffic
ראו מטה דוגמה לתצורה של Single Forest Deployment והסבר על התקנת השירותים:
Single AD Forest Deployment
Install and configure the proxy service for password protection
1. Choose one or more servers to host the proxy service for password protection.
o Each such service can only provide password policies for a single forest. The host machine must be joined to a domain in that forest. Root and child domains are both supported. You need network connectivity between at least one DC in each domain of the forest and the password protection machine.
o You can run the proxy service on a domain controller for testing. But that domain controller then requires internet connectivity, which can be a security concern. We recommend this configuration for testing only.
o We recommend at least two proxy servers for redundancy. See High availability.
2. Install the Azure AD Password Protection Proxy service using the AzureADPasswordProtectionProxySetup.exe software installer.
o The software installation does not require a reboot. The software installation may be automated using standard MSI procedures, for example:
AzureADPasswordProtectionProxySetup.exe /quiet
Note
The Windows Firewall service must be running before you install the AzureADPasswordProtectionProxySetup.msi package to avoid an installation error. If Windows Firewall is configured to not run, the workaround is to temporarily enable and run the Firewall service during the installation. The proxy software has no specific dependency on Windows Firewall after installation. If you're using a third-party firewall, it must still be configured to satisfy the deployment requirements. These include allowing inbound access to port 135 and the proxy RPC server port. See Deployment requirements.
3. Open a PowerShell window as an administrator.
o The password protection proxy software includes a new PowerShell module, AzureADPasswordProtection. The following steps run various cmdlets from this PowerShell module. Import the new module as follows:
PowerShellCopy
Import-Module AzureADPasswordProtection
o To check that the service is running, use the following PowerShell command:
Get-Service AzureADPasswordProtectionProxy | fl.
The result should show a Status of "Running."
4. Register the proxy.
o After step 3 is completed, the proxy service is running on the machine. But the service doesn't yet have the necessary credentials to communicate with Azure AD. Registration with Azure AD is required:
Register-AzureADPasswordProtectionProxy
This cmdlet requires global administrator credentials for your Azure tenant. You also need on-premises Active Directory domain administrator privileges in the forest root domain. After this command succeeds once for a proxy service, additional invocations of it will succeed but are unnecessary.
The Register-AzureADPasswordProtectionProxy cmdlet supports the following three authentication modes.
Interactive authentication mode:
PowerShellCopy
Register-AzureADPasswordProtectionProxy -AccountUpn 'yourglobaladmin@yourtenant.onmicrosoft.com'
Note
This mode doesn't work on Server Core operating systems. Instead, use one of the following authentication modes. Also, this mode might fail if Internet Explorer Enhanced Security Configuration is enabled. The workaround is to disable that Configuration, register the proxy, and then re-enable it.
Device-code authentication mode:
PowerShell Copy
Register-AzureADPasswordProtectionProxy -AccountUpn 'yourglobaladmin@yourtenant.onmicrosoft.com' -AuthenticateUsingDeviceCode
To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code XYZABC123 to authenticate.
You then complete authentication by following the displayed instructions on a different device.
Silent (password-based) authentication mode:
PowerShell Copy
$globalAdminCredentials = Get-Credential
Register-AzureADPasswordProtectionProxy -AzureCredential $globalAdminCredentials
Note
This mode fails if Azure Multi-Factor Authentication is required. In that case, use one of the previous two authentication modes.
You don't currently have to specify the -ForestCredential parameter, which is reserved for future functionality.
5. Registration of the proxy service for password protection is necessary only once in the lifetime of the service. After that, the proxy service will automatically perform any other necessary maintenance.
6. Tip
7. There might be a noticeable delay before completion the first time that this cmdlet is run for a specific Azure tenant. Unless a failure is reported, don't worry about this delay.
8. Register the forest.
o You must initialize the on-premises Active Directory forest with the necessary credentials to communicate with Azure by using the Register-AzureADPasswordProtectionForest PowerShell cmdlet. The cmdlet requires global administrator credentials for your Azure tenant. It also requires on-premises Active Directory domain administrator privileges in the forest root domain. This step is run once per forest.
The Register-AzureADPasswordProtectionForest cmdlet supports the following three authentication modes.
Interactive authentication mode:
PowerShellCopy
Register-AzureADPasswordProtectionForest -AccountUpn 'yourglobaladmin@yourtenant.onmicrosoft.com'
Note
This mode won't work on Server Core operating systems. Instead use one of the following two authentication modes. Also, this mode might fail if Internet Explorer Enhanced Security Configuration is enabled. The workaround is to disable that Configuration, register the proxy, and then re-enable it.
Device-code authentication mode:
PowerShellCopy
Register-AzureADPasswordProtectionForest -AccountUpn 'yourglobaladmin@yourtenant.onmicrosoft.com' -AuthenticateUsingDeviceCode
To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code XYZABC123 to authenticate.
You then complete authentication by following the displayed instructions on a different device.
Silent (password-based) authentication mode:
PowerShell Copy
$globalAdminCredentials = Get-Credential
Register-AzureADPasswordProtectionForest -AzureCredential $globalAdminCredentials
Note
This mode fails if Azure Multi-Factor Authentication is required. In that case, use one of the previous two authentication modes.
These examples only succeed if the currently signed-in user is also an Active Directory domain administrator for the root domain. If this isn't the case, you can supply alternative domain credentials via the -ForestCredential parameter.
9. Note
10. If multiple proxy servers are installed in your environment, it doesn't matter which proxy server you use to register the forest.
11. Tip
12. There might be a noticeable delay before completion the first time that this cmdlet is run for a specific Azure tenant. Unless a failure is reported, don't worry about this delay.
13. Registration of the Active Directory forest is necessary only once in the lifetime of the forest. After that, the Domain Controller Agents in the forest will automatically perform any other necessary maintenance. After Register-AzureADPasswordProtectionForest runs successfully for a forest, additional invocations of the cmdlet succeed but are unnecessary.
14. For Register-AzureADPasswordProtectionForest to succeed, at least one domain controller running Windows Server 2012 or later must be available in the proxy server's domain. But the DC Agent software doesn't have to be installed on any domain controllers before this step.
15. Configure the proxy service for password protection to communicate through an HTTP proxy.
If your environment requires the use of a specific HTTP proxy to communicate with Azure, use this method: Create a AzureADPasswordProtectionProxy.exe.config file in the %ProgramFiles%\Azure AD Password Protection Proxy\Service folder. Include the following content:
XMLCopy
<configuration>
<system.net>
<defaultProxy enabled="true">
<proxy bypassonlocal="true"
proxyaddress="http://yourhttpproxy.com:8080" />
</defaultProxy>
</system.net>
</configuration>
If your HTTP proxy requires authentication, add the useDefaultCredentials tag:
XMLCopy
<configuration>
<system.net>
<defaultProxy enabled="true" useDefaultCredentials="true">
<proxy bypassonlocal="true"
proxyaddress="http://yourhttpproxy.com:8080" />
</defaultProxy>
</system.net>
</configuration>
In both cases, replace http://yourhttpproxy.com:8080 with the address and port of your specific HTTP proxy server.
If your HTTP proxy is configured to us an authorization policy, you must grant access to the Active Directory computer account of the machine that hosts the proxy service for password protection.
We recommend that you stop and restart the proxy service after you create or update the AzureADPasswordProtectionProxy.exe.config file.
The proxy service doesn't support the use of specific credentials for connecting to an HTTP proxy.
16. Optional: Configure the proxy service for password protection to listen on a specific port.
o The DC Agent software for password protection on the domain controllers uses RPC over TCP to communicate with the proxy service. By default, the proxy service listens on any available dynamic RPC endpoint. But you can configure the service to listen on a specific TCP port, if this is necessary because of networking topology or firewall requirements in your environment.
To configure the service to run under a static port, use the Set-AzureADPasswordProtectionProxyConfiguration cmdlet.
PowerShellCopy
Set-AzureADPasswordProtectionProxyConfiguration –StaticPort <portnumber>
Warning
You must stop and restart the service for these changes to take effect.
To configure the service to run under a dynamic port, use the same procedure but set StaticPort back to zero:
PowerShellCopy
Set-AzureADPasswordProtectionProxyConfiguration –StaticPort 0
Warning : You must stop and restart the service for these changes to take effect.
17. Note
18. The proxy service for password protection requires a manual restart after any change in port configuration. But you don't have to restart the DC Agent service software on domain controllers after you make these configuration changes.
o To query for the current configuration of the service, use the Get-AzureADPasswordProtectionProxyConfiguration cmdlet:
PowerShell Copy
Get-AzureADPasswordProtectionProxyConfiguration | fl
ServiceName : AzureADPasswordProtectionProxy
DisplayName : Azure AD password protection Proxy
StaticPort : 0
Install the DC Agent service
Install the DC Agent service for password protection by using the AzureADPasswordProtectionDCAgentSetup.msi package.
The software installation, or un-installation, requires a restart. This is because password filter DLLs are only loaded or unloaded by a restart.
You can install the DC Agent service on a machine that's not yet a domain controller. In this case, the service will start and run but remain inactive until the machine is promoted to be a domain controller.
You can automate the software installation by using standard MSI procedures. For example:
msiexec.exe /i AzureADPasswordProtectionDCAgentSetup.msi /quiet /qn
Warning: The example msiexec command here causes an immediate reboot. To avoid that, use the /norestart flag. The installation is complete after the DC Agent software is installed on a domain controller, and that computer is rebooted. No other configuration is required or possible.
דגש חשוב : השירות הנ"ל מצריך גישה אל הכתובות הבאות :
פורסם במקור בפורטל אז'ור
להכרזה הרשמית מפי מייקרוסופט לחצו כאן
מאת : עידן נפתלי | יועץ וארכיטקט תשתיות מחשוב , פתרונות ענן ואבטחת מידע | U-BTech Solutions