Hi, I have one for any DBA's out there about the superuser account. - sql

Is there any database that comes with NO default superuser account, or is there a way to have no superuser at all. I have extensively researched this for the past week and I can find nothing on this topic. My manager is keen on having no superuser by the time the system I'm working on is in deployment, however I feel this is not possible?

With MS SQL Server you can install it to use windows accounts. So you set up superuser tied to windows account. After deployment just disable this account in Windows and you are good to go.
To make sure it works properly you enable audit on user enabling, so you know when someone tries to enable the user account and use it to access DB.
It is bad idea to remove sysadmin completely because you might run into lot of troubles in the future.

Just yesterday our intern set up SQLServer and didn't add a database administrator at the relevant step in the setup, so it installed but was rather useless..
Questions like this are from a similar side of the fence:
https://dba.stackexchange.com/questions/11299/how-to-add-sysadmin-to-user-in-sql-server-2008-when-no-sysadmin-accounts-exist

Related

Change TFSService password

We would like to change the password for our TFSService account. This is the domain account that was used install TFS and has several Windows services running under it.
I did review the link below on changing the TFS service password. Is it as simple as updating the password in Active Directory and then using the TFS administration console to update the account password? Are both steps above required? Are there any additional tasks required?
https://learn.microsoft.com/en-us/tfs/server/admin/change-service-account-password
thanks
Yes, it should just be that.
As with any production environment, there may things in your setup strangers on the internet are not aware of, so it would be best to test this process on a non-production copy if possible first.
Although I know setting up a non-production copy of TFS will end up probably end up running on a different domain.

Creating databases and tables in ssms

I just installed ssms on my local computer.
When I try to create a database or a database table it gives me an error stating that I don't have the right permissions. I tried granting permissions for this user by going to Security->Logins->myUser. But again it told me I didn't have the right permissions. I then tried adding a new login/user which gave me the same error.
What can I do to give myself the correct permissions if I installed the ssms and there are no other users except sa, which has "login with this user" disabled by default. I can't login as another user and I can't change my current user permissions. VERY CONFUSED - someone please help!
During the installation you (or somebody else) had to add an user besides the SA to login with Windows authentication. Use this user.
Your user is a simple user that does not have enough permissions.
If you are not the guy who installed the server, ask whoever installed this to set the right permission for your user.
Also please check recover-sa-password and Disaster Recovery: What to do when the SA account password is lost in SQL Server 2005
You should check that you are placing the files in a folder where the SQL Server account (not the one you are logging on as, but the service account) has rights to write.
For starters, and not to be kept in a production environment, try to make sure that the default path for placing the database files has Read/Write set to Everyone.

Does using "chmod 666" on specific directories creates any vulnerability? (installing Kohana)

Obviously I am very new, so please bear with me.
I installed Kohana Framework in my localhost. To do is so we have to set two specific folders with write permissions to all. "chmod 666" is suggested. (here)
The remaining directories are set to 755.
My question is more directed to Apache.
Will the use of "chmod 666" create a vulnerability in a webserver?
What exacly means "write access for everyone"?
Many thanks in advance!
666 is almost always a really bad idea. The web site where you read that needs a good flogging.
"Write access for everyone" means that anyone with a user account on your system can write to that directory.
These rights are only for your current server, so if you are the only one with access to a user account on your machine you should be pretty safe. Write access for everyone means everyone with a user account on your machine has the right to write. Please note that 3rd party software (like apache) can have it's own user as well and this could be compromised if there's a exploit in that software. This way someone from the outside could gain access to that folder. It's a common practice to only give rights to users that really need access.
Note: On a normal Windows machine (don't know if this is still true with Windows 7 though) everyone has access to everyone's files. So this is just another security measure.

Can Hudson be configured to prevent certain users from accessing certain projects?

I have various projects being built and tested periodically on a Hudson server, but I don't want every employee in the company to see published artifacts for every project.
Project-based matrix security seemed at first the key, but after many tests I find that granting overall read permissions is mandatory if you want users to be able to read anything in the hudson server.
So, in the end read permissions are binary: either you grant global read permission or you block everything, am I right?
Haven't it tested with the newest release, but I use the matrix setup. I gave Anonymous the overall read. This way they can see the login screen when they type {{http://servername:port/}} but does not give them access to the jobs. In the jobs themselves I configured the users that should actually see the job. Works like a charm.
UPDATE:
Meanwhile I found out that you can use authenticated instead of Anonymous. This enabled access to Hudson/Jenkins through the links in the Build failed messages. Now everyone gets the logon dialog and after signing in, they are right away at the job run of interest.
After trying to do something similar to you with Hudson's authorization settings, I came to the same conclusion you did.

Vista + VB.NET - Access Denied while writing to HKEY_LOCAL_MACHINE

I want my program to be able to edit a values within a registry key that resides in 'HKEY_LOCAL_MACHINE'
My.Computer.Registry.SetValue("HKEY_LOCAL_MACHINE\SOFTWARE\XYZ", "MyValue", "MyData")
The above works fine in Windows XP, but throws an UnauthorizedAccessException in Vista.
You are running into Vista's UAC feature. It will not let you write to arbitrary places in the HKLM hive because you are not running with Administrative priviledges.
There are two ways to work around this issue
Run the program with Administrative priviledges (different than running a program as an account which has Administrative priviledges)
Choose another place, perhaps HKCU, to store the data
The second option is much better as it allows your application to run with non-Admin priviledges which you can't always assume your user has.
Here is a fairly detailed article on UAC. It's not 100% programming material but it gives a good explanation as to what exactly it is and you can hopefully relate that to your particular program: http://technet.microsoft.com/en-us/library/cc709691.aspx
Since changes to the Local Machine hive can have affect across the system you will find that changes to it are restricted to non-administrative users. If you try to run your same code on an XP machine a non-admin account you will get the same error. On Vista since the process is non-admin by default you are getting this error. Information on this is in the "Made for Windows 2000", "Made for Windows XP", and "Made for Windows Vista" certification guidelines.
Given that I've got little information on what your program is doing more information may be needed to give you specific guidance, so I will speak in the general case. You want your application to leave the local machine hive alone unless you need it. When your program is run in non-admin mode it you can either disable the functionality that requires access to these admin keys or you can request that the admin privs.
Vista has tighter restrictions around Adminstrator accounts. If you're not logged in as an Administrator account, you'll have to write to HKEY_CURRENT_USER as opposed to HKEY_LOCAL_MACHINE.
IMO, this makes more sense. Each user has their own settings/etc for their programs. If you want to make global settings for your program, you'll have to do it with an Administrator account.