I've been reading about how you should set specific service accounts to each sql service, but from what i've read, none have been detailed enough on how to properly create one, would anyone mind explaining what would be the steps on how to create a local, low permission account for the sql service on windows?
Some basic information is available at http://msdn.microsoft.com/en-us/library/cc281953.aspx
I tend to make domain user accounts with no particular rights on the network apart from what the account would normally receive (eg domain users). During SQL Server installation you provide these accoounts to the SQL installer - it will correctly configure the accounts for you (adding them to certain groups, etc).
If you're doing it after SQL installation the correct way to change the service account is to use the SQL Server Configuration Manager (in your start menu) as it will ensure the accounts are, once again, correctly configured.
Using domain accounts is great as you can then grant the service accounts access to particular network shares (backups) and other database servers (linked servers, etc).
As an additional measure if your network resources (file shares, etc) are secured using custom made security groups, rather than "domain users", your SQL Server services won't have access to these areas of the network they shouldn't be able to reach. I personally haven't tried removing the "domain users" membership - you can't break anything by giving it a go on a VM? :)
This site describes the different options to use the least privileges and the danger of the other options:
WHEN TO USE DOMAIN USER ACCOUNT?
WHEN TO USE NETWORK SERVICE ACCOUNT?
WHEN TO USE LOCAL USER ACCOUNT?
WHEN TO USE LOCAL SYSTEM ACCOUNT?
-
-
http://goo.gl/vG55n
Related
So I'm looking for a solution for ssh key authorisation access to numerous servers, and have been pointed towards using LDAP. I wanted to present the use case and see if LDAP would be applicable and any suggestions or help would be appropriated.
Would it be possible to use LDAP to restrict access to specific servers per user/group using ssh keys. So a user tries to access a box which would bounce out to the LDAP server with the server and user details. This would then check if that person has access to that server and potentially return the correlating key to grant access.
After some research it seems possible to do the above, but I couldn't find anywhere where its for specific servers.
Also is openLDAP the best to use, I've tried setting this up and run into several issues like checksum on config files etc.
I have question around DLP (data leakage prevention) from a corporate network.
I have a Virtual Machine on a corporate network. The VM can access an Azure SQL DB in the cloud: aaa.database.windows.net through a connection over port 1433.
However, I don't want that same VM to connect to bbb.database.windows.net.
Azure offers no guarantees on the public IP (both servers could appear as the same IP) - what technology can I use on the corporate's perimeter network/firewall to permit access to aaa but disallow access to bbb?
The attack I am concerned about is someone internal to the company querying data out of aaa and inserting it in to bbb. For example, if the one server is ourcorporatedate.database.windows.net and the other is somerandom.database.windows.net the someone internal to the company could take corporate data and write it to some random database.
Thanks
You can use Virtual Network service endpoints and rules. Virtual network rules are one firewall security feature that controls whether your Azure SQL Database or SQL Data Warehouse server accepts communications that are sent from particular subnets in virtual networks. Learn how to use it and benefits/limitations on this documentation.
If database aaa and bbb have the same public IP address. I think there is not a good way to set in the on-premise firewall to permit access to aaa but deny access to bbb. From the same client, the firewall rule will have the same source IP, protocol, port, and destination IP for outbound traffic.
If you want to selectively grant access to just one of the databases in your Azure SQL server, you can only create a database-level rule for the required database. Also, Specify an IP address range for the database firewall rule that is beyond the IP address range specified in the server-level firewall rule, and ensure that the IP address of the client falls in the range specified in the database-level rule. Server level rules allow access to the Azure SQL Server. Which means that the client will have access to all the databases stored on that SQL Server. Refer to this doc.
The current VPN feature in SQL Azure does not directly prevent this (but please look for future updates where this is planned for the service endpoints feature for SQL Azure). However, there are various mitigations you can use to detect or reduce the ability to do this:
You can enable auditing on the aaa database. This can detect all logins and major state changes to the DB. (Detect)
You can reduce the permissions for various kinds of users on the database to the bare minimum and use features which further reduce the size of the data that a customer can copy out of the database at all. This includes row-level security, data masking, always encrypted (which you would lock down to a specific app/user to be able to decrypt sensitive data in the client - other clients without the key just get cypertext), etc.
Use firewall rules (as stated in the other answers) to restrict which clients can connect to the database at all - then you can restrict where they can connect with permissions.
Please note that SQL Azure's logical servers do not generally imply that every customer database in that server has the same IP. Currently there is a knob in service endpoints (docs page is currently down so I can't get you a link atm) to configure whether you go through the per-region gateway or not. If you don't (recommended), you would see the IP of the hosting node and this can change over time. The Service endpoints feature will give VPN users more control for network-level rules going forward, but some of these features have not yet landed in production. I encourage you to mitigate with other steps (above) until that is available to you.
I'm setting up a Jenkins server for a project of my company.
I configured the security realm to use LDAP and had no problem until we decided to hire external development team along with our devs.
We cannot create LDAP accounts for them for some reasons, however it is essential to use CI server together to collaborate and to get benefits of using CI server.
Is it possible to add external users who are not in LDAP?
I can think of only one solution so far.
use 'Jenkins's own user database' instead of 'LDAP' and create all users manually.
Any other solutions for this situations?
Seems like PAM is the way to go.
I haven't done it and am looking into doing it, but here is a suggestion from the lead Jenkins developer: http://jenkins-ci.361315.n4.nabble.com/Mixed-mode-authentication-td3447248.html
I don't think so , probably the best you can do it try to persuade your network security team to add the external development team to your LDAP system giving them a different security role.
For example you could create roles for jenkins_admin, jenkins_staff, jenkins_contractor and then give them different privileges but without rights to other resources.
How will you allow your external development team to commit to your SCM?
So I'm setting up a dedicated server using Debian 5 Lenny. I will be using some Atlassian Tools (JIRA, Confluence, Bamboo, and Fisheye). I want to use a local LDAP server to store information for the users that will be accessing these software titles, so that they can use one set of credentials to log in.
I also want webmail users to be configured using LDAP.
However, this is a small operation. Three people. That's why all of the software, including the ldap server, will all be on the same machine.
That said, is it safe to use LDAP to store user credentials (including passwords) in LDAP without using Kerberos? I'm confused as to when Kerberos should be used.
Hypothetically, let's say I had two servers on a subnet. Server A received requests from the outside world, for atlassian tools. Server a communicates to ldap server (internally) on server b. In that case, would I use kerberos?
When do I use Kerberos? When do I not?
I am not setting anything like "Active Directory" up. No Samba either. Users do not need to login to a domain (with access to files on the domain), they just need to login to webapps. But if I was doing LDAP on it's own dedicated machine, then I might want Kerberos?
:confuzzled: :(
-Sam
The simplest possible answer is yes, it is possible to store user names, user ids, and passwords without using Kerberos, and in fact directory services accessed via LDAP are an excellent tool for storing this sort of authentication and authorization information.
Update:
In my opinion, if you do choose an open source server, you will find OpenDS to be superior to OpenLDAP or Apache.
Basically, if you have Kerberos, you do not need any directory server. If you aren't in a corporate environment and are looking for an identity management store, you should definitively go for a directory server like OpenLDAP or Apache Directory. Kerberos require running a correctly set up DNS and NTP server. This might be way to much. Even if you do, those lazy morons from Atlassian still did not implement Kerberos support into their products. You can't even go with that.
I just noticed that there are only three of you, maybe a simple database setup with MySQL would suffice instead of running a full-blown directory server?
I read somewhere:
Analysis services should run under
network account
Ensure SQL
Browser uses a domain account
Why is that?
I did not find documentation dictating those restrictions on those 2 services. These two articles seem to give some discretion to the user on how they want to set them up:
SQL Server Configuration - Service Accounts
http://msdn.microsoft.com/en-us/library/cc281953.aspx
SQL Server - Setting Up Windows Service Accounts
http://msdn.microsoft.com/en-us/library/ms143504.aspx
The only caveat I see is for the Analysis Services service in a failover cluster configuration, it says For failover cluster configurations, use the domain user account.