Is there a way to supply the consumer.config/producer.config property files having encrypted SSL password? I don't want to store the passwords in plaintext format in the filesystem
bin/kafka-run-class.sh kafka.tools.MirrorMaker --consumer.config sourceCluster1Consumer.config --consumer.config sourceCluster2Consumer.config --num.streams 2 --producer.config targetClusterProducer.config --whitelist=".*"
Related
I have restored a database in SQL Server 2019 Dev edition. The .bak file was created from a SQL Server 2017 database on a different machine.
I get this error:
Failed to decrypt column 'EmployeeSalary'.
Failed to decrypt a column encryption key using key store provider: 'MSSQL_CERTIFICATE_STORE'. The last 10 bytes of the encrypted column encryption key are: ‘xx-xx-xx-xx-xxx-xx-xxx-xx'.
Certificate with thumbprint 'xxxxxxxxxxxx' not found in certificate store 'My' in certificate location 'LocalMachine'. Verify the certificate path in the column master key definition in the database is correct, and the certificate has been imported correctly into the certificate location/store.
Parameter name: masterKeyPath
Almost all the tables have one or more encrypted columns.
I do not see any "Always encryption..." certificate in Cert Manager.
Also I do not have any certificate.
What changes are required to make it work?
I am using CentOS 7 in my personal laptop. I have created Public/Private keys ( SSH key pair) for that user. I can see the two keys also in the path /home/user/.ssh/. After creating the key pairs I have coped the public key to the file " .ssh/authorized_keys " and disabled the root access for the user in the file " .ssh/sshd_config" after that I restarted the ssh services. So I wanted to know how I can restrict others accessing my server based on keys ( even if he has password he should not be able to login without key). I am not sure how to use those keys which I created.
Once your are sure that you can login with your keypair, you can add this line to your sshd config on the server :
PasswordAuthentication no
and restart your sshd service
It will prevent any password authentication. You will only connect using your private key.
We use SFTP in our project to transfer files over an SSH connection. This is done through java code. Assuming that if for characters like ?, ! etc we need to give the encoded value in the sftp command, we encoded the password in the code and generated the command. But SFTP isn't working with these encoded password now, it accepts the password directly. What could be the issue. Please help.
Example username: xyz password: abc!
We use URLEncoder to encode the username and password.
String username= URLEncoder.encode(username, "UTF-8");
String password = URLEncoder.encode(password, "UTF-8");
After encoding Our code would generate SFTP command as : sftp://xyz:abc%21#10.9.10.9/home/documents/xyz.txt
But this isn't working, Authentication fails with wrong password. Where as manually if we give command sftp://xyz:abc!#10.9.10.9/home/documents/xyz.txt it works.
Please let us know if we are going wrong.
Thanks in advance.
That's not actually an issue. SFTP is a subsystem of SSH, and SSH creates a secure channel upon client connection (similarly to what SSL does but at layer 7): once the secure and encrypted connection is established, your username and password will be sent to the SSH server inside such connection, therefore there is no need to encode them nor to encrypt them.
The SSH server expects to receive your username/password as they are, not pre-processed nor encoded. And you can do that safely with SFTP for the reason explained here above. So no reason to be worried.
I am using Pvk2Pfx to convert a pvk and cer to a pfx file, the command I am using is
pvk2pfx -pvk MyTest.pvk -spc MyTest.cer -pfx MyTest.pfx
During the creation of pvk file by using makecert, I was prompted to enter a password for private key.
When I ran the command to convert, I was also prompted to enter the password of the pvk file. When I tried to import the pfx file to my certificate store in Windows, I don't have to specify the password. But according to Microsoft document
/po pfxpassword Specifies a password for the .pfx file. If a password for the .pfx file is not specified, the password for the .pfx file will be the same as the password for .pvk file
In this case I have not used /po switch in my command, I think the pfx file should have the same password of pvk file, right? Why I don't need to provide password to import it to certificate store?
Looks like it will only use the password for the .pvk file as password for the .pfx file if you provide the password using the /pi switch.
pvk2pfx /pvk pvkfilename.pvk /pi pvkpassword /spc spcfilename.cer /pfx pfxfilename.pfx
If you don't specify a pvk password, you will be promted to input one, but the resulting pfx file will NOT be password protected.
Additional info about pvk2pfx.
I have installed the openldap version 2.4.23 on windows xp and using the apache DS as a client.I can authenticate users on a client server I set up for testing.
My next step is to turn on a password policy. This is where things have gotten a bit hazy for me and I'm hoping someone can help me out.
i added a password policy also by using the followin command
ldapadd -x -c -f -D "cn=Manager,dc=maxcrc,dc=com" -w secret
but after addition of password policies how do i make them in effect.
The openldap documentation says the password policy module should be configured with the DN of the default policy.
i added the following lines in slapd.conf file
# invokes password policies for this DIT only
overlay ppolicy
# Default ppolicy
ppolicy_default "cn=passwordDefault,ou=policies,dc=maxcrc,dc=com"
but somehow it is not getting loaded , i have already spent more a lot of time on this, but i am not getting the proper guide for the same.
Can anyone shed some light on this in plain, layman's terms?
Thanks in advance.
My ldif file is as follows.
dn: cn=passwordDefault,ou=policies,dc=localdomain,dc=com
objectClass: pwdPolicy
objectClass: person
objectClass: top
cn: passwordDefault
sn: passwordDefault
pwdAttribute: userPassword
pwdCheckQuality: 1
pwdMinAge: 1
pwdMaxAge: 90
pwdMinLength: 6
pwdInHistory: 4
pwdMaxFailure: 3
pwdFailureCountInterval: 0
pwdLockout: TRUE
pwdLockoutDuration: 0
pwdAllowUserChange: TRUE
pwdExpireWarning: 604800
pwdGraceAuthNLimit: 3
pwdMustChange: TRUE
pwdSafeModify: TRUE
after adding this policy and restarting the server i tried changing the password of existing as well as newly added users.
The server allows me to change the password to a string with length less than 6
whereas i have mentioned pwdMinLength: 6 in ldif.
as well as i tried changing the password more than once , but it allows me to change the password to recently used password, whereas the pwdInHistory: 4 in ldif.
The password policy doesn't work if you use the rootDN to execute the updates. You must use an existing admin account, or the user's own account.
It is not clear how you are setting the password when testing, but I would check if you are passing the password in the correct format, meaning that the server needs to receive the password in cleartext. Some clients would hash the value before sending the value to the OpenLDAP server, in which case it would be impossible for the OpenLDAP server to determine the length of password. The communication can and should be encrypted, but it shouldn't be pre-hashed. Hashing can be handled by the server:
pwdCheckQuality
If the value is 1 and the supplied password is in cleartext then a user supplied function (defined using the pwdCheckModule - if defined - will be called to check the password quality. If this function is not available then the password will be accepted (assuming it passes all the other tests defined by the various pwdPolicy attributes).
reference: http://www.zytrax.com/books/ldap/ch6/ppolicy.html
the rootdn bypass password policy, so do not use rootdn in your
ldappasswd command.
https://www.openldap.org/lists/openldap-technical/201102/msg00262.html
You can basically put any password (not empty thou) if setting passwords using ldappasswd and binding with rootdn.
It's a bit tricky situation since you cannot change the password with "passwd" command either for the user. In this case the password policy would kick in.
If you know the rootdn password, you can bypass everything.