I have a project soon to ensure we have both the admin and user audit logging enabled in all keycloak configurations for both existing and future deployed systems.how we can do that if we have to automate the process and what string will we use for this?
i know and tried how to enable login audit manually but what to see if there is any automated way to do that and even if we have add strings in configuration or in database what will be the strings?
Related
I have configured SQL Audit but can not see the caller application. Is that at all posible?
Our application requires that users are created with a login, and I would like to be able to distinguish whether their queries come from the application or from e.g. SSMSP
I want to authorize several Logic Apps to access operations on an API secured by an app registration, which has several app roles describing different operations. Currently a directory administrator is doing this manually using New-AzureADServiceAppRoleAssignment once the Logic Apps are created, because the associated service principal doesn't exist until then.
I'd rather this were automated, because especially in development, the manual work of asking a directory administrator to re-run this script is very tedious. However I don't know how to grant the scripting account - a service principal linked to a DevOps service connection - only the permissions to do this, and not make it a directory administrator able to do anything. If the service connection is a directory administrator, developers would be able to supply it scripts to tell it to create or delete any combination of role assignments, enabling them to let themselves into anything, and also shut out people who should be able to prevent this. This is an unacceptable security hole.
What is the minimal permission needed to allow an automated process to script the creation of app role assignments but nothing else, and where is this documented?
For this requirement, you can just add the scripting account as owner of your app(just create a new user without any roles and add it as the app's owner). Then it can just add role assignment in this app but can't do other operations on role assignment of other apps.
We have an instance of SSRS running on 'Local System' service account. I have added the SMTP settings to the Configuration Manager. I now want to change the service account to use an authenticated Windows AD account to I can access the Exchange server and utilise subscriptions.
I am using 2008, other than a need to restart IIS/RS I want to check about the symmetric keys that are used for accessing the report server database that have been encrypted with the local machine.
I want to check the steps and caveats of changing the service account in configuration manager from Local System to MyDomain\My.User.
This page mentions about having to backup encryption keys first, then removing the reference to it after stopping IIS. Updating the service account and creating a new key before starting IIS.
So I need to do/worry about this or will the tool just handle this?
I suspect the tool 'should' manage all this for me but we know what assumptions are.
You need to use the Reporting Services Configuration tool to make changes to the service account being used. If you use this tool then it will automatically take care of permissions changes and modifying encryption keys. More details are available on MSDN.
The issue described on the website you linked to probably occurred because the service account was changed using the Services management tool in Windows, rather than the Reporting Services Configuration tool, and therefore the encryption key was not automatically updated.
Regardless of the above you should always back up the encryption keys for the report server and store them elsewhere.
I want to create a publication task in Jenkins to automatically publish my database changes along with my application.
If I understood correctly, a common practice is to create a publish profile that includes the database name as well as the account (login and password) of the account used for the deployment.
This means that the deployment account username and password will be stored in clear text on each developer computer as well as on the version control server and the continuous integration server.
Even though I created a specific login and password for the deployment, it seems pretty unsecured to me.
Is there a workaround? I can only think of replacing the password within the msbuild command line on the continuous integration server.
tl;dr version
Windows Authentication is the preferred, secure method of connecting to your SQL Server instance and if it's possible to use that then it's recommended to use that for connections.
If SQL Authentication is used then the default in publish profiles is that the password isn't saved. For build servers and other shared profile scenarios you may need to accept lower levels of security (by editing the publish profile to add the password, or setting it as a parameter in the build configuration) or work around it in some other way (custom script that reads it from some kind of a secret store, such as an encrypted value).
Long version
Windows Authentication: If at all possible use Windows Authentication, giving permissions as required to users who need it. For Continuous Integration scenarios you would need to give appropriate permissions to the account the build server executes under - full details are in the recent whitepaper on the SSDT blog.
SQL Authentication: If you look at the publish profile (Open With... Xml Editor) you'll see that the password information isn't actually stored there.
If you choose "Save Password" you'll have "Persist Security Info=True;" stored in the connection string rather than the password itself.
When a connection is made to a server/database in SSDT with "Save Password" enabled, the connection info is encrypted and stored in the registry under "HKEY_CURRENT_USER\Software\Microsoft\SSDT\ConnectionStrings". This has to be present on the machine in order to successfully publish using the publish profile.
Hence in a team environment every user would need to connect at least once before that publish profile would work for them. However, the password would be safely encrypted on user machines.
For the build server, your options are more limited. One possibility is to manually log in as the build server user and then connect to the database, but this isn't very scalable. To avoid the less secure options you mentioned you'd need to implement your own logic for persisting the password securely. You can look at the Protected Data API which can be used to do something similar to what SSDT does but on a per-machine level, or use an encrypted configuration file.
If you have to use SQL Authentication I think passing the password into the publish action as part of the build configuration may be the "best" way to go in terms of a tradeoff between ease of development and security. At least that way you can restrict who can view and edit the build configuration in TFS and regular developers won't see it.
I prefer to keep our SSIS packages in a solution on the server, not in sql. By default, sensitive data is encrypted with a user key. Since the sql server agent uses a service account to run jobs, we have to change this encryption method to something else. I like encrypting with a password.
The problem is whenever I setup a job in a step there is no place to input this password. When I click on the configurations tab, I get a popup dialog for the password. That keeps it stored properly, but is this really the right place to put it. It seems really unusual, and I keep running into issues where it seems to reset itself if I make certain changes.
Does anyone know of a better place to input this password that is more stable?
Thanks,
There is no need for you to have a password in the package at all if you can use Windows authentication and avoid SQL Server authentication and ensure that the rights necessary to execute your package are available to your service account.
Barring that, you should already be overriding the connection string with a config file using package configurations so your package is portable, and then the password doesn't need to be in the dtsx anyway.
The way you deploy your package and store your package in your local project solution can be different. You can save sensitive data with a password when saving your packages locally and "rely on server storage and roles for access control" when deploying the package. Although the data will not be stored in an encrypted format in the msdb database, you can restrict access to the password information by managing pre-existing database roles.
You need set the password on your Job.
Go to the properties of your Job > two clicks over your Step > in the tab "General" type your login and password, than in the tab "Configuration" type your password (the password that you put inside the SSIS)