As such, they have many of the same storage and management issues that passwords have in automation.Ĭertificate-based authentication uses a shared certificate model the client and the app registration are both configured with the same certificate and consequently can use a self-signed certificate. When authenticating directly as an app registration, there are two supported mechanisms:Ĭlient secrets are essentially just very strong passwords. It can be permitted to directly perform specific operations, or it can be enabled to provide delegated access to Azure resources on behalf of the user accessing the application-much as a service account in AD can leverage Kerberos Constrained Delegation (KDC) to impersonate a user to a specific resource. Administrators may be tempted to use a known service account password to bypass controls such as Privileged Identity Management (PIM) and MFA unless controls are put in place.Īpp Registrations and Certificates: A Better Way?Īn app registration in Azure is much like an application service account in Active Directory (AD).Password-only authentication without MFA is more vulnerable to issues such as password reuse or weak passwords if good password policies aren’t implemented.This can be partially mitigated for external attack by restricting the account to access only from specific public IP addresses, but this approach again creates an additional administrative burden This creates an additional administrative burden on the accounts used for script automation and puts them at risk if the credentials are leaked.The service account must be excluded from MFA requirements, since there is currently no way to satisfy MFA from an automated script. ![]() In the example, the password is trivially retrievable in the script directly from the PSCredential object-but there are other avenues external to the script whereby an attacker might obtain the password, depending on the storage and encryption methods used. Even if the password is stored in an encrypted format, it must be accessible and decryptable by the script.To create the PSCredential object, the script needs access to the service account password, which should be stored in an encrypted format (unlike the clear text of the example above). Unfortunately, there is no way to require a script to store the password in an encrypted format, and an administrator may choose to use plaintext out of expediency or ignorance. A plaintext password can be retrieved with just simple file system access to the script or associated storage and introduces other vectors for the credential to leak (e.g., backups that aren’t adequately secured).There are problems with this approach, however: $Credential.GetNetworkCredential().PasswordĬode language: PowerShell ( powershell ) Figure 1 Connecting with a credential object Get-AzureADUser -SearchString script | Select-Object DisplayName $SecureString = ConvertTo-SecureString -String "SuperSecretPasswordShh!" -AsPlainText -Force $Credential = New-Object $SecureString Connect-AzureAD -Credential $Credential | Select-Object Account, TenantDomain This approach is illustrated in the following code and in Figure 1. ![]() Most Azure PowerShell modules support automation by allowing the script to authenticate as a user account using a PSCredential object to pass the user ID and password. A common pattern for administrators is to create a regular Azure account as a “service account” for use with the script, assign it the requisite permissions, then authenticate as the service account in the context of the script. When these scripts are run interactively, the administrator can enter their password directly and respond to multi-factor authentication (MFA) prompts. From an authentication perspective, running such a script isn’t any less secure than the administrator performing the actions manually. However, when the scripts are automated (e.g., run as a scheduled job), things become more complicated. ![]() In the Microsoft Azure world, PowerShell has long been the automation tool of choice for administrators coming from a Windows background. In some cases, PowerShell has been the only tool to accomplish certain tasks because the deployment of new capabilities in Azure often exceeds the pace of updating the Azure Portal. Experienced Azure administrators are likely to have a repository of useful scripts to accomplish anything from managing license assignments to automating complicated virtual machine (VM) deployments. Being able to automate tasks ensures consistency and prevents mistakes caused by forgetfulness or by simply mistyping or mis-clicking-aka “fat-finger errors.” Automation is a fundamental requirement for good systems administration, no matter what the platform.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |