ever seen this in configtx.yaml and wondered what it means?

# If your MSP is configured with the new NodeOUs, you might
# want to use a more specific rule like the following:
# Rule: "OR('SampleOrg.admin', 'SampleOrg.peer', 'SampleOrg.client')"

Let me try to explain. Taking this example in configtx.yaml:

What this is saying is in order to read (don’t ask me read what as I don’t know) the caller should be one (or more) of:

• An admin of Org1
• A peer of Org1
• A client of Org1

How will Fabric decide if any of these conditions is true? It happens as follows:

1. The Genesis block contains the MSP information of Org1 as was defined in the configtx.yaml file. That folder basically gets copied into the Genesis block by the configtxgen utility.
2. If the caller’s X.509 certificate matches any certificate stored under admincerts folder of the MSP directory of Org1, then caller is deemed an admin of Org1
3. If the caller’s X.509 certificate is issued by a CA that is listed under the cacerts or intermediatecerts folder of the MSP directory of Org1, then caller is a member of Org1

1. If further, the caller’s X.509 certificate has OU=peer set in the Subject field then caller is deemed a peer of Org1
2. Or if the caller’s X.509 certificate has OU=client set in the Subject field then caller is deemed a client of Org1

Using the Node OUs ‘Org1MSP.peer’, ‘Org1MSP.client’ allows us to specify a more fine grained filter than just Org1MSP.member. That is what the Node OUs are about. You would set OU=peer on the certs used to bootstrap the peer nodes. The certs used to bootstrap orderer nodes would have OU=orderer set on them. And the users of the organization (these are people like Alice and Bob) will have OU=client set in their certificates. To show an example:

Subject: C=US, ST=California, L=San Francisco, OU=orderer, CN=orderer0.foo.com

To activate the Node OUs requires some steps which have to be done per organization:

1. Normally the MSP dir passed to configtx.yaml has following 5 folders in it: cacerts, tlscacerts and admincerts are mandatory and intermediatecerts and tlsintermediatecerts are optional. You need to add a config.yaml under the MSP dir that looks like:
   NodeOUs:
   Enable: true
   ClientOUIdentifier:
   Certificate: cacerts/ca-cert.pem
   OrganizationalUnitIdentifier: client
   PeerOUIdentifier:
   Certificate: cacerts/ca-cert.pem
   OrganizationalUnitIdentifier: peer
   AdminOUIdentifier:
   Certificate: cacerts/ca-cert.pem
   OrganizationalUnitIdentifier: admin
   OrdererOUIdentifier:
   Certificate: cacerts/ca-cert.pem
   OrganizationalUnitIdentifier: orderer
2. The cryptogen tool (v1.4.3) will generate this file automatically if EnableNodeOUs: true is set in its yaml config. But remember cryptogen will never be used in practice (guess why)

Notes:

1. According to https://hyperledger-fabric.readthedocs.io/en/release-1.4/msp.html the four OUs are supposed to be exclusive i.e., you should only set one of them in the X.509 certificate:
   

   Identities can use organizational units to be classified as either a client, an admin, a peer, or an orderer. The four classifications are mutually exclusive. The 1.1 channel capability needs to be enabled before identities can be classified as clients or peers. The 1.4.3 channel capability needs to be enabled for identities to be classified as an admin or orderer.

This means one also needs following section in configtx.yaml for Node OUs to take effect:

2. Note that support for the orderer Node OU was only added in v1.4.3 of Fabric. See https://jira.hyperledger.org/browse/FAB-12620

3. And there is no support for admin Node OU on the backend. See https://jira.hyperledger.org/browse/FAB-15388 and look at my note:

I am trying to understand rationale of this task. Doesn’t Fabric currently identify administrators by checking if the cert of the caller matches one of the certs stored in the `admincerts` folder in the msp dir? If so, wouldn’t there be a conflict and overlap in identifying administrators if the admins are now identified depending if the caller has `OU=admin` set in their X.509 cert (as this task suggests). Maybe I am missing something?

Two Updates:

1. https://jira.hyperledger.org/browse/FAB-16376 provides the answer to the question above. Admin OU support: When Admin OU is enabled, admins should be identified by either OU or admincerts directory. Sadly it is not implemented yet. So until its implemented OU=admin will have no effect.
2. Watch out for these two bugs in cryptogen 1.4.3
   https://jira.hyperledger.org/browse/FAB-16933
   https://jira.hyperledger.org/browse/FAB-16936