IAM audit logs not capturing failed authentication attempts for service IDs

Cloud Platforms IBM Cloud
, , , , , , , ,
1

We’re implementing security compliance monitoring and discovered that our IAM audit logs aren’t capturing failed authentication attempts for service IDs. Successful API calls are logged correctly, but when we test with invalid credentials or expired tokens, no audit events appear in Activity Tracker. We’ve checked the audit log event filtering configuration and confirmed that authentication events should be included. The IAM service permissions look correct for our monitoring service ID. This is critical for our SOC2 compliance requirements since we need to track all authentication failures and policy violations. Has anyone configured verbose logging for IAM authentication events successfully?

2

Interesting point about the API gateway. Our Activity Tracker is in the same region and we have the enterprise plan. Where specifically do I configure the multi-layer logging you mentioned?

3

Failed authentication attempts should definitely be logged. Check if you have the Activity Tracker instance in the same region as your IAM events. Also verify that your Activity Tracker plan includes security events - not all plan tiers capture authentication failures by default.

4

The missing failed authentication events for service IDs is typically caused by incomplete event routing configuration. Here’s how to achieve full audit coverage:

Audit Log Event Filtering: Your Activity Tracker needs explicit event type inclusion. Update your event routing configuration:

{
  "event_types": [
    "iam.authentication.success",
    "iam.authentication.failure",
    "iam.policy.violation",
    "iam.token.expired"
  ],
  "sources": ["iam", "api-gateway"],
  "severity": ["normal", "warning", "critical"]
}

The key is including both success AND failure event types explicitly. Default configurations often only capture successful operations.

IAM Service Permissions: Your monitoring service ID needs specific IAM permissions to receive authentication audit events. Assign these roles:

  • Reader role on IAM Identity Service
  • Viewer role on Activity Tracker
  • Service Configuration Reader (for policy violation events)

Verify with:

ibmcloud iam service-policies SERVICE_ID_NAME

Ensure the policy includes resource type ‘iam-identity’ and ‘activity-tracker’.

Verbose Logging Configuration: Enable detailed authentication logging by setting these IAM parameters:

  1. Go to IAM Settings → Advanced
  2. Enable “Detailed audit logging for authentication events”
  3. Set “Failed authentication retention” to match your compliance period (typically 90-365 days)
  4. Enable “Service ID authentication tracking”

For API-level configuration:

audit_config:
  authentication_events:
    log_level: verbose
    include_failures: true
    include_token_details: false  # Privacy consideration
    include_ip_address: true

Log Retention Policies: Your Activity Tracker instance must be configured for compliance retention:

  • Retention period: Set to 365 days minimum for SOC2
  • Archive to Cloud Object Storage: Enable for long-term retention
  • Event quota: Increase if you’re hitting limits (check current usage in Activity Tracker dashboard)

Critical setting:

{
  "retention_days": 365,
  "archive_enabled": true,
  "archive_bucket": "audit-logs-archive",
  "event_quota_per_day": 500000
}

Multi-Layer Logging Strategy: For complete visibility, capture events at three levels:

  1. IAM Service Layer: Authentication decisions (configured above)
  2. API Gateway Layer: Request-level attempts before IAM evaluation
  3. Application Layer: Service-to-service authentication within your apps

Enable API Gateway logging:

ibmcloud api-gateway logging-config set \
  --log-level INFO \
  --include-auth-failures true

Validation Process: Test your configuration:

  1. Generate a failed authentication attempt with expired service ID credentials
  2. Wait 2-3 minutes for event propagation
  3. Query Activity Tracker:
ibmcloud at event-list \
  --type iam.authentication.failure \
  --time-range 10m

You should see events with outcome:failure and reason codes (401, 403, etc.).

Common Pitfalls:

  • Failed attempts at the TLS layer (before reaching IAM) won’t generate IAM events - these require API Gateway logs
  • Service ID authentication failures sometimes categorized under ‘iam.serviceid.access’ rather than ‘iam.authentication’
  • Regional Activity Tracker instances only capture events from that region - use global routing for multi-region coverage

This comprehensive configuration addresses all four focus areas and ensures SOC2-compliant audit coverage for authentication events. The verbose logging with proper retention will capture all failed authentication attempts including expired tokens and policy violations.

5

You need to check the event routing configuration. IAM generates authentication events but they might not be routed to your Activity Tracker instance. Go to your Activity Tracker settings and verify the event routing rules include ‘iam.authentication’ event types. Also check if you have any exclusion filters that might be dropping failed authentication events.

6

I ran into this last quarter. The issue was that failed authentication attempts at the API gateway level don’t always propagate to IAM audit logs if the request doesn’t reach the IAM service. Make sure you’re also collecting API Gateway logs, not just IAM logs. We had to enable logging at multiple layers to get complete visibility.