Connect PowerShell to your Azure Subscription using Azure AD account

Standard

Just a cross post highlighting my blog entry on our team blog called  “Ask PFE Platforms” about using Azure AD to connect PowerShell to an Azure Subscription

“A while back I had shared with you a way to connect PowerShell to your Azure Subscription via the certificate method using Get-AzurePublishSettingsFile cmdlet. This method works as long as the subscription and certificates are valid, and it has limitations when more than one person is expected to be able to access the subscription. Also, Azure Resource Manager doesn’t accept certificate based authentication. Today, I would like to give you a quick overview on an alternative way using an Azure AD account. Going forward this is a preferred way as it enables mechanism to manage a subscription and is compatible with Azure Resource Manager”

Check it out…

http://blogs.technet.com/b/askpfeplat/archive/2015/11/23/an-alternative-way-to-connect-powershell-to-azure-using-an-azure-ad-account.aspx

Building a VM in Windows Azure using PowerShell in a few quick steps

Standard

Just a cross post highlighting my blog entry on our team blog called  “Ask PFE Platforms” about building VM in Windows Azure using PowerShell.

“……….today I would like to walk you through building a VM in Windows Azure using your favorite management tool ‘PowerShell’, and in doing so you will also unlock 133 cmdlets that will help you manage other services you may have running in Windows Azure. If you have not signed up for a 90 day trial yet, I suggest you give it a try. Also did you know if you have an existing MSDN subscription, you may be entitled to up to 1500 compute hours that’s $6500 in annual Windows Azure benefits at no charge.”

Check it out…

http://blogs.technet.com/b/askpfeplat/archive/2013/04/14/building-a-vm-in-windows-azure-using-powershell-in-a-few-quick-steps.aspx

 

PowerShell Web Access in Windows Server 2012

Standard

 

Just a cross post highlighting my blog entry on our team blog called  “Ask PFE Platforms” about a neat feature in Windows Server 2012 called PowerShell Web Access.

“…..you can use the new PowerShell Web Access (PSWA) feature in Windows Server 2012 to allow remote administrative access to a set of servers in your IT infrastructure. Furthermore, you can granularly delegate access and only expose specific administrative privileges to different levels of support teams in your IT environment. PowerShell Web Access (PSWA) brings great remote manageability in Windows Server 2012. It acts as a gateway to provide full or limited access into the PowerShell sessions on remote servers.”

Check it out..

http://blogs.technet.com/b/askpfeplat/archive/2012/09/17/want-remote-powershell-management-from-your-browser-see-how-powershell-web-access-in-windows-server-2012-may-help.aspx

PowerShell : Exporting multi-valued attribute via Export-Csv cmdlet

Standard

The attributes that are multi-valued are hard to export to a CSV via the Export-Csv cmdlet as the exported value just shows the string type in Excel/Notepad.

For instance, take a look below when I try to export the proxyAddresses attribute values in PowerShell console and to a CSV later.

image

image

I found out that you can using the join function i.e @{Name=’proxyAddresses’;Expression={[string]::join(“;”, ($_.proxyAddresses))}} can export the multiple values from a multi-valued attribute to a CSV accordingly.

So, this is how it would look for the query I ran above.

Get-QADUser test.user1 -IncludeAllProperties | select name,@{Name='proxyaddresses';Expression={[string]::join(";", ($_.proxyaddresses))}} | Export-Csv .testUser1.csv

To accomplish the export of all values in a spreadsheet/csv.

image

This should come handy also when you are trying to retrieve the ‘memberof’ attribute of users and trying to export all groups that a user is part of to a CSV. Just replace the attribute you are after in the join function above.

Add -notype paramater at the end of the export-csv cmdlet to avoid the #type information in the first row in csv.

Running PowerShell under “run-as” or elevated privileges

Standard

There are times when I am in a PowerShell session and pass another set of credentials when I use connect-qadservice cmdlet to connect to another domain with the –credential parameter, however often times I would launch the PowerShell under “run-as” with the elevated credentials and launch a native session and I would have multiple session going at the same time. For latter scenario, I needed a way to identify which is which to adhere to a safe practice. There are probably other ways to tackle this but you can create PowerShell profile in each of your elevated session and change the look and feel as below.

Launch the PowerShell under run-as and run this :

new-item -path $profile -type file -force

notepad $profile

And add the following line into your profile

(get-host).UI.RawUI.Foregroundcolor=”yellow”

You may also want to add a different ‘window’ title for your admin session, you can add this.

$a = (Get-Host).UI.RawUI
$a.WindowTitle = “Admin Session”

Save the changes in the notepad and launch your elevated PowerShell session to see the results.

image

See this for more changes and tweaks you can do to a PowerShell console.

http://technet.microsoft.com/en-us/library/ee156814.aspx

PowerShell : How do I create Trust ?

Standard

A question was raised on ActiveDir regarding the ability to create Trust via a command line utility. It was discussed how netdom is no longer a supported command line utility to create Trusts. I referenced a snip from AD Cook Book using PowerShell to create Trust via the .Net AD namespace method alternatively.(System.DirectoryServices.ActiveDirectory).

You can use following code to create a two-way transitive trust between the local forest and a remote forest. You will have to run this code on the opposite side of the trust in order for the trust to be fully functional.

$localfor=[System.DirectoryServices.ActiveDirectory.Forest]::getCurrent()
$strRemoteFor='remotedomain.net'
$strRemoteUser='administrator'
$strRemotePass='P@ssw0rd'
$remoteCon=New-Object
System.DirectoryService.ActiveDirectory.DirectoryContext('Forest',
$strRemoteFor,$strRemoteUser,$strRemotePass)
$trustDirection='BiDirectional'$localFor.CreateTrustRelationship
($remoteFor,$trustDirection)

PowerShell : How do I clear sIDhistory attribute ?

Standard

What is sIDhistory attribute ?

The sIDhistory attribute is the key attribute that holds the previous SID(s) of Users and Groups objects that facilitate the Active Directory migrations. It contains previous SIDs used for the object if the object was moved from another domain. Whenever an object is moved from one domain to another, a new SID is created and that new SID becomes the objectSID. The previous SID is added to the sIDHistory property. ADMT is one tool that allows you migrate SID from one domain to another, it calls on to the DsAddSidHistory API to accomplish this task.

However, there are times when you look into clearing the sIDhistory attribute after the migration is complete such as when you are attempting to avoid a token size bloat (kerberos token size threshold). You must do your homework before trying to remove sIDhistory, you should check the ACLs of your servers and applications and you should NOT clean up all groups (or users) at once, you should always try accessing the target resources and applications after sIDhistory has been cleared from a few groups/users, only after successful access (of a user that has re-authenticated – i.e. doesn’t have the SIDs from a group’s sIDhistory in his token), you should proceed with a mass removal.

To use PowerShell with Quest Cmdlets,

Get-QADUser user1 | %{Set-QADUser $_ -ObjectAttributes @{sIDHistory=@{delete=$_['sIDHistory']}}}

You may also pass a list of users or groups

Get-QADUser (get-content users.txt) | %{Set-QADUser $_ -ObjectAttributes @{sIDHistory=@{delete=$_['sIDHistory']}}}

PowerShell : How do I set the delegation sensitive flag on users and computers ?

Standard

Kerberos Delegation, constrained and unconstrained is a complex topic, and one that often comes up when Security implications of External/Forests Trusts are discussed. Few days ago, on ActiveDir a similar topic was shed light upon. In brief Brian Arkills sums it up below,

The other security implication that most folks seem oblivious to is the one that comes with unconstrained Kerberos delegation across a trust. When you’ve got a single domain/forest by itself, your domain admin group controls who/what can use delegation. Once you setup a trust to another domain, you extend that ability to the domain admins in the other domain(s). In other words, the domain admins in the other domain can choose to allow a user/computer in their domain to permit unconstrained Kerberos delegation using the user accounts in *your* domain. Almost everyone says unconstrained delegation is bad, and the assumption is that no one will use it. But there are no controls in the product to prevent its use, except by also preventing any delegation (i.e. by marking all or a subset of user accounts as ‘sensitive to delegation’). And of course, unconstrained delegation is the only way to use delegation across a forest trust meaning it’s the only game in town for certain scenarios.

A service that runs under an account that is trusted for Kerberos delegation can assume/impersonate the identity of a client requesting the service. This parameter sets the TrustedForDelegation property of an account object. This value also sets the ADS_UF_TRUSTED_FOR_DELEGATION flag of the Active Directory User Account Control attribute.

It is that marking of the user accounts as “delegation sensitive” with PowerShell is what I would like to share with you.

image

For user and computer accounts, as stated above the setting is enclosed under the useraccountcontrol bits.

http://support.microsoft.com/kb/305144

We take the TRUSTED_FOR_DELEGATION and its associated value in decimal i.e 524288 and assign it a variable.

$NOT_DELEGATED=1048576

Using Quest Cmdlets, we use the Set-QADUser and use the bitwise exclusive operator to set the flag as sensitive (Thanks to Shay Levy for helping me with the correct bitwise syntax)

Get-QADUser user1  |
    Set-QADObject $_ -ObjectAttributes @{userAccountControl= ($_.userAccountControl -bxor $NOT_DELEGATED)}

For computer accounts, there is an explicit parameter for the Set-QADComputer Cmdlet i.e -TrustForDelegation

With ADWS (the native AD Cmdlets) the same parameter (being applicable to both i.e users and computers) for Set-ADUser and Set-ADComputer is called –TrustedForDelegation.

By default, when an account has been granted delegation privileges *every* user account can be “impersonated” in this way. However, with above you can mark certain user accounts as “delegation sensitive”, which means that those user accounts can never be used in a delegation scenario. Marking admin accounts as delegation sensitive is highly recommended. Generally, delegation is used with Kerberos, but there is an option to use protocol transition so that NTLM might be used on some of the hops (this is called S4U). Also note that for service accounts (user accounts), the delegation tab will only appear (allowing for the constrained delegation) when there is a SPN registered against that user account.

image

More reading here :

http://blogs.technet.com/b/askds/archive/2008/03/06/kerberos-for-the-busy-admin.aspx

http://blogs.technet.com/b/askds/archive/2008/06/13/understanding-kerberos-double-hop.aspx

PowerShell : How to lookup Schema version of your forest ?

Standard

The schema version is revealed via the objectversion attribute off of the schema object from your configuration head of the forest i.e “cn=schema,cn=configuration,dc=yourdomain,dc=int”.

So using Quest Cmdlets, you can run this query :

Get-QADObject "cn=schema,cn=configuration,dc=yourdomain,dc=int" -ip objectversion | select objectversion

qadobject_sv

The –ip is the alias for includedproperties.

And, when using the native AD Cmdlets of Server 2008 R2 (ADWS), the syntax is slightly different ;

Get-ADObject "cn=schema,cn=configuration,dc=r2,dc=lab" -properties objectversion

qadobject_sv1

Above, you see the query ran with Quest Cmdlets resulting in objectversion 31 which is against a Server 2003 R2 Forest, whereas the latter is for a Server 2008 R2 Forest i.e Schema version 47.

Reviewing few very useful adds in Quest AD Cmdlets v1.4

Standard

Whereas most of newly added cmdlets focus on  PKI and Email Address Management in v1.4, there are a few cmdlets and handful of new parameters that ought to come in very handy with your AD tasks. Below I review a few that I think are some great adds :

When you are enumerating a large number of objects in shell (without outputting results into a file), you might just want to have a quick idea of the ‘total’ number of objects meeting the criteria of you query.

Get-QADProgressPolicy

“displays a progress bar for long-running commands”

progress_bar

This progress bar overlays (highlights in and out) as your query is running. It also appears when you are performing a count using the measure-object cmdlet or the “.count” switch

progress_bar2

You can set the progress bar setting and its threshold with

Set-QADProgressPolicy -ShowProgress $true -ProgressThreshold 2

The –activity parameter when relying on the progress bar allows you tag each line of progress with a number so that lengthy process is a bit more obvious with respect to the process to one or more cmdlet’s retrieved results.

Some new parameters :

Five new parameters for Get-QADUser

ExpiredFor

Inactive

InactiveFor

NotLoggedOnFor

PasswordNotChangedFor

Four new parameters for Get-QADComputer

Inactive

InactiveFor

NotLoggedOnFor

PasswordNotChangedFor

But what mechanism decides the “inactivity” benchmark to ask cmdlet to retrieve that information ?

You do.

Get-QADInactiveAccountsPolicy

inactivepolicy1

You can change these settings,

Set-QADInactiveAccountsPolicy -AccountExpiredPeriod 0 -AccountNotLoggedOnPeriod 30 –PasswordNotChangedPeriod 120

.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, “Courier New”, courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }
.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, “Courier New”, courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }

Note : These settings are profile specific so ones you define these thresholds they will stay there until you change those settings again.

The NotLoggedOnPeriod is probably based on the LastLogonTimeStamp, but I will check and edit this post if its any different. If it is, remember it may not be accurate and should only be used for estimation. The LastLogonTimeStamp gets updated from the LastLogon (DC specific attribute) based on a 9-14 day swing period.

Also :

“This parameter overrides the logon-related inactivity condition of the Inactive or InactiveFor parameter. Thus, if the NotLoggedOnFor value of 60 is supplied in conjunction with the InactiveFor value of 30, the cmdlet searches for accounts that are expired for 30 or more days, or have the password age of 30 or more days, or have not been used to log on for 60 or more days.”

Previously if you had to use the Get-QADGroupMember cmdlet to retrieve the enabled accounts only, you had to pass the LDAPFilter, now you can use the same –enabled and –disabled parameter as you could with Get-QADUser cmdlet since v1.3.

groupmemberdisabled

This and much more. All details can be found here.

The folks who develop these cmdlets and work on adding new parameters do take the feedback very seriously. I have myself asked and gotten couple of requests met. You can do the same.