I have an Ubuntu 15.04 Server set up as a AD controller. The server also has shares for which I have assigned the proper permissions for our staff. My problem is that I need to backup the shares using rsync on the server but the server user (svradmin) (not being a part of the AD domain) does have SUDO rights but not access to the shares. How do I get around this? I am not sure how to give the server user access to backup the shares.
Needed to run rsync under sudo. Rookie mistake.
Related
This was the second time this issue was happening. after a server restart, I couldn't connect to the SSAS tabular model through SSMS with neither my own username (admin) nor the service account.
However, we could all connect to the model from other servers in the network.
The icon changes to this as well :
after restarting the service a few times and restarting the server and running CHKDSK \R on all drives and getting to nowhere, it gets fixed by itself.
We are really concerned as we cannot find the root cause of the issue and don't want this to happen when we go live with the project. any idea?
Please ensure when you are trying to connect to SSAS or SQL locally that you open SSMS with Run as Administrator. My assumption is that your account has been given access through the local Windows Administrators group (rather than through direct permissions on your username or through different group permissions). When that is the case, Run as Administrator is required to utilize those local Administrators group permissions on the local server. This is not the case when connecting remotely to a server.
So what I need is a remote/cloud Windows Server that I can connect to using RDP (or another remote connection program) where I can create users, groups, basically everything I could do with an on-premises Server instance. What I need though is to be able to setup all the office computers to authenticate through the cloud AD. I have no clue how to do this. I cannot have a Server running on-premises, period. Just need something where I can connect each computer to the remote domain/forest, hopefully using an IP to the server, and then have the employees be able to logon to any domain-connected PC using their credentials. Thank you for any and all answers! -Scott
You need Azure Active Directory. You can control everything with remote management in the way you have described. Per the provided link, "Azure Active Directory (Azure AD) provides an easy way for businesses to manage identity and access, both in the cloud and on-premises."
Hope someone might be able to help. We have a TurnKey VM running OpenLDAP however cannot SSH to the server and can only access LDAP. That's it.
https://www.turnkeylinux.org/openldap
Is there anyway to get the LDAP database without SSH access?
Otherwise, we have console access, however this is limited. When we SSH in to the server, it just stalls and nothing happens.
Thanks
I'm looking at using SQL LocalDB as the client side database which will replace the current SQL CE 3.5 database inside an in-house application developed in .net 4.
I've come across a problem that I'm not sure how to get around and that's with security setup of the LocalDB instance.
If I setup a script inside .net to create a private LocalDB instance, e.g. (localdb)\T1, then create a new database inside that instance plus add a SQL user account + password (non domain account), how do I stop the local windows users (like my own AD account) with admin level privileges from accessing the 'T1' instance + database using SSMS?
I could see a scenario playing out where we deploy the application, then we have some IT savvy user who goes snooping around and decides to install SSMS and connect to (localdb)\T1 with their windows account, which would give him/her full access to the database, which is exactly what I'm trying to stop from happening.
Some of our staff work remotely with no connection to a domain so we give them local admin rights to their pc so they can install software, so even if I could block their assigned windows login name, there would be nothing stopping them from setting up a new local admin account and logging in with that, opening SSMS then accessing the database.
Any pointers on this would be greatly appreciated!
In fact, it shouldn't be so hard. Install SQL Server on client machine using local admin account. To make you life easier, use Mixed Authentication.
After you have your instance installed, local admin account should have sysadmin server role assigned (that's normal security settings). Now, use the following:
Create new SQL Server user and assign sysadmin server role to that account. Close SSMS and log-in using new credentials. Or simply use sa account (not so good practice but in this case it's OK).
Go to "Security - Logins" and remove sysadmin role from local admin. Also, check in user mappings and take all rights "away" from local admin.
As a test, try to log-in as local admin, I guess you won't be able to log-in into server because there is no "home" database for that user. But even if you can log-in, it has only "public" role.
It's up to you to install your database and secure it - assign permission to user of your choice.
Regarding you fear that local admin can install MSSQL again: he/she can install it, but it would be another instance. That instance knows nothing about users in your instance so you should be safe.
You can also consider usage of application roles in SQL server.
I brought my laptop home from work hoping I could get some tasks done over the weekend. Unfortunately, I couldn't login to SQL Server using Windows Authentication. I've checked the SQL Server Configuration Manager and the instance (MSSQLSERVER) is set to Log On As Local System, which supposedly means that I should be able to login fine using Windows Authentication... or am I missing something here? Note that in the login window, I tried a lot of different combinations and it always keeps telling me that connection failed because the server is not accessible or I'm not authorized to access it.
A little background about how the instance was installed: I installed and configured it myself. I chose the Mixed Authentication mode and gave a password to the default sa user (which isn't working either by the way). The thing I suspect could be the problem is the fact that I installed the SQL SERVER instance when I was logged in as my Domain User at work (DOMAIN\UserName). Now I'm at home and I do not have access to the LAN at the office, so I'm logged in as the {COMPUTERNAME}\Kassem user.
Any thoughts?
A windows account has to be added to SQL Server to have any rights. If you didn't add {COMPUTERNAME}\Kassem, you can't login to SQL Server.
The recovery option here is the SA password, which should always work.
To connect to the default instance, connect to localhost or .. Connecting to .\MSSQLSERVER won't work, even though MSSQLSERVER is the default instance name.