Generic Kms Key Windows 10 Enterprise
Sherry Galeazzi
We are trying to setup the IRPA process to scan supplier invoices in ByDesign. As a part of setup we are supposed to maintain a windows generic credential which is similar to ByDesign login credentials.
But the problem is we are not using the password policy to login to ByDesign instead we have setup a single sign on (SSO) and in this case we actually do not have any credentials which we can use in Windows Generic Credentials. I've searched for help document as well but could not find any answer for this. Can you please help me is figuring out how to setup the generic credentials if the ByDesign login security policy is single sign on.
The bots that have been published by us have explicit steps where the username and password information is read and used. The standard delivered bots are designed for basic authentication but not SSO.
Each user who logs into the device and has access to the Office suite needs to have their own licence. But suppose for a moment there are 50 devices and you log into a different one each day for 50 days, on day six, you would have a problem because Microsoft 365 business and enterprise licences that include the Office suite only allow for its activation on up to five devices.
What the club would really like to do is have named individual logins for staff, but then have generic logins for volunteers who need access to a limited range of content, and a different generic login for kids who need access to a different limited range of content.
What follows below is how this could be implemented with a mix of individual accounts for named users, and generic accounts for volunteers and kids. This is not licencing-compliant but I suspect its how many smaller organisations operate because they have been given no viable option by Microsoft.
For example, if you require MFA either at every login, or periodically, then you need to ensure these accounts are either excluded or that MFA is achieved using an Office phone physically adjacent to the device on which the accounts are used. You might also want to think about how to prevent the account being used on any device except that on which it is intended to be used.
e.g MS Clustering requires the pre-defined clustering admin account, the SQL Server sys. admin. account "sa" is required to run some functions and replacing this with a named admin account which should have the same access rights as "sa" just does not work sometimes, etc.
IMO this is operationally dangerous, as there will always be situations where access is needed to a specific account there and then to deal with an immediate emergency. And as anyone who has worked in IT for more than 10 minutes realises, these emergency situations occur all the time.
SOX is about seperation of duties and the creation of procedures to monitor and control same. Once you have a procedure in place to cover the 'viewing/usage' of an 'SA' type password, and that procedure is documented and repeatable, then you are covered. One way to get around your immediate issue....is to put the password in an sealed envelope and to maintain a register of when it was created/opened. If the 'SA' holder is not available, then the register is updated + countersigned, the envelope opened, password used, problem solved, password changed, new envelope created, register updated + countersigned. Being SOX compliant will be a matter of showing your SOX auditors the register, the current sealed envelope and the process of opening/using/creating a new version.
"SQL Server sys. admin. account "sa" is required to run some functions and replacing this with a named admin account which should have the same access rights as "sa" just does not work sometimes, etc."
Assuming that the envelop is not kept under lock and key. If I want to make an unauthorized change to the production db I just rip open the envelop, make my db change, change the password, put it in a new envelop and viola! Since the password is only written inside the envelop there should be no audit trail that it has been changed. In fact I wouldn't even need to change it I would just place it back in a new envelope. Perhaps a wax seal with the directors signet ring...
I work in a 15 person DBA shop that supports 425+ SQL servers, one-third of which are production. All 15 DBAs are in a global group which is a member of the sysadmin fixed server role on all of our SQL Servers. We do not separate duties into dev, QA, and prod, and we are not developers or business people.
We have been looking at several solutions to the sa account problem in the context of an imminent SOX audit. The problem as defined is that the sa account allows anonymous access using a priviledged, shared account. So we are trying to address the problem either by making the sa account inaccessible, or monitoring its usage. We have identified three solutions.
3) Randomize the sa password daily, and modify the system stored procedure sp_password to record whose account attemted to change the sa password. Also monitor for the use of sp_configure to set Allow Updates to 1.
1) auditing adds performance load to the system and it renders the errlog and the application eventlog useless because of all the noise. Also, you still don't get any information about which windows account actually logged in as sa.
2) tracing adds performance load to the system, especially on very busy systems where the load increases exponentially as the system becomes busier. Also, you still don't get any information about which windows account actually logged in as sa.
Microsoft recommends going to Windows Only authentication mode. Great! We'd love to, but we aren't developers. We can't just flip a switch and then let the application support people sort out the mess. Ultimately, this is a difficulty that Microsoft created by having an sa account that had no controls on it at all. When I've asked MS what they are doing about this, they are barely aware of something called SOX. They've been useless.
With the number of servers we support, it would be impossible to operate effectively without DBAs being sysadmins. Impossible! We have good separation between developers, change management approvers, and DBAs. We have good processes and procedures, but we have been operating in the modern environment of competition with outsourcers and co-sourcers. If we can't operate efficiently, we may not be a support group worth keeping internal.
I would most appreciate somebody sharing a real solution to this problem of SOX and the SQL Server sa account. Remember, we support a large enterprise of servers. We have to automate everything to be effective and efficient. Half-baked solutions won't work.
This program allows you to select which users are able to unlock the system using their own Windows domain credentials. A log of when the system is locked and when and by whom it is unlocked is kept in a protected file as well as a Windows
James - auditing logins for the sa account only should not have any visible impact to your SQL Server performance. If you have a couple of SQL Servers to audit then SQL Trace would do just fine. If not an audit software would work just as well. But depending on how secure you can make the SQL Server machine, it may not even be needed (see below).
Regarding access to the 'sa' account I would make sure no one would be able to use it outside of the SQL Server box itself. Instead you could have 15 sa proxy accounts (saJohn, saSally...) each with its own password - one for each of your DBAs that map to the 'sa' account. Now you would know which DBA is using the 'sa' credential without giving the DBAs the actual 'sa' password. You can do this really easily with a SQL Server proxy - there is one free on the pynlogic website.
I would add that giving sysadmin access on a production server to anyone's everyday ID is just plain stupid. Set up ID's that are specifically for privileged access. That makes it easy to track what each ID did, and prevents the issue of accidentally running a truncate script meant for a test box against a production server.
Fourthly, get together with the people who make the security decisions and write down a solid policy of how these passwords are passed out, by whom, the acceptible reasons for giving people access to these accounts, the reasons for account access "rejection", how you are tracking who has account access and how you deal with the account access when someone changes jobs / teams or leaves the company.
Now, as a DBA, your situation makes me majorly paranoid, waiting to change the SA password and revoke access to everyone's accounts. But from a SOX Compliant POV, really all you have to do is plug the holes and document the process.
c80f0f1006