When I change pwdChangedTime in Openldap, it gives an error like the following. How can I change the pwdChangetime value as admin without changing the user's password?
ldap_modify: Constraint violation (19)
additional info: pwdChangedTime: no user modification allowed
How can I change user's pwdChangedTime attribute in openldap 2.4.41?
As you already experienced pwdChangedTime is a special attribute set by the server, a so-called operational attribute. Normally this cannot be altered by a user application.
But OpenLDAP supports the so-called Relax Rules control which can be used if the bound client is authorized for manage operations.
When using OpenLDAP CLI tools you can simply use:
ldapmodify -e relax [..more options..]
Related
I am using a group context to configure the db connection. The password of the db has a password type. When deploying the job, the password is automatically encrypted in the default.properties under the contexts folder.
What if i want to change the password without using the studio (on a client environment)? what can i use to encrypt the new password?
I was able to do it by creating a separate encryption job with a tjava component and the following code:
System.out.println(routines.system.PasswordEncryptUtil.encryptPassword(context.Password));
where context.Password is an input context variable of type String. When running the job, the user is prompted to enter a password and then the encrypted Talend password will be printed. It will have the following format: enc:routine.encryption.key.v1:[encryptedPassword] The routine encryption key can be modified if needed by following this link: https://help.talend.com/r/en-US/8.0/installation-guide-data-integration-windows/rotating-encryption-keys-in-talend-studio
There's actually a few ways for this:
myJob.sh --context_param myPassword=pass123
this unfortunately can be seen by anyone via ps / task manager.
You can also edit the contexts/contextName.properties file and change the context parameters there. This way the context can only be seen if you have access to the file.
Theoretically both should be able to accept the cleartext/encrypted password.
Implicit context load feature can also be used to load contexts: https://help.talend.com/r/en-US/8.0/data-integration-job-examples/creating-job-and-defining-context-variables
Can someone please give me an example for corporatePasswordStore that is mentioned here:
https://docs.corda.net/node-administration.html?fbclid=IwAR0gRwe5BtcWO0NymZVyE7_yMfthu2xxnU832vZHdbuv17S-wPXgb7iVZSs#id2
I've been doing a lot of research in the last few days on how to hide the plain passwords from node.conf; it's a new topic for me and this is what I came up with so far:
Create a priv/pub key with gpg2
Create a password store with pass (using the key that I generated earlier).
Store all the plain passwords from node.conf inside that password store.
Replace the plain passwords in node.conf with environment variables (e.g. keyStorePassword = ${KEY_PASS})
Create a script file (e.g. start_node.sh) that will do the following:
a. Set an environment variable to one of the passwords from the password store: export key_store_password=$(pass node.conf/keyStorePassword)
b. Start the node: java -jar corda.jar
c. Restart the gpg agent to clear the cached passwords, otherwise you can get any password from the store without passing the passphrase: gpgconf --reload gpg-agent
Pros:
Using the bash file start_node.sh allows to set many passwords as environment variables at once (e.g. keyStore, trustStore, db passwords, RPC user password)
Since we are running the bash file with bash start_node.sh and not source start_node.sh, the environment variable is not exposed to the parent process (i.e. you cannot read that environment variable value inside the terminal where you ran bash start_node.sh
History commands are not enabled by default inside bash scripts.
Cons:
You no longer can have a service that automatically starts on VM startup, because the start_node.sh script will ask for the passphrase for your gpg key that was used to encrypt the passwords inside the password store (i.e. it's an interactive script).
Am I over-complicating this? Do you have an easier approach? Is it even necessary to hide the plain passwords?
I'm using Corda open source so I can't use the Configuration Obfuscator (which is for Enterprise only): https://docs.corda.r3.com/tools-config-obfuscator.html#configuration-obfuscator (edited)
I wrote a detailed article here: https://blog.b9lab.com/enabling-corda-security-with-nodes-configuration-file-412ce6a4371c, which covers the following topics:
Enable SSL for database connection.
Enable SSL for RPC connection.
Enable SSL for Corda webserver.
Enable SSL for Corda standalone shell.
Hide plain text passwords.
Set permissions for RPC users.
I want to encrypt db.username and db.password written in alfresco-global.properties .
Can anyone please help me in this, where that username & password is used so that i can write decryption code there, so that alfresco can understand.
I am using Alfresco 4.2 Enterprise.
Can't you just change permissions on alfresco-global.properties so only the user running the Alfresco JVM can read it ?
Anyways, that said the values are used in tomcat/webapps/alfresco/WEB-INF/classes/alfresco/core-services-context.xml. Create a custom bean baseDefaultDataSource deriving from org.apache.commons.dbcp.BasicDataSource and handle the decryption in that class. Make sure to pass the decrypted value to the jdbc driver. Also make sure the definition gets processed after the defaults kick in. You might want to drop your spring context into tomcat/shared/classes/alfresco/extension.
1)Is there any monitoring or supervision attribute in the OpenLDAP server which can tell if the running OpenLDAP server is a provider or consumer without doing any operations on the Server like ldapmodify?
2) Is their any option to modify the syncrepl config online if yes then how to do ?
The answer to both is to use the 'online configuration' mode whereby the configuration is held inside the directory. Then you can both look up for (1) and modify for (2).
This probably isnt an issue with SiteCore per se but I've included it for completeness. I have sitecore 6.3 running under IIS7 using a custom identity for the app pool. I cant get Sitecore to write its logging information (using the default log4net settings) to the eventlog. I've followed the advice here: http://logging.apache.org/log4net/release/faq.html#Why%20doesn%27t%20the%20EventLogAppender%20work? and although it works fine when I make the custom identity a member of the administrator's group I need to find a way to get it working in production without such a security hack.
The weird thing is that I have a MSI that installs it (running under an account which IS a member of the administrator's group) and creates the correct registry keys in the eventlog for me and yet despite that, I am still getting the following error when I run the application using the custom identity (without it being a member of administrators).
log4net:ERROR DOMConfigurator: Could not create Appender [EventLogAppender] of type [log4net.Appender.EventLogAppender]. Reported error follows.
System.Security.SecurityException: Requested registry access is not allowed.
at Microsoft.Win32.RegistryKey.OpenSubKey(String name, Boolean writable)
at System.Diagnostics.EventLog.GetEventLogRegKey(String machine, Boolean writable)
at System.Diagnostics.EventLog.FindSourceRegistration(String source, String machineName, Boolean readOnly)
at System.Diagnostics.EventLog.DeleteEventSource(String source, String machineName)
at log4net.Appender.EventLogAppender.ActivateOptions()
at log4net.Repository.Hierarchy.DOMHierarchyConfigurator.ParseAppender(XmlElement appenderElement)
The Zone of the assembly that failed was:
MyComputer
log4net:ERROR DOMConfigurator: Appender named [EventLogAppender] not found.
Thinking I could narrow it down to a registry permission issue I granted Everyone full permissions to the following registry key and subkeys but it didnt work either: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog
The custom identity is a member of the following groups:
Event Log Readers
IIS_USERS
Performance Monitor Users
I've also seen the following question which seems to ask the same thing. The Microsoft article seems to suggest it might be a problem with ACLs on an event log and gives examples on how you can change SSDLs but I'd rather avoid that if at all possible.
EDIT:
I have another server running where the log is being populated fine. The custom identity was a member of administrators so I revoked that and rebooted, trying to purposely break it but I cant. Config is identical on both boxes and same identity used to run the MSI which creates the registry keys. Have run procmon on both (after doing a IISReset and spinning up the app pool again) to examine registry activity. Strange thing is - on the box that works you get 477 name not found records for my event source in the wrong places (Application, and a different Custom EventLog "MyCompany"). No hits for the place where it is logging which is "MyCompany\MyCompany.SiteCore". Whilst on the box which is broken, it does appear to be requesting to read the right key (albeit only 6 times) but you then get the Log4Net registry access error.
As I understand it EventStores are stored in the registry, so you only need write permission to registry to create or delete an EventStore. This is usually only needed once and most applications create this as part of the install procedure so that the application does not need to be run as Administrator during normal execution.
However your error message (in the question) includes the method DeleteEventSource from which I would deduce/guess that the EventSource does exist but is wrong in some way. So perhaps this is currently registered as writing to the event log named MyCompany and you are now trying to change it to "MyCompany\MyCompany.SiteCore" which requires you to delete the old eventsource and create a new one.
So it sounds like your installation routine is creating a different EventSource from the one that your application is actually using.
If that doesn't help, then I would suggest enabling internal logging for Log4net (but obviously not to the eventlog) which will probably give you more information.
Giving full permission to the registry key is not enough.
According to Microsoft
To create an event source in Windows Vista and later or Windows Server 2003, you must have administrative privileges.
The reason for this requirement is that all event logs, including security, must be searched to determine whether the event source is unique. Starting with Windows Vista, users do not have permission to access the security log; therefore, a SecurityException is thrown.
Starting with Windows Vista, User Account Control (UAC) determines the privileges of a user. If you are a member of the Built-in Administrators group, you are assigned two run-time access tokens: a standard user access token and an administrator access token. By default, you are in the standard user role. To execute the code that accesses the security log, you must first elevate your privileges from standard user to administrator. You can do this when you start an application by right-clicking the application icon and indicating that you want to run as an administrator.
I think, contrary to the Apache documentation, log4net DOES need write access to the registry – or at least it does in my case. To prove this, I backed up the registry on the server where it wasnt working and granted IIS administrator privileges before spinning up sitecore. Sure enough it started logging away to the eventlog nicely and then when I exported the registry again to run a diff, there WAS a difference.
The value for the eventlogmessage file on my event source had been updated from:
C:\Windows\Microsoft.NET\Framework\v2.0.50727\EventLogMessages.dll
To
C:\Windows\Microsoft.NET\Framework64\v2.0.50727\EventLogMessages.dll
So I assumed that merely changing this value in the registry by hand would work.
But it didn’t.
So I ran procmon on the two servers I have: A=the working one, B=the failing one. Sure enough, on server B I have a line which says:
Operation: RegOpenKey, Path: HKLM\System\CurrentControlSet\Services\EventLog, Desired Access:Read/Write, Result: ACCESS DENIED.
I’ve traced through with Server A and in exactly the same place, the key is requested with Desired Access:Read.
Conclusion:
It seems unavoidable that I will need to grant my app pool identity administrator privileges in production for at least enough time to programatically do the necessary registry writes the first time from within log4net. I dont know why administrator; I have tried granting Full permissions to the entire eventlog node in the registry for my custom app to no avail. It seems to do something which I cannot identify or pin down. I will then revoke this privilege immediately after it starts to log and monitor whether subsequent installs knock out the functionality afterwards. (Hopefully not).
If anyone has any insight into this behaviour it would be greatly appreciated.