ORA-12754 When Setting ADG_ACCOUNT_INFO_TRACKING to Global

ADG_ACCOUNT_INFO_TRACKING was first introduced in 18.1 enchance the security posture in a data guard configuration. Setting this parameter to global result in login failures accross the data guard configuraiton being counted towards FAILED_LOGIN_ATTEMPTS value set in the user account profile. Setting it to local result in the default behavior which is only login failures in the primary is counted towards the FAILED_LOGIN_ATTEMPTS values.
In a recent deployment which was on AWS EC2 VMs (this point is key to this post and it is not using AWS RDS) following error was observed when testing the ADG_ACCOUNT_INFO_TRACKING works as expected, by using a wrong password and trying to login from a standby instance and to see if it locks after FAILED_LOGIN_ATTEMPTS number of login failures.

sqlplus locktest/locktest321@testro

SQL*Plus: Release 19.0.0.0.0 - Production on Tue Jan 26 13:59:45 2021
Version 19.10.0.0.0

Copyright (c) 1982, 2020, Oracle. All rights reserved.

ERROR:
ORA-12754: Feature 'ADG Statement Redirection' is disabled due to missing capability 'Runtime Environment'.
ORA-01017: invalid username/password; logon denied 

Error is strange as ADG statement redirection wasn't being used. This feature was introduced in 19.1 and controlled by ADG_REDIRECT_DML. Secondly the due to the error ADG_ACCOUNT_INFO_TRACKING wasn't working as expected and one could have unlimited number of login failures.
The two parameters in concern had the following values.

adg_account_info_tracking string GLOBAL
adg_redirect_dml boolean FALSE 

Setting adg_redirect_dml to true didn't make any difference either.
Further investigations showed that dml redirecation is not avaiable on "Authorized Cloud Environments". This is mentioned in the license documentation. But nowhere on it says anything about ADG_ACCOUNT_INFO_TRACKING.



Priror to testing on AWS EC2 a similar setup was created and operational in Azure (using Azure VM). If ADG_ACCOUNT_INFO_TRACKING is also not supported in authorized cloud environment similar to dml redirection then it should fail on Azure VM setup as well.
It seems that ADG_ACCOUNT_INFO_TRACKING is using DML redirection behind the scene to update the failed login atttempt count in the primary. However, use of this is flagged as "missing capability" only when databases are craeted on AWS EC2 VMs and not on Azure VM even though license doc says dml redirection is not supported on authorized cloud environments. It seems issue is localized only to AWS EC2.
SR raised and Oracle has created internal bug 32838564 - SETTING ADG_ACCOUNT_INFO_TRACKING=GLOBAL RESULTS IN ORA-12754 IN AWS DG ENVIRONMENT and investigating.

Update 07 July 2022
Oracle confirmed that ADG_ACCOUNT_INFO_TRACKING is using dml redirection behind the scene. Since dml redirection is not allowed on cloud environment the ADG_ACCOUNT_INFO_TRACKING also fails. Bug 32838564 was closed as not a bug based on above explanation.

Udev Rules for AWS EBS Volumes

AWS EBS volumes could be used as ASM disks. When ASMLib or AFD is not used, udev rules must be used to set the correct permissions on the EBS block volumes. It's generally good practice to use a unique identifier (UUID) to identify the partitions that require permission being set. It's not a guarantee that partitions or the blocks will be attached to the server in the same order and getting the same name.
Depending on the tool/option used a unique identifier may not be always available. For example the default dos partition table type created using fdisk would not generate any unique ID.

Model: Xen Virtual Block Device (xvd)
Disk /dev/xvdb: 268GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number  Start   End    Size   Type     File system  Flags
 1      1049kB  268GB  268GB  primary  ext4

udevadm info --query=property /dev/xvdd1
DEVNAME=/dev/xvdd1
DEVPATH=/devices/vbd-51760/block/xvdd/xvdd1
DEVTYPE=partition
ID_PART_ENTRY_DISK=202:48
ID_PART_ENTRY_NUMBER=1
ID_PART_ENTRY_OFFSET=2048
ID_PART_ENTRY_SCHEME=dos
ID_PART_ENTRY_SIZE=209713152
ID_PART_ENTRY_TYPE=0x83
ID_PART_TABLE_TYPE=dos
MAJOR=202
MINOR=49
SUBSYSTEM=block
TAGS=:systemd:
USEC_INITIALIZED=634695673

On the other-hand if the partition table type was GPT, this could generate several unique IDs which could be used in the udev rule to identify the partition.

fdisk /dev/sdd

Command (m for help): g
Building a new GPT disklabel (GUID: EC7F1589-8BD2-4C94-8F8F-D22013D40406)


Command (m for help): n
Partition number (1-128, default 1):
First sector (2048-20971486, default 2048):
Last sector, +sectors or +size{K,M,G,T,P} (2048-20971486, default 20971486):
Created partition 1


Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.

 fdisk -l /dev/sdd
WARNING: fdisk GPT support is currently new, and therefore in an experimental phase. Use at your own discretion.

Disk /dev/sdd: 10.7 GB, 10737418240 bytes, 20971520 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: gpt
Disk identifier: EC7F1589-8BD2-4C94-8F8F-D22013D40406


#         Start          End    Size  Type            Name
 1         2048     20971486     10G  Linux filesyste

udevadm info --query=property /dev/sdd1
...
ID_PART_ENTRY_DISK=8:48
ID_PART_ENTRY_NUMBER=1
ID_PART_ENTRY_OFFSET=2048
ID_PART_ENTRY_SCHEME=gpt
ID_PART_ENTRY_SIZE=20969439
ID_PART_ENTRY_TYPE=0fc63daf-8483-4772-8e79-3d69d8477de4
ID_PART_ENTRY_UUID=573dded4-21f1-48ce-925f-e02c5d94dace
ID_PART_TABLE_TYPE=gpt
ID_PATH=pci-0000:00:0d.0-ata-4.0
ID_PATH_TAG=pci-0000_00_0d_0-ata-4_0
...
SUBSYSTEM=block
TAGS=:systemd:

The partition UUID could be found out using blkid as well.

blkid /dev/sdd1
/dev/sdd1: PARTLABEL="data" PARTUUID="573dded4-21f1-48ce-925f-e02c5d94dace"

The ID_PART_ENTRY_UUID could be used in the udev rule.

KERNEL=="sd?1",ENV{ID_PART_ENTRY_UUID}=="573dded4-21f1-48ce-925f-e02c5d94dace", SYMLINK+="oracleasm/cgdata1", OWNER="oracle", GROUP="asmadmin", MODE="0660"

Similar to fdisk with g (gpt) option, parted could be used to achieve the same.

parted /dev/xvdd
GNU Parted 3.1
Using /dev/xvdd
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) mktable gpt
Warning: The existing disk label on /dev/xvdd will be destroyed and all data on this disk will be lost. Do you want to continue?
Yes/No? yes
(parted) mkpart data 0% 100%

(parted) print all
Model: Xen Virtual Block Device (xvd)
Disk /dev/xvdd: 107GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number  Start   End    Size   File system  Name  Flags
 1      1049kB  107GB  107GB               data

udevadm info --query=property /dev/xvdd1
DEVLINKS=/dev/disk/by-partlabel/data /dev/disk/by-partuuid/5a081ffa-56e2-467b-82a9-16e3a4f441bd
DEVNAME=/dev/xvdd1
DEVPATH=/devices/vbd-51760/block/xvdd/xvdd1
DEVTYPE=partition
ID_PART_ENTRY_DISK=202:48
ID_PART_ENTRY_NAME=data
ID_PART_ENTRY_NUMBER=1
ID_PART_ENTRY_OFFSET=2048
ID_PART_ENTRY_SCHEME=gpt
ID_PART_ENTRY_SIZE=209711104
ID_PART_ENTRY_TYPE=ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
ID_PART_ENTRY_UUID=5a081ffa-56e2-467b-82a9-16e3a4f441bd
ID_PART_TABLE_TYPE=gpt
MAJOR=202
MINOR=49
SUBSYSTEM=block
TAGS=:systemd:
USEC_INITIALIZED=685327395