AD Managed Service accounts vs SharePoint Managed Accounts

So sometimes I get the following question from a customer:
“Can I use Managed Service Accounts with SharePoint?”
My answer is:
“What exactly do you mean?”
As the title of this post already gave away, there are 2 different types of Managed Accounts in the Microsoft ecosystem, being:

1. Active Directory Managed Services Accounts
   The managed service account is designed to provide crucial applications such as Exchange Server and IIS with the isolation of their own domain accounts, while eliminating the need for an administrator to manually administer the service principal name (SPN) and credentials for these accounts. Passwords are automatically created for the MSA when the account is created, and refreshed every 30 days. You can change a password manually. The default behavior is that the password for the managed service account is automatically updated.What you need to remember from that definition is: Managed Service Accounts are managed by Active Directory and provide automatic password updates.
2. SharePoint 2010/2013 Managed Accounts
   A Managed Account is an Active Directory user account whose credentials are managed by and contained within SharePoint.  In addition to storing the credentials of the object, Microsoft SharePoint Server 2010/2013 can also leverage Active Directory Domain Policies to  automatically reset passwords while meeting the requirements established by policy.What you need to remember from that definition is: Managed Accounts are managed by SharePoint (2010/2013) and provide automatic password updates.

Some interesting extra information: Active Directory Managed Service Accounts require the AD Schema to be on level Windows 2008 R2.
So, what can we use? Easy!
Active Directory Managed Service Accounts are NOT supported for SharePoint.
SharePoint Managed Accounts are used (if you like it or not) in SharePoint 2010 and 2013.
More information:
Great post about AD Managed Service Accounts:
http://blogs.technet.com/b/askds/archive/2009/09/10/managed-service-accounts-understanding-implementing-best-practices-and-troubleshooting.aspx
Great post about SharePoint Managed Accounts:
http://blogs.technet.com/b/wbaer/archive/2010/04/11/managed-accounts.aspx

Reference:

http://www.sharepointom.be/blog/?p=37

SharePoint 2010 New Feature: Managed Accounts

The following is an excerpt from the third issue of the SharePoint 2010 Beta series of USP Journal:
Another new feature of SharePoint 2010 is managed accounts. Consider having an application pool account, for example called DOMAIN\sp_user. You use that account for a large amount of web applications. Imagine the pain when changing the password for that account; you would need to go into each and every web application and reset the password after the change, not to mention that the applications you haven’t changed yet will stop working.
SharePoint 2010 introduces the managed account. In short, rather than specifying the user name and password on every occasion, you create a managed account and set the password there. Then, when you need to enter a user account you simply select which managed account to use and you don’t need to know the password.
This also allows farm administrators to set up the service accounts so that others do not need to know the password for the account.
Oh, but there’s more. Service accounts are usually left out of the password expiry policy for the very reasons stated above. However, this is a bad security practice, because the password for such service accounts is often weak or known by multiple people. Keeping a password unchanged for years also means that an attacker would have more time to break the password encryption.
So, SharePoint 2010 also introduces automatic password change. Simply set the managed account to change the password a number of days before the password expires, and SharePoint will keep and maintain the password for the service account without you having to do anything.
You can also set up alerts so that you are notified before the password expires, and what’s even better, SharePoint will automatically detect password expiration policies that are defined for you.

Reference:

http://blog.furuknap.net/sharepoint-2010-new-feature-managed-accounts

Service Accounts and Managed Service Accounts in SharePoint 2010

With SharePoint 2010 we now have the ability to allow SharePoint to manage various service accounts thus foregoing the need to have IT administrators manually manage password changes. This new feature is a great benefit to SharePoint administrators and security conscious admins in general as it allows us to easily enforce our corporate security policies by changing these passwords on a schedule, and the administrators don’t even know what the password is so the likelihood of a compromise due to a disgruntled admin, though not eliminated, is somewhat reduced.
But the introduction of this new feature isn’t all good. The complication comes from the fact that SharePoint 2010 doesn’t implement this capability consistently. So an account that is configured as a Managed Service Account and set to have its password changed automatically could also be used in certain places that don’t understand the managed account concept. When the managed account password is changed the feature that uses that account and only knows the username and password (so it does not use the managed account details) will effectively be broken. As an example, if you configure the Enterprise Search Service to use a managed account whose password is scheduled to be changed every 30 days and you use that same account for the content crawl account then when that password is changed the content crawl will cease to function as it will be unable to authenticate the account. It’s important to note, however, that this issue only comes to light when you configure the managed account to have it’s password changed automatically.
So what things can be managed accounts and what cannot? The following lists what I’ve come across so far (if I’ve missed anything please leave a comment so I can update these lists):
Managed Service Accounts:

• All Service Application Pool Accounts
  • Access Service Application
  • BCS Service Application
  • Excel Services Service Application
  • Metadata Service Application
  • PerformancePoint Service Application
  • Enterprise Search Service Application
  • Secure Store Service Application
  • Subscription Settings Service Application
  • User Profile Service Application
  • Visio Services Service Application
  • Web Analytics Service Application
  • Word Automation Service Application
  • Word Viewing Service Application
  • PowerPoint Viewing Service Application
  • Security Token Service Application
• All Content Web Application Pools
• Service Instances
  • Claims to Windows Token Service
  • Document Conversion Launcher Service
  • Document Conversion Load Balancer Service
  • Microsoft SharePoint Foundation Sandboxed Code Service
  • SharePoint Foundation Help Search
  • SharePoint Server Search (Enterprise Search)
  • Web Analytics Data Processing Service

Service Accounts (should not be managed):

• Search Crawl Accounts
  • For Foundation Search and Server (Enterprise) Search
• Unattended User Accounts
  • Excel Services Service Application
  • Visio Services Service Application
  • PerformancePoint Service Application
  • (in general, any Secure Store application credentials)
• Object Cache Portal Accounts
  • Super User Account
  • Super Reader Account
• User Profile
  • Synchronization Service Account (listed incorrectly on the FarmCredentialManagement.aspx page)
  • Synchronization Connection Account
• Server Search Custom Crawl Rule Accounts
  • Any crawl rule that specifies an account other than the default crawl account

Again, these are just the accounts that I’ve personally bumped up against so it may not be a complete listing.

Viewing and Creating Managed Accounts

To see the current list of Managed Service Accounts using Central Admin go to Security –> Configure managed accounts:





 You can edit the settings for any managed account by simply clicking the edit icon associated with the account you wish to modify. Once on the Manage Account screen you can configure the automatic password change settings:


To perform the same tasks using Windows PowerShell we can use the Get-SPManagedAccount cmdlet to retrieve the list of managed accounts:

Or we can retrieve a specific account using the -Identity parameter or by passing in a Web Application or Service:

clTo change the settings for a Managed Account we can use the Set-SPManagedAccount cmdlet:

To create a new Managed Account we use the New-SPManagedAccount cmdlet. In the example below I’m manually creating a PSCredential object so that I can specify my password (pa$$w0rd) in script (very useful for building out dev or test environments – otherwise you should use Get-Credential to prompt for the password so that it is not hard coded anywhere):

Applying Managed Accounts

Once you have your Managed Accounts created you can begin to use them for things such as Service Instances and Service and Content Application Pools. To associate a managed account with a specific Service Instance using Central Admin you can go to Security –> Configure service accounts. On the Service Accounts page you can set the account used for the Farm Account, Service Instances, Web Content Application Pools, and Service Application Pools. The Service Instances are highlighted in the following image:

Service Instances

To set the account associated with a particular Service Instance using Windows PowerShell we simply get the ProcessIdentity property of the Service Instance and set its Username property. Once set we call Update() to update the Configuration Database and then Deploy() to push the change out to all Service Instances. To make this easier I put this code in a function that I can call by passing in the Service Instance and credentials to use:
function Set-ServiceIdentity($svc, $username)
{
   $pi = $svc.Service.ProcessIdentity
   if ($pi.Username-ne $username) {
       $pi.Username= $username
       $pi.Update()
       $pi.Deploy()
    }
}
Here’s an example of how you can call this function:

Service Application Pools

To create a new Service Application pool we use the New-SPServiceApplicationPool cmdlet and pass in the name of the Application Pool to create and the Managed Account to assign as the Application Pool identity:

It’s extremely important to note that the application pool that you create using the New-ServiceApplicationPool cmdlet cannot be used for your content Web Applications. Unfortunately there is no out-of-the-box equivalent for creating Application Pools for Web Applications.

Web Application Pools

As previously noted there is no cmdlet for creating Application Pools for Web Applications. Instead what you need to do is first check if the Application Pool you need already exists by using the SPWebService’s ContentService static property. If it exists then pass in just the name of the Application Pool to the New-SPWebApplication cmdlet, otherwise pass in the name and the Managed Account to use as the Application Pool’s identity:

Applying Service Accounts

When it comes to applying non-managed accounts to the various features things get a little more complicated. Let’s start with the Crawl Accounts.

SharePoint Foundation Search Service

For SharePoint Foundation Search we can set the crawl account (or content access account) using Central Admin by navigating to the Services on Server page and clicking the SharePoint Foundation [Help] Search link which takes you to the settings page where we can set the crawl account:







To set the same information using Windows PowerShell we actually have to go old-school and use STSADM as there’s no PowerShell equivalent cmdlet. Here’s a snippet of PowerShell code that I use to accomplish this:

function ConvertTo-UnsecureString([System.Security.SecureString]$string)
{
    $unmanagedString = [System.Runtime.InteropServices.Marshal]::SecureStringToGlobalAllocUnicode($string)
    $unsecureString = [System.Runtime.InteropServices.Marshal]::PtrToStringUni($unmanagedString)
    [System.Runtime.InteropServices.Marshal]::ZeroFreeGlobalAllocUnicode($unmanagedString)

    return $unsecureString
}

$searchSvcAccount = Get-Credential "localdev\spsearchsvc"
$crawlAccount = Get-Credential "localdev\spcrawl"

$stsadmArgs = "-o spsearch -action start " + `
    "-farmserviceaccount `"$($searchSvcAccount.Username)`" " + `
    "-farmservicepassword `"$(ConvertTo-UnsecureString $searchSvcAccount.Password)`" " + `
    "-farmcontentaccessaccount `"$($crawlAccount.Username)`" " + `
    "-farmcontentaccesspassword `"$(ConvertTo-UnsecureString $crawlAccount.Password)`" " + `
    "-databaseserver `"spsql1`" " +  `
    "-databasename `"SharePoint_FoundationSearch`""

Write-Host "Running: stsadm $stsadmArgs"
$stsadmoutput = cmd /c "stsadm $stsadmArgs" 2>&1
if ($lastexitcode -ne 0) {
    throw "Unable to start Foundation Search Service.`n$stsadmoutput"
}

Note that I’m using a helper function to convert the secure password to a static string which I can then pass to the STSADM spsearch command.

SharePoint Server Search Service

To manage the crawl account for the SharePoint Server Search Service (also known as the Enterprise Search Service) using Central Admin we simply need to navigate to the Search Administration page of the Service Application that we wish to modify and click the link for the Default content access account. This will bring up the following screen:




Note that by default this account will be set to be the same account you used for the Search Service Instance which is a Managed Account. If you do not change this account and you have configured SharePoint to manage the account password then your crawls will fail when the password changes. To make this change using Windows PowerShell we use the Set-SPEnterpriseSearchServiceApplication cmdlet:
$crawlAccount = Get-Credential "localdev\spcrawl" $searchApp | Set-SPEnterpriseSearchServiceApplication -DefaultContentAccessAccountPassword $crawlAccount.Password -DefaultContentAccessAccountName $crawlAccount.Username
Remember not to do this step until after you have provisioned the Administration Component.

Object Cache Accounts

Many administrators when they first configure SharePoint 2010 and hit a Web Application for the first time are likely to see a recurring event in the event log stating that the object cache has not been configured correctly. The specific error is as follows:

Object Cache: The super user account utilized by the cache is not configured. This can increase the number of cache misses, which causes the page requests to consume unneccesary system resources.

This is essentially telling you that you have missed a manual configuration step in which you need to run some PowerShell to set two accounts for SharePoint to use to access the object cache:

function Set-WebAppUserPolicy($webApp, $userName, $userDisplayName, $perm) {
    [Microsoft.SharePoint.Administration.SPPolicyCollection]$policies = $webApp.Policies
    [Microsoft.SharePoint.Administration.SPPolicy]$policy = $policies.Add($userName, $userDisplayName)
    [Microsoft.SharePoint.Administration.SPPolicyRole]$policyRole = $webApp.PolicyRoles | where {$_.Name -eq $perm}
    if ($policyRole -ne $null) {
        $policy.PolicyRoleBindings.Add($policyRole)
    }
    $webApp.Update()
}
$webApp = Get-SPWebApplication "http://content"
$portalSuperUserAccount = Get-Credential "localdev\SPSuperUser"
$webApp.Properties["portalsuperuseraccount"] = $portalSuperUserAccount.UserName
Set-WebAppUserPolicy $webApp $portalSuperUserAccount.UserName $portalSuperUserAccount.UserName "Full Control"

$portalSuperReaderAccount = Get-Credential "localdev\SPSuperReader"
$webApp.Properties["portalsuperreaderaccount"] = $portalSuperReaderAccount.UserName
Set-WebAppUserPolicy $webApp $portalSuperReaderAccount.UserName $portalSuperReaderAccount.UserName "Full Read"

Make sure that you do not use the same account for both the super user and super reader. (And of course make sure you change the URL and account names to match your environment). For more information about these settings see the following TechNet article: http://technet.microsoft.com/en-us/library/ff758656.aspx

Unattended Accounts

There are some services, specifically the Visio Services Service Application, the Excel Services Service Application, and the PerformancePoint Service Application, that allow us to set an account that we can use for access data sources behind the scenes. These are called unattended access accounts. To set these accounts we must create a new target application in the Secure Store Service Application and associate the target application’s ID with the appropriate Service Application. The following PowerShell code demonstrates how to do this for the Visio Services Service Application (the Excel Services Service Application is virtually identical and just uses cmdlets specific to Excel rather than Visio; PerformancePoint is a lot simpler):

#Get the Visio Service App
$svcApp = Get-SPServiceApplication | where {$_.TypeName -like "*Visio*"}
#Get the existing unattended account app ID
$unattendedServiceAccountApplicationID = ($svcApp | Get-SPVisioExternalData).UnattendedServiceAccountApplicationID
#If the account isn't already set then set it
if ([string]::IsNullOrEmpty($unattendedServiceAccountApplicationID)) {
    #Get our credentials
    $unattendedAccount = Get-Credential "localdev\SPUnattended"

    #Set the Target App Name and create the Target App
    $name = "$($svcApp.ID)-VisioUnattendedAccount"
    Write-Host "Creating Secure Store Target Application $name..."
    $secureStoreTargetApp = New-SPSecureStoreTargetApplication -Name $name `
        -FriendlyName "Visio Services Unattended Account Target App" `
        -ApplicationType Group `
        -TimeoutInMinutes 3

    #Set the group claim and admin principals
    $groupClaim = New-SPClaimsPrincipal -Identity "nt authority\authenticated users" -IdentityType WindowsSamAccountName
    $adminPrincipal = New-SPClaimsPrincipal -Identity "$($env:userdomain)\$($env:username)" -IdentityType WindowsSamAccountName

    #Set the account fields
    $usernameField = New-SPSecureStoreApplicationField -Name "User Name" -Type WindowsUserName -Masked:$false
    $passwordField = New-SPSecureStoreApplicationField -Name "Password" -Type WindowsPassword -Masked:$false
    $fields = $usernameField, $passwordField

    #Set the field values
    $secureUserName = ConvertTo-SecureString $unattendedAccount.UserName -AsPlainText -Force
    $securePassword = $unattendedAccount.Password
    $credentialValues = $secureUserName, $securePassword

    #Get the service context
    $subId = [Microsoft.SharePoint.SPSiteSubscriptionIdentifier]::Default
    $context = [Microsoft.SharePoint.SPServiceContext]::GetContext($svcApp.ServiceApplicationProxyGroup, $subId)

    #Check to see if the Secure Store App already exists
    $secureStoreApp = Get-SPSecureStoreApplication -ServiceContext $context -Name $name -ErrorAction SilentlyContinue
    if ($secureStoreApp -eq $null) {
        #Doesn't exist so create.
        Write-Host "Creating Secure Store Application..."
        $secureStoreApp = New-SPSecureStoreApplication -ServiceContext $context `
            -TargetApplication $secureStoreTargetApp `
            -Administrator $adminPrincipal `
            -CredentialsOwnerGroup $groupClaim `
            -Fields $fields
    }
    #Update the field values
    Write-Host "Updating Secure Store Group Credential Mapping..."
    Update-SPSecureStoreGroupCredentialMapping -Identity $secureStoreApp -Values $credentialValues

    #Set the unattended service account application ID
    $svcApp | Set-SPVisioExternalData -UnattendedServiceAccountApplicationID $name
}

When it comes to PerformancePoint we have a lot less work we need to do as the product team was nice enough to make it so that the Set-SPPerformancePointSecureDataValues does all the work of setting up the target application for us (note though that they did screw up how the Service Application is passed into the cmdlet requiring you to pass in the ID of the Service Application rather than the actual Service Application object):

$unattendedAccount = Get-Credential "localdev\SPUnattended"
$secureValues = Get-SPPerformancePointSecureDataValues -ServiceApplication $svcApp.Id
if ($secureValues.DataSourceUnattendedServiceAccount -ne $unattendedServiceAccount.UserName) {
    Write-Host "Setting unattended service account $($unattendedServiceAccount.UserName)..."
    $svcApp.Id | Set-SPPerformancePointSecureDataValues -DataSourceUnattendedServiceAccount $unattendedServiceAccount
}

User Profile Synchronization Service Identity

One thing to watch out for is when setting the account for the User Profile Synchronization Service. This service wants you to use the Farm Account as the identity. This means that your Farm Admin account cannot have it’s password managed by SharePoint if you intend to use this service (or at least, it shouldn’t be unless you don’t mind manually fixing this service every time your password changes – good luck with that BTW). Your Farm Admin account will always be a Managed Account (you can’t change that) so be extra careful when changing this accounts password (either manually or automatically). To set this account using Central Admin you can click Start next to the User Profile Synchronization Service entry on the Services on Server page.

 


To accomplish the same thing using PowerShell we need to get an instance of the Synchronization Service and set a few properties and call the SetSynchronizationMachine method passing in the username and password of the Farm Admin account (note that it requires the password be passed in as a standard string and not a secure string so I use my previously defined ConvertTo-UnsecureString function):

$syncMachine = Get-SPServer "sp2010dev"
$profApp = Get-SPServiceApplication | where {$_.Name -eq "User Profile Service Application 1"}
$account = Get-Credential "localdev\spfarm"
if ($syncMachine.Address -eq $env:ComputerName) {
    $syncSvc = Get-SPServiceInstance -Server $env:ComputerName | where {$_.TypeName -eq "User Profile Synchronization Service"}
    $syncSvc.Status = [Microsoft.SharePoint.Administration.SPObjectStatus]::Provisioning
    $syncSvc.IsProvisioned = $false
    $syncSvc.UserProfileApplicationGuid = $profApp.Id
    $syncSvc.Update()
    $profApp.SetSynchronizationMachine($syncMachine.Address, $syncSvc.Id, $account.UserName, (ConvertTo-UnsecureString $account.Password))
}

if ($syncSvc.Status -ne "Online") {
    Write-Host "Starting User Profile Synchronization Service..."
    Start-SPServiceInstance $syncSvc
}
do {Start-Sleep 2} while ((Get-SPServiceInstance -Server $env:ComputerName | where {$_.TypeName -eq "User Profile Synchronization Service"}).Status -ne "Online")

Summary

As you can see setting the accounts that are used throughout SharePoint 2010 is anything but consistent and in some cases a real pain in the a$$. I know I didn’t cover how to set every account (custom crawl rule accounts, user profile sync connection accounts, others?) but hopefully someone out there has already documented these, or if not perhaps they’d be nice enough to post a comment here for others benefit from (maybe one day I’ll add them myself but for now I think this post is quite long enough). As always, please let me know if I’ve missed something or otherwise got something wrong as I certainly don’t claim to have all the answers.
Happy PowerShelling



Reference:

http://blog.falchionconsulting.com/index.php/2010/10/service-accounts-and-managed-service-accounts-in-sharepoint-2010/

Managed account in SharePoint2010

Managed accounts is a brand new concept of SharePoint 2010. They are designed to give administrators more control over the domain accounts that are used in different section of SharePoint.
When you register a account with SharePoint, administrators can maintain the account from SharePoint itself:
1) Free from worries of password change how & where in SharePoint
If a password left unchanged in any part of SharePoint it can do lot of hell J
When a domain account is registered with SharePoint as a managed account. It can be used as:
1) To run application pools
2) To run service applications.
The account which install SharePoint2010 is automatically/already registered as a managed account. More accounts can be added later by clicking è Security category in Central Administration home page and select Configure managed accounts under the subcategory General Security. While registering a managed account, you simply need to provide the
username with domain and password.
You have many option there like i.e. to have SharePoint automatically handle the password changes for you. This option is the most useful option as it removes from burden to change password everywhere in the SharePoint :
If you decide to use the automatic password change option, SharePoint will take over setting the password for the account in Active Directory for as long as the account is registered as a managed account.

 

If don’t allow SharePoint to change the passwords automatically; It can still be easy to manage password from within Central Administration now from the Managed Accounts page, you can edit the account whose password you like to change. There you can change the password by checking the box next to Change password now.
Imp Note: If someone change the password for the account directly in AD without the knowledge of SharePoint, your managed accounts will not work. SharePoint needs the account’s password to use it. For any password change it is recommended to change the password from SharePoint and not with AD.

Reference:

https://ashishbanga.wordpress.com/2012/10/23/managed-account-in-sharepoint2010/

Managed Accounts in SharePoint 2010

To understand it more clearly let me give you a small example; consider having an applicton pool account, for example called DOMAIN\SharePointAdmin. And we are using this account for a large number of web applications. Suppose if we want to change the password for that account; you would need to go into each and every web application and reset the password after the change, not to mention that the applications you haven't changed yet will stop working. This was the scenario in SharePoint 2007. SharePoint 2010 introduces the managed account. In short, rather than specifying the user name and password on every occasion, you create a managed account and set the password there. Then, when you need to enter a user account you simply select which managed account to use and you don't need to know the password. This also allows farm administrators to set up the service accounts so that others do not need to know the password for the account.

Managed Account credentials are encrypted using a farm encryption key that is specified when we run PSConfig[ui].exe at farm creation (SharePoint Configuration wizard). The passphrase is stored in a secure registry location so that it can only be accessed by the farm account and encrypted so that only the farm account has access. The farm encryption key later, is stored in the Configuration Database.  Another benefit of managed accounts is, suppose an administrator would like to create a new Web application using Windows PowerShell or SharePoint Central Administration - the administrator only needs to specify the Application Pool account  or select the account in the SharePoint Central Administration (in the case of Central admin screen) user interface as opposed to both having to know the domain\username and associated password.This was the limitation with earlier SharePoint versions.

Get Managed Accounts using SharePoint Central Administration?

1. To view existing Managed Accounts using SharePoint Central Administration, select Security from the SharePoint Central Administration homepage.
2. On the Security page select Configure managed accounts under General Security.
3. The Managed Accounts page will list all Managed Accounts registered in SharePoint.

Register Managed Accounts using SharePoint Central Administration

1. To register new Managed Accounts using SharePoint Central Administration, select Security from the SharePoint Central Administration homepage.
2. On the Security page select Configure managed accounts under General Security.
3. On the Managed Accounts page select Register Managed Account.
4. On the Register Managed Account page (see illustration below) specify the credentials and select the password change policies as desired.

Reference:

http://www.c-sharpcorner.com/uploadfile/Roji.Joy/managed-accounts-in-sharepoint-2010/

Get all the Managed accounts in SharePoint 2010 using Powershell

In this article we will seeing how to get all the managed accounts using powershell in SharePoint 2010.

Managed Accounts:

Managed Accounts is a new feature in SharePoint 2010. Managed accounts are Active Directory user accounts whose credentials are managed by and contained within SharePoint. When administrators configure a new web application or service application they don't have to remember the username and passwords every time if the service account is registered. They can just simply select the managed account and they can configure the web application and service application. For example when administrator create a new web application (Go to Central Administration => Application management => Manage Web Applications => Click New in the ribbon interface)

Administrator can just choose the service account (whose account is already is registered) for the application pool from the drop down as shown in the following




Automatic password change:

SharePoint 2010 also introduces automatic password change.

Automatic password change enables SharePoint to automatically generate new strong passwords on a schedule you set. Select the Enable automatic password change checkbox to allow SharePoint to manage the password for the selected account.

If an account policy based expiry date is detected for the account, and the expiry will occur before the scheduled date and time, the password will be changed on a configured number of days before the expiry date at the regularly scheduled time.

We can choose to enable e-mail notifications in order to have the system generate warning notifications about upcoming password change events.

We can also specify a time and schedule for the system to automatically change the password.

Get all Managed Accounts:

Go to Central Administration => Security => General Security => Configure managed accounts.



You could be able to see all the managed accounts.

The same thing can be achieved using the following powershell cmdlet.

Get-SPManagedAccount:

Get-SPManagedAccount – Retrieves accounts registered in the configuration database.

Go to Start => All Programs => Microsoft SharePoint 2010 Products =>SharePoint 2010 Management Shell => Run as administrator.

Type the following command

Get-SPManagedAccount

This command displays all the managed accounts in the farm.

Note: For more information on Get-SPManagedAccount cmdlet refer http://technet.microsoft.com/en-us/library/ff607835.aspx

Reference:

http://www.c-sharpcorner.com/uploadfile/anavijai/get-all-the-managed-accounts-in-sharepoint-2010-using-powershell/