Duplicate "Just-in-Time" SSO Filespace user, group and permission ACLs

  • Updated

 

Target audience: Filespace administrators

Overview

Our users often wish to operate multiple Filespaces for various reasons and duplicate "Just-in-Time" SSO access control lists (ACLs) comprising of Users, Groups and Permissions across Filespaces for simplicity of uniformed user access.

It could be hosting a separate Filespace for production to archive data and ensuring the data layout and Filespaces appear to users exactly the same. Or data migrations between Filespaces hosted on different object storage providers.

If you are performing a migration you might like to explore our Filespace data migration article and Migration Strategies article for general data movement concepts.

In this article we will focus on the task of listing the Users identifying their Admin roles, Groups and Permissions via command-line scripts to export and import between source and destination Filespaces running on either Linux, macOS or Windows.

The scripts are designed as individual scripts: if you only require duplicating your users, groups between Filespaces and not the permissions for instance, you can merely skip the permissions allocation process. Your Filespaces might require the same users, and groups, however maintain a separate data layout, you can allocate those unique permissions to your newly duplicated users and groups. 

You can run the scripts multiple times, to refresh configurations. Existing users and groups will be ignored, as they already exist. User Admin role assignments and permissions allocations will be applied.

"Just-in-Time" SSO Filespaces, users and their groups are only created within the Filespace configuration as users log in, we can however pre-create the user and groups to assign the permissions in advance. 

For Lucid built-in Filespaces or hybrid SSO ACLs also consult this KB article.

Requirements

All LucidLink users and administrators will require the LucidLink version 2.1 client or later installed to use the new SSO implementation.

You will need to implement and distribute your Filespace key to your users. Your Filespace key will be available once you complete the integration. Your Filespace keys are unique for each Filespace. 

Compatibility

  • All existing LucidLink 2.0 Filespaces
  • All major operating systems (macOS, Windows, Linux)

Duplication process

Step 1. Capture your users, groups and permissions configuration by exporting your configuration.

The backups will be the basis for our import scripts.

Connect to your Filespace as root or admin user. You will be required to backup your users, groups and permissions.

lucid user --password <password> > jit_users_backup.txt
lucid group --password <password> > jit_groups_backup.txt
lucid permission --configured --password <password> > jit_permissions_backup.txt
Please note, as of Filespace format 2.2 the legacy term “Shares” has been changed to “Permissions”. You can backup your shares, the script will detect your Filespce format.
lucid share --configured --password <password> > jit_shares_backup.txt

Continue with the remaining steps determined by your operating environment, Linux, macOS and Windows sections below. 

Linux and macOS (Bash)

Step 2. You will need to duplicate your Filespace directory structure to import your permissions. If you've already migrated your data in entirety, perfect, if not you will have to at minimum have the exact folder structure to assign permissions against. 

If need be, backup your folder structure into a "folders" directory. Skip this step if your data is duplicated.

rsync -av -f"+ */" -f"- *" "/media/source/" "folders"

Disconnect from your source Filespace and connect to your alternate "Just-in-Time" SSO implemented Filespace. 

Download jit_users_script.sh, jit_groups_script.sh, jit_permissions_script.sh and make each script executable. 

curl -O https://lucidlink-support.s3.amazonaws.com/scripts/JIT/jit_users_script.sh 
curl -O https://lucidlink-support.s3.amazonaws.com/scripts/JIT/jit_groups_script.sh
curl -O https://lucidlink-support.s3.amazonaws.com/scripts/JIT/jit_permissions_script.sh
chmod u+x *_script.sh

Step 3. Once you've successfully connected to your Just-in-Time SSO integration, you can now begin the importation process. 

Lists users from backup, imports users and assigns user roles.

./jit_users_script.sh <password>

Step 4. List groups and import.

./jit_groups_script.sh <password>

Step 5.  Allocate listed permissions for users and groups.

If you've already copied the data and your directory structure exists your permissions will create successfully. If not Rsync directory structure only from the folders backup we performed in Step 2 before permission creation.

rsync -av -f"+ */" -f"- *" "folders/" "/media/dest"
"The path is invalid.
Request failed with: Bad Request" implies a possibility the directory structure does not exist.
./jit_permissions_script.sh <password>

Step 6. Check Filespace users, groups and permissions

lucid user --password <password>
lucid group --password <password>
lucid permission --configured --password <password>

Step 7. Clean up temporary files, scripts, optionally the bash history and backups after taking special consideration ensure your users, groups and permission allocations are correct.

Consult these output files to identify any allocations which might not have been assigned correctly due to edge cases. 

rm jit_users_import.txt jit_users_commands.txt jit_users_output.txt jit_users_roles_import.txt jit_users_roles_commands.txt jit_users_roles_output.txt jit_groups_import.txt jit_groups_commands.txt jit_groups_output.txt jit_permissions_import.txt jit_permissions_commands.txt jit_permissions_output.txt
rm jit_users_script.sh jit_groups_script.sh jit_permissions_script.sh
rm jit_users_backup.txt jit_groups_backup.txt jit_permissions_backup.txt

Remove Bash shell history

for i in $(history | grep 'lucid' | awk '{print$1}' | sort -nr); do history -d $i;done
for i in $(history | grep '_script.sh' | awk '{print$1}' | sort -nr); do history -d $i;done
sed -i -e '/lucid/d' ~/.bash_history
sed -i -e '/_script.sh/d' ~/.bash_history

Windows (PowerShell)

Step 2. You will need to duplicate your Filespace directory structure to import your permissions. If you've already migrated your data in entirety, perfect, if not you will have to at minimum have the exact folder structure to assign permissions against. 

If need be, backup your folder structure into a "folders" directory. Skip this step if your data is duplicated.

robocopy <source> "$env:USERPROFILE\folders" /e /xf * /r:0 /w:0

Disconnect from your source Filespace and connect to your alternate "Just-in-Time" SSO implemented Filespace. 

Download jit_users_script.ps1, jit_groups_script.ps1, jit_permissions_script.ps1 

Invoke-WebRequest https://lucidlink-support.s3.amazonaws.com/scripts/JIT/jit_users_script.ps1 -OutFile jit_users_script.ps1
Invoke-WebRequest https://lucidlink-support.s3.amazonaws.com/scripts/JIT/jit_groups_script.ps1 -OutFile jit_groups_script.ps1
Invoke-WebRequest https://lucidlink-support.s3.amazonaws.com/scripts/JIT/jit_permissions_script.ps1 -OutFile jit_permissions_script.ps1

Step 3. Once you've successfully connected to your Just-in-Time SSO integration, you can now begin the importation process. 

Lists users from backup, imports users and assigns user roles.

.\jit_users_script.ps1 <password>

Step 4. List groups and import.

.\jit_groups_script.ps1 <password>

Step 5.  Allocate listed permissions for users and groups.

If you've already copied the data and your directory structure exists your permissions will create successfully. If not Robocopy directory structure only from the folders backup we performed in Step 2 before permission creation.

robocopy "$env:USERPROFILE\folders" <dest> /e /xf * /r:0 /w:0
"The path is invalid.
Request failed with: Bad Request" implies a possibility the directory structure does not exist.
.\jit_permissions_script.ps1 <password>

Step 6. Check Filespace users, groups and permissions

lucid user --password <password>
lucid group --password <password>
lucid permission --configured --password <password>

Step 7. Clean up temporary files, scripts, optionally your command history and backups after taking special consideration ensure your users, groups and permission allocations are correct.

Consult these output files to identify any allocations which might not have been assigned correctly due to edge cases. 

remove-item jit_user_output.txt,jit_user_error_output.txt,jit_user_log.txt,jit_user_role_output.txt,jit_user_role_error_output.txt,jit_user_role_log.txt,jit_group_output.txt,jit_group_error_output.txt,jit_group_log.txt,jit_permissions_output.txt,jit_permissions_error_output.txt,jit_permissions_log.txt
remove-item jit_users_script.ps1,jit_groups_script.ps1,jit_permissions_script.ps1
remove-item jit_users_backup.txt,jit_groups_backup.txt,jit_permissions_backup.txt

Remove PowerShell command-line shell history

clear-history -CommandLine *lucid*
clear-history -CommandLine *_script.ps1*
$HistorySavePath = (Get-PSReadlineOption).HistorySavePath; (Get-Content "$HistorySavePath") -notmatch "lucid" | Out-File "$HistorySavePath"
$HistorySavePath = (Get-PSReadlineOption).HistorySavePath; (Get-Content "$HistorySavePath") -notmatch "_script.ps1" | Out-File "$HistorySavePath"
Edge cases might be caused by special characters and/or unusual spacings within your permissions. These will hopefully be an anomaly in your configuration and can be simply recreated manually.
Alternatively adjust the default script regular expressions to account for your configuration. Please do not hesitate to reach out to support via a ticket. 

Was this article helpful?

0 out of 0 found this helpful