Insufficient access rights to perform the operation error in Azure AD Connect

Hello team,

If you're getting Insufficient access rights to operate your Azure AD Connect synchronization logs, do the following:


STEP 1 - Make sure you have the latest version of Azure AD Connect installed: https://www.microsoft.com/en-us/download/details.aspx?id=47594

STEP 2 - If you're syncing passwords, make sure that your sync service account has Replicate Directory Changes and Replicate Directory Changes All permissions in your on-premises Active Directory

STEP 3 - Make sure that your sync service account has to write permissions on your sourceAnchor attribute (which is most likely set to ms-ds-consistencyGuid). You can do that either using the user interface, or PowerShell, which is easier:

$accountName = "DOMAINNAME\USERNAME" #[this is the account that will be used by Azure AD Connect Sync to manage objects in the directory.



$ForestDN = "DC=DOMAINNAME,DC=SOMETHING"



$cmd = "dsacls '$ForestDN' /I:S /G '`"$accountName`":WP;ms-ds-consistencyGuid;user'"



Invoke-Expression $cmd

STEP 4 - Make sure that inheritance is turned on for the AD objects that get errors in the synchronization logs. To do that

4.1-Open Active Directory Users and Computers

4.2-Enable the Advanced features in the View settings and,

4.3-Open up the user object that can't sync.

4.4-Go to the security tab and then into advanced.

4.5-Check to make sure the box is checked to inherit permissions. But before you do that make sure that the enabling inheritance will not bring down some grants that you do not want to be there.

Have fun,
Thiago Leoncio

How to Create and use Snapshots in Kubernetes

Objective

Today I am going to show how to create snapshots in Kubernetes. This is really helpful in case you want to manage or mitigate the risk of losing your PODs.

From UI:

From the command line: 

  

Creating periodic snapshots 

When you create a StorageClass, you can specify a snapshot schedule on the volume as specified below. This allows snapshotting the persistent data of the running pod using the volume. 

Above spec will take snapshots of the portworx-repl-1-snap-internal PVC every 190 minutes.

Creating a snapshot on demand 

You can also trigger a new snapshot on a running POD by creating a PersistentVolumeClaim as specified in the following spec:

Note the format of the “name” field. The format is name.<new_snap_name>-source.<old_volume_name>. Above example references the parent (source) persistent volume claim pvc013 and creates a snapshot by the name snap013. 

Listing snapshots

To list snapshots taken by Portworx, use the /opt/pwx/bin/pxctl volume snapshot list command.

 For example: 

# /opt/pwx/bin/pxctl volume snapshot list 

ID                                   NAME   SIZE  HA   SHARED   IO_PRIORITY SCALE    STATUS 

1056733319296008813 snap013 1 GiB  2      no               LOW                 1               up - detached  

You can use the ID or NAME of the snapshots when using them to restore a volume. 

Restoring a pod from a snapshot 

To restore a pod to use the created snapshot, use the pvc name.snap013-source.pvc013 in the pod spec. 

Managing snapshots through pxctl 

You can provide the SAN capabilities, using portworx and then create a snapshot of a volume, let's say using an MYSQL DB.

First, create a database and a demo table in your MYSQL container. 

# mysql --user=tleoncio --password=password
MySQL [(none)]> create database pxThiagoLeoncio;
Query OK, 1 row affected (0.00 sec)
MySQL [(none)]> use pxThiagoLeoncio;
Database changed
MySQL [pxdemo]> create table  K8SThiagoLeoncioSample (counter int unsigned);
Query OK, 0 rows affected (0.04 sec)
MySQL [pxdemo]> quit;
Bye

Now create a snapshot of this database using pxctl. 

First, use pxctl volume list to see what volume you want to snapshot 

# /opt/pwx/bin/pxctl v l
ID     NAME          SIZE HA SHARED ENCRYPTED IO_PRIORITY SCALE STATUS
381983511213673988 pvc-e7e66f98-0915-11e7-94ca-7cd30ac1a138 20 GiB 2 no  no   LOW   0  up - attached on 147.75.105.196

Then use pxctl to snapshot your volume 

opt/pwx/bin/pxctl snap create 381983511213673988 --name snap-013
Volume successfully snapped: 835956864616765999

Also, you can use pxctl to see your snapshot created

# /opt/pwx/bin/pxctl snap list
ID     NAME SIZE HA SHARED ENCRYPTED IO_PRIORITY SCALE STATUS
835956864616765999 snap-01 20 GiB 2 no  no   LOW   0  up - detached

Then we create a mysql Pod to mount the snapshot discussed in this article:

kubectl create -f portworx-mysql-snap-pod.yaml




apiVersion: v1
kind: Pod
metadata:
  name: test-portworx-snapped-volume-pod
spec:
  containers:
  - image: mysql:5.6
    name: mysql-snap13
    env:
      # Use secret in real usage
    - name: MYSQL_ROOT_PASSWORD
      value: password
    ports:
    - containerPort: 3306
      name: mysql
    volumeMounts:
    - name: snap-013
      mountPath: /var/lib/mysql
  volumes:
  - name: snap-013
    # This Portworx volume must already exist.
    portworxVolume:
      volumeID: "vol1"

Inspect that the database shows the cloned tables in the new MYSQL instance. 

# mysql --user=tleoncio --password=password
mysql> show databases;
+--------------------+
| Database           |
+--------------------+ 
| mysql              |
| performance_schema |
| pxThiagoLeoncio    |
+--------------------+
3 rows in set (0.00 sec)

mysql> use pxThiagoLeoncio;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> show tables;
+-----------------------+
| Tables_in_pxdemo      |
+-----------------------+
| K8SThiagoLeoncioSample|
+-----------------------+
1 row in set (0.00 sec)

I hope this helps and happy coding,

Thiago Leoncio.