Server is ethernet connected on LAN, means exposed to the internet?

You may have an Internet connection, but you are almost certainly behind a NAT router, not directly connected to the Internet.  Normally, that NAT router is the only machine that faces the Internet, has a direct connection, and is under constant attack by numerous bots roaming the IP’s of the Internet. 

You only have a local IP for your local network.  Only the router has your true IP that is seen on the Internet.  When your browser or NTP service (or other Internet need you may have) needs to see something on the Internet, it makes a connection to an Internet server, and your router notes that connection and allows that server to respond, using the associated ports of your connection.  The router will route those responses back to your machine, and not any other. 

The outside bots and servers cannot attack or connect to your machine, because they can’t even see it, and they don’t know your local IP.  The only contact that outside machines can have with your machine is strictly through connections your machine initiates first, through your router.

Now if you *did* want to put your server directly on the Internet, most routers have a setting where they can put any machine into a ‘DMZ’, a special unprotected zone, which means the Internet is directly connected to any machine you choose!  And the router won’t block any Internet traffic then, but allow all of it to come through to you. 

I would strongly advise you to first disconnect ALL of your drives, and backup your boot drive, because you will be very rapidly attacked!  Never use the DMZ unless you have a lot of security experience!

Manage another user (service account) credentials for network access

I have a Windows account that is used for running services (i.e. it’s not intended that any person should log in as that account). Turns out one of the services needs to access a remote network share that’s on a machine in a different Windows domain, and so needs to supply remote credentials to get to that share.

Now if it was me needing to access the remote share, I would simply open Credential Manager, and save the required credentials. But it’s not me, and my understanding of credential manager is it only saves credentials to be used by the logged in user.

I can of course solve this problem. I temporarily elevate the privileges of the service account to allow interactive logins, then I login as that user and use credential manager to store the correct remote credentials. Then I remove the interactive login privileges. But that feels very hacky and not the kind of thing I ought to be doing.

The work around is to log in with your normal user account and then run following in an elevated command prompt;

runas /user:serviceaccountname "%windir%\system32\cmdkey.exe /add:server.domain.com /user:username /pass:password"

For example, if service account need permission on Azure storage then;

runas /user:yourUserName.onmicrosoft.com "%windir%\system32\cmdkey.exe /add:{storageAccountName}.file.core.windows.net /user:Azure\{storageAccountName} /pass:sharedkeyofthestorageaccount=="

You will be prompted for credential. Put in your service account name and password. The credential for the service account will be stored in credential manager and you will be good to go;

Resource

https://superuser.com/questions/537697/manage-another-users-credentials-for-network-access

View effective permission of single user

Login to SQL Server as an admin account. Run following query by impersonating the user;

execute as user = 'SomeUserName' -- Set this to the user name you wish to check
select * from fn_my_permissions(null, 'DATABASE') -- Leave these arguments, don't change to MyDatabaseName
order by subentity_name, permission_name
revert

This will list all effective permission for this user;

Read, Write and Execute permission to SQL Login

I have a web application. This application connect to MS SQL SERVER 2017 for data manipulation (SELECT, UPDATE, DELETE, INSERT) and execute stored procedures. The application also run SQL Agent jobs. I need to create a user in the database to allows application to connect and execute queries, stored procedures and run SQL Agent jobs.  

Open SSMS (sql server management studio) login through sysaddmin  acount e.g.  sa

Make sure “user1” has connect permission to yourDB.

Execute this query

use yourDB
go

GRANT EXECUTE TO user1
GRANT SELECT TO user1
GRANT INSERT TO user1
GRANT UPDATE TO user1
GRANT DELETE TO user1

and also execute this

GRANT ALTER ON SCHEMA::dbo TO user1

where user1 is your user

If we want to allow this user to run sql agent jobs, we need to add it to “SQLAgentOperatorRole”. This role will allow the user to run any job on the server.

Now to SQL Agent permissions;

USE [msdb]
GO
CREATE USER [user1] FOR LOGIN [user1]
GO
USE [msdb]
GO
ALTER ROLE [SQLAgentOperatorRole] ADD MEMBER [user1]
GO

Make sure user has these permissions in MSDB database;

This is a good article on setting up jobs and an idea to integrate those jobs in UI.

for troubleshooting, assign user to “sysadmin” Server Role. Make sure to revoke this permission afterwards.

How to Drop Orphan User in SQL Server (Msg 15138)

I am not able to drop a SQL user and keep getting this error message;

Msg 15138, Level 16, State 1, Line 5

The database principal owns a schema in the database, and cannot be dropped.

There is an orphan user who owns a schema or role and can not be dropped until user is detached from schema/role.

First see if there is any role associated and remove it;

-- Query to get the orphan users
EXEC sys.sp_change_users_login 'REPORT'

-- Query to get the user associated Database Role
SELECT 
	DBPrincipal_2.name as [Role], DBPrincipal_1.name as [OWNER] 
FROM sys.database_principals as DBPrincipal_1 
INNER JOIN sys.database_principals as DBPrincipal_2 
	ON DBPrincipal_1.principal_id = DBPrincipal_2.owning_principal_id 
WHERE DBPrincipal_1.name = 'ADDUSER'

--Query to fix the role
ALTER AUTHORIZATION ON ROLE::[db_owner] TO [dbo]

SSMS STEPS: Object Explorer->Target Server->Target Database->Security->roles->Right click on database role. Change user name to your selected name or “dbo” and click OK.

Now fix the issue where we will transfer the ownership of the database role/schema to dbo.

----*** Query to get the user associated schema
select * from information_schema.schemata
where schema_owner = MyUser'

--Query to fix the error Msg 15138 on database schema
ALTER AUTHORIZATION ON SCHEMA::[MyDatabaseSchema] TO [dbo]

--Query to drop the user
DROP USER [MyUser]
GO

SSMS STEPS: Object Explorer->Target Server->Target Database -> Security->Schemas->Right Click on schema->Change user name to your selected name or “dbo”.

Schema and/or database role has been transferred to “dbo”. You are safe to drop the user.