However, some extractions and conversions are required before these certificates can be used on Windows and configured for SQL Server.

Here, the idea is to propose a solution (the architecture) that prepares the certificate, imports it on the SQL Server host, and configures SQL Server to use it.

We will also see how to separate the preparation and activation steps in order to reduce the impact on the SQL Server service.

In this blog post, we will describe the global approach and the Ansible logic used to implement certificate-based TLS encryption for SQL Server.

Implementation logic

Before configuring TLS encryption on SQL Server, the first point was to understand the certificate format provided by the customer PKI.

In our case, the generated file is a <machine>.pem file. This file contains the server certificate used for TLS, the private key and the certificate chain with the intermediate and root certificates.

As this format cannot be directly used as-is on the Windows side for SQL Server, some extraction and conversion steps are required.

The general idea is to use the Ansible control node as a working area.

The PEM file is first copied into a temporary folder where the different parts of the certificate are extracted:

• the leaf certificate
• the intermediate certificate
• the root certificate
• the private key

These elements are then used to build a PFX file which can be imported on the Windows SQL Server host.

The PFX is installed in the LocalMachine\My certificate store while the intermediate and root certificates are imported into the appropriate Windows certificate stores.

The implementation has been designed around three different execution modes: stage, activate, and full.

The stage mode is used to prepare the certificate without any impact on the SQL Server service. It copies the PEM file, performs the extractions, builds the PFX file, copies it to the managed Windows node and imports the certificates into the Windows certificate stores. No registry change is performed, and the SQL Server service is not restarted. This mode is useful when we want to prepare the server in advance before switching SQL Server to the new certificate.

The activate mode assumes that the certificate is already present on the Windows server. Its role is to configure SQL Server to use the installed certificate and depending on the selected option, restart the SQL Server service or leave the change pending until the next planned reboot.

This can be useful when the certificate activation must be aligned with an existing maintenance window, for example during monthly OS patching.

The full mode executes the complete configuration from end to end. It performs the extraction and conversion steps, imports the certificates, grants the required permissions, configures SQL Server to use the expected certificate, and restarts the SQL Server service only if required. To avoid unnecessary impact, the role relies on the certificate thumbprint. If the expected certificate is already configured, no change is applied and the SQL Server service is not restarted. This behavior is important for idempotency.

For example, if the full mode is executed after an activate mode, nothing should be changed if the certificate is already the correct one. The same logic applies if the playbook is executed by mistake while the certificate has not been renewed.

Another point to manage is the restart of the SQL Server service. SQL Server loads the certificate configuration when the service starts. Therefore, when a new certificate is configured, the change is only effective after a restart of the SQL Server service.

For this reason the role should provide an option to control whether the restart is performed immediately or postponed to the next planned reboot.

We also have to consider DNS aliases. The standard use case is to generate a certificate containing at least the short name and the FQDN of the SQL Server host in the subjectAltName. If DNS aliases are used by client applications, they can also be added to the certificate SAN.

For example:

[alt_names]
DNS.1 = A-WS2022-2.lab.local
DNS.2 = A-WS2022-2

Finally, the customer confirmed that the private key included in the PEM file is not encrypted.

This simplifies the conversion process to PFX, but it also means that the PEM file must be handled carefully during the Ansible execution, especially in temporary folders and during file transfers. With this approach, the role provides a controlled way to prepare, activate, or fully configure TLS encryption for SQL Server while keeping the impact on the SQL Server service under control.

Logical workflow

The complete workflow can be represented as follows:

Architecture summary

The certificate manipulation is performed on the Ansible control node.

The Windows certificate import and SQL Server configuration are performed on the managed Windows SQL Server host.

This separation is useful because the PEM processing and PFX generation are handled with Linux tools such as OpenSSL while the certificate installation, private key permissions, registry configuration and SQL Server restart are handled through Windows modules and PowerShell. The design also supports a controlled deployment approach.

The certificate can first be staged without service impact then activated later during a maintenance window.

The full mode can be used when the complete implementation must be executed in a single run. The use of the certificate thumbprint is important for idempotency. It allows the role to detect whether SQL Server is already configured with the expected certificate and avoids unnecessary service restarts when no change is required.

Remarks

For certain reasons we do not disclose the code of the created role.

Thank you. Amine Haloui

L’article Customer case study – automating SQL Server TLS Encryption with Ansible and Certificates (Architecture) est apparu en premier sur dbi Blog.

The Multi-Layered Threat: Why One Tool is Never Enough

We’ve all left the key in our bike lock at least once. This simple human oversight makes the heaviest chain irrelevant and we often see the exact same logic applied to data environments. Most organizations spend months hardening their production core but leave the keys in the locks of the dev and staging systems that sit right next to it.

The numbers back this up. While 91% of organizations are concerned about their exposure across lower environments, a staggering 86% still allow data compliance exceptions in non-production. This gap between concern and action has real consequences: more than half of these organizations have already experienced a breach or audit failure in their testing and development systems (PR Newswire).

Effective security is rarely a single-layer problem. Between the stolen backup that lands in the wrong hands, the analyst running a SELECT on a table they probably shouldn’t see, and the packet quietly crossing an unsecured network segment, the attack surface is wide, and no single mechanism covers it all.

Transport Layer Security (TLS), Transparent Data Encryption (TDE), symmetric encryption, dynamic masking, row-level security, data anonymization: for most RDBMS, the options exist and they work. Most teams already have access to at least one of them. The real challenge isn’t finding a solution; it’s understanding what each one actually protects, where it breaks down, and whether it survives contact with a production environment.

Shadow Environments: The Weakest Link in Your Data Chain

Here is the uncomfortable truth: non-production environments are often where security policies are quietly buried. It starts with a backup restored without encryption, or real customer data seeding a dev database “just for a quick test“.

The fundamental problem is that most protections assume a controlled environment. Encryption can be bypassed by someone with the right credentials. Masking can be misconfigured. Row-level security doesn’t help much when the whole database is sitting on a developer’s laptop.

Technical Trade-offs: Finding Your Strategic Fit

To make this reasoning concrete, the table below maps six core techniques against the operational criteria that define their success. The goal isn’t to pick a favorite tool, but to identify which combination actually addresses your specific vulnerabilities.

	Physical File Theft	Read Access (SELECT)	Network Sniffing	Performance Impact	Granularity	Applicable in Prod (live data)	Applicable in DEV
TLS					Data packet
TDE					Column Tablespace Datafile
Symmetric encryption (applicative)					Field Value
Dynamic Masking					Column
Row-level security					Row
Data anonymization					Field Column

• TLS protects data in motion. The moment a packet leaves a server, TLS ensures anyone intercepting it sees encrypted noise. What it doesn’t do is equally important: it has no opinion about who queries your database or what’s stored on disk. Once the data arrives, TLS’s job is done.
  TLS is now the industry standard for securing data in motion.
  (SQL Server technical blog about TLS here)
• TDE encrypts the physical files that make up your database (data files, log files, backups), so that anyone who gets their hands on them without the encryption key can’t read them. The performance impact is a negligible overhead; in fact, Microsoft for example enables TDE by default for all its cloud-based databases.
  (PostgreSQL technical blog about TDE here)
  However, deploying TDE in development is a security best practice, but it quickly becomes an operational nightmare for environment refreshes, especially if you want to use distinct certificates to avoid leaking production secrets into lower environments.
• Symmetric encryption is field-level encryption applied directly in the application layer. Unlike TDE, it survives a legitimate SELECT; even a user with full read access sees ciphertext unless they hold the applicative key. The tradeoff is performance: encrypting and decrypting at scale adds up quickly.
  (MongoDB technical blog about Client-side Field Level Encryption here)
• Dynamic masking doesn’t encrypt anything. It intercepts query results and replaces sensitive values with masked equivalents based on the user’s role. Fast, lightweight, zero application changes required. The catch: it only controls what’s displayed, not what’s stored. A user with sufficient privileges can bypass it entirely.
  (SQL Server technical blog about dynamic masking here)
• Row-Level Security enforces access at the row level directly inside the database engine. Users see only the rows they’re allowed to see, regardless of how the query is written. No application changes, no trust placed in the calling layer. The policy lives in the database and applies universally.
  (Oracle technical blog about Virtual Private Database here)
• Data anonymization doesn’t protect sensitive data, it eliminates it. Real values are replaced with realistic but fictional equivalents (synthetic data), permanently and irreversibly. No encryption key to steal, no masking rule to bypass. Whatever leaks simply isn’t sensitive anymore. This is why anonymization is the only control that makes unconditional sense in non-production environments. A stolen backup, a misconfigured SELECT, a sniffed packet: none of it matters if the data was anonymized before it ever reached a staging environment. We covered how to implement it in practice in a previous post

Ownership Gaps: The Security No Man’s Land

We are shifting from a technical challenge to a human and organizational one. The security landscape moves so fast that the struggle of mastering every layer has become overwhelming.

This complexity is where governance goes to die. Infrastructure teams build the walls, developers write the code, and DBAs manage the house, but the accountability for the data itself often falls through the cracks. The most dangerous gap isn’t a missing feature; it’s the absence of a governance model strong enough to stop the game of hot potato and force a cross-domain ownership of security.

The CISO’s role in this landscape is not to master every technical layer, it is to force the question of ownership into the open. Who signs off on what data enters a non-production environment? Who is accountable when a dev database is restored without encryption? Who audits that masking policies are still effective after a release?

Without explicit answers to these questions, security becomes a game of assumptions. Every team assumes another layer is holding. And the gaps compound silently, until they don’t.

From Handcrafted Scripts to Enterprise Platforms

Every technique in this table can be implemented on a spectrum, from a carefully written script to a fully automated enterprise solution. The right choice depends on your scale, your team, and how much operational overhead you can realistically absorb.

• TLS certificate deployment: you can generate and rotate certificates manually, instance by instance. Or you can automate the entire lifecycle using Ansible against an internal PKI with a consistent and auditable way that is invisible to the teams consuming it. The security outcome is identical; the operational cost is not.
• Data anonymization: a custom script that detects PII columns and replaces values with masked data works well at small scale. The challenge appears when your data spans multiple database engines (SQL Server, Oracle, PostgreSQL, …) and when anonymized values need to remain consistent across foreign keys and referential constraints. Replacing a customer ID in one table while leaving it intact in another isn’t anonymization, it’s a GDPR incident waiting to happen. Solutions like Delphix Continuous Compliance handle cross-DBMS consistency, constraint awareness, and sensitive field detection out of the box, turning a fragile hand-rolled process into a governed, repeatable and auditable one.
• Dynamic masking and row-level security: defining a handful of policies manually in SSMS is perfectly reasonable for a contained environment. Automating policy deployment across environments and instances is a different challenge entirely. It is a level of scale where ad-hoc scripts quickly become a liability.

Conclusion: Moving Beyond Security by Accident

Security is not a one-time project. It is an operational discipline that requires the same rigor in a developer’s sandbox as it does in production, and that rigor has to be enforced by design, not by goodwill.

Most breaches in non-production environments don’t happen because a tool failed. They happen because nobody owned the decision to use it in the first place.

At dbi services, we help organizations move from fragile, handcrafted scripts to governed, auditable architectures across every environment, every database engine, and every team.

Because under GDPR, one incident is all it takes to make ownership everyone’s problem.

L’article Beyond TDE and TLS: Bridging the Data Security Governance Gap in Lower Environments est apparu en premier sur dbi Blog.

The Center for Internet Security publishes the “CIS Oracle database 19c Benchmark” with recommendations to enhance the security of Oracle databases.

One type of recommendations is to remove grant execute to public (chapter 5.1.1.1-5.1.1.7 Public Privileges). There is a list of powerful SYS packages. And for security reasons, only users that really need this functionality should have access to it. But per default, it is granted to public and all users can use it.

In theory, to fix that is easy, e.g.

REVOKE EXECUTE ON DBMS_LDAP FROM PUBLIC;

But is that really a good idea?

Who is using an object from another schema?

If the object is used in a program unit, a named PL/SQL block (package, function, procedure, trigger), you can see the dependency in the view dba_dependencies.

select distinct owner from dba_dependencies 
where referenced_name='DBMS_LDAP' and owner<>'SYS'
order by 2,1;

And for these objects, the users already have a direct grant for it. So, remove of the public grant does not affect these user-objects.
But wait! Rarely used, but there are named blocks with invokers right’s (create procedure procname AUTHID CURRENT_USER is…) . See How Roles Work in PL/SQL Blocks

select owner, object_name from dba_procedures where authid='CURRENT_USER';

In this case the user can also access objects used in program units he has granted via a role. You have to check which users have access to these program units. These users are potentially affected by the change!

For objects used outside of above program units: If a user has a direct grant, or an indirect grant via a role to the object, removing the grant to public does not affect the work of this user with these objects.

So, what about the other users without direct/indirect grants to the object (except “public”)? How can we see if above mentioned objects are used (e.g. from external code in a Perl script or an application server connecting to the database)?

To see the usage of an object, we can use unified auditing and create an audit policy for the object.

create audit policy CIS_CHECK_USAGE
actions
execute on sys.dbms_ldap
when 'SYS_CONTEXT(''USERENV'', ''CURRENT_USER'') != ''SYS''' EVALUATE PER STATEMENT;

audit policy CIS_CHECK_USAGE;
alter audit policy cis_check_usage add actions EXECUTE on SYS.DBMS_LOB;
alter audit policy cis_check_usage add actions ...

Hint: Unified auditing can also be used if the Oracle binary is not relinked for unified audit (the relink only deactivates traditional auditing, unified auditing is always active)

To automate above steps, you can do it dynamically with the Perl script below (run it with $ORACLE_HOME/perl/bin/perl, so the required Oracle modules are present):

  use DBI;
  my $dbh = DBI->connect('dbi:Oracle:', '', '',{ PrintError => 1, ora_session_mode=>2 });
  my @pdblist;
  my $sth=$dbh->prepare(q{select PDB_NAME from cdb_pdbs where pdb_name<>'PDB$SEED' union select 'CDB$ROOT' from dual});
  $sth->execute();
  while (my @row = $sth->fetchrow_array) {
    push(@pdblist, $row[0]);
  }

  foreach my $pdb (@pdblist){
    # switch PDB
    print "PDB=$pdb\n";
    $dbh->do("alter session set container=$pdb");

    # create cis_check_usage
    print q{ create audit policy cis_check_usage actions all on sys.AUD$ when 'SYS_CONTEXT(''USERENV'', ''CURRENT_USER'') != ''SYS''' EVALUATE PER STATEMENT}."\n";
    $dbh->do(q{ create audit policy cis_check_usage actions all on sys.AUD$ when 'SYS_CONTEXT(''USERENV'', ''CURRENT_USER'') != ''SYS''' EVALUATE PER STATEMENT});
    $dbh->do(q{ audit policy cis_check_usage});

    # add execute to public
    my $sql=q{
     SELECT  PRIVILEGE||' on '||owner||'.'||table_name FROM DBA_TAB_PRIVS WHERE GRANTEE='PUBLIC' AND PRIVILEGE='EXECUTE' AND TABLE_NAME IN (
     'DBMS_LDAP','UTL_INADDR','UTL_TCP','UTL_MAIL','UTL_SMTP','UTL_DBWS','UTL_ORAMTS','UTL_HTTP','HTTPURITYPE',
     'DBMS_ADVISOR','DBMS_LOB','UTL_FILE',
     'DBMS_CRYPTO','DBMS_OBFUSCATION_TOOLKIT', 'DBMS_RANDOM',
     'DBMS_JAVA','DBMS_JAVA_TEST',
     'DBMS_SCHEDULER','DBMS_JOB',
     'DBMS_SQL', 'DBMS_XMLGEN', 'DBMS_XMLQUERY','DBMS_XMLSTORE','DBMS_XMLSAVE','DBMS_AW','OWA_UTIL','DBMS_REDACT',
     'DBMS_CREDENTIAL'
      )};
    $sth=$dbh->prepare("$sql");
    $sth->execute();
    while (my @result = $sth->fetchrow_array) {
      print  "alter audit policy cis_check_usage add actions $result[0]\n";
      $dbh->do("alter audit policy cis_check_usage add actions $result[0]");
    }
  }

Revoke the grants

After some days/weeks, you can evaluate the usage of dbms_ldap or other objects audited by the cis_check_usage policy

select dbusername, current_user, object_schema||'.'||object_name as object, 
      sql_text, system_privilege_used,
       system_privilege, unified_audit_policies, con_id , event_timestamp 
from cdb_unified_audit_trail 
where unified_audit_policies like '%CIS_CHECK_USAGE%';

With this query, we see the usage of the objects we audited with the CIS_CHECK_USAGE policy. If there are no rows, check if you really enabled the policy (select * from audit_unified_enabled_policies where policy_name='CIS_CHECK_USAGE';)

With the next query, we exclude the objects per user that can be accessed by a direct grant or a grant via a role, so, a revoke from public will not affect this user.

select distinct current_user, action_name, object_schema, object_name, con_id 
from cdb_unified_audit_trail a
where unified_audit_policies like '%CIS_CHECK_USAGE%'
and current_user not in ( 
  select grantee from cdb_tab_privs -- direct grant
  where owner=a.object_schema and table_name=a.object_name and con_id=a.con_id
union all
  select r.grantee from cdb_role_privs r, cdb_tab_privs t -- grant via role
  where r.granted_role=t.grantee and r.con_id=t.con_id 
  and r.grantee=a.current_user   and t.owner=a.object_schema 
  and t.table_name=a.object_name and r.con_id=a.con_id
);

And what is left, needs attention.

Sometimes the objects are used by a background process, e.g. if you see the object_name DBMS_SQL, but in sql_text it is not used, then the user probably does not need it. But if it is present in sql_text, then the user definitely needs a grant. I recommend to grant the object via a role, so it behaves as before, the user can use it directly, but not in procedures/functions/packages.

create  role cis_dbms_sql ;
grant execute on sys.dbms_sql to cis_dbms_sql;
grant cis_dbms_sql to user1;

Then pragmatically, remove the execute rights from public on a test system and check if the application still works as expected. Generate the revoke commands dynamically, and do not forget to also dynamically generate an undo script in case of problems:

SELECT  'revoke '||PRIVILEGE||' on '||owner||'.'||table_name||' from PUBLIC;' 
FROM DBA_TAB_PRIVS 
WHERE GRANTEE='PUBLIC' AND PRIVILEGE='EXECUTE' AND TABLE_NAME IN (
   'DBMS_LDAP',' UTL_INADDR' ,'UTL_TCP', 'UTL_MAIL', 'UTL_SMTP', 'UTL_DBWS',
 'UTL_ORAMTS','UTL_HTTP','HTTPURITYPE',
'DBMS_ADVISOR','DBMS_LOB','UTL_FILE',
'DBMS_CRYPTO','DBMS_OBFUSCATION_TOOLKIT', 'DBMS_RANDOM',
'DBMS_JAVA','DBMS_JAVA_TEST',
'DBMS_SCHEDULER','DBMS_JOB',
'DBMS_SQL', 'DBMS_XMLGEN', 'DBMS_XMLQUERY','DBMS_XMLSTORE','DBMS_XMLSAVE','DBMS_AW','OWA_UTIL','DBMS_REDACT',
'DBMS_CREDENTIAL'
);

SELECT  'grant '||PRIVILEGE||' on '||owner||'.'||table_name||' to PUBLIC;'
FROM DBA_TAB_PRIVS 
WHERE GRANTEE='PUBLIC' AND PRIVILEGE='EXECUTE' AND TABLE_NAME IN (
   'DBMS_LDAP',' UTL_INADDR' ,'UTL_TCP', 'UTL_MAIL', 'UTL_SMTP', 'UTL_DBWS',
 'UTL_ORAMTS','UTL_HTTP','HTTPURITYPE',
'DBMS_ADVISOR','DBMS_LOB','UTL_FILE',
'DBMS_CRYPTO','DBMS_OBFUSCATION_TOOLKIT', 'DBMS_RANDOM',
'DBMS_JAVA','DBMS_JAVA_TEST',
'DBMS_SCHEDULER','DBMS_JOB',
'DBMS_SQL', 'DBMS_XMLGEN', 'DBMS_XMLQUERY','DBMS_XMLSTORE','DBMS_XMLSAVE','DBMS_AW','OWA_UTIL','DBMS_REDACT',
'DBMS_CREDENTIAL'
);

It has to be run in each PDB and CDB$ROOT.

If all works as expected, then it is fine.

Installation of patches and new components

But keep that in mind if you want to install something later. It may fail. For example, install an rman catalog:

RMAN> create catalog;
create catalog;
error creating dbms_rcvcat package body
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-06433: error installing recovery catalog
RMAN Client Diagnostic Trace file : /u01/app/oracle/diag/clients/user_oracle/RMAN_1732619876_110/trace/ora_rman_635844_0.trc

To create a valid rman catalog, you need to grant the execute right for UTL_HTTP, DBMS_LOB, DBMS_XMLGEN and DBMS_SQL directly to the rman user. Strange for me: it does not work if you grant it to a role (e.g. recovery_catalog_owner), but it works with a grant to public.

My recommendation to install new softare or patches is:

• Run the undo-script mentioned above (grant execute to public)
• Apply the Oracle or application patch or new application installation
• Check for invalid objects
• Run the hardening-script (revoke execute from public)
• Check for additional invalid objects and determine the missing grants
• Extend your hardening script with the required grants and re-run it.

Conclusion

Generally, the CIS hardening about revoking execute from public is possible. But it is very dangerous that the functionality of the application could be compromised. Especially with components that are used very rarely, this could only be noticed very late at best, e.g. in the case of end-of-year processing.

L’article Remove grant to public in Oracle databases est apparu en premier sur dbi Blog.

Monitoring backups in a SQL Server Always On Availability Group can often feel like a game of hide and seek where the rules change every time you flip a failover switch. On paper, your backup strategy is solid ; you’ve configured your replica priorities and your jobs are running like clockwork. But when you query the backup history to ensure everything is under control, you realize the truth is fragmented.

Because the msdb database is local to each instance, each replica only knows about the backups it performed itself. If your backups happen on the secondary today and the primary tomorrow, no single node holds the complete story. This leads to inconsistent monitoring reports, “false positive” alerts, and a lot of manual jumping between instances just to answer a simple question: “Are we actually protected with consistent backups?”.

Before we dive deeper, a quick disclaimer for the lucky ones: If you are running SQL Server 2022 and have implemented Contained Availability Groups you can stop reading here, you are safe. In a Contained AG, the system databases are replicated alongside your data, meaning the backup history is finally unified and follows the group.

For the others, in this post, we’re going to explore how to stop chasing metadata across your cluster. We’ll look at the limitations of the local msdb, compare different ways to consolidate a unified backup view using Linked Servers, OPENDATASOURCE, and PowerShell, and see how to build a monitoring query that finally tells the whole truth, regardless of where the backup actually ran.

The traditional approach

The traditional approach is therefore to query the msdb through the AG listener, pointing to the primary replica. Using a simple TSQL query to find the most recent backup, we get the following results.

SELECT
bs.database_name,
MAX(bs.backup_finish_date) AS LastBackup
FROM msdb.dbo.backupset bs
WHERE bs.database_name = 'StackOverflow2010'
GROUP BY bs.database_name;

As we can see, the two backup dates differ (14:39 being the time the database was created in the AG and 15:15 being the time of the last backup). As a result, if a failover occurs, the main msdb will contain incomplete data because the primary msdb will be the one on SQLAGVM2.

This traditional approach is perfectly acceptable for standalone instances because there is only one source of truth, but in the case of Always-On, we need a more robust solution. Let’s examine the different possibilities.

The good old Linked Servers

If you want to keep everything within the SQL Engine, Linked Servers are your go-to tool. The idea is simple: from your Primary replica, you reach out to the Secondary, query its msdb, and union the results with your local data.

SELECT
@@SERVERNAME AS [PrimaryServer],
bs.database_name,
MAX(bs.backup_finish_date) AS LastBackup
FROM msdb.dbo.backupset bs
WHERE bs.database_name = 'StackOverflow2010'
GROUP BY bs.database_name

UNION ALL

SELECT
'REMOTE_MSDB' AS [ReportingServer],
bs.database_name,
MAX(bs.backup_finish_date) AS LastBackup
FROM [REMOTE_MSDB].msdb.dbo.backupset bs
WHERE bs.database_name = 'StackOverflow2010'
GROUP BY bs.database_name;

On paper, the best way to secure a Linked Server is to use the Self option, ensuring that your own permissions are carried over to the next node. It’s the most transparent approach for auditing and security. However, this is where we often hit a silent wall: the Double-Hop. Unless Kerberos delegation is perfectly configured in your domain, NTLM will prevent your identity from traveling to the second replica. You’ll end up with a connection error, not because of a lack of permissions, but because your identity simply couldn’t make the trip. To determine the type of authentication protocol you are using, use the following query.

SELECT auth_scheme 
FROM sys.dm_exec_connections 
WHERE session_id = @@SPID;

To bypass this hurdle, it is common to see Fixed Logins being used as a pragmatic workaround. But by hardcoding credentials to make the bridge work, we create a permanent, pre-authenticated tunnel. From a security standpoint, this can facilitate lateral movement if one instance is ever compromised, a major concern in modern Zero Trust architectures. Furthermore, it obscures your audit logs, as the remote server only sees the service account instead of the actual user. These hidden complexities and security risks are precisely why many DBAs are now moving toward more decoupled, scalable alternatives.

The “On-the-Fly” Connection: OPENDATASOURCE

To address the frustrations of Linked Servers, another T-SQL path often explored is the use of ad hoc queries via OPENDATASOURCE.
The concept is tempting: instead of building a permanent bridge (Linked Server), you use a temporary ladder ; OPENDATASOURCE allows you to define a connection string directly inside your T-SQL statement, reaching out to a remote replica only for the duration of that specific query. It feels lightweight and dynamic because it requires no pre-configured server objects.

In theory, you would use it like this to pull backup history from your secondary node:

SELECT 
    @@SERVERNAME AS [Source Server],
    bs.database_name, 
    MAX(bs.backup_finish_date) AS LastBackup
FROM OPENDATASOURCE('MSOLEDBSQL', 'Data Source=SQLAGVM1,1432;Integrated Security=SSPI').msdb.dbo.backupset bs
WHERE bs.database_name = 'StackOverflow2010'
GROUP BY bs.database_name;

However, if the environment is not properly configured, an error will occur immediately.

Msg 15281, Level 16, State 1, Line 1
SQL Server blocked access to STATEMENT 'OpenRowset/OpenDatasource' of component 'Ad Hoc Distributed Queries' because this component is turned off as part of the security configuration for this server. A system administrator can enable the use of 'Ad Hoc Distributed Queries' by using sp_configure. 

By default, SQL Server locks this door. It is a protective measure to prevent users from using the SQL instance as a jumping point to query any other server on the network. To get past this error, a sysadmin must explicitly enable Ad Hoc Distributed Queries. This requires tweaking the advanced configuration of the instance.

EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
GO
EXEC sp_configure 'Ad Hoc Distributed Queries', 1;
RECONFIGURE;
GO

Once these options have been reconfigured, access to the remote msdb is finally possible.

While we successfully made OPENDATASOURCE work, the trade-offs are significant. We have ended up with a solution that is brittle, difficult to maintain, and a potential liability:

• Hardcoding & Maintenance: Every replica requires a manually adapted connection string. If a server is renamed, a port is migrated, or a password expires, the entire monitoring logic collapses.
• Security & Shadow IT Risk: Enabling Ad Hoc Distributed Queries opens a permanent hole in your instance. You aren’t just allowing your script to run; you are allowing any sysadmin to connect to any external server, creating a ghost feature that can be easily misused.

In short, we are fighting the SQL engine’s security defaults just to get a simple timestamp. For a truly robust and scalable solution, it is time to look beyond T-SQL.

Here comes the superhero Powershell

PowerShell steps in as the ultimate lifesaver, delivering high-level automation and pure execution simplicity. It allows you to centralize and control your scripts from an external management server, piloting your entire fleet remotely without cluttering your SQL instances.

By leveraging the power of dbatools, we shatter the limitations of traditional T-SQL. We gain dynamic flexibility and enhanced security by bypassing risky configurations, all while maintaining total control over how we manipulate the retrieved data. The security gain does not come from PowerShell itself, but from removing risky SQL Server surface area features and centralizing access control on a hardened management host. This works because PowerShell establishes direct connections from your management host to each replica. This bypasses the NTLM double-hop issue entirely, as your identity is never passed between servers, removing any need for complex Kerberos delegation or risky fixed logins.

Here is how to put this into practice. By using the Availability Group Listener as your unique gateway, you can dynamically discover the cluster topology and query all member nodes.

$Listener = 'SQLLISTENER,1432'
$TargetDB = 'StackOverflow2010'

try {
    $Nodes = Invoke-DbaQuery -SqlInstance $Listener -Database 'master' -Query "SELECT replica_server_name FROM sys.dm_hadr_availability_replica_cluster_states" 
    $BackupQuery = "SELECT SERVERPROPERTY('ServerName') as [InstanceName], MAX(backup_finish_date) as [LastBackup] FROM msdb.dbo.backupset WHERE database_name = '$TargetDB' GROUP BY database_name"
    write-output $Nodes
    $Results = foreach ($Node in $Nodes.replica_server_name) {
        write-output $Node
        Invoke-DbaQuery -SqlInstance $Node -Database 'msdb' -Query $BackupQuery -ErrorAction SilentlyContinue
    }

    $Results | Where-Object { $_.LastBackup } | Sort-Object LastBackup -Descending | Select-Object -First 1 | Format-Table -AutoSize
}
catch {
    Write-Error "Error : $($_.Exception.Message)"
}

This script is just a first step, but it lays the foundation for truly scalable infrastructure management. By shifting the logic to PowerShell instead of overloading our SQL instances, we achieve a robust and extensible method capable of handling large Always-On ecosystems without additional manual effort.

In this example, the listener name is hardcoded for the sake of clarity. However, the true strength of this approach lies in its ability to work behind the scenes with a dynamic inventory. In a Production environment, you would typically query a CMDB or a centralized configuration file to automatically populate the list of instances. This transforms a simple check into a silent, reliable automation that adapts seamlessly as your SQL environment evolves.

While we wrote the T-SQL manually in this example for the sake of clarity, it is worth noting that dbatools offers an even more streamlined approach with the Get-DbaBackupHistory command. This native function eliminates the need for manual queries entirely, returning rich metadata objects that are ready to be filtered and aggregated across your entire fleet.

$Nodes.replica_server_name | Get-DbaBackupHistory -Database 'StackOverflow2010' | Sort-Object End -Descending | Select-Object -First 1

Final Thoughts: Taking Control of the Always-On Fleet

To wrap up, remember that technical skills are only as good as the management strategy behind them. Transitioning away from legacy methods toward a PowerShell-driven approach is about gaining control over your environment. Here is what you should keep in mind:

• Beyond T-SQL Boundaries: While Linked Servers or OPENDATASOURCE might work for quick fixes, they quickly become bottlenecks and security risks in hardened infrastructures.
• Object-Oriented Efficiency: By using PowerShell and dbatools, you stop managing raw text and start handling objects. This allows you to effortlessly filter, sort, and aggregate data from multiple Always-On nodes to extract a single, reliable source of truth.
• Smarter Security: Running queries externally via dedicated management shells ensures you maintain a high security posture without needing to enable high-risk surface area features on your SQL instances.

The real game-changer is the Central Management Server. By centralizing your logic on a dedicated administration machine, you stop scattering scripts across every instance. This server becomes your orchestrator: it pulls from your inventory (CMDB, central tables), broadcasts tasks across your entire fleet, and consolidates the results. This is exactly the approach we take at dbi services to manage the extensive SQL Server environments under our care. We leverage PowerShell and the dbatools module as the backbone of our scripting architecture. This allows us to collect data in the most comprehensive and optimized way possible, ensuring we deliver top-tier service to our clients.

This is how you move from artisanal, server-by-server management to an industrial-grade automation capable of piloting hundreds of instances with the same simplicity as a single one.

L’article SQL Server Always-On: Centralizing Backup History Across Replicas est apparu en premier sur dbi Blog.

Why and How to Anonymize Data

Development teams require realistic datasets in order to:

• Test application performance
• Validate complex business processes
• Reproduce error scenarios
• Train Business Intelligence or Machine Learning algorithms

However, the use of real data requires the implementation of anonymization or pseudonymization mechanisms ensuring:

• Preservation of functional and referential consistency
• Prevention of data subject re-identification

Among the possible anonymization techniques, the main ones include:

• Dynamic Data Masking, applied on-the-fly at access time but which does not anonymize data physically
• Tokenization, which replaces a value with a surrogate identifier
• Cryptographic hashing, with or without salting

Direct data copy from Production to Development

In this scenario, a full backup of the production database is restored into a development environment. Anonymization is then applied using manually developed SQL scripts or ETL processes.

This approach presents several critical weaknesses:

• Temporary exposure of personal data in clear text
• Lack of formal traceability of anonymization processes
• Risk of human error in scripts
• Non-compliance with GDPR requirements

This model should therefore be avoided in regulated environments.

Data copy via a Staging Database in Production

This model introduces an intermediate staging database located within a security perimeter equivalent to that of production. Anonymization is performed within this secure zone before replication to non-production environments.

This approach makes it possible to:

• Ensure that no sensitive data in clear text leaves the secure perimeter
• Centralize anonymization rules
• Improve overall data governance

However, several challenges remain:

• Versioning and auditability of transformation rules
• Governance of responsibilities between teams (DBAs, security, business units)
• Maintaining inter-table referential integrity
• Performance management during large-scale anonymization

Integration of Delphix Continuous Compliance

In this architecture, Delphix is integrated as the central engine for data virtualization and anonymization. The Continuous Compliance module enables process industrialization through:

• An automated data profiler identifying sensitive fields
• Deterministic or non-deterministic anonymization algorithms
• Massively parallelized execution
• Orchestration via REST APIs integrable into CI/CD pipelines
• Full traceability of processing for audit purposes

This approach enables the rapid provisioning of compliant, reproducible, and secure databases for all technical teams.

Conclusion

Database anonymization should no longer be viewed as a one-time constraint but as a structuring process within the data lifecycle. It is based on three fundamental pillars:

• Governance
• Pipeline industrialization
• Regulatory compliance

An in-house implementation is possible, but it requires a high level of organizational maturity, strong skills in anonymization algorithms, data engineering, and security, as well as a strict audit framework. Solutions such as Delphix provide an industrialized response to these challenges while reducing both operational and regulatory risks.

To take this further, Microsoft’s article explaining the integration of Delphix into Azure pipelines analyzes the same issues discussed above, but this time in the context of the cloud : Use Delphix for Data Masking in Azure Data Factory and Azure Synapse Analytics

What’s next ?

This use case is just one example of how Delphix can be leveraged to optimize data management and compliance in complex environments. In upcoming articles, we will explore other recurring challenges, highlighting both possible in-house approaches and industrialized solutions with Delphix, to provide a broader technical perspective on data virtualization, security, and performance optimization.

What about you ?

How confident are you about the management of your confidential data?
If you have any doubts, please don’t hesitate to reach out to me to discuss them !

L’article Data Anonymization as a Service with Delphix Continuous Compliance est apparu en premier sur dbi Blog.

• Encryption in transit
• Encryption at rest
• Encryption in use

Among these, encryption in transit is fundamental : it protects data as it moves between your application and the database. In MongoDB, this is achieved through TLS (Transport Layer Security), which ensures that communication remains private and secure. You have two options when it comes to using TLS for your database :

• Using TLS for encryption only.
• Using TLS both for encryption and authentication to the database.

Setting up TLS for encryption

Create a Certificate Authority

We’ll first create a Certificate Authority. These certificates will be self-signed, which is fine for testing, but you shouldn’t use self-signed certificates in a production environment ! On Linux, use the openssl library to generate the certificates.

openssl req -newkey rsa:4096 -nodes -x509 -days 365 -keyout ca.key -out ca.pem -subj "/C=CH/ST=ZH/L=Zurich/O=dbi/OU=MongoDBA/CN=vm.domain.com"

Here is a description of some important parameters of the commands :

• -newkey rsa:4096 : Generates a new private key and a certificate request using RSA with a 4096-bit key size.
• -nodes : Skips password encryption of the private key. Without it, OpenSSL would prompt you to set a passphrase.
• -x509 : Generates a self-signed certificate. x509 is supported by MongoDB.
• -days 365 : Validity of the certificate in days.
• -keyout ca.key : Filename for the private key.
• -out ca.pem : Filename for the certificate.
• -subj "..." : Provides the subject’s Distinguished Name (DN). If you don’t specify it, OpenSSL will prompt for each field.

Create a Server Certificate

Then, we’ll create the server certificate for the MongoDB instance. In the openssl-server.cnf file below, you should change the req_distinguished_name fields with what you used while creating the Certificate Authority, and replace vm.domain.com by the name of your machine.

If you only have an IP and no DNS entry for your VM, use IP.1 instead of DNS.1 in the alt_names section.

cat > openssl-server.cnf <<EOF
[ req ]
distinguished_name = req_distinguished_name
req_extensions = v3_req
prompt = no

[ req_distinguished_name ]
C = CH
ST = ZH
L = Zurich
O = dbi
OU = MongoDBA
CN = myVM

[ v3_req ]
keyUsage = digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
subjectAltName = @alt_names

[ alt_names ]
DNS.1 = myVM
EOF

Then, generates the certificate with these commands :

openssl req -newkey rsa:4096 -nodes -keyout mongodb-server.key -out mongodb-server.csr -config openssl-server.cnf

openssl x509 -req -in mongodb-server.csr -CA ca.pem -CAkey ca.key -CAcreateserial -out mongodb-server.crt -days 365 -extensions v3_req -extfile openssl-server.cnf

cat mongodb-server.key mongodb-server.crt > mongodb-server.pem

Create a Client Certificate

Finally, we’ll create a client certificate. The process is the same, with a few tweaks :

• OU should be different from the one from the server certificate. It is not mandatory for the communication, but it will be for the authentication if you decide to enable it.
• CN should also be different.
• extendedKeyUsage should be set with clientAuth instead of serverAuth.

cat > openssl-client.cnf <<EOF
[ req ]
distinguished_name = req_distinguished_name
req_extensions = v3_req
prompt = no

[ req_distinguished_name ]
C = CH
ST = ZH
L = Zurich
O = dbi
OU = MongoDBAClient
CN = userApp

[ v3_req ]
keyUsage = digitalSignature, keyEncipherment
extendedKeyUsage = clientAuth
EOF

The creation of the certificate is the same.

openssl req -newkey rsa:4096 -nodes -keyout mongodb-client.key -out mongodb-client.csr -config openssl-client.cnf

openssl x509 -req -in mongodb-client.csr -CA ca.pem -CAkey ca.key -CAcreateserial -out mongodb-client.crt -days 365 -extensions v3_req -extfile openssl-client.cnf

cat mongodb-client.key mongodb-client.crt > mongodb-client.pem

MongoDB Configuration Change

Make sure to set permissions correctly for your certificates.

chmod 600 ca.pem mongodb-server.pem mongodb-client.pem
chown mongod: ca.pem mongodb-server.pem mongodb-client.pem

Now, you can change your MongoDB configuration file to include the certificates. Simply add the net.tls part to your mongod.conf file.

net:
  bindIp: yourIP
  port: 27017
  tls:
    mode: requireTLS
    certificateKeyFile: /path/to/mongodb-server.pem
    CAFile: /path/to/ca.pem

You can now restart your MongoDB instance with systemctl restart mongod (or whatever you’re using), and then try the connection to your instance for your client. Of course, the port mentioned in the net.port field of your configuration file shouldn’t be blocked by your firewall.

> mongosh --host myVM --port 27017 --tls --tlsCertificateKeyFile mongodb-client.pem --tlsCAFile ca.pem
Current Mongosh Log ID:	682c9641bbe4593252ee7c8c
Connecting to:		mongodb://vmIP:27017/?directConnection=true&tls=true&tlsCertificateKeyFile=Fclient.pem&tlsCAFile=ca.pem&appName=mongosh+2.5.1
Using MongoDB:		8.0.9
Using Mongosh:		2.5.1

For mongosh info see: https://www.mongodb.com/docs/mongodb-shell/

test>

You’re now connected to your MongoDB instance through TLS ! And if you’re not using the certificate, the requireTLS mode prevents the connection from being established, and generated these error messages in your logs :

{"t":{"$date":"2025-05-21T04:43:55.277+00:00"},"s":"I",  "c":"EXECUTOR", "id":22988,   "ctx":"conn52","msg":"Error receiving request from client. Ending connection from remote","attr":{"error":{"code":141,"codeName":"SSLHandshakeFailed","errmsg":"The server is configured to only allow SSL connections"},"remote":"IP:50100","connectionId":52}}

If you want to learn more about MongoDB logs, I wrote a blog on this topic: MongoDB Log Analysis : A Comprehensive Guide.

Setting up TLS authentication

Now that you’re connected, we will set up authentication so that you can be connected as a specific user to MongoDB. Using the already established connection, create a user in the $external database. Each client certificate that you create can be mapped to one MongoDB user. Retrieve the username that you will use :

> openssl x509 -in mongodb-client.pem -inform PEM -subject -nameopt RFC2253 | grep subject
subject=CN=userApp,OU=MongoDBA,O=dbi,L=Zurich,ST=ZH,C=CH

And then create the user in the $external database, using the existing MongoDB connection :

test> db.getSiblingDB("$external").runCommand({
  createUser: "CN=userApp,OU=MongoDBA,O=dbi,L=Zurich,ST=ZH,C=CH",
  roles: [
    { role: "userAdminAnyDatabase", db: "admin" }
  ]
});

To check that everything works as intended, you can try to display collections in the admin database. For the moment, there is no error because you have all the rights to do it (no authorization is enforced).

test> use admin
switched to db admin
admin> show collections;
system.users
system.version

You can now edit the MongoDB configuration file by adding the net.tls.allowConnectionsWithoutCertificates set to true, and the security.authorization flag set to enabled. The mongod.conf file should look like this :

net:
  bindIp: X.X.X.X
  port: XXXXX
  tls:
    mode: requireTLS
    certificateKeyFile: /path/to/mongodb-server.pem
    CAFile: /path/to/ca.pem
    allowConnectionsWithoutCertificates: false

security:
  authorization: enabled

After restarting with systemctl restart mongod, you can now connect again. If you use the same command as before, you will log in without authentication, and get the error below whenever you try to do anything :

MongoServerError[Unauthorized]: Command listCollections requires authentication

So you should now connect via this command :

mongosh --host vmIP --port 27017 --tls --tlsCertificateKeyFile mongodb-client.pem --tlsCAFile ca.pem --authenticationDatabase '$external' --authenticationMechanism MONGODB-X509

If you want to show the admin collections, you will now get an error, because your user only has the userAdminAnyDatabase role granted (this role was chosen during the user creation, see above).

admin> show collections
MongoServerError[Unauthorized]: not authorized on admin to execute command { listCollections: 1, filter: {}, cursor: {}, nameOnly: true, authorizedCollections: false, lsid: { id: UUID("9c48b4c4-7702-49ce-a97c-52763b2ad6b3") }, $db: "admin" }

But it’s fine, you can grant yourself more roles (readWriteAnyDatabase, for instance) and create new users if you want.

The communication between the client and the server is now fully secured. Congratulations !

MongoServerError[BadValue]

Side note : if you ever encounter this error:

MongoServerError[BadValue]: Cannot create an x.509 user with a subjectname that would be recognized as an internal cluster member

… make sure to follow the RFC-2253 standards. For instance, you could have this error if one of the field is too long. Also, as a reminder, the client certificate should have a different Distinguished Name (DN) than the server certificate (see documentation for more information).

L’article Setting up TLS encryption and authentication in MongoDB est apparu en premier sur dbi Blog.

I am not going into the setup or basic configuration as you can already find related bogs here and more information in the documentation:

• Uyuni, an open-source configuration and infrastructure management solution for software-defined infrastructure (1) – The server (this is for version 4.x)
• Uyuni, an open-source configuration and infrastructure management solution for software-defined infrastructure (2) – Adding a client (this is for version 4.x)
• SUMA (SUSE Manager) is back and it has a new name: SUSE Multi-Linux
• SUSE Manager installation (this is for version 4)

What I want to look at in this post is automatic scheduling of OpenSCAP scans/reports. When this requirement came up, it seemed pretty easy to do, as you can easily schedule such a scan against a single system. As you can see below I have a Red Hat 9 system registered to my SUSE Multi Linux Server:

What you can easily do out of the box is to manually schedule an OpenSCAP scan:

Once the scan completes, it becomes visible under the “List Scan” tab and you can browse into the details:

Quite easy to do but still a manual action. As we wanted to have it automated the obvious choice was to create a “Recurring Action”:

This gives you to option to create and configure a “Recurring Action”:

The issue is, there is no pre-defined “Custom State” which is scheduling an OpenSCAP scan:

The very same is true for “System Groups”, which you normally would use because otherwise you’d need to schedule that on every single system:

The last option seemed to be something under “Schedule” but this only gives you a list of what you already have:

At this point we were stuck and had to talk to SUSE support, which really was a great experience by the way. It turned out there is no easy, build-in, way to do this. A feature request has been logged, but of course there is no guarantee that it will be implemented.

But, there is a workaround, not a very beautiful one, but at least it works. SUSE Multi Linux Manager (and Uyuni of course) come with an API and there is one call for triggering an OpenSCAP scan. Using this, a custom state channel can be created which in turn calls the API to trigger the scan:

The “SLS Contents” actually contains the code (Python in this case) which is taking to the API and triggers the scan:

/usr/local/bin/schedule_xccdf_scan.py:
  file.managed:
    - user: root
    - group: root
    - mode: 755
    - contents: |
        #!/usr/bin/python3
        import xmlrpc.client

        client = xmlrpc.client.ServerProxy('https://suma.dwe.local/rpc/api')
        key = client.auth.login('admin', 'xxxx')
        client.system.scap.scheduleXccdfScan(
            key,
            1000010000,
            '/usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml',
            '--profile xccdf_org.ssgproject.content_profile_cis_server_l1'
        )
        client.auth.logout(key)

schedule_xccdf_scan:
  cmd.run:
    - name: /usr/local/bin/schedule_xccdf_scan.py
    - require:
      - file: /usr/local/bin/schedule_xccdf_scan.py

I am not going into the code itself, this should be easy to understand. The important part is the system ID in line 14. This defines the system you want the scan to happen on (you can also provide an array of systems, see the API documentation linked above).

As soon as you have this, you can schedule this automatically as a recurring action on either the system itself, or a group of systems in “System Groups”:

Not as easy as it could be, and the systems are still hard coded in the Python code, but at least we have something that works. Hope that helps.

L’article Scheduling OpenSCAP reports in SUSE Multi-Linux Manager est apparu en premier sur dbi Blog.

What is an Oracle Wallet

An Oracle wallet is used to store certificates for Listeners with https protocol, or it can be used as an encrypted password store for Oracle logins.

Technically, an Oracle wallet is an encrypted, password-protected PKCS#12 container file (ewallet.p12) that also can be accessed with openssl tools to show and extract keys and certificates.

openssl pkcs12 -nokeys -info -in ewallet.p12

Storing credentials (user/password/tns_alias) in an Oracle wallet is a proprietary extension from Oracle which is not understood by openssl.

Secret bag
Bag attributes
    localKeyID: AA BB CC DD ....
Bag Type: 1.2.840.113549.1.16.12.12
Bag Value: <Unsupported tag 16>

Generally, do not modify an Oracle wallet with openssl tools! To work with Oracle wallets, use the orapki or mkstore utilities in $ORACLE_HOME/bin;

Auto-login Wallets

The PKCS#12 file (ewallet.p12) is password protected. To startup SSL Listeners or to login with sqlplus or dgmgrl to a database non-interactive (without a password prompt), a different wallet-type is required, a so-called auto_login* wallet.

How does that work? Oracle creates a proprietary shadow-file of the ewallet.p12 file, the cwallet.sso; Oracle tools like sqlplus or tnslsnr have access to this proprietary file without the need of a password. Security is primarily based on filesystem permissions and a blackbox file structure of the cwallet.sso. Not very secure, but even better than cleartext passwords in files.

For this auto-login feature, there are 3 additional wallet-types (2-4):

1. The normal wallet without auto-login (ewallet.p12)
2. The auto_login wallet (ewallet.p12, cwallet.sso)
3. The auto_login_local wallet (ewallet.p12, cwallet.sso)
4. The auto_login_only wallet (cwallet.sso)

To create the wallets, use the orapki command

orapki wallet create -wallet .  #create a wallet in the current directory (non-auto-login)
orapki wallet create -wallet .  -auto_login
orapki wallet create -wallet .  -auto_login_local
orapki wallet create -wallet .  -auto_login_only

auto_login_only

The auto_login_only wallet is a special case. There is no PCKS#12 container, and you have access to the content without a wallet-password. So you can extract user-credentials in cleartext or private keys without a password! So do not use auto_login_only to store user-certificates/private-keys or credentials. This type of wallet is intended to only store trusted (public) certificates, required to initialize SSL connections to a remote site.

auto_login and auto_login_local

The auto_login and auto_login_local wallet contains both the ewallet.p12 and the cwallet.sso file. To modify the wallet, the wallet password must be provided. orapki then updates both files.

The difference of the two wallet types are that the auto-login feature of the auto_login_local wallet can only be used on the host it was created and and by the user who created the wallet. But do not confuse: the ewallet.p12 file can be accessed with the wallet password on other systems or by other users. The difference is in the cwallet.sso file.

The auto_login_local wallet should be used for server certificates (in orapki named user_certificate) The server certificate should not be used on another host.

Determine the wallet-type

To see which wallet type is on a system, that is a bit tricky. Oracle tools will not show the wallet type. If there is only a cwallet.sso, but no ewallet.p12 file, then it is probably an auto_login_only wallet. But: it is also possible that someone only copied the cwallet.sso file from another system. That works for auto-login, but you can no longer modify the wallet. To test, use mkstore -wrl . -listCredential; if it asks for a password, it is not an auto_login_only wallet.

And to see if it is a auto_login_local or auto_login (global) wallet you have to copy it to another host and see if the auto login feature still works or not.

But is there a better way than such try-and-error methods?

Yes! use the od (octal dump) utility and analyze the first line.

od cwallet.sso | head -n 1 

I used different ORACLE_HOME’s and created with each home 2 wallets of the same login type and compared the output. Then, I identified the third number group of the first line to be constant for the same type of wallet and different for another type of wallet. E.g. for an auto_login_local wallet it is always 034116.

0000000 174241 034116 000000 003000 000000 020400 012406 010137 #auto_login_local
0000000 174241 033116 000000 003000 000000 020400 033406 125027 #auto_login (global)
0000000 174241 033516 000000 003000 000000 020400 065406 020030 #auto_login_only

Hint: the output is dependent of the endianness of the system. On X86 architecture with little-endian (example above), the od output of an auto_login_local wallet is “034116”, on a big-endian system (e.g. AIX) it is “047070”. If you copy the cwallet.sso from an AIX system to Linux, you will get the same number group as from a Linux wallet. So the output is dependent on the platform where od is called, and not on the platform where the wallet was created. Below you can see the output of a big-endian system:

0000000  120770 047070 000000 000006 000000 000041 003313 117047 #auto_login_local
0000000  120770 047066 000000 000006 000000 000041 003321 045646 #auto_login
0000000  120770 047067 000000 000006 000000 000041 003047 065254 #auto_login_only

To get the wallet-type, you can use the following shell-script code

  if [ -f cwallet.sso ]; then
    autologincode=$( od cwallet.sso |head -n 1 | awk '{print $3}' )
    echo autologincode=$autologincode
    case $autologincode in
      047066|033116) type="auto_login (global)"; test -f ewallet.p12 || type="$type, but ewallet.p12 is missing" ;;
      047067|033516) type="auto_login_only";     test -f ewallet.p12 && type="$type, but unknown ewallet.p12 present" ;;
      047070|034116) type="auto_login_local";    test -f ewallet.p12 || type="$type, but ewallet.p12 is missing" ;;
      *) echo "unknown" ;;
    esac
    echo "Wallet-type is $type"
  elif [ -f ewallet.p12 ]; then
    echo "Wallet-type is without autologin"
  else
    echo "No Oracle wallet in this directory"
  fi

Converting wallets

To convert an auto_login or auto_login_local wallet to a non-auto-login wallet: simply remove the cwallet.sso file.

As long as the ewallet.p12 file exists, it can be converted to an auto_login or auto_login_local wallet

orapki wallet create -wallet . -auto_login 
orapki wallet create -wallet . -auto_login_local

But you can not create an auto_login_only wallet from another wallet type (existing ewallet.p12). The error-message is PKI-02001: A wallet already exists at: .

And to create an auto_login(_local) wallet from an auto_login_only wallet? The command above for conversion works. The type is changed to auto_login, but: Oracle forgets to create the ewallet.p12 file. As a result, you have a wallet that can no longer be modified! 🙁

With Oracle tools it seems not to be directly possible, you have to rebuild the wallet. Certificates can be moved by export/import, but credentials have to be re-added manually.

To move the certificates, first, convert the proprietary cwallet.sso file to a jks keystore.

read PW  # type the password (it is not stored in the shell-history)
orapki wallet pkcs12_to_jks \
  -wallet . \
  -jksKeyStoreLoc ewallet.jks \
  -jksKeyStorepwd $PW

Then, you can convert the jks to a p12 file

mkdir new_wallet/
keytool -importkeystore \
    -srckeystore ewallet.jks \
    -srcstoretype JKS \
    -srcstorepass "$PW" \
    -destkeystore new_wallet/ewallet.p12 \
    -deststoretype PKCS12 \
    -deststorepass "$PW"

If it only contains trusted certificates, it can be converted to an Oracle auto_login wallet:

orapki wallet create -wallet new_wallet/ -pwd $PW -auto_login  #or -auto_login_local
orapki wallet display -wallet new_wallet/   #should now work without password

But if it also contains “User Certificates” (server certificate and private key), you can use the command above and it looks like an auto_login wallet. But: It ignores the auto-login part, it always asks for a password! 🙁

To transfer the user certificate, you have to import it in an empty Oracle wallet

cd new_wallet
mv ewallet.p12 container.p12
rm *wallet.*
orapki wallet create -wallet . -auto_login   #create a new, empty wallet
orapki wallet import_pkcs12 -wallet . -pwd $PW -pkcs12file container.p12 -pkcs12pwd $PW

Afterwards, we have a working auto_login wallet with the user certificate and some, but probably not all, trusted certificates. Import the missing trusted certificates afterwards

orapki wallet add -wallet . -cert Pcs3ss_v4.pem -trusted_cert  -pwd $PW

Summary

The auto-login feature of Oracle wallets, which is implemented by the proprietary cwallet.sso file, enables non-interactive logins and startup of SSL Listeners within the Oracle world, e.g. for batch processing.

For security reasons, keep an eye on the filesystem permissions. If possible, restrict the access to the owner only (oracle, chmod 600). If there is no need to copy wallets to different servers, use the auto_login_local wallet type. The advantage is that if someone copies the cwallet.sso file to another host, it can not use the auto-login feature.

The auto_login_only wallet is a good solution to store trusted certificates (which are publicly available). Use-case is a wallet for client-connects with TCPS and no need for client-authentication.

All wallet-types, except auto_login_only, can be converted with orapki from each type to another.

Converting an auto_login_only wallet is partially possible with a combination of openssl- and Oracle tools.

L’article Different types of Oracle wallets est apparu en premier sur dbi Blog.

Setting up Microsoft Defender and Arc on a Linux server, especially one without internet access and with robust security monitoring and hardening, may seem counterintuitive. However, because the software was already purchased, managers insist on deploying the same product across all servers. So here we are, deploying a Microsoft closed source antivirus on a Linux open source operating system. But don’t get me wrong, Defender and Arc do have some benefits which make it worth installing, you can find those in the Summary below.

The whole setup was done based on the Microsoft official best practice:
https://learn.microsoft.com/en-us/defender-endpoint/linux-install-manually

First, for all Distributions we will need the On-boarding script generated out of your companies Microsoft Azure environment. For that we need to go into the Microsoft Defender Portal:

• Head to Settings > Endpoints > Device Management > Onboarding.
• Next, in the first drop down, pick “Linux Server” as the operating system. In the second drop down, choose “Local Script” as the deployment method.

• After that, click “Download onboarding package” and save the file as WindowsDefenderATPOnboardingPackage.zip

Finally, unzip that file and drop it in the home directory of each server you want to join.

Preparing Microsoft Defender/ Arc for RPM-Based Distributions

# Jump to your home folder
$ cd

# Download the official azure installation script for defender
$ curl -o mde_install.sh https://github.com/microsoft/mdatp-xplat/blob/master/linux/installation/mde_installer.sh

# In case your Linux server has no direct internet access you can use curl with a Proxy. Use -x:
curl -x http://proxy.yourdomain.ch:80 -o mde_install.sh https://github.com/microsoft/mdatp-xplat/blob/master/linux/installation/mde_installer.sh

# Install dependencies which will be needed for the process
$ sudo yum install yum-utils

# Add the official repository for the defender and arc packages
$ sudo yum-config-manager --add-repo=https://packages.microsoft.com/config/rhel/8/prod.repo

# Trust the repositories by importing the GPG-Key
$ sudo rpm --import https://packages.microsoft.com/keys/microsoft.asc

# Install both packages 
$ sudo apt-get install mdatp azcmagent

# Add a proxy to both the mdatp (Defender) and azcmagent (ARC)
$ sudo mdatp config proxy set --value http://proxy.yourdomain.ch:80
$ sudo azcmagent_proxy add http://proxy.yourdomain.ch:80

Preparing Microsoft Defender/ Arc for SLES/ SUSE

# Jump to your home folder
$ cd

# Download the official azure installation script for defender
$ curl -o mde_install.sh https://github.com/microsoft/mdatp-xplat/blob/master/linux/installation/mde_installer.sh

# In case your Linux server has no direct internet access you can use curl with a Proxy. Use -x:
curl -x http://proxy.yourdomain.ch:80 -o mde_install.sh https://github.com/microsoft/mdatp-xplat/blob/master/linux/installation/mde_installer.sh

# Add the official repository for the defender and arc packages
$ sudo zypper addrepo -c -f -n microsoft-prod https://packages.microsoft.com/config/sles/15/prod.repo

# Trust the repositories by accepting the GPG key after the zypper refresh
$ sudo zypper refresh

# Install both packages 
$ sudo zypper install mdatp azcmagent

# Add a proxy to both the mdatp (Defender) and azcmagent (ARC)
$ sudo mdatp config proxy set --value http://proxy.yourdomain.ch:80
$ sudo azcmagent_proxy add http://proxy.yourdomain.ch:80

Preparing Microsoft Defender/ Arc for Debian

# Jump to your home folder
$ cd

# Download the official azure installation script for defender
curl -o mde_install.sh https://github.com/microsoft/mdatp-xplat/blob/master/linux/installation/mde_installer.sh

# In case your Linux server has no direct internet access you can use curl with a Proxy. Use -x:
$ curl -x http://proxy.yourdomain.ch:80 -o mde_install.sh https://github.com/microsoft/mdatp-xplat/blob/master/linux/installation/mde_installer.sh

# Install dependencies which will be needed for the process
$ sudo apt-get install curl libplist-utils gpg gnupg apt-transport-https

# Add the new Repositories to your server
$ curl -o microsoft.list https://packages.microsoft.com/config/debian/12/prod.list

# Move the new repo-file to the apt repository folder
$ sudo mv microsoft.list /etc/apt/sources.list.d/microsoft-prod.list

# Download and import the GPG key for the new repositories via proxy:
$ curl -x http://proxy.yourdomain.ch:80 -sSL https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor | sudo tee /usr/share/keyrings/microsoft-prod.gpg > /dev/null

# Refresh all repositories
$ sudo apt update

# Install both packages 
$ sudo apt-get install mdatp azcmagent

# Add a proxy to both the mdatp (Defender) and azcmagent (ARC)
$ sudo mdatp config proxy set --value http://proxy.yourdomain.ch:80
$ sudo azcmagent_proxy add http://proxy.yourdomain.ch:80

Preparing Microsoft Defender/ Arc for Ubuntu

# Jump to your home folder
$ cd

# Download the official azure installation script for defender
curl -o mde_install.sh https://github.com/microsoft/mdatp-xplat/blob/master/linux/installation/mde_installer.sh

# In case your Linux server has no direct internet access you can use curl with a Proxy. Use -x:
$ curl -x http://proxy.yourdomain.ch:80 -o mde_install.sh https://github.com/microsoft/mdatp-xplat/blob/master/linux/installation/mde_installer.sh

# Install dependencies which will be needed for the process
$ sudo apt-get install curl libplist-utils gpg gnupg apt-transport-https

# Add the new GPG-Key to your server and install it
$ curl https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor > microsoft.gpg

$ sudo install -o root -g root -m 644 microsoft.gpg /usr/share/keyrings/
rm microsoft.gpg

# Create a new Repository file and update your apt package manager
$ sudo sh -c 'echo "deb [arch=amd64 signed-by=/usr/share/keyrings/microsoft.gpg] https://packages.microsoft.com/ubuntu/$(lsb_release -rs)/prod $(lsb_release -cs) main" >> /etc/apt/sources.list.d/microsoft-ubuntu-$(lsb_release -cs)-prod.list'

# Refresh all repositories
$ sudo apt update

# Install both packages 
$ sudo apt-get install mdatp azcmagent

# Add a proxy to both the mdatp (Defender) and azcmagent (ARC)
$ sudo mdatp config proxy set --value http://proxy.yourdomain.ch:80
$ sudo azcmagent_proxy add http://proxy.yourdomain.ch:80

Setup/ Configure Defender/ Arc on all Distributions

# Make sure the Azure script has access to be executed
$ sudo chmod +x mde_installer.sh

# Execute the Azure script with your generated Onboarding script
$ sudo ./mde_installer.sh -o WindowsDefenderATPOnboardingPackage.py
# This step shall return a state “Onboarded”

# We can now additionally activate the real time protection
$ sudo mdatp config real-time-protection --value enabled

# One can check the health of the setup with running
$ sudo mdatp health

# Now we can add the Linux server to the ARC
$ sudo azcmagent connect -l switzerlandnorth -s <SubscriptionID> -g <GroupPolicy>
# This step will return a webpage on your Azure including a unique key which we need to type in into the login prompt. This can only be done if your account ahs sufficient rights to maintain and add new clients to your organizations Azure

Summary & Hints

This technical guide will help you connect any Linux server to your existing Azure Defender and Arc portal. Once set up, you’ll unlock some great benefits for securing your systems. Here’s what you get:

• Real-time threat protection: Defender instantly scans files for malware, viruses, or other threats as they pop up on your Linux servers.
• Cross-platform support: It works seamlessly with Windows, macOS, and more, so you can manage all devices from one place.
• Advanced threat detection: In addition, it uses smart cloud analytics to spot serious threats like ransomware or sneaky zero-day attacks.
• Vulnerability checks: Finds weak spots in your Linux setup, like outdated apps or bad configs, and suggests fixes.
• Centralized management: Furthermore, you can control all your Linux servers from the Defender portal, making updates and monitoring a breeze.
• Easier compliance: Helps meet strict security standards (like Cyber Essentials) with built-in tools for Linux environments.

It may take a bit for your newly added Linux machines to appear in the Defender and Arc Azure Portal. Depending on your data center’s location, it could take up to half a day for the portal to fully sync and display all your Linux systems’ details.

L’article Setting up Microsoft Defender & Arc on Linux est apparu en premier sur dbi Blog.

Well, in SQL Server we are dealing with two principals in terms of “owning” a database:

• dbo
• db_owner

Principals in terms of SQL Server are entries that can request SQL Server resources.
We have so called server principals which are operating on instance-level – here we are talking about logins. At the other hand we have database principals which are operating at database-level – here we are talking about users.
While “dbo” is a single principal (a database-level user) who owns effectively the database, “db_owner” is a database role which can contain multiple users (the role itself is a principal as well as all their members) equipped with the rights to do any operation within the database – means executing DML (Data Manipulation Language – statements like SELECT, INSERT, UPDATE and DELETE) as well as DDL (Data Definition Language – statements like ALTER DATABASE etc.) and DCL (Data Control Language – statements like GRANT and REVOKE) against the database engine.
Furthermore every principal which is member of the server role “sysadmin” is not working under his own user in a database, he is mapped implicitly as “dbo” into each database.
There are tiny little differences between the two principals “dbo” and “db_owner” that I want to show you in several demos.

By the way: for my demo I’m using the new SSMS 21 which is available in preview these days. My colleague Stéphane Haby already written a blog post about the installation of the newest release of SSMS 21.

The range of functions and authorizations of the user “dbo” and members of the database role “db_owner” are quiet the same, but they differ in the following points:

1. The “dbo” is able to restore his own database (WITH REPLACE) while members of the role “db_owner” are not
2. All security checks are skippt when you acting as “dbo“, means DENYs are ignored meanwhile DENYs are taken into account when operating as a member of the role “db_owner“

Let’s dig into the demo: After creating the database “dbo_vs_dbowner” I’ve created two logins with descriptive names:

The login “Ced_dbo” is the owner of the database, the login “Ced_dbowner” is member of the database role db_owner:

The setup for the demo is now complete.
Now we come to the section, where I want to show you the different behaviour when working with each of them.

BACKUP/RESTORE

Let’s check if we have enough permissions to backup the database first.
Ced_dbo – of course, there is no problem to perform a backup of his own database:

Ced_dbowner – no problem to perform a backup of the database as well:

Now, let’s take a look at the behaviour when performing a restore.
Ced_dbo – Restore is working properly here:

Ced_dbowner – Performing a restore of the database is not possible under this credentials, because he is neither the owner nor member of the server role “db_creator” or “sysadmin”:

Caution: Performing a restore of his own database is only possible for the user Ced_dbo if he’s providing the parameter WITH REPLACE within the restore statement. If he drops his database first – yes this operation is allowed to execute for the “dbo” as well as for members of the database role “db_owner” – and tries to restore it afterwards, the operation will fail!
This makes sense because the master database keeps track of the owner of all databases. If a database is dropped, this information will be lost and SQL Server no longer has a clue who the owner of the database is/was and we need server level permissions (e.g. dbcreator or sysadmin) to create the database again from the backup.

https://learn.microsoft.com/en-us/sql/relational-databases/backup-restore/restore-database-general-page?view=sql-server-ver16#permissions

Bypassing Security Checks

Now we are goinig to check out the different behaviour of the sessions with our 2 users mentioned above under this point.
Due to the fact that Microsoft also uses the principle of inheritance of authorisations in the SQL Server environment, DENY had to be added to the well-known GRANT and REVOKE control commands of a DBMS. This differs from other DBMS like for example Oracle. Generally speaking, within SQL Server we are confronted with the fact that a DENY is overriding every other permission set for a user or group.

SQL Server knows the concept of bypassing security checks when we are connected with users who are members of the server role “sysadmin” and owner of databases as well – means for all types of users like this, DENYs are completely ignored.

A few weeks ago I prepared myself to teach our SQL Server dbi-services course “DBA ESSENTIALS” and I was astonished to realise that things has changed obviously when working with SQL Server 2022. Security bypassing seemed to be skippt by Microsoft, because the database owner was unable to do stuff which was denied for public as well as all the other users, but…

…after performing countless tests on different versions of SQL Server 2022, with older versions of SSMS and so on and so forth I’m able to to confirm, that SQL Server 2022 behaves the same way as always and as expected. I haven’t got a clue what magic happens within my testing environment during my preparation
Let’s dig into the next demo to illustrate and prove that things are behaving the same way the always did.
First of all, I created the Stored Procedure called “spr_getInfo” within the database as follows:

USE [dbo_vs_dbowner]
GO
CREATE PROCEDURE spr_getInfo
AS
BEGIN
  SELECT * FROM [dbo_vs_dbowner].[dbo].[T1]
  WHERE T1_ID = 3
END

Then I set a DENY to execute this Stored Procedure for all users:

USE [dbo_vs_dbowner]
GO
DENY EXECUTE ON OBJECT::dbo.spr_getInfo TO [public]
GO

Ced_dbowner – even this user is member of the database role “db_owner” which is granted to do everything within the database he is not allowed to execute the Stored Procedure because the DENY overrides the GRANT in terms of executing this Stored Procedure as mentioned above:

Selecting from the table directly is nevertheless allowed (same statement as used within the Stored Procedure), because the DENY impacts only the execution of the Stored Procedure but not the SELECT on the base table:

Now, let’s have a look how the execution behaves under the owner of the database.
Ced_dbo – as mentioned at the beginning of this section, for the owner of the database the DENY is ignored and a query result is being returned when the Stored Procedure is executed:

Conclusion

From my point of view, as a DBA it’s very important to know the tiny differences between “dbo” and members of the database role “db_owner” to avoid unpleasant surprises in our daily business.
And last but not least: things behave in the same manner as we are familiar with since a long time ago. Whether this is an advantage or a disadvantage remains a philosophical question…

L’article dbo vs. db_owner in SQL Server – What are the differences between them? est apparu en premier sur dbi Blog.