I'm logged into a Windows 8.1 machine using domain admin credentials and want to run regsvr32. I receive an access denied error unless I choose Run As Administrator from the context menu. Domain Admins are in the Administrators Group as seen in the Local Users and Groups window. Can someone explain why? Thanks.
It is part of User Account Control, which was introduced in Vista.
Admin users do not have full admin rights by default, even they have to be granted permissions when appropriate. It is Microsoft locking down its security model for a "Least Privileged Environment", where a user does not have more permissions than they actually need at any given time.
Have a look at this article:
The Windows Vista and Windows Server 2008 Developer Story: Windows Vista Application Development Requirements for User Account Control (UAC)
Related
I'm building a windows application from Visual Studio - VB.NET. This application administrative privileges from the operating system. This is completely fine with the PCs which got the administrative privileges. But for the PCs which doesn't have administrative privileges the UAC prompts.
I tried so many things to embed administrative access to the application but non of them success.
Please guide me to make this success
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 am trying to install DNN using Web Platform Installer. It tries to connect to .\SQLEXPRESS, which I have installed along with SQL Server, and wants me password for sa. When I provide it
with a password, it says "password invalid or cannot connect to database".
I thought to myself there might be a problem with the sa account. I opened SSMS 2012. There is a red arrow downward sign on the sa account. Whenever I am trying to change login status to Granted it opens up an error message:
error 15151
Cannot alter the login 'sa' because it does not exist or you don't have permission.
Nonetheless I tried it with administrator account and also by disabling UAC. None worked. Screen shot follows:
Details:
SQLEXPRESS version: 10.0.2531
SQL Server version: 11.0.2100
Update: Following some guidelines I tried to change authentication in SQL Server Management Studio from Windows Authentication to Mixed Authentication, but it failed with the following permission error:
Make sure you're connecting with a server login that has the sysadmin server-level role. You'll need that permissions level to do what you're trying.
Check the server authentication mode. If it is or was Windows Auth only, the sa account is automatically disabled. Note that if SQL Authentication was disabled and later turned back on, the sa account will still be disabled.
If you find that nobody is in the sysadmin server-level role, you'll need to stop the server and restart it in single-user mode so you can add at least one login to the sysadmin server-level role. In single-user mode, the Administrators group has sysadmin access, but you'll have a limited subset of commands to manipulate data in tables (single user is for fixing servers, not running applications). NB: Only one connection is allowed in this mode, so if you have a broker or service that's trying to connect you'll need to disable that or it can take the session you were planning to use with SSMS.
This question is related to: Windows authentication does not work
I am developing a .NET 4.0 MVC3 application that has Integrated Windows Authentication turned on. If I open my application from my development machine (I am logged in as DOMAIN\USER) I am logged in automatically as DOMAIN\SERVERADMINACCOUNT. From any other machine on the network everything works as expected (current user is logged in automatically using NTLM).
Does anyone have an idea what's happening? The server is Windows 2003 with IIS6. All clients machines are Windows XP with SP3 or Windows 7 (mine is XP).
I found the answer!
In Control Panel -> User Accounts -> Advanced tab I clicked Manage passwords button and removed the configuration for the domain I used. Now I am logged in to my web application as a currently logged in Windows user.
I have an LDAP server Novell eDirectory in my Environment through which has the user data. In my Environment i have set of Windows and Linux servers. I need to use this LDAP As the Authentication Source for for both the servers.
For Linux i need to achieve this by setting the linux as LDAP Client & extended edirectory schema for linux users and users are able to login into the machine and even able to create the home directories for the user. But the problem comes with the windows machines.
For windows machines i have used novell gina which authenticates the user using LDAP but it also requires a local or domain user credentials to login into the local system.Then for every user i have to create a local user on every system which is off target of purpose.
Then i have used pgina (Another Open Source Gina) through which i can authenticate the user using LDAP and it creates a profile for the user. Fine but it is also creating a local user with the LDAP username.If any admin changes password on the local machine for this user then the password of both the LDAP and local user will not be in sync.
How can i get the login behavoiur of active directory where it will authenticate against active directory (Think AD as LDAP) and creates a profile for you in the local system but never creates a local user.Anybody can throw some light on this to solve the issue?
Thanks and Regards,
Sunny.
I guess you are using Open Enterprise server. If you are on OES linux, probably you can use Domain Services for Windows This can help achieve what you want. You will not even need a gina login. Its a Domain emulator. So, there wont be any ldap login. It would be a kerberos login. Your eDirectory (and other related services) work exactly like AD domain. But nothing stops you to use the plain ldap login against eDirectory. You can continue to use the linux login as its now. If you are using gdm (gnome display manager) on linux it can do a domain login like the windows.