Hyperledger Composer: fabric-ca request register failed with errors after machine restart - hyperledger-composer

I had a composer-rest-server running on a host. Due to some reason I had to reboot my aws instance. So I stopped all the fabric docker containers except the chaincode and also stopped the composer rest server.
After rebooting the machine, I restarted all the containers. At this time the chaincode container did not start. However, I issued a ping command with admin identity card and the chaincode container too started.
Next, I restarted the composer rest server with the same admin identity. However, when I tried to issue an "identitiy request" command for a participant it resulted in:
Unhandled error for request POST /api/system/identities/issue: Error: fabric-ca request register failed with errors [[{"code":20,"message":"Authorization failure"}]]
Does it mean the old admin identities are invalidated after a system restart?

This is occurring because when the AWS instance reboots, the identity data within the fabric-ca container is cleared (the container uses sqlite for an ephemeral data store).
If you instead setup the fabric-ca container to use a mysql or postgresql db container, you will be able to persist the identity data even after machine/container restarts.
This question also pertains to your situation as well Hyperledger Composer Identity Issue error after network restart (code:20, authorization failure)

This error is usually seen when you try and Issue a New Identity whilst using an Identity that does not have the rights to do so.
(If you are in single user mode the card you started the REST server with does not have the rights, or if in Multi-User mode the card currently being used in the Wallet does not have the rights.)
The Network Admin card initially created to administer the network has the rights to Issue New identities, and if you want to create additional Identities (Cards) that have the right you need to give them issuer rights when you create them. This is an option you use when Issuing an identity. On the CLI you would use a command such as composer identity issue -c admin#my-network --issuer -u mynewuser ...
On the REST server you would include an option in the JSON data e.g.:
{
"participant" : "org.acme.mynetwork.Manager#MGR02",
"userID" : "BrianM",
"options": {"issuer":true}
}

Related

Use gMSA for Hashicorp Vault mssql credential rotation

I want to start using Vault to rotate credentials for mssql databases, and I need to be able to use a gMSA in my mssql connection string. My organization currently only uses Windows servers and will only provide gMSAs for service accounts.
Specifying the gMSA as the user id in the connection string returns the 400 error error creating database object: error verifying connection: InitialBytes InitializeSecurityContext failed 8009030c.
I also tried transitioning my vault services to use the gMSA as their log on user, but this made nodes unable to become a leader node even though they were able to join the cluster and forward requests.
My setup:
I have a Vault cluster running across a few Windows servers. I use nssm to run them as a Windows service since there is no native Windows service support.
nssm is configured to run vault server -config="C:\vault\config.hcl" and uses the Local System account to run under.
When I change the user, the node is able to start up and join the raft cluster as a follower, but can not obtain leader status, which causes my cluster to become unresponsive once the Local System user nodes are off.
The servers are running on Windows Server 2022 and Vault is at v1.10.3, using integrated raft storage. I have 5 vault nodes in my cluster.
I tried running the following command to configure my database secret engine:
vault write database/config/testdb \
connection_url='server=myserver\testdb;user id=domain\gmsaUser;database=mydb;app name=vault;' \
allowed_roles="my-role"
which caused the error message I mentioned above.
I then tried to change the log on user for the service. I followed these steps to rotate the user:
Updated the directory permissions for everywhere vault is touching (configs, certificates, storage) to include my gMSA user. I gave it read permissions for the config and certificate files and read/write for storage.
Stopped the service
Removed the node as a peer from the cluster using vault operator raft remove-peer instanceName.
Deleted the old storage files
Changed the service user by running sc.exe --% config "vault" obj="domain\gmsaUser" type= own.
Started the service back up and waited for replication
When I completed the last step, I could see the node reappear as a voter in the Vault UI. I was able to directly hit the node using the cli and ui and get a response. This is not an enterprise cluster, so this should have just forwarded the request to the leader, confirming that the clustering portion was working.
Before I got to the last node, I tried running vault operator step-down and was never able to get the leader to rotate. Turning off the last node made the cluster unresponsive.
I did not expect changing the log on user to cause any issue with node's ability to operate. I reviewed the logs but there was nothing out of the ordinary, even by setting the log level to trace. They do show successful unseal, standby mode, and joining the raft cluster.
Most of the documentation I have found for the mssql secret engine includes creating a user/pass at the sql server for Vault to use, which is not an option for me. Is there any way I can use the gMSA in my mssql config?
When you put user id into the SQL connection string it will try to do SQL authentication and no longer try windows authentication (while gMSA is a windows authentication based).
When setting up the gMSA account did you specify the correct parameter for who is allowed to retrieve the password (correct: PrincipalsAllowedToRetrieveManagedPassword, incorrect but first suggestion when using tab completion PrincipalsAllowedToDelegateToAccount)
maybe you need to Install-ADServiceAccount ... on the machine you're running vault on

Windows Service account login failure

I installed a custom windows service on a new VM in a new environment and I am unable to ge tit to start using the domain service account. The service in question has been installed successfully on numerous other VMs (using Win server 2008, and recently, Win Server 2012 R2). In all cases, after installing successfully using the default Local System Account, and verifying that the service starts up successfully using that account, I modify the start up account to use a specified domain account as this service needs to be able to communicate with a SQL server as well as read and write from t/from various network shares.
This time, after setting up the new Win Server 2012 R2 VM, installing the service, checking that it starts ok using Local system account, and then changing the start up to use my designated service account, when I try to start the service it fails with an error:
"Error 1069: The service did not start due to a logon failure."
I checked the credentials by using them to RDP into this VM. It was successful, so I have the correct account and password.
I checked the event log, and saw an error in the Windows Application Log:
"Could not write to AD. Error 0x80070032."
When I googled this, it took me to this page Error Page, which seems to be describing a scenario where there was failure saving a changed password, but no one has changed the password on this account as it is a service account it is set to never expire...
Any ideas??

identity expired error while doing composer network ping

Long time back I have created a composer network by using composer version 0.19.0. Now when I am trying to ping the network using following command getting this error.
composer network ping --card admin#tutorial-network
output :Error: Error trying to ping. Error: 2 UNKNOWN: identity expired
Please help me how to resolve this issue.
Do you have any other identities registered (and thus have cards in your card store) with your business network which haven't expired ? If you don't then you are locked out of your business network. If you do but they don't have the appropriate ACLS to perform things like identity management (composer identity issue/bind etc) then so long as you have a card that doesn't have an expired identity that can perform install/upgrade you could upgrade your business network to provide required ACLs for that participant to be able to do identity management.
I had same issue today and solved like below.
First you need to delete that card using this command.
composer card delete
Then you can add a new card. (You have a .bna file at the same directory) Use this command below for importing new card.
composer card import --file networkadmin.card
You can ping successfully.
composer network ping --card admin#cardName
I hope this will solve your problem. Then you can start the rest server with below code.
composer-rest-server

Querying the Historian seems to kill business network

I am on composer 0.16.0 and Fabric 1.0.4
While experimenting with Historian queries via composer-client consistently run into a situation when the network becomes non-responsive and the only way to reanimate it seems to be restarting the Fabric and redeploying the network.
The error follows:
>
Error: Error trying to ping. Error: Error trying to query business network. Error: chaincode error (status: 500, message: Error: The current identity has not been registered: admin)
>
So, the questions are:
1. Is this a known issue and is there a workaround? Happy to do more diagnostics and file it properly if that helps.
2. Any way to reboot the network without restarting the Fabric?
Thank you!
so the error "The current identity has not been registered: admin" is fundamentally caused by the fact you are restarting your CA server each time - ie a new CA server, a new authority issuing new credentials effectively for 'admin' (and hence your present admin credentials from 'previous' in your card store are not recognised by the new CA server).
Suggest to
1) clear out old admin cards from your card store eg. composer card delete --name admin#tutorial-network
2) re-import your 'admin' card through playground or CLI - and do a composer network ping to retrieve credentials to the card store.
3) Reduce your Historian queries result sets by adding selection criteria
Note: To restart your existing Dev Fabric - just use docker stop to stop your containers - and docker start you can restart them from the same state (or use docker-compose stop and docker-compose start if you're familiar with that command). Else, use docker persistence to persist your data.
https://hyperledger.github.io/composer/tutorials/developer-tutorial.html
Probably good to

Recovering RDP access to potentially compromised GCE Windows 2008 R2 server

I have a Windows 2008R2 server in GCE that is behaving oddly (may be compromised). I can no longer access it via RDP. When I reboot the machine and look at the serial console, I see at the very bottom after the boot sequence, that something called Credentials Manager runs and appears to delete or change some username/password. I suspect that this is what is changing the RDP password. (see image attached). On a normally running Windows VM, I do not see this in the trace.
GCE Agent started.
Starting AddressManager
Starting CredentialsManager
Credentials have changed. Updating...
Changing username...
Deleting old user...
Username or password was updated successfully.```
I have tried resetting or adding a new password using the metadata windows-startup-script-cmd = net user but that does not seem to do anything.
What I get is an error message of the form:
Booting on date 05/05/2015 10:22:49
WARNING: Computer Name windows does not match Compute Engine Instance Name XXXXX.
Did you forget to run gcesysprep?
attributes/windows-startup-script-bat value is not set or metadata server is not reachable.
attributes/windows-startup-script-ps1 value is not set or metadata server is not reachable.
So the question is, how can I get into the machine to see what is happening? Is there a way that the GCE startup sequence could be changed to not call the credential manager to change the password or username?
What you could do is if you have a Gcloud SDK (https://cloud.google.com/compute/docs/gcloud-compute/) installed, you can run the following command while that instance is running:
gcloud compute instances decribe instance_name
This will provide all the information about the instance and you will see a section called MetaData which will display the users and the passwords. Then you can try to remote in and remove any credentials setup in the Credentials Manager located in Control Panel -> User Accounts.
I hope this give you access to your VM

Resources