Modifying an Identity: Failed to verify if user can act on type 'user'

Doing some testing with Hyperledfer Fabric, I'm doing the task of creating a new identity with a wrong type, to then practice modifying the identity. However, when I execute:

fabric-ca-client register \
--id.name peer2 \
--id.affiliation org1 \
--id.type user \
--id.secret 'IAMPEER2!' \
-u http://Org1Administrator:Org1Rocks@localhost:7054

I get:

2022/04/13 20:16:05 [INFO] Configuration file location: 
/etc/hyperledger/fabric-ca-server/fabric-ca-client-config.yaml
Error: Response from server: Error Code: 45 - Failed to verify if user
 can act on type 'user': : scode: 403, local code: 42, local msg: 'peer1' is not a registrar, 
remote code: 71, remote msg: Authorization failure

I was able to register identity previously with no problems. I don't see why it's not allowing me to register an identity of type user. I've checked fabric-ca-client-config.yaml and I see no restrains to do so:

#############################################################################
#  Registration section used to register a new identity with fabric-ca server
#
#  name - Unique name of the identity
#  type - Type of identity being registered (e.g. 'peer, app, user')
#  affiliation - The identity's affiliation
#  maxenrollments - The maximum number of times the secret can be reused to enroll.
#                   Specially, -1 means unlimited; 0 means to use CA's max enrollment
#                   value.
#  attributes - List of name/value pairs of attribute for identity
#############################################################################
id:
  name:
  type:
  affiliation:
  maxenrollments: 0
  attributes:
   # - name:
   #   value:

Any ideas?

So the key element to check was:

'peer1' is not a registrar

I was running within the fabric-ca-server container, and the last enrolled user was of type: peer, not admin.

The solution to this problem was to enroll again with an Admin user.

That's usually the first user registered when setting up the CA server. This led me to think that the last enrolled user acts as current user under which subsequent commands are executed. I was not aware of this behavior.