# idaas-identity

Part of **IDAAS**

# IDaaS Identity Management Troubleshooting Guide

## Problem Index

| Problem | Symptom | Severity | Solution Summary |
|--------|--------|---------|------------------|
| Bounced Emails from Legacy IDaaS Instances | System sends "Email Returned" bounce notifications due to invalid default account email | Medium | Replace the placeholder email (e.g., `example@example.com`) with a valid enterprise email in the Accounts and Orgs console |
| Synchronized RAM User Deletion Fails | Error when attempting to delete a RAM user synchronized from IDaaS | High | Manually remove MFA devices, AccessKeys, and group memberships before deletion |
| Okta-to-IDaaS User Sync Failure | Users not appearing in IDaaS after Okta provisioning setup | Medium | Verify SCIM/SAML configuration, enable password sync, and manually trigger sync via Okta console |

## Problem Details

### Problem 1: Bounced Emails from Legacy IDaaS Instances

**Symptoms**
- Error message: `Email Returned`
- Behavior: System-generated bounce notifications are received when IDaaS attempts to send alerts or notifications
- Context: Occurs in legacy IDaaS EIAM 1.X instances where the default administrator account uses a placeholder email like `example@example.com`

**Root Cause**
- The default account created during instance initialization uses a non-functional sample email address. When IDaaS attempts to send system notifications (e.g., for security alerts or user invitations), the email is rejected by the mail server, resulting in a bounce.

**Solution**
1. Log on to the IDaaS console at https://idc.console.aliyun.com
2. Navigate to **Accounts and Orgs** in the left navigation panel
3. Locate the default administrator account (usually auto-created)
4. Click **Edit** in the top-right corner of the account details page
5. In the email configuration field, replace `example@example.com` with a valid, active enterprise email address
6. Click **Save** at the bottom of the form

```bash
# No CLI command available; this is a console-only operation
```

**Verification**
- After saving, trigger a test notification (e.g., invite a test user)
- Confirm the enterprise email inbox receives the message without bounce
- Check that no new "Email Returned" alerts appear in system logs

### Problem 2: Synchronized RAM User Deletion Fails

**Symptoms**
- Behavior: Attempting to delete a RAM user synchronized from IDaaS fails silently or returns an error
- Context: Occurs when the RAM user has active dependencies such as MFA devices, AccessKeys, or group memberships

**Root Cause**
- Alibaba Cloud RAM enforces dependency checks before allowing user deletion. A synchronized user cannot be deleted if it retains:
  - Attached MFA device
  - Active AccessKeys
  - Membership in one or more user groups

**Solution**
1. Log on to the RAM console at https://ram.console.aliyun.com
2. Go to **Users** under Member Management in the left navigation pane
3. Find and click the target username to open its details page
4. In the **User Groups** section, remove the user from all groups
5. Navigate to **Security Information Management > Login Management** and detach any MFA device
6. Go to **AccessKey Management** and delete all associated AccessKeys
7. Return to the Users list and click **Delete** in the Actions column

```bash
# Example: Delete AccessKey via CLI (if known)
aliyun ram DeleteAccessKey --UserPrincipalName <user@example.com> --AccessKeyId <your-access-key-id>
```

**Verification**
- After completing all steps, the **Delete** button should be enabled
- Successful deletion results in the user disappearing from the RAM user list
- Confirm in IDaaS that the user is no longer synchronized (if applicable)

### Problem 3: Okta-to-IDaaS User Sync Failure

**Symptoms**
- Behavior: Users provisioned in Okta do not appear in IDaaS
- Context: After configuring Okta SAML 2.0 application and enabling provisioning

**Root Cause**
- Password synchronization is not enabled in Okta, or the sync was not manually triggered after configuration. IDaaS requires a valid password (even placeholder) to create user records.

**Solution**
1. In the Okta Admin Console, go to the application’s **Provisioning** tab
2. Ensure **Sync Password** is checked
3. Select **Sync a randomly generated password** (or another valid option per your policy)
4. Click **Save** to apply settings
5. To immediately trigger sync, go to the **Push Groups** tab and click **Save** (status changes from *Pushing* to *Active*)

```json
// Expected SCIM payload structure (for validation)
{
  "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
  "userName": "user@example.com",
  "password": "auto-generated-placeholder"
}
```

**Verification**
- Within 5–10 minutes, the user should appear in the IDaaS user directory
- Check IDaaS audit logs for successful user creation events
- Attempt SSO login with the user to confirm end-to-end functionality

## FAQ

**Q: How do I check if my IDaaS instance is using a legacy version?**  
A: Legacy IDaaS EIAM 1.X instances typically have limited UI features and use placeholder emails by default. Check your instance creation date or consult the **Overview** page in the IDaaS console. Upgrading to EIAM 2.0 is recommended for improved reliability and features.

**Q: What permissions are required to delete a synchronized RAM user?**  
A: You need the `AliyunRAMFullAccess` policy attached to your administrator RAM user or role. This grants full control over RAM user lifecycle operations, including dependency removal and deletion.

**Q: Why doesn’t revoking Okta app authorization delete the user in IDaaS?**  
A: Revoking authorization in Okta only marks the user as unauthorized in IDaaS—it does not delete the record. Manual cleanup by an IDaaS administrator is required to fully remove the user.

**Q: How can I enable debug logging for synchronization issues?**  
A: IDaaS provides detailed audit logs under **Log Audit** in the console. Filter by *User Provisioning* or *Synchronization* events to trace SCIM operations. For Okta, check the **Provisioning Reports** tab in the Okta application for sync status and errors.

**Q: Can I use a custom email domain for system notifications in IDaaS?**  
A: Yes. Replace the default account’s email with any valid, routable enterprise email address (e.g., `admin@yourcompany.com`). Ensure your mail server accepts messages from Alibaba Cloud IPs to prevent future bounces.