Staged Users - CLI Reference

Overview

Staged users implement a formal user lifecycle management system in FreeIPA, enabling approval workflows, bulk provisioning, and integration with external HR or identity management systems. Rather than creating users directly in the active state where they can immediately authenticate, staged users provide a holding area for user entries that require review, approval, or additional configuration before activation.

This three-state lifecycle model separates user provisioning from user activation:

Staged: User entry exists but cannot authenticate. Used for pre-provisioning, approval workflows, or import from external systems.

Active: User entry is fully functional and can authenticate (with credentials). This is the normal operational state.

Preserved: User entry is disabled but retained for compliance, future reactivation, or historical reference. Users cannot authenticate but attributes and group memberships are preserved.

Note: There is also a fourth state, “Deleted,” where user entries are permanently removed from the directory.

This lifecycle supports common enterprise scenarios:

New hire processing with manager approval before activation
Bulk import from HR systems followed by batch activation
Pre-provisioning accounts before employee start dates
Compliance retention of terminated user accounts

User Lifecycle States

Staged Users (cn=staged users, cn=accounts, cn=provisioning, SUFFIX)

Staged user entries are candidates for activation. They exist in a separate LDAP container and have the following properties:

Cannot authenticate: Even if credentials (password, OTP tokens, certificates) are set, staged users cannot log in or obtain Kerberos tickets.

Not in groups: Staged users can have group memberships defined, but these don’t take effect until activation. POSIX groups that reference staged users won’t include them in membership queries.

No UID/GID assignment: While UID and GID can be pre-assigned, they’re not reserved. If a different user is created with the same UID before activation, conflicts may occur.

Full attribute support: All standard user attributes can be set (name, email, phone, SSH keys, certificates, etc.). This enables complete pre-provisioning.

External provisioning: External systems (HR databases, identity management platforms) can write directly to the staging container via LDAP, then IPA administrators activate users after validation.

###Active Users (cn=accounts, SUFFIX)

Active user entries are fully operational POSIX users with the following properties:

Can authenticate: Users can log in to IPA-enrolled systems, obtain Kerberos tickets, and access services (with appropriate credentials and policies).

Group membership active: Group memberships take effect; users appear in POSIX group lookups and policy evaluations (HBAC, sudo).

UID/GID assigned: UID and GID numbers are definitively reserved. POSIX operations use these values.

Policy enforcement: HBAC rules, sudo rules, SELinux user mapping, and other policies apply to active users.

Certificate/keytab usage: Kerberos principals, SSH keys, X.509 certificates, and service keytabs function normally.

Preserved Users (cn=deleted users, cn=accounts, cn=provisioning, SUFFIX)

Preserved user entries represent disabled accounts that are retained for compliance or potential reactivation:

Cannot authenticate: Like staged users, preserved users cannot log in even if credentials exist.

Attributes retained: All user attributes, group memberships, and metadata are preserved for audit trails or regulatory compliance.

Different from deletion: Unlike permanently deleted users, preserved users can be reactivated to active status (restoring full functionality).

Compliance retention: Many organizations must retain identity records for terminated employees for 3-7 years. Preservation meets this requirement without keeping accounts active.

Eventual deletion: Preserved users can be permanently deleted after retention periods expire.

Staging Workflows

Manual Approval Workflow

HR submits request: HR or manager creates staged user with basic attributes
IT completes provisioning: IT staff add SSH keys, assign groups, configure authentication
Manager approves: Manager or security team reviews and approves
IT activates: Administrator runs stageuser-activate, user becomes active
User logs in: User can now authenticate and access resources

This separates data entry (which non-privileged staff can do) from activation (which requires administrative privileges).

Bulk Import Workflow

Extract from HR system: Export employee data (CSV, LDIF, or database query)
Import to staging: Script creates staged users via stageuser-add or direct LDAP writes
Validation: Administrators review staged users for conflicts, missing data, formatting issues
Batch activation: Activate all valid users in one operation
Error handling: Resolve issues with problem accounts, re-attempt activation

This prevents partial failures from leaving the active user directory in an inconsistent state.

Pre-Provisioning Workflow

Future start date known: Employee won’t start for 2-4 weeks
Create staged user: Provision account with all attributes now
Infrastructure preparation: Configure home directories, email, access rights
Activate on start date: Run activation on employee’s first day
Immediate access: New hire can log in immediately on day one

This eliminates first-day delays waiting for account provisioning.

External System Integration

HR system writes to staging: External identity management system uses LDAP bind with write privileges to staging container
IPA validates entries: Custom scripts or manual review verify data quality
Conditional activation: Activate users meeting quality criteria, hold others for review
Feedback loop: Update external system with activation status or error messages

This enables IPA to participate in complex provisioning workflows without tight coupling to external systems.

Activation Process

When stageuser-activate is executed:

Validation: IPA verifies the staged user entry is well-formed (required attributes present, valid UID/GID ranges, etc.)
Conflict detection: Checks for UID/GID conflicts with existing active users
Entry move: LDAP entry is moved from staging container to active container
DN transformation: DN changes from uid=alice,cn=staged users,... to uid=alice,cn=users,cn=accounts,...
Kerberos principal creation: If not already present, Kerberos principal is created
Group membership activation: Group memberships become active
UID/GID finalization: UID and GID numbers are definitively assigned
Initial password: If password was set in staging, it carries over (user must change on first login if policy requires)

Activation is atomic—it either fully succeeds or fully fails (user remains staged).

Username Constraints

FreeIPA supports flexible username formats, but POSIX and Kerberos impose certain constraints. The default username format:

Cannot be only numbers: Usernames like “12345” are prohibited (conflicts with UIDs in some contexts)

Must start with a letter, number, underscore, or period: Valid: alice, 1admin, _service, .hidden. Invalid: -invalid, @bad

May contain letters, numbers, underscores, periods, hyphens: Valid: john.doe, admin_2, test-user

May end with a letter, number, underscore, period, hyphen, or dollar sign: Valid: user1, admin_, backup., test-, host$ (for machine accounts)

Length limits: Most UNIX systems support usernames up to 32 characters. IPA defaults to this limit.

These rules can be adjusted via ipa config-mod --ipausernamemaxlength and --ipausernamesearchformat, but deviating from defaults may cause compatibility issues with legacy systems.

Staged User Validation

IPA performs validation when adding or modifying staged users:

Required attributes: uid (username), givenName (first name), sn (last name) are typically required

Unique UID: Usernames must be unique within the staging container (duplicate usernames in staging vs active are allowed, but activation will fail if conflict exists)

Valid UID/GID numbers: If specified, must be within configured ID ranges

ipaUniqueID: Auto-generated if not provided (should always be auto-generated)

Email format: If email is provided, must be valid email format

Shell validity: If login shell specified, should exist on target systems (IPA doesn’t validate but misconfiguration will cause login issues)

Home directory: If specified, should follow organizational standards (usually /home/username)

Staged users can be created with minimal attributes and refined later via stageuser-mod before activation.

##Examples

Create Basic Staged User

# Create staged user with required attributes
$ ipa stageuser-add tuser1 \
  --first=Tim \
  --last=User \
  --email=tuser1@example.com
  User login: tuser1
  First name: Tim
  Last name: User
  Email address: tuser1@example.com
  UID: (will be assigned at activation)

Create Staged User with Full Attributes

# Pre-provision user with all attributes
$ ipa stageuser-add alice \
  --first=Alice \
  --last=Smith \
  --email=alice@example.com \
  --phone="+1-555-1234" \
  --title="Software Engineer" \
  --manager=bob \
  --employeenumber="E12345" \
  --employeetype="fulltime" \
  --shell=/bin/bash \
  --homedir=/home/alice

Create Staged User with Password

# Set initial password during staging (user will change on first login)
$ ipa stageuser-add charlie --first=Charlie --last=Brown
$ ipa stageuser-mod charlie --password
Password: [enter password]

Create Staged User with SSH Key

# Add SSH public key for immediate access after activation
$ ipa stageuser-add diana --first=Diana --last=Prince
$ ipa stageuser-mod diana \
  --sshpubkey="ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC... diana@laptop"

List All Staged Users

# View all users awaiting activation
$ ipa stageuser-find
  5 users matched
  User login: tuser1
  First name: Tim
  Last name: User
  User login: alice
  First name: Alice
  Last name: Smith
  [...]

Search Staged Users by Attribute

# Find staged users by department
$ ipa stageuser-find --title="Software Engineer"

# Find staged users by manager
$ ipa stageuser-find --manager=bob

# Find staged users by employee type
$ ipa stageuser-find --employeetype="contractor"

View Staged User Details

# Show complete staged user entry
$ ipa stageuser-show alice --all
  dn: uid=alice,cn=staged users,cn=accounts,cn=provisioning,dc=example,dc=com
  User login: alice
  First name: Alice
  Last name: Smith
  Email: alice@example.com
  Manager: bob
  [...]

Modify Staged User

# Update attributes before activation
$ ipa stageuser-mod alice \
  --phone="+1-555-5678" \
  --city="San Francisco" \
  --state="CA"

Activate Staged User

# Move user from staged to active
$ ipa stageuser-activate alice
  User login: alice
  First name: Alice
  Last name: Smith
  Email: alice@example.com
  UID: 1234567
  GID: 1234567
  [...]

# User can now authenticate
$ ipa user-show alice
  [shows active user]

Batch Activation

# Activate multiple staged users
for user in alice bob charlie; do
  ipa stageuser-activate $user
done

# Or use xargs for parallel activation
$ ipa stageuser-find --pkey-only | grep "User login" | awk '{print $3}' | \
  xargs -I {} -P 5 ipa stageuser-activate {}

Delete Staged User

# Remove staged user without activation (abandon provisioning)
$ ipa stageuser-del tuser1

Add Certificate to Staged User

# Pre-configure certificate for activation
$ ipa stageuser-add-cert alice \
  --certificate="MIIDzTCCArWgAwIBAgIBATANBgkqhkiG9w0BAQsFADA..."

Add Manager Relationship

# Set manager for organizational hierarchy
$ ipa stageuser-add-manager alice --users=bob

Add Kerberos Principal Alias

# Configure additional Kerberos principals
$ ipa stageuser-add-principal alice alice.admin@EXAMPLE.COM

Add Passkey Mapping

# Pre-configure passkey for passwordless login after activation
$ ipa stageuser-add-passkey alice <passkey-mapping-data>

Add Certificate Mapping

# Configure certificate-to-user mapping
$ ipa stageuser-add-certmapdata alice \
  --subject="CN=Alice Smith,OU=Engineering,O=Example Corp" \
  --issuer="CN=Example Corp CA"

Modify Multiple Attributes

# Bulk attribute update
$ ipa stageuser-mod alice \
  --phone="+1-555-9999" \
  --mobile="+1-555-8888" \
  --city="Boston" \
  --state="MA" \
  --postalcode="02101" \
  --street="123 Main St"

Filter by Group Membership

# Find staged users intended for specific group
$ ipa stageuser-find --in-groups=developers

# Find staged users NOT in a group
$ ipa stageuser-find --not-in-groups=contractors

Rename Staged User

# Change username before activation
$ ipa stageuser-mod alice.smith --rename=asmith

Create Staged User with Custom UID/GID

# Specify exact UID/GID (useful for migrations)
$ ipa stageuser-add migrated1 \
  --first=Migrated \
  --last=User \
  --uid=5000 \
  --gidnumber=5000

Generate Random Password

# Create staged user with random initial password
$ ipa stageuser-add testuser --first=Test --last=User --random
  User login: testuser
  Random password: xK9mP2nQ7wR3
  [save this password for the user]

Set Password Expiration

# Force password change at first login
$ ipa stageuser-mod alice \
  --password-expiration="2024-01-01 00:00:01"

Set Principal Expiration

# Set Kerberos principal expiration for temporary access
$ ipa stageuser-mod contractor1 \
  --principal-expiration="2024-12-31 23:59:59"

Configure Authentication Type

# Require OTP authentication after activation
$ ipa stageuser-mod alice --user-auth-type=otp

# Require password + OTP (two-factor)
$ ipa stageuser-mod alice --user-auth-type="password,otp"

External IdP Configuration

# Configure external identity provider mapping
$ ipa stageuser-mod alice \
  --idp="google-workspace" \
  --idp-user-id="alice@example.com"

RADIUS Configuration

# Configure RADIUS proxy for this user
$ ipa stageuser-mod alice \
  --radius="radius-server.example.com" \
  --radius-username="alice@example.com"

SMB/CIFS Attributes

# Configure Windows/Samba attributes for AD integration
$ ipa stageuser-mod alice \
  --smb-home-dir="\\\\fileserver\\home\\alice" \
  --smb-home-drive="H:" \
  --smb-profile-path="\\\\fileserver\\profiles\\alice"

Bulk Import from CSV

# Script to import staged users from CSV
#!/bin/bash
# CSV format: username,firstname,lastname,email,title

while IFS=, read -r username firstname lastname email title; do
  ipa stageuser-add "$username" \
    --first="$firstname" \
    --last="$lastname" \
    --email="$email" \
    --title="$title"
done < employees.csv

Validation Before Activation

# Check for conflicts before activating
$ ipa user-find --login=alice
# If exists, resolve conflict first

$ ipa stageuser-show alice --all
# Verify all required attributes are set

$ ipa stageuser-activate alice
# Proceed with activation

Best Practices

Provisioning Strategy

Staged-first approach: Always create users in staging, even for immediate activation. This provides consistency, audit trail, and rollback capability.

Attribute completeness: Provision all known attributes in staging (email, phone, manager, department). It’s easier to set everything once than to update active users later.

Validation before activation: Review staged users for completeness, conflicts (duplicate UIDs), and policy compliance before activation.

Batch operations: Group related activations together (e.g., all new hires from same cohort). This simplifies tracking and rollback if issues arise.

Automation: Use scripts for repetitive tasks (bulk imports, attribute standardization). Manual entry is error-prone for large volumes.

Security Considerations

Staging container permissions: Limit write access to staging container. External systems should only be able to write to staging, not directly to active users.

Password handling: If setting passwords in staging, use secure channels to deliver credentials to users. Never email plaintext passwords.

Activation approval: Implement approval workflows (manager sign-off, security review) before activation for sensitive roles.

Audit logging: Log all staging operations (add, modify, activate, delete) for compliance and security auditing.

UID/GID conflicts: Always check for UID/GID conflicts before activation. Conflicts can cause file ownership and access control issues.

Lifecycle Management

Preservation over deletion: When users leave, move to preserved state rather than immediate deletion. This satisfies compliance retention requirements.

Retention policies: Define how long preserved users are retained (typically 3-7 years for compliance) before permanent deletion.

Reactivation testing: Periodically test the preservation → active workflow to ensure it works when needed (rehire, extended leave return).

Cleanup: Regularly review staging container for abandoned entries (users who were never activated). Delete or activate these to prevent clutter.

Integration with External Systems

One-way sync preferred: External systems write to staging, IPA activates. Avoid bi-directional sync which creates race conditions and conflicts.

Idempotent imports: Import scripts should be idempotent—running twice shouldn’t create duplicates or errors.

Error handling: External imports should gracefully handle failures (duplicate usernames, invalid attributes) without aborting entire batch.

Status feedback: After activation, update external system with success/failure status so HR/provisioning systems stay synchronized.

##Integration Points

Active Users

Activated staged users become active users and inherit all active user capabilities:

See user topic for active user management
All user commands apply after activation
Group memberships, roles, and policies take effect

Group Membership

Staged users can be added to groups, but membership only becomes effective after activation:

Group assignments defined in staging carry over to active state
Useful for pre-configuring access rights before user starts

Authentication

Staged users cannot authenticate even if credentials are configured:

Passwords, OTP tokens, SSH keys, certificates can be set but won’t work until activation
After activation, all configured authentication methods become functional

RBAC (Roles, Privileges, Permissions)

Role assignments can be configured for staged users but don’t take effect until activation:

Useful for pre-configuring administrative access
Prevents privilege escalation via staging container

Certificates and Keys

X.509 certificates and SSH public keys can be added to staged users:

Certificates don’t validate for authentication until activation
SSH keys become functional immediately upon activation
Useful for pre-configuring certificate-based authentication

External Provisioning Systems

Staging container enables integration with external identity systems:

HR databases can write user data via LDAP
Identity management platforms can use staging as intermediate step
Enables approval workflows outside IPA

Preserved Users

Users can be moved from staging to preserved state (unusual but supported):

Useful if provisioning is canceled but record must be retained
Can later be moved from preserved to staging or directly to active

Use Cases

1. New Hire Pre-Provisioning with Start Date

Provision new employee accounts before start date for day-one access.

# HR notifies IT of new hire starting in 2 weeks
# Create staged user with all attributes now
ipa stageuser-add jsmith \
  --first=Jane \
  --last=Smith \
  --email=jsmith@example.com \
  --title="Senior Developer" \
  --manager=techlea \
  --employeenumber=E45678 \
  --employeetype=fulltime \
  --shell=/bin/bash \
  --homedir=/home/jsmith

# Add to appropriate groups while still staged
ipa group-add-member engineering --stageusers=jsmith
ipa group-add-member developers --stageusers=jsmith

# Add SSH key provided by new hire
ipa stageuser-mod jsmith \
  --sshpubkey="ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAA... jsmith@laptop"

# Set initial password (user will change on first login)
ipa stageuser-mod jsmith --password

# On employee's first day, activate account
ipa stageuser-activate jsmith

# User can immediately log in with SSH key or password
# Group memberships active, access granted day one

2. Bulk Import from HR System

Import employee data from CSV export and activate in batch.

# Export from HR system to CSV:
# username,firstname,lastname,email,title,department,employeetype

# Import script using CSV
while IFS=, read -r username firstname lastname email title dept emptype; do
  ipa stageuser-add "$username" \
    --first="$firstname" \
    --last="$lastname" \
    --email="$email" \
    --title="$title" \
    --ou="$dept" \
    --employeetype="$emptype" || echo "Failed: $username"
done < hr_export.csv

# Review staged users for quality
ipa stageuser-find | grep "User login"

# Validate specific entries
ipa stageuser-show jdoe --all

# Batch activate all valid entries
for user in $(ipa stageuser-find --pkey-only | grep "User login:" | awk '{print $3}'); do
  echo "Activating: $user"
  ipa stageuser-activate "$user" || echo "FAILED: $user"
done

# Review failures and fix
ipa stageuser-find  # Shows remaining staged users needing attention

3. Manager Approval Workflow

Require manager approval before account activation.

# Helpdesk creates staged user per manager request
ipa stageuser-add contractor1 \
  --first=John \
  --last=Contractor \
  --email=jcontractor@vendor.com \
  --manager=hiring-manager \
  --employeetype=contractor

# Email sent to manager for approval (external to IPA)
# Manager replies approving

# After approval, IT activates
ipa stageuser-activate contractor1

# Set account expiration for contractor end date
ipa user-mod contractor1 --principal-expiration=20241231235959Z

# Contractor can now log in
# Account automatically disabled after expiration date

4. Staged User Cleanup - Provisioning Canceled

Remove staged users when hiring is canceled.

# List all staged contractors for review
ipa stageuser-find --employeetype=contractor

# Hiring for contractor2 canceled
# Delete staged user before activation
ipa stageuser-del contractor2

# Alternative: Move to preserved for record retention
# (unusual for staged users but possible)
ipa stageuser-activate contractor2  # Activate first
ipa user-disable contractor2          # Immediately disable
ipa user-del --preserve contractor2   # Move to preserved

# Verify deletion
ipa stageuser-find --user=contractor2
# No entries matched

5. Bulk Activation with Error Handling

Activate large batch of users with robust error handling.

# Get list of all staged users
USERS=$(ipa stageuser-find --pkey-only | grep "User login:" | awk '{print $3}')

# Track successes and failures
SUCCESS_LOG="activation_success.txt"
FAILURE_LOG="activation_failures.txt"
> "$SUCCESS_LOG"  # Clear log files
> "$FAILURE_LOG"

# Activate with error handling
for user in $USERS; do
  if ipa stageuser-activate "$user" 2>&1 | tee -a activation_output.log; then
    echo "$user" >> "$SUCCESS_LOG"
    echo "✓ Activated: $user"
  else
    echo "$user" >> "$FAILURE_LOG"
    echo "✗ FAILED: $user"
  fi
done

# Summary
echo "Successfully activated: $(wc -l < $SUCCESS_LOG) users"
echo "Failed activations: $(wc -l < $FAILURE_LOG) users"

# Review failures
if [ -s "$FAILURE_LOG" ]; then
  echo "Failed users:"
  cat "$FAILURE_LOG"

  # Investigate each failure
  for user in $(cat "$FAILURE_LOG"); do
    echo "=== Checking $user ==="
    ipa stageuser-show "$user" --all
  done
fi

6. External LDAP Integration for Staging

External identity system writes directly to staging container via LDAP.

# Create service account for external provisioning system
ipa service-add ldap/provisioning-system.example.com

# Grant write access to staging container
ipa permission-add "Write Staged Users" \
  --subtree="cn=staged users,cn=accounts,cn=provisioning,dc=example,dc=com" \
  --right=add \
  --right=write \
  --attrs=objectClass,uid,givenName,sn,cn,mail,telephoneNumber,title

ipa privilege-add "Provisioning System Access"
ipa privilege-add-permission "Provisioning System Access" \
  --permissions="Write Staged Users"

ipa role-add "Provisioning Service"
ipa role-add-privilege "Provisioning Service" \
  --privileges="Provisioning System Access"

ipa role-add-member "Provisioning Service" \
  --services=ldap/provisioning-system.example.com

# External system can now:
# 1. Bind with service credentials
# 2. Write user entries to staging container
# 3. IPA admins review and activate

# External system example (pseudocode):
# ldap_add("uid=newuser,cn=staged users,cn=accounts,cn=provisioning,dc=example,dc=com", {
#   objectClass: ["top", "person", "inetOrgPerson"],
#   uid: "newuser",
#   givenName: "New",
#   sn: "User",
#   mail: "newuser@example.com"
# })

7. Staged User Attribute Validation

Validate staged users before activation to prevent failures.

# Create validation script
cat > validate_staged_users.sh << 'EOF'
#!/bin/bash
ERRORS=0

for user in $(ipa stageuser-find --pkey-only | grep "User login:" | awk '{print $3}'); do
  echo "Validating: $user"

  # Check required attributes
  if ! ipa stageuser-show "$user" --all | grep -q "First name:"; then
    echo "  ERROR: Missing first name"
    ((ERRORS++))
  fi

  if ! ipa stageuser-show "$user" --all | grep -q "Last name:"; then
    echo "  ERROR: Missing last name"
    ((ERRORS++))
  fi

  if ! ipa stageuser-show "$user" --all | grep -q "Email:"; then
    echo "  WARNING: Missing email"
  fi

  # Check UID conflict
  if ipa user-find --login="$user" --all 2>/dev/null | grep -q "User login:"; then
    echo "  ERROR: Username already exists in active users"
    ((ERRORS++))
  fi
done

echo "Validation complete. Errors found: $ERRORS"
exit $ERRORS
EOF

chmod +x validate_staged_users.sh

# Run validation before batch activation
./validate_staged_users.sh
if [ $? -eq 0 ]; then
  echo "All staged users valid. Proceeding with activation..."
else
  echo "Validation errors found. Fix before activation."
fi

8. Migrating Active Users Back to Staging

Move active user back to staging for reconfiguration (unusual but possible).

# Scenario: User activated prematurely; needs reconfiguration
# Note: Direct user->staged move not supported by command
# Workaround: Preserve, delete, recreate in staging

# Disable and preserve user
ipa user-disable problemuser
ipa user-del --preserve problemuser

# Recreate in staging with corrections
ipa stageuser-add problemuser \
  --first=Correct \
  --last=Name \
  --email=correctemail@example.com

# Complete configuration
ipa stageuser-mod problemuser --title="Correct Title"

# Activate when ready
ipa stageuser-activate problemuser

# Note: This loses some metadata (creation date, etc.)
# Alternative: Modify active user directly if corrections simple

9. Pre-Provisioning Multiple Users from Template

Create multiple staged users based on template for similar roles.

# Template for data science team
create_ds_user() {
  local username=$1
  local firstname=$2
  local lastname=$3

  ipa stageuser-add "$username" \
    --first="$firstname" \
    --last="$lastname" \
    --email="${username}@example.com" \
    --title="Data Scientist" \
    --ou="Data Science" \
    --employeetype="fulltime" \
    --shell=/bin/bash \
    --homedir="/home/$username"

  # Add to standard groups
  ipa group-add-member data-scientists --stageusers="$username"
  ipa group-add-member engineering --stageusers="$username"

  echo "Created staged user: $username"
}

# Provision multiple users
create_ds_user "ds_alice" "Alice" "Johnson"
create_ds_user "ds_bob" "Bob" "Williams"
create_ds_user "ds_charlie" "Charlie" "Davis"

# Activate all on team start date
for user in ds_alice ds_bob ds_charlie; do
  ipa stageuser-activate "$user"
done

10. Auditing Staged Users for Stale Entries

Identify and clean up staged users never activated.

# List all staged users with creation dates
echo "=== Staged User Audit ===" > staged_audit.txt
for user in $(ipa stageuser-find --pkey-only | grep "User login:" | awk '{print $3}'); do
  echo "User: $user" >> staged_audit.txt
  ipa stageuser-show "$user" --all | grep -E "(Created on|Modified on)" >> staged_audit.txt
  echo "" >> staged_audit.txt
done

# Manual review of audit report
cat staged_audit.txt

# Identify users staged > 90 days ago (manual date comparison)
# Delete stale entries
ipa stageuser-del ancient_user1
ipa stageuser-del ancient_user2

# Or activate if valid
ipa stageuser-activate valid_but_old_user

# Establish policy: Staged users not activated within 30 days are deleted
# Implement periodic cleanup script

Security Considerations

1. Staged Users Bypass Some Security Controls

Staged users can be created without full validation checks applied to active users.

Password complexity policies may not be enforced until activation
UID/GID uniqueness not validated until activation (conflicts cause activation failure)
HBAC rules don’t apply to staged users (cannot authenticate anyway)
Staged users visible in LDAP; information disclosure if staging contains PII
Minimize data in staged users; add sensitive attributes after activation

2. Staging Container Write Access is Privileged

Write access to staging container enables account provisioning without full admin rights.

External systems with write access can create arbitrary user entries
Malicious or compromised external system could stage attackers’ accounts
Staging write access should require authentication and authorization
Audit all writes to staging container; log source system and submitter
Consider approval workflow even for automated staging

3. Activation is High-Privilege Operation

Activating staged users creates fully functional accounts.

Activation should require administrative privileges
Separate “staging writer” role from “activator” role for separation of duties
Activation grants immediate access if password/keys pre-configured
Require manual review before activation for sensitive environments
Log all activation operations with administrator identity

4. Username Squatting in Staging

Attacker with staging write access could squat desired usernames.

Create staged user with target username before legitimate user provisioned
Activation of legitimate user fails due to username conflict
Denial of service against new hire provisioning
Implement staging user review process
Delete or rename squatting accounts detected during validation

5. Attribute Injection During Staging

Staged users can have attributes set that may be dangerous when activated.

UID=0 in staging activates as root UID (IPA should prevent but verify)
Excessive group memberships grant immediate broad access upon activation
SSH keys or certificates added to staged user work immediately when activated
Review all staged user attributes before activation
Implement attribute validation rules for staging

6. Staged User Enumeration

Any authenticated user may enumerate staged users depending on permissions.

Staging container may be readable by all authenticated users
Leaked PII (names, emails, employee numbers) before user consents
Advance knowledge of new hires; insider trading or competitive intelligence
Restrict read access to staging container to provisioning team only
Minimize attributes set during staging; add details after activation

7. Prolonged Staging Creates Security Debt

Users remaining staged for months accumulate security risks.

Credentials configured but never tested; may not work when activated
User already departed before activation; dead account created
Attributes outdated (email changed, department changed, role changed)
Establish maximum staging duration (e.g., 30 days)
Periodic staged user audits to delete stale entries

8. External System Compromise Propagates to IPA

If external provisioning system compromised, attacker gains staging write access.

Attacker stages malicious accounts for later activation
Attributes injected could cause post-activation compromise
External system credentials (LDAP bind DN, password) must be protected
External system should use dedicated service principal, not shared admin account
Monitor staging container for anomalous entries (suspicious usernames, attributes)

9. Activation Failures Leave Inconsistent State

Failed activation may leave user partially migrated.

Entry moved but Kerberos principal creation failed
Group memberships updated but UID assignment failed
Requires manual cleanup to restore consistent state
Test activation in non-production environment first
Implement error handling and rollback for bulk activations

10. Staged Users Don’t Trigger Account Expiration Policies

Time-based policies don’t apply until activation.

User staged for 6 months, then activated; appears brand new to expiration policies
May violate password age policies or account review cycles
Set password expiration explicitly after activation if needed
Adjust account metadata (creation date) if organizational policy requires

11. Group Membership Pre-Configuration Privilege Escalation

Staged users can be added to administrative groups before activation.

Staged user added to “admins” group; activation grants immediate admin rights
No review of group memberships during activation
Attacker with staging write + activation could create admin account
Review group memberships during staged user validation
Prohibit adding staged users to high-privilege groups without approval

12. UID/GID Collisions After Delay

UIDs assigned at activation may conflict if another user created in interim.

Staged user A assigned UID 50000 in staging
Before activation, active user B assigned UID 50000
Activation of A fails with UID conflict
IPA detects this but requires manual resolution
Don’t hard-code UIDs in staged users; let IPA assign at activation
If UIDs must be pre-assigned, implement locking/reservation mechanism

13. Password Set in Staging May Violate Policy

Passwords set on staged users bypass password complexity checks.

Weak password set in staging accepted
Upon activation, weak password becomes active
User can authenticate with weak password until forced change
Enforce password policy checks even for staged users
Or require password reset on first login after activation

14. Staged User Deletion Has No Approval

Anyone with staging write access can delete staged users.

Accidental or malicious deletion of legitimate provisioning
No preserved/trash container for staged users
Deletion immediate and permanent
Implement audit logging for staged user deletions
Consider using preserved state instead of direct deletion for canceled provisioning

15. Mass Activation Without Validation

Bulk activation scripts may activate invalid or malicious accounts.

Scripted activation bypasses per-user review
Invalid attributes, UID conflicts, group assignments not caught until after activation
Malicious accounts activated without scrutiny
Implement validation checks in activation scripts
Require two-person rule for mass activations (one prepares, another approves)

Troubleshooting

1. Activation Fails - UID Already in Use

Symptom: stageuser-activate fails with “UID number already assigned” error.

Diagnosis:

# Check UID number in staged user
ipa stageuser-show username --all | grep "UID"

# Check if UID in use
ipa user-find --uid=1234567

# If found, another user has this UID

Resolution:

Remove UID from staged user; let IPA auto-assign at activation:

  # UID cannot be removed from staged user directly
  # Workaround: Delete and recreate without UID
  ipa stageuser-del username
  ipa stageuser-add username --first=... --last=...
  # Don't specify --uid

Or manually assign different UID:

  ipa stageuser-mod username --uid=1234999
  ipa stageuser-activate username

2. Cannot Find Staged User Just Created

Symptom: Created staged user but stageuser-find doesn’t show it.

Diagnosis:

# Verify creation succeeded
ipa stageuser-show username

# Check if accidentally created as active user instead
ipa user-show username

# Check replication if multi-master
ipa-replica-manage list

Resolution:

If user created as active user by mistake:

  ipa user-del --preserve username
  ipa stageuser-add username --first=... --last=...

If replication lag, wait 30-60 seconds and retry
Verify using correct container in LDAP:

  ldapsearch -x -b "cn=staged users,cn=accounts,cn=provisioning,dc=example,dc=com" uid=username

3. Staged User Missing Required Attributes for Activation

Symptom: Activation fails with “missing required attribute” error.

Diagnosis:

# Show all attributes
ipa stageuser-show username --all

# Check for givenName, sn, cn

Resolution:

Add missing required attributes:

  ipa stageuser-mod username --first=FirstName --last=LastName
  ipa stageuser-activate username

Required attributes: uid, givenName, sn (minimum)
Verify with stageuser-show --all before activation

4. Cannot Modify Staged User - Permission Denied

Symptom: stageuser-mod fails with permission error.

Diagnosis:

# Check current user permissions
ipa user-show $(ipa whoami) --all | grep "memberof role"

# Verify role has staging privileges
ipa role-show "Stage User Administrators" | grep privileges

Resolution:

User needs “Stage User Administrators” privilege or equivalent
Request admin to grant privileges:

  # As admin
  ipa role-add-member "Stage User Administrators" --users=username

Or use admin account for staging operations

5. Batch Activation Partially Fails

Symptom: Activated 50 users; 3 failed with errors.

Diagnosis:

# Review activation script output
grep -i "error\|fail" activation_output.log

# Check which users remain staged
ipa stageuser-find

# Investigate each failure
ipa stageuser-show failed_user1 --all

Resolution:

Common failures: UID conflict, username conflict, missing attributes
Fix each failed user:

  # UID conflict
  ipa stageuser-mod failed_user1 --uid=9999999

  # Missing attribute
  ipa stageuser-mod failed_user2 --email=user@example.com

  # Retry activation
  ipa stageuser-activate failed_user1
  ipa stageuser-activate failed_user2

Implement better validation before bulk activation

6. Activated User Cannot Log In

Symptom: Activation succeeded but user authentication fails.

Diagnosis:

# Verify user is active (not staged)
ipa user-show username

# Check password set
ipa user-show username --all | grep "Password"

# Verify Kerberos principal exists
ipa user-show username --all | grep "Principal"

# Test kinit
kinit username

Resolution:

If no password set, set one:

  ipa user-mod username --password

If Kerberos principal missing (rare):

  # Contact IPA administrator; may need manual principal creation

Check HBAC rules allow access:

  ipa hbactest --user=username --host=targethost --service=sshd

7. Staged User in Wrong Container

Symptom: User appears in wrong LDAP container.

Diagnosis:

# Show user DN
ipa stageuser-show username --all | grep "dn:"

# Should be: uid=username,cn=staged users,cn=accounts,cn=provisioning,...
# If different, user not in staging container

Resolution:

If user in active container:

  # Delete from active and recreate in staging
  ipa user-del --preserve username
  ipa stageuser-add username --first=... --last=...

If user in preserved container:

  ipa user-undel username  # Restore to active
  ipa user-del --preserve username
  ipa stageuser-add username --first=... --last=...

8. Cannot Delete Staged User

Symptom: stageuser-del fails with error.

Diagnosis:

# Verify user exists in staging
ipa stageuser-show username

# Check for group memberships
ipa group-find --stageusers=username

# Check error message details
ipa stageuser-del username 2>&1 | tee error.log

Resolution:

Remove from groups first:

  ipa group-remove-member groupname --stageusers=username

Then delete:

  ipa stageuser-del username

If still failing, check LDAP directly:

  ldapdelete -x -D "cn=Directory Manager" -W \
    "uid=username,cn=staged users,cn=accounts,cn=provisioning,dc=example,dc=com"

9. Staged User Has Different Attributes After Modification

Symptom: Modified staged user attribute but change didn’t take effect.

Diagnosis:

# Show user
ipa stageuser-show username --all

# Check for replication lag if multi-master
ssh ipa02.example.com
ipa stageuser-show username --all

Resolution:

Wait for replication (30-60 seconds)
Verify modification command succeeded:

  ipa stageuser-mod username --email=new@example.com
  # Should show: "Modified stage user 'username'"

Check for command typos or syntax errors
Force replication if needed:

  ipa-replica-manage force-sync --from=ipa01.example.com

10. Group Membership Not Carrying Over After Activation

Symptom: Added staged user to group but after activation user not in group.

Diagnosis:

# Before activation, check group membership
ipa group-show groupname | grep "stage users"

# After activation, check if user in group
ipa group-show groupname | grep "Member users"

Resolution:

Group memberships should carry over automatically
If not, manually add after activation:

  ipa group-add-member groupname --users=username

Verify before activation:

  ipa group-show groupname --all

11. Staged User Search Returns No Results

Symptom: stageuser-find --employeetype=contractor returns no results but staged contractors exist.

Diagnosis:

# List all staged users
ipa stageuser-find

# Check specific user's attribute
ipa stageuser-show contractor1 --all | grep employeeType

Resolution:

Attribute name is case-sensitive: try --employeetype and --employeeType
Attribute value may differ: contractor vs Contractor
Use criteria search instead:

  ipa stageuser-find contractor

Or show all and manually filter:

  ipa stageuser-find --all | grep -i contractor

12. Cannot Add Staged User to Group

Symptom: group-add-member --stageusers=username fails.

Diagnosis:

# Verify staged user exists
ipa stageuser-show username

# Verify group exists
ipa group-show groupname

# Check exact error
ipa group-add-member groupname --stageusers=username 2>&1

Resolution:

Ensure using --stageusers not --users:

  # Correct
  ipa group-add-member engineers --stageusers=alice

  # Wrong (won't find staged user)
  ipa group-add-member engineers --users=alice

User must be in staging container, not active
Group must allow user membership (user groups, not host groups, etc.)

13. Activated User Has Wrong UID

Symptom: After activation, user has unexpected UID number.

Diagnosis:

# Check UID
ipa user-show username | grep UID

# Check if UID was pre-specified in staging
# (requires checking historical data or re-staging)

Resolution:

UIDs assigned at activation from ID range if not pre-specified
If wrong, cannot change UID of active user (POSIX limitation)
Workaround: Preserve user, delete, recreate with correct UID:

  ipa user-del --preserve username
  ipa user-del username  # Permanent delete from preserved
  ipa stageuser-add username --uid=500123 --first=... --last=...
  ipa stageuser-activate username

Note: This loses group memberships, roles, etc.
Alternative: Leave UID as-is if system tolerates

14. External System Cannot Write to Staging Container

Symptom: External provisioning system gets permission denied when writing staged users via LDAP.

Diagnosis:

# Check service principal exists
ipa service-show ldap/provisioning.example.com

# Verify permissions granted
ipa permission-find "staged users"

# Check role membership
ipa role-show "Provisioning Service" | grep services

Resolution:

Grant write permissions to staging container:

  ipa permission-add "Write Staged Users" \
    --subtree="cn=staged users,cn=accounts,cn=provisioning,dc=example,dc=com" \
    --right=add --right=write \
    --attrs=objectClass,uid,givenName,sn,cn,mail

  ipa privilege-add-permission "Provisioning Privilege" \
    --permissions="Write Staged Users"

  ipa role-add-privilege "Provisioning Service" \
    --privileges="Provisioning Privilege"

  ipa role-add-member "Provisioning Service" \
    --services=ldap/provisioning.example.com

Verify external system using correct bind credentials
Check firewall allows LDAP (389/tcp, 636/tcp) from external system

15. Confusion Between Active and Staged Users with Same Username

Symptom: Active user “alice” and staged user “alice” both exist; unclear which is which.

Diagnosis:

# Check active user
ipa user-show alice

# Check staged user
ipa stageuser-show alice

# Both can exist simultaneously

Resolution:

This is allowed by design (e.g., re-provisioning existing user)
Use specific commands for each:
- Active user: ipa user-* commands
- Staged user: ipa stageuser-* commands
Cannot activate staged user if active user with same name exists:

  ipa stageuser-activate alice
  # Error: user already exists

Rename one user:

  ipa user-mod alice --rename=alice-old
  ipa stageuser-activate alice

Commands

stageuser-activate

Usage: ipa [global-options] stageuser-activate LOGIN [options]

Activate a stage user.

Arguments

Argument	Required	Description
`LOGIN`	yes	User login

Options

Option	Description
`--all`	Retrieve and print all attributes from the server. Affects command output.
`--raw`	Print entries as stored on the server. Only affects output format.
`--no-members`	Suppress processing of membership attributes.

stageuser-add

Usage: ipa [global-options] stageuser-add LOGIN [options]

Add a new stage user.

Arguments

Argument	Required	Description
`LOGIN`	yes	User login

Options

Option	Description
`--first FIRST`	First name
`--last LAST`	Last name
`--cn CN`	Full name
`--displayname DISPLAYNAME`	Display name
`--initials INITIALS`	Initials
`--homedir HOMEDIR`	Home directory
`--gecos GECOS`	GECOS
`--shell SHELL`	Login shell
`--principal PRINCIPAL`	Principal alias
`--principal-expiration PRINCIPAL-EXPIRATION`	Kerberos principal expiration
`--password-expiration PASSWORD-EXPIRATION`	User password expiration
`--email EMAIL`	Email address
`--password PASSWORD`	Prompt to set the user password
`--random`	Generate a random user password
`--uid UID`	User ID Number (system will assign one if not provided)
`--gidnumber GIDNUMBER`	Group ID Number
`--street STREET`	Street address
`--city CITY`	City
`--state STATE`	State/Province
`--postalcode POSTALCODE`	ZIP
`--phone PHONE`	Telephone Number
`--mobile MOBILE`	Mobile Telephone Number
`--pager PAGER`	Pager Number
`--fax FAX`	Fax Number
`--orgunit ORGUNIT`	Org. Unit
`--title TITLE`	Job Title
`--manager MANAGER`	Manager
`--carlicense CARLICENSE`	Car License
`--sshpubkey SSHPUBKEY`	SSH public key
`--user-auth-type USER-AUTH-TYPE`	Types of supported user authentication
`--class CLASS`	User category (semantics placed on this attribute are for local interpretation)
`--radius RADIUS`	RADIUS proxy configuration
`--radius-username RADIUS-USERNAME`	RADIUS proxy username
`--idp IDP`	External IdP configuration
`--idp-user-id IDP-USER-ID`	A string that identifies the user at external IdP
`--departmentnumber DEPARTMENTNUMBER`	Department Number
`--employeenumber EMPLOYEENUMBER`	Employee Number
`--employeetype EMPLOYEETYPE`	Employee Type
`--preferredlanguage PREFERREDLANGUAGE`	Preferred Language
`--certificate CERTIFICATE`	Base-64 encoded user certificate
`--setattr SETATTR`	Set an attribute to a name/value pair. Format is attr=value.
`--addattr ADDATTR`	Add an attribute/value pair. Format is attr=value. The attribute
`--all`	Retrieve and print all attributes from the server. Affects command output.
`--raw`	Print entries as stored on the server. Only affects output format.
`--no-members`	Suppress processing of membership attributes.

stageuser-add-cert

Usage: ipa [global-options] stageuser-add-cert LOGIN [options]

Add one or more certificates to the stageuser entry

Arguments

Argument	Required	Description
`LOGIN`	yes	User login

Options

Option	Description
`--all`	Retrieve and print all attributes from the server. Affects command output.
`--raw`	Print entries as stored on the server. Only affects output format.
`--no-members`	Suppress processing of membership attributes.
`--certificate CERTIFICATE`	Base-64 encoded user certificate

stageuser-add-certmapdata

Usage: ipa [global-options] stageuser-add-certmapdata LOGIN [CERTMAPDATA] [options]

Add one or more certificate mappings to the stage user entry.

Arguments

Argument	Required	Description
`LOGIN`	yes	User login

CERTMAPDATA no Certificate mapping data

Options

Option	Description
`--issuer ISSUER`	Issuer of the certificate
`--subject SUBJECT`	Subject of the certificate
`--certificate CERTIFICATE`	Base-64 encoded user certificate
`--all`	Retrieve and print all attributes from the server. Affects command output.
`--raw`	Print entries as stored on the server. Only affects output format.
`--no-members`	Suppress processing of membership attributes.

stageuser-add-manager

Usage: ipa [global-options] stageuser-add-manager LOGIN [options]

Add a manager to the stage user entry

Arguments

Argument	Required	Description
`LOGIN`	yes	User login

Options

Option	Description
`--all`	Retrieve and print all attributes from the server. Affects command output.
`--raw`	Print entries as stored on the server. Only affects output format.
`--no-members`	Suppress processing of membership attributes.
`--users USERS`	users to add

stageuser-add-passkey

Usage: ipa [global-options] stageuser-add-passkey LOGIN PASSKEY [options]

Add one or more passkey mappings to the stage user entry.

Arguments

Argument	Required	Description
`LOGIN`	yes	User login

PASSKEY yes Passkey mapping

Options

Option	Description
`--all`	Retrieve and print all attributes from the server. Affects command output.
`--raw`	Print entries as stored on the server. Only affects output format.
`--no-members`	Suppress processing of membership attributes.

stageuser-add-principal

Usage: ipa [global-options] stageuser-add-principal LOGIN [PRINCIPAL] [options]

Add new principal alias to the stageuser entry

Arguments

Argument	Required	Description
`LOGIN`	yes	User login

PRINCIPAL no Principal alias

Options

Option	Description
`--all`	Retrieve and print all attributes from the server. Affects command output.
`--raw`	Print entries as stored on the server. Only affects output format.
`--no-members`	Suppress processing of membership attributes.

stageuser-del

Usage: ipa [global-options] stageuser-del LOGIN [options]

Delete a stage user.

Arguments

Argument	Required	Description
`LOGIN`	yes	User login

Options

Option	Description
`--continue`	Continuous mode: Don’t stop on errors.

stageuser-find

Usage: ipa [global-options] stageuser-find [CRITERIA] [options]

Search for stage users.

Arguments

Argument Required Description

CRITERIA no A string searched in all relevant object attributes

Options

Option	Description
`--login LOGIN`	User login
`--first FIRST`	First name
`--last LAST`	Last name
`--cn CN`	Full name
`--displayname DISPLAYNAME`	Display name
`--initials INITIALS`	Initials
`--homedir HOMEDIR`	Home directory
`--gecos GECOS`	GECOS
`--shell SHELL`	Login shell
`--principal PRINCIPAL`	Principal alias
`--principal-expiration PRINCIPAL-EXPIRATION`	Kerberos principal expiration
`--password-expiration PASSWORD-EXPIRATION`	User password expiration
`--email EMAIL`	Email address
`--password PASSWORD`	Prompt to set the user password
`--uid UID`	User ID Number (system will assign one if not provided)
`--gidnumber GIDNUMBER`	Group ID Number
`--street STREET`	Street address
`--city CITY`	City
`--state STATE`	State/Province
`--postalcode POSTALCODE`	ZIP
`--phone PHONE`	Telephone Number
`--mobile MOBILE`	Mobile Telephone Number
`--pager PAGER`	Pager Number
`--fax FAX`	Fax Number
`--orgunit ORGUNIT`	Org. Unit
`--title TITLE`	Job Title
`--manager MANAGER`	Manager
`--carlicense CARLICENSE`	Car License
`--user-auth-type USER-AUTH-TYPE`	Types of supported user authentication
`--class CLASS`	User category (semantics placed on this attribute are for local interpretation)
`--radius RADIUS`	RADIUS proxy configuration
`--radius-username RADIUS-USERNAME`	RADIUS proxy username
`--idp IDP`	External IdP configuration
`--idp-user-id IDP-USER-ID`	A string that identifies the user at external IdP
`--departmentnumber DEPARTMENTNUMBER`	Department Number
`--employeenumber EMPLOYEENUMBER`	Employee Number
`--employeetype EMPLOYEETYPE`	Employee Type
`--preferredlanguage PREFERREDLANGUAGE`	Preferred Language
`--certificate CERTIFICATE`	Base-64 encoded user certificate
`--smb-logon-script SMB-LOGON-SCRIPT`	SMB logon script path
`--smb-profile-path SMB-PROFILE-PATH`	SMB profile path
`--smb-home-dir SMB-HOME-DIR`	SMB Home Directory
`--smb-home-drive SMB-HOME-DRIVE`	SMB Home Directory Drive
`--timelimit TIMELIMIT`	Time limit of search in seconds (0 is unlimited)
`--sizelimit SIZELIMIT`	Maximum number of entries returned (0 is unlimited)
`--all`	Retrieve and print all attributes from the server. Affects command output.
`--raw`	Print entries as stored on the server. Only affects output format.
`--pkey-only`	Results should contain primary key attribute only (“login”)
`--in-groups IN-GROUPS`	Search for stage users with these member of groups.
`--not-in-groups NOT-IN-GROUPS`	Search for stage users without these member of groups.
`--in-netgroups IN-NETGROUPS`	Search for stage users with these member of netgroups.
`--not-in-netgroups NOT-IN-NETGROUPS`	Search for stage users without these member of netgroups.
`--in-roles IN-ROLES`	Search for stage users with these member of roles.
`--not-in-roles NOT-IN-ROLES`	Search for stage users without these member of roles.
`--in-hbacrules IN-HBACRULES`	Search for stage users with these member of HBAC rules.
`--not-in-hbacrules NOT-IN-HBACRULES`	Search for stage users without these member of HBAC rules.
`--in-sudorules IN-SUDORULES`	Search for stage users with these member of sudo rules.
`--not-in-sudorules NOT-IN-SUDORULES`	Search for stage users without these member of sudo rules.
`--in-subids IN-SUBIDS`	Search for stage users with these member of Subordinate ids.
`--not-in-subids NOT-IN-SUBIDS`	Search for stage users without these member of Subordinate ids.

stageuser-mod

Usage: ipa [global-options] stageuser-mod LOGIN [options]

Modify a stage user.

Arguments

Argument	Required	Description
`LOGIN`	yes	User login

Options

Option	Description
`--first FIRST`	First name
`--last LAST`	Last name
`--cn CN`	Full name
`--displayname DISPLAYNAME`	Display name
`--initials INITIALS`	Initials
`--homedir HOMEDIR`	Home directory
`--gecos GECOS`	GECOS
`--shell SHELL`	Login shell
`--principal PRINCIPAL`	Principal alias
`--principal-expiration PRINCIPAL-EXPIRATION`	Kerberos principal expiration
`--password-expiration PASSWORD-EXPIRATION`	User password expiration
`--email EMAIL`	Email address
`--password PASSWORD`	Prompt to set the user password
`--random`	Generate a random user password
`--uid UID`	User ID Number (system will assign one if not provided)
`--gidnumber GIDNUMBER`	Group ID Number
`--street STREET`	Street address
`--city CITY`	City
`--state STATE`	State/Province
`--postalcode POSTALCODE`	ZIP
`--phone PHONE`	Telephone Number
`--mobile MOBILE`	Mobile Telephone Number
`--pager PAGER`	Pager Number
`--fax FAX`	Fax Number
`--orgunit ORGUNIT`	Org. Unit
`--title TITLE`	Job Title
`--manager MANAGER`	Manager
`--carlicense CARLICENSE`	Car License
`--sshpubkey SSHPUBKEY`	SSH public key
`--user-auth-type USER-AUTH-TYPE`	Types of supported user authentication
`--class CLASS`	User category (semantics placed on this attribute are for local interpretation)
`--radius RADIUS`	RADIUS proxy configuration
`--radius-username RADIUS-USERNAME`	RADIUS proxy username
`--idp IDP`	External IdP configuration
`--idp-user-id IDP-USER-ID`	A string that identifies the user at external IdP
`--departmentnumber DEPARTMENTNUMBER`	Department Number
`--employeenumber EMPLOYEENUMBER`	Employee Number
`--employeetype EMPLOYEETYPE`	Employee Type
`--preferredlanguage PREFERREDLANGUAGE`	Preferred Language
`--certificate CERTIFICATE`	Base-64 encoded user certificate
`--smb-logon-script SMB-LOGON-SCRIPT`	SMB logon script path
`--smb-profile-path SMB-PROFILE-PATH`	SMB profile path
`--smb-home-dir SMB-HOME-DIR`	SMB Home Directory
`--smb-home-drive SMB-HOME-DRIVE`	SMB Home Directory Drive
`--setattr SETATTR`	Set an attribute to a name/value pair. Format is attr=value.
`--addattr ADDATTR`	Add an attribute/value pair. Format is attr=value. The attribute
`--delattr DELATTR`	Delete an attribute/value pair. The option will be evaluated
`--rights`	Display the access rights of this entry (requires —all). See ipa man page for details.
`--all`	Retrieve and print all attributes from the server. Affects command output.
`--raw`	Print entries as stored on the server. Only affects output format.
`--no-members`	Suppress processing of membership attributes.
`--rename RENAME`	Rename the stage user object

stageuser-remove-cert

Usage: ipa [global-options] stageuser-remove-cert LOGIN [options]

Remove one or more certificates to the stageuser entry

Arguments

Argument	Required	Description
`LOGIN`	yes	User login

Options

Option	Description
`--all`	Retrieve and print all attributes from the server. Affects command output.
`--raw`	Print entries as stored on the server. Only affects output format.
`--no-members`	Suppress processing of membership attributes.
`--certificate CERTIFICATE`	Base-64 encoded user certificate

stageuser-remove-certmapdata

Usage: ipa [global-options] stageuser-remove-certmapdata LOGIN [CERTMAPDATA] [options]

Remove one or more certificate mappings from the stage user entry.

Arguments

Argument	Required	Description
`LOGIN`	yes	User login

CERTMAPDATA no Certificate mapping data

Options

Option	Description
`--issuer ISSUER`	Issuer of the certificate
`--subject SUBJECT`	Subject of the certificate
`--certificate CERTIFICATE`	Base-64 encoded user certificate
`--all`	Retrieve and print all attributes from the server. Affects command output.
`--raw`	Print entries as stored on the server. Only affects output format.
`--no-members`	Suppress processing of membership attributes.

stageuser-remove-manager

Usage: ipa [global-options] stageuser-remove-manager LOGIN [options]

Remove a manager to the stage user entry

Arguments

Argument	Required	Description
`LOGIN`	yes	User login

Options

Option	Description
`--all`	Retrieve and print all attributes from the server. Affects command output.
`--raw`	Print entries as stored on the server. Only affects output format.
`--no-members`	Suppress processing of membership attributes.
`--users USERS`	users to remove

stageuser-remove-passkey

Usage: ipa [global-options] stageuser-remove-passkey LOGIN PASSKEY [options]

Remove one or more passkey mappings from the stage user entry.

Arguments

Argument	Required	Description
`LOGIN`	yes	User login

PASSKEY yes Passkey mapping

Options

Option	Description
`--all`	Retrieve and print all attributes from the server. Affects command output.
`--raw`	Print entries as stored on the server. Only affects output format.
`--no-members`	Suppress processing of membership attributes.

stageuser-remove-principal

Usage: ipa [global-options] stageuser-remove-principal LOGIN [PRINCIPAL] [options]

Remove principal alias from the stageuser entry

Arguments

Argument	Required	Description
`LOGIN`	yes	User login

PRINCIPAL no Principal alias

Options

Option	Description
`--all`	Retrieve and print all attributes from the server. Affects command output.
`--raw`	Print entries as stored on the server. Only affects output format.
`--no-members`	Suppress processing of membership attributes.

stageuser-show

Usage: ipa [global-options] stageuser-show LOGIN [options]

Display information about a stage user.

Arguments

Argument	Required	Description
`LOGIN`	yes	User login

Options

Option	Description
`--rights`	Display the access rights of this entry (requires —all). See ipa man page for details.
`--all`	Retrieve and print all attributes from the server. Affects command output.
`--raw`	Print entries as stored on the server. Only affects output format.
`--no-members`	Suppress processing of membership attributes.