Dose anybody know if I can encrypt a regestry key value using batch programing?
It depends what you mean by encrypt.
You can set up permissions to stop users getting access, using regini.
See regini /? for more info, or see this article.
To protect the key you specified you can use this
regini -m \\1stbyteit-pc C:\regpermissions.txt
regpermissions.txt
HKEY_CLASSES_ROOT\Software\Blackbird\main\ADMIN_PASSWORD [1 5]
I have used [1 5] as an example. The list of permission numbers are
1 - Administrators Full Access
2 - Administrators Read Access
3 - Administrators Read and Write Access
4 - Administrators Read, Write and Delete Access
5 - Creator Full Access
6 - Creator Read and Write Access
7 - World Full Access
8 - World Read Access
9 - World Read and Write Access
10 - World Read, Write and Delete Access
11 - Power Users Full Access
12 - Power Users Read and Write Access
13 - Power Users Read, Write and Delete Access
14 - System Operators Full Access
15 - System Operators Read and Write Access
16 - System Operators Read, Write and Delete Access
17 - System Full Access
18 - System Read and Write Access
19 - System Read Access
20 - Administrators Read, Write and Execute Access
21 - Interactive User Full Access
22 - Interactive User Read and Write Access
23 - Interactive User Read, Write and Delete Access
Related
There are 2 nfs shares on our linux redhat servers to host the live and landing data. There is keytab refreshed ( ticket produced) every 30 minutes , apparently it give system account an access to those 2 shared drives. If key tab ticket is not valid then i guess we would get key is expired error on browsing those 2 nfs locations.
This is what documented as a part of handover from other team. I don't have test env and I got to replace the keytab from rc4 to aes but my problem is that I don't know how keytab is associated with those 2 locations? . It seems it encrypts the locations and allow the access to them with keytab only.
Do I need to change any conf file to replace keytab from rc4 to aes. Kerb cong has already got entry to allow new encryption types aes128.
Unix , nfs storage and ad teams are not giving me answer and i am new to all of this. I have read online that there is sssd.conf file that could be used in conjunction with kerb conf . Can you give me direction from your experience
I've got two accounts:
1111111 - it's my main account
2222222 - used for audit purposes
I have created an S3 bucket in 2222222 (and called it 'my-audit-bucket).
In 11111 I have created a trail in CloudTrail and set it to store all data in 'my-audit-bucket'. That has been working perfectly fine for quite a while (additionally I've got SQS configured, which is used to push logs to Splunk).
Now I want to encrypt the CloudTrails using CMK. I changed the configuration but wasn't able to save it, as I got:
"You don't have adequate permissions in S3 to perform this operation"
Any idea what should I add to the configuration?
Ok so I have an application that I inherited that we do not know the root token and we do not have any recovery keys or unseal keys. The problem is, we cannot authenticate into Vault at all and we also cannot have the instance go down.
I do have access to the datastore it uses (DynamoDB) and the encrypting keys. My assumption is that it would be possible in theory to manually add an entry and set a password directly on the underlying datastore instance so that we can have a root account again.
I know this one is weird but we cannot re-initialize the database.
Any thoughts on how this could be done?
You can try one of the below -
The initial root token generated at vault operator init time -- this token has no expiration
By using another root token; a root token with an expiration cannot create a root token that never expires
By using vault operator generate-root (example) with the permission of a quorum of unseal key holders
Root tokens are useful in development but should be extremely carefully guarded in production. In fact, the Vault team recommends that root tokens are only used for just enough initial setup (usually, setting up auth methods and policies necessary to allow administrators to acquire more limited tokens) or in emergencies, and are revoked immediately after they are no longer needed. If a new root token is needed, the operator generate-root command and associated API endpoint can be used to generate one on-the-fly.
You can read more here - https://www.vaultproject.io/docs/concepts/tokens
No matter how bad the breakup was with the previous administrator, call him and ask for the shards. Now. It's an emergency.
To create a root token, you need a quorum of shards. A shard is a large number that could be in base64. For example, this is what the same shard looks in both formats:
9PTUFNoCFapAvxQ2L72Iox/hmpjyHGC5PpkDj9itaMo=
f4f4d414da0215aa40bf14362fbd88a31fe19a98f21c60b93e99038fd8ad68ca
You can mix and match formats, but each shard can be only entered once.
Run the command vault status to know how many different shards you need to find. The default Threshold is 3:
$ vault status
Key Value
--- -----
Recovery Seal Type shamir
Initialized true
Sealed false
Total Recovery Shares 5
Threshold 3
If you do get your hands on some shards, enter the command vault operator generate-root and enter them at the prompt. Don't cancel the ongoing root token generation, if someone entered a shard some time in the past, Vault has it (even if you don't). vault operator generate-root -status will tell you if Vault already has some shards. Here is an example where the first shard of three was entered:
$ vault operator generate-root -status
Nonce 9f435314-ce20-4716-cea7-a083de224e4e
Started true
Progress 1/3
Complete false
OTP Length 26
If you can't find the shards, you are in trouble. You will have to find a password and read all the secrets one by one (can be scripted), ideally every version of them. You say you can't log in, so you might have to ask your user to do it.
Keep in mind that some backends (like the PKI) can't be exported manually, not even by root.
I'm currently working with SterlingDB (not the phone 7 version) and would like to be able to access the same Sterling Database from 2 different applications (and therefore different AppDomains).
I have ascertained that even when you pass a FileSystemDriver to the RegisterDatabase method:
engine.SterlingDatabase.RegisterDatabase<PodcastDatabase>(new FileSystemDriver("MyTestApp/"));
you end up with 2 different databases:
I:\Users\Dave\AppData\Local\Sterling Database\TestMeGo\1123790033 and
I:\Users\Dave\AppData\Local\Sterling Database\TestMeGo\1728918701
This is presumably because the apps are contained in separate AppDomains and the IsolatedStorage which is used by Sterling is compartmentalised accordingly.
Is there a way to have just one Sterling database which more than 1 app can access?
Thanks
It should be possible, as you can read here. You either let the storage be based on the XAP url, or on the source domain. If you can get both apps to be from the same source domain, and use the GetUserStoreForSite method, you should be able to get it to work.
I have a script (Joomla) that creates files and directories on the server. The problem is that it creates them under owner 99 99 (nobody) and after I can't delete or modify them by FTP without the help of the server admin.
I think that is move_uploaded_file function of php.
Is there any solution of this problem by the WHM or by the server admin? Can I modify the default owner in ftp?
What happens is the HTTP server is ran by a user called "nobody", and your FTP user is another one. When the upload occurs, the HTTP server creates the file under its username, and your FTP user has no permission to write (or delete) these files.
The easiest way to fix this (but not really secure) is to add both users in a same group, and change the file permissions to allow users of the same group to read/write on these files.
Your admin should take care of it, but you'll have to call chmod() to change the permissions of your uploaded files.
Explaining it better:
The linux/unix file permissions are composed by permissions of user (u), group (g) and others (o).
I'll only cover 3 types of file permisions here, which are read (r), write (w) and execute (x). So, you end up having something like this:
-rw-rw---x 1 jweyrich staff 12288 Oct 24 00:22 avatar.png
The first rw- is the permission (read/write) of the USER that owns the file (jweyrich).
The second rw- is the permission (read/write) of the GROUP that owns the file (staff).
The --x at the end are the permissions (execute) of the OTHERS users..
Your PHP scripts run as "nobody" user (and by, let's say, "nobody" group), so every file you create from your PHP will be owned by the "nobody" user (and his group). A user can be part of one or more groups.
To solve the permission problem, your FTP user and the "nobody" must be in a common group, let's say the admin put your user in the "nobody".
Once they're in the same group, your PHP script has to give "rw" (read/write) permissions to the "nobody" group members. To do so:
chmod("path_to_your_file", 0770);
The 0770 is equivalent to "u+rwx,g+rwx,o-rwx" , which I explain here:
u+rwx = for user (owner, which is "nobody"), give read/write/execute permissions
u+rwx = for group (which is also "nobody"), give read/write/execute permissions
o-rxw = for others, remove the read/write/execute permissions
After that, your FTP user, which is now part of the "nobody" group, will have read//write access to the uploaded files, and thus can also delete the files. It would look like this:
-rwxrwx--- 1 nobody nobody 12288 Oct 24 00:22 avatar.png
It's not the ideal introduction to unix file permissions, but I hope this helps.
The user that PHP runs under - nobody - is set by the system administrator. There's nothing you can do about that.
You can try chown() to change the file's owner if you know the FTP user's ID. Usually though, you will not be allowed to do this from within PHP.
Depending on the group situation on the server, it could be that if you use chmod to change the file's access rights after the file has been uploaded, the FTP account can access the file:
Try this first:
chmod($uploaded_file, 0660); // owner+group read+write
If that doesn't work, try this:
chmod($uploaded_file, 0666); // global read+write
one of these should make the file usable by the FTP account.
The 0666 is highly discouraged because other users on the server could write into your files, but in some configurations, it's the only way to get going.