Lync service accounts on sql databases

Hi all,
Please what are the permission required by Lync server 2013 on SQL Databases so the services not get effected as our SQL team informed that permission on SQL instances will be removed unless it required by application.
Regards,

Hi, Ahmad,
You can use any option among three options.
The first option require a user with a membership of RTCUniversalServerAdmins group, sysadmins SQL Server security group and SQL Server local Administrators group.
Best Regards,
Lisa Zheng
Lisa Zheng
TechNet Community Support

Similar Messages

Use SIA service account for SQL Server reporting connections (BIP4.1)

Is it possible to use the SIA service account as a proxy for a SQL Server connection using OLE DB? This way, anytime a report was refreshed, the SIA service account would be used when authenticating to the reporting database? This is a common pattern in software development to minimize database maintenance (when there is sufficient security being enforced at the application layer - BOBJ provides this).
This would make SQL Server database security management very easy for the DBAs (just add the BOBJ service account to the database and assign dbreader).
I would think this would be an option, but a Relational Connection only provides the following 3 Authentication modes when using the IDT to create and publish a Relational Connection (OLEDB/MSSQL):
Use BusinessObjects credential mapping
This takes the username and password from the "Database Credentials" section of the BusinessObjects User object for the user in the current session. It passes the info as hard-coded SQL authentication.
Use single sign-on when refreshing reports at view time
This is ONLY for end-to-end single-sign-on (as the error message in the next paragraph specifies) and uses the Windows AD credentials for the user in the current session. It is this method of authentication that I'd like to use, i.e. Windows Integrated Security, but I'd like to have the SIA account act as the account that makes the connection, not end-to-end.
Use specified username and password
This is for hard-coding usernames and passwords (only SQL authentication in OLE DB).
I've tried leaving the "Cache security context" option OFF in Windows AD Authentication settings, hoping it would default to using the service account for authentication to the database... to no avail. It fails during tests in the IDT with the message:
"Single Sign-On failed in the CMS. Please contact your system administrator for details. : The authentication provider (secWinAD) associated with this logon session does not have inter-process Single Sign-On enabled. Contact your system administrator for details. (FWB 00019)"
Alternatively, a SQL user could be hard-coded into the connection (same simple maintenance on the DBA side), but we'd really like to rely on Windows Integrated Security if possible!
Is there a way?
Any help is greatly appreciated!
David

Hey David,
Did you ever solve this? We get the same SSO error when indexing information spaces in Explorer.
Thanks,
Brandon

Service Account for SQL Server Agent on SQL Server 2008 R2

This SQL Server instance is SQL Server 2008 R2 (10.50.4000). We had Active Domain Service accounts created to run the service accounts for SQL Server and SQL Server Agent.
It has become company policy to alter the service accounts that run SQL Server and SQL Server Agent. Currently, both were running under the Local System Accounts. We have altered the SQL Server but we are having issues with the SQL Server Agent.
I am told by another DBA that
"The agent is requiring elevated rights. It will startup if it has local admin rights, but not with domain accounts without admin rights."
So I was wondering if anyone has come across this issue and how did they resolve it.
lcerni

"The agent is requiring elevated rights. It will startup if it has local admin rights, but not with domain accounts without admin rights."
This is completely not true. It is indeed possible to run agent as a domain account without giving it local admin. Chances are you'll need to update the local acls by adding the account to the local security groups. Please see this article for more information:
http://technet.microsoft.com/en-us/library/ms143504(v=sql.105).aspx
Edit: In addition, it'll need rights to SQL server for that account to connect and do its work. It will need to be given sysadmin:
http://technet.microsoft.com/en-us/library/ms191543.aspx
Sean Gallardy | Blog |
Twitter

Managed Service Accounts on SQL 2005?

I am doing research on the proper way to configure service accounts in SQL as ours are absolutely setup incorrectly. I was thinking about using Managed Service Accounts (MSA's) so we dont have to manage passwords going forward and I cant find anything
to say if it is compatible with SQL 2005 or not.
It looks like it is with SQL 2008R2 as well as SQL 2012.
Anyone using MSA's with SQL 2005? Can I one account per service for each of the services without an issue?

Hello,
MSA's are not compatible with SQL Server 2005 or 2008 but 2008R2 and 2012 will work.
Sean Gallardy | Blog | Microsoft Certified Master
Thanks Sean. I appreciate the quick answer.
Have a great weekend.

How to add a service account in SQL Server to display the "Service Account Name" and "Display Name"

Can someone
help with steps on how to add the following in SQL Server 2012 environments?<o:p></o:p>
"Service Account Name" and "Display Name"<o:p></o:p>
Your help will be greatly appreciated.<o:p></o:p>
leonie6214

Hello,
Is the following article what you are looking for?
http://msdn.microsoft.com/en-us/library/ms345578.aspx
If not, could you explain a little bit more what you want to accomplish?
Hope this helps.
Regards,
Alberto Morillo
SQLCoffee.com

Group managed service accounts for SQL Server

Hey guys,
Unfortunately I missed that (g/s)MSAs aren't supported yet for SQL Servers but I'm using them without any worries since ages.
As i digged a bit deeper I could find different informations due to the related TechNet entrys. So it seems Microsofts Informations about (s)MSAs and gMSAs aren't consistent.
I'm not a SQL Server guy and use SQL only for System Center testing stuff so i would like to get a real world exps of SQL Server guys.
Should I continue using gMSAs or are there any worries I should know?
some sources I found so far:
Not supported:
"Hi Adam,
Thank you for your feedback. Windows Server 2012 Group Managed Service Account is not currently supported as SQL 2012 released earlier than Windows Server 2012. We will consider to support gMSA in future SQL Server release.
Regards,
Min He, Program Manager, SQL Server"
11.2012 -
https://connect.microsoft.com/SQLServer/feedback/details/767211/gmsa-for-sql-server-failover-Clusters
gMSA are not yet available, are not yet supported for SQL Server. gMSA exist and are available and supported in Windows Server 2012 and higher.  SQL does not support them , but
from an OS perspective, they exist and are supported.
http://blogs.msdn.com/b/sqlosteam/archive/2014/02/19/msa-accounts-used-with-sql.aspx
Within the FAQ Task Scheduler isn't supported as well ...
http://technet.microsoft.com/en-us/library/ff641729%28WS.10%29.aspx
... but also PFEs using them for Tasks... this is confusin... 0o
http://blogs.msdn.com/b/arvindsh/archive/2014/02/03/managed-service-accounts-msa-and-sql-2012-practical-tips.aspx
supported?:
Configure Windows Service Accounts and Permissions
... New Account Types Available with Windows 7 and Windows Server 2008 R2
http://technet.microsoft.com/en-us/library/ms143504(v=sql.110).aspx#Default_Accts
The MSA must be created in the Active Directory by the domain administrator before SQL Server setup can use it for SQL Server services.
others sources won't mentioning s/gMSAs...
I couldn't find clear informations about using gMSA for SQL Server 2014.
only the same page which also Looks like the page for 2008 R2 and SQL 2012.
Configure Windows Service Accounts and Permissions
            SQL Server 2014
http://msdn.microsoft.com/en-us/library/ms143504.aspx
annoying topic so far... ;)

Hi Enrico
aside from what Dan says about the risk for support, on which I agree, the following thread may clear it up a bit:
http://social.msdn.microsoft.com/Forums/sqlserver/en-US/acb2048c-ffce-4d44-b882-6aafc7eb689d/managed-service-accounts-to-run-sql-server-service?forum=sqlsecurity
Andreas Wolter (Blog |
Twitter)
MCM - Microsoft Certified Master SQL Server 2008
MCSM - Microsoft Certified Solutions Master Data Platform, SQL Server 2012
www.andreas-wolter.com |
www.SarpedonQualityLab.com

Question : Service Accounts for SQL Server 2012

Hello,
I am planning to create AD accounts for SQL Server 2012 services that will be installed on Windows 2012 server.
I was reading the following
Configure Windows Service Accounts and Permissions
and
Windows Privileges and Rights
Is there a recommendation / document that would list that assocation of SQL Server Services with Actvie Directory service accounts / privileges required for installation and starting the services.
Isn't it recommended to create separate account for every service and they should not be local accounts ?
Hope to hear soon as to what industry standards are being followed for production systems ?
Thank you very much in advance.
Regards
Nikunj

From MSDN:
Each service in SQL Server represents a process or a set of processes to manage authentication of SQL Server operations with Windows. Each service can be configured to use its own service account. This facility is exposed
at installation. SQL Server provides a special tool, SQL Server Configuration Manager, to manage the services configuration.
When choosing service accounts, consider the principle of least privilege. The service account should have exactly the privileges that it needs to do its job and no more privileges. You also need to consider account isolation; the service accounts should
not only be different from one another, they should not be used by any other service on the same server. Do not grant additional permissions to the SQL Server service account or the service groups.
From Glen Berry's Blog:
You should request that a dedicated domain user account be created for use by the SQL Server service. This should just be a regular, domain account with no special rights on the domain. You do not need or want this account to be a local admin on the machine
where SQL Server will be installed. The SQL Server setup program will grant the necessary rights on the machine to that account during installation.
You will also want a separate, dedicated domain user account for the SQL Server Agent service. If you are going to be installing and using other SQL Server related services such as SQL Server Integration Services (SSIS), SQL Server Reporting Services (SSRS),
or SQL Server Analysis Services (SSAS), you will want dedicated domain accounts for each service. The reason you want separate accounts for each service is because they require different rights on the local machine, and having separate accounts is both more
secure and more resilient, since a problem with one account won’t affect all of the SQL Server Services.
Depending on your organization, getting these domain accounts created could take anywhere from minutes to weeks to complete, so make sure to allow time for this. For each one of these accounts, you will need their logon credentials for the SQL Server setup
program. You are going to want to make sure that the accounts don’t have a temporary password that must be changed during the next login. If they are set up that way, make sure to change them to use a strong password, and record this information in a secure
location.
Please Mark This As Answer if it solved your issue
Please Mark This As Helpful if it helps to solve your issue
Thanks,
Shashikant

SP2010 Application Pool Service Account fails to login to master database on a SQL Server mirror

This is a weird problem that just started showing up, cause unknown. Could go in this forum or in SQL 2008...I put it here because for me the context is SP2010.
We have 2 SQL servers (2008 R2 with SP1). Each server has 2 named instances, the second being a mirror for the other server's main instance. In other words, the named instance /SQL has a /SQLMirror on the other server and vice versa.
The error is: Login failed for user 'domain\sharepointapppoolaccount'. Reason: Failed to open the explicitly specified database.
As best I can tell, the specified database is "master" on the mirror instance. I am unaware of any reason for the app pool account to be connecting to the master on the mirror (the master database itself is NOT mirrored). There is nothing
in the user mapping that would suggest any reason to try connecting. And there are no equivalent errors in the main instance (SQL).
SP2010 Event ID 18456 - Why would a service account try to connect to the master database?

Hi,
When the principal server(SQL) disconnects clients from the principal database, then the mirror server(SQL) will take charge of clients’ requests.
So the error is regarding to the mirror server may be due to that the mirror server is taking charge of the clients’ request instead of the principal server when the principal is becomes unavailable.
I recommend to grant sysadmin permissions to the service account in SQL(mirror server) to see if the issue still occurs.
Best regards.
Thanks
Victoria Xia
TechNet Community Support

SQL 2012 service accounts best practice

I'm installing SQL Server 2012 for ConfigMgr 2012 r2 and I wonder what is the best practice for SQL service accounts.
During the installation of SQL Server, in the server configuration/Service accounts menu I'm allowed to configure following service accounts: SQL Server Agent, SQL Server Agent Database Engine, SQL Server Reporting Services, SQL Server Browser.
Do I have to create separate domain user (not admin) accounts for each service and configure service principal name (SPN) for all of them?
For example: Domain user account named SQLSA for SQL Server Agent, another domain user account
SQLADBE for SQL Server Agent Database Engine etc.

During the installation of SQL Server 2012, the user is prompted to provide service account
credentials. The default service accounts suggested vary depending on whether SQL Server
2012 is installed on a computer running Windows Vista or Windows Server 2008 or on a computer
running Windows 7 or Windows Server 2008 R2. On computers running Windows Vista
or Windows Server 2008 operating systems, the following default service accounts are used:
- NETWORK SERVICE Database Engine, SQL Server Agent, Analysis Services,
Integration Services, Reporting Services, SQL Server Distributed Replay Controller,
SQL Server Distributed Replay Client
- LOCAL SERVICE SQL Server Browser, FD Launcher (Full-Text Search)
- LOCAL SYSTEM SQL Server VSS Writer
On computers running Windows 7 or Windows Server 2008 R2 operating systems, the following
default accounts are used:
- Virtual Account or Managed Service Account Database Engine, SQL Server Agent,
Analysis Services, Integration Services, Replication Services, SQL Server Distributed
Replay Controller, SQL Server Distributed Replay Client, FD Launcher (Full-Text Search)
- LOCAL SERVICE SQL Server Browser
- LOCAL SYSTEM SQL Server VSS Writer
For Windows 7 and Windows Server 2008 R2, you can use a Managed Service Account
(MSA) or a Managed Local Account. The differences between these account types are as
follows:
- Managed Service Account (MSA) This special kind of domain account managed
by a domain controller is assigned to a single member computer and used for running
services. The MSA password is managed by the domain controller. MSAs can register
a Service Principal Name (SPN) with Active Directory. MSAs use a $ name suffix; for
example, CONTOSO\SQL-A-MSA$. You must create the MSA prior to running SQL
Server Setup if you want to use an MSA with SQL Server services.
- Virtual Accounts or Managed Local Accounts These virtual accounts can access
the network in a domain environment and are used by default for service accounts
during SQL Server 2012 setup when run on Windows 7 or Windows Server 2008 R2.
Such accounts use the NT SERVICE\<SERVICENAME>format. You don’t need to specify
a password when using virtual accounts with SQL Server 2012 because this is handled
automatically by the operating system.
You should run SQL Server services, using the minimum possible user rights, and use an
MSA or virtual account when possible. If you are manually configuring service accounts, use
separate accounts for different SQL Server services. If it is necessary to change the properties
of service accounts used for SQL Server 2012, use SQL Server tools such as SQL Server
Configuration Manager. This ensures that all necessary dependencies are
updated, which does not happen if you use only the Services console.
Although you can configure domain accounts as service accounts, this strategy requires
more effort because you must ensure that service account passwords are changed regularly.
You must also manage SPNs, which are required for Kerberos authentication.
Best regads
P.Ceglie

SQL server service accounts question

We created a test SQL environment using a Technet evaluation copy of Windows Server 2012 along with an evaluation copy of SQL2012. After testing, everything is working as planned so were going to enter the product keys for both Windows Server and SQL 2012.
My question is that once we have our Server licensed we’re going to start a new domain and recreate all the user accounts but I installed SQL using a local user account I created called ”sqladmin”. Once Server 2012 is the DC in the new domain will I need to
change all the service accounts for SQL in order for it to function or can I still use the local “sqladmin” user account? If I can re-use that local account are there any downside to that? What’s the best practice in this scenario

Once Server 2012 is the DC in the new domain will I need to change all the service accounts for SQL in order for it to function or can I still use the local “sqladmin” user account? If I can re-use that local account are there any downside to that?
What’s the best practice in this scenario
Hi,
You can use your sqladmin account but that wont be a good security practice. You should always follow principal of least privilege and should run SQL server with domain account having least privilege.Below link will help you in this
Configure SQL server account and services
Please mark this reply as the answer or vote as helpful, as appropriate, to make it useful for other readers
My TechNet Wiki Articles

Why would you use a managed service account rather than a virtual account in SQL Server 2012?

In SQL Server 2012, service accounts are created as
virtual accounts (VAs), as described
here, as opposed to
managed service accounts (MSAs).
The important differences I can see for these, based on the descriptions:
MSAs are domain accounts, VAs are local accounts
MSAs use automagic password management handled by AD, VAs have no passwords
in a Kerberos context, MSAs register SPNs automatically, VAs do not
Are there any other differences? If Kerberos is not in use, why would a DBA ever prefer an MSA?
UPDATE:
Another user has noted a
possible contradiction in the MS docs concerning VAs:
The virtual account is auto-managed, and the virtual account can access the network
in a domain environment.
versus
Virtual accounts cannot be authenticated to a remote location. All virtual accounts
use the permission of machine account. Provision the machine account in the format
<domain_name>\<computer_name>$.
What is the "machine account"? How/when/why does it get "provisioned"? What is the difference between "accessing the network in a domain environment" and "authenticating to a remote location [in a domain environment]"?

Hi,
“Virtual accounts cannot be authenticated to a remote location. All virtual accounts use the permission of machine account. Provision the machine account in the format <domain_name>\<computer_name>$.”
“The virtual account is auto-managed, and the virtual account can access the network in a domain environment. If the default value is used for the service accounts during SQL Server setup on Windows Server 2008 R2 or Windows 7, a virtual account
using the instance name as the service name is used, in the format NT SERVICE\<SERVICENAME>”
Per the above description, they are two concepts and not conflict with each other.
As you understand, virtual account access network resources by using the credentials of the computer account. Generally, computer account will not be granted permission unless giving the computer account permission on the shared folder manually.
Thanks.
Tracy Cai
TechNet Community Support

SQl engine service account in different trusted domain from server?

Is it possible to use an SQL service account from a different, but still trusted, domain than the one to which the server is joined? If so, are there any nonstandard configuration settings I need to use?
I've got this setup running, but when I try to connect with an account from any domain other than the one to which the server is joined, I get the following error:
Login failed for user 'SERVICEACCOUNTDOMAIN\account'. Reason: Token-based server access validation failed with an infrastructure error. Check for previous errors.
I've created the SPN in the service account's domain, and verified there is both connectivity and a valid trust relationship. The users I'm testing also have logon permissions for the server.

Hi AccuMegalith,
Firstly, it is possible to use an SQL Server service account from a different, trusted domain. We need to note the following configuration.
For more details, please review this article:
Security Account Delegation.
1. The service account must be trusted for delegation on the domain controller.
The following options in Active Directory Users and Computers must be specified in order for delegation to work:
•The Account is sensitive and cannot be delegated check box must not be selected for the user requesting delegation.
•The Account is trusted for delegation check box must be selected for the service account of SQL Server.•The
Computer is trusted for delegation check box must be selected for the server running an instance of Microsoft SQL Server
2. The service account must have SPNs registered on the domain controller. If the service account is a domain user account, the domain administrator must register the SPNs.
Login failed for user 'SERVICEACCOUNTDOMAIN\account'. Reason: Token-based server access validation failed with an infrastructure error. Check for previous errors.
Secondly, regarding to above error message, it means that SQL Server was able to authenticate you, but weren't able to validate with the underlying Windows permissions.
It could be caused by that the Windows login has no profile or that permissions could not be checked due to UAC. Please perform the following steps to troubleshoot this issue. For more details, please review this
blog.
1. Run SQL Server Management Studio (SSMS) as administrator and disable UAC.
2. Check if that login is directly mapped to one of the SQL Server logins by looking into the output of sys.server_principals.
3. If the login is directly mapped to the list of available logins in the SQL instance, then check if the SID of the login matches the SID of the Windows Login.
Thanks,
Lydia Zhang
If you have any feedback on our support, please click
here.
Lydia Zhang
TechNet Community Support

What is the effect of the service account permissions

Hi,
What is the effect of the service account permissions? For example, suppose the service account for SQL Server database engine is SomeDomain\A, and has no permission to execute stored procedure X, and a user with domain account SomeDomain\B does have the
said permission. Which one will prevail, i.e. can the user execute stored procedure X? If so, what permissions must I give the service account SomeDomain\A?
I am asking this in the context of planning deployment in the production environment of a data warehouse application.
Cheers,
Jerome
Jerome Smith BI Consultant, MCP

Hi Jerome,
Service account for SQL Server Database Engine only have limited permissions. To grant the account permission to execute stored procedure X, please refer to the following
query:
USE database;
GRANT EXECUTE ON OBJECT::dbo.X
TO SomeDomain\A;
GO
Since the user is in the context of planning deployment in the production environment of a data warehouse application, we may need to add some additional permissions. For more details, please refer to the following blog:
http://blogs.msdn.com/b/data_otaku/archive/2011/06/28/securing-the-data-warehouse.aspx
Thanks,
Katherine Xiong
Katherine Xiong
TechNet Community Support

Best practice for service account?

Hello guys,
May I ask what's the best practice to have and maintain a service account?
For ConfigMgr, you may need to have a service account for e.g client install.
An employee who run this service just depart, and we realize we don't have service account credential left to our knowlege.
So let say we have to reset it, and reconfigure back the service account with new credential, what's the best practice to have this credential kept in safe and can be retrieved back for future use?
Do you keep it in a secured email? Secured envelope? How you maintain it in a big organization.
Please throw me some ideas. Thank you very much :)
p/s: this issue may not restrict to ConfigMgr only, you may need service account for SQL, IIS and etc.
---Pat

Hi,
Dfferent customers use different solution, some use applications like this for instance,
http://keepass.info/
and save the database of password on a network share.
Regards,
Jörgen
-- My System Center blog ccmexec.com -- Twitter
@ccmexec

Contained Database Users are now available in Azure SQL Database Update preview

Contained Database Users should be of particular help for people migrating to Azure SQL Database. At the moment, this is a preview release but you can start testing. Here is the announcement of the
preview with links to more information.
New SQL Database public preview with new Standard-tier performance level
Previously announced in November 2014 and now available for customers to try, the
new
public preview of SQL Database improves the compatibility of SQL Server applications for Azure SQL Database. Details of this preview are available on the
SQL
Database documentation webpage, including the following key enhancements: easier management of large databases to support heavier workloads with parallel queries
and online indexing, support for programmability functions like CLR and XML index to support more robust application design, improved monitoring and troubleshooting with XEvents and 100 new Dynamic Management Views (DMV), and more performance in the Premium
tier.
To try this preview, please sign up via the Preview
features webpage. Only SQL Database servers with a mix of one or more Basic, Standard, or Premium (not Web or Business) databases are compatible and eligible to
upgrade to the preview. Please note that any move of an existing Basic, Standard, or Premium database into this preview is irreversible; we recommend that you create a database copy or leverage test databases on any server enrolled in this preview.
A new Standard-tier performance level, S3, is also available in this preview which gives you more pricing flexibility between Standard and Premium. S3 will deliver 100 Database Throughput Units (DTU) and all the features available in the Standard tier. Please
note that S3 will appear on your bill as a multiple of S2 until further notice.
For more information, please visit the SQL
Database webpage and the
Microsoft
Azure Blog. For a comprehensive look at pricing, please visit the
SQL
Database pricing webpage.
Rick Byham, Microsoft, SQL Server Books Online, Implies no warranty

Hello Rick
That is great, one thing I'd like to ask, does it support SSMS,SSDT?
No sign of that yet, that I’ve seen.....
Best Regards,Uri Dimant SQL Server MVP,
http://sqlblog.com/blogs/uri_dimant/
MS SQL optimization: MS SQL Development and Optimization
MS SQL Consulting:
Large scale of database and data cleansing
Remote DBA Services:
Improves MS SQL Database Performance
SQL Server Integration Services:
Business Intelligence

Lync service accounts on sql databases

Similar Messages

Maybe you are looking for