We're using Roundhouse to deploy our databases and keep versions for SQL Server (2008+)
I have a script which grants permissions and needs to have a username passed in. I know there is support for token replacement in Roundhouse, but the only token I've seen mentioned is {{database}}.
What built-in tokens are available?
Can users define their own tokens? Is so how?
At this time ONLY the items in the configuration - https://github.com/chucknorris/roundhouse/wiki/ConfigurationOptions
Note the full name of the option when using token replacement:
-d, --db, --database, --databasename=VALUE | REQUIRED: DatabaseName - The database you want to create/migrate.
-c, --cs, --connstring, --connectionstring=VALUE | REQUIRED: ConnectionString - As an alternative to ServerName and Database - You
can provide an entire connection string instead.
It's the bolded name, e.g. "{{DatabaseName}}" or "{{ConnectionString}}" from the examples above.
Related
Can someone help me how i can update an authentication data entry using wsadmin without logging into was console as i have too many data sources and doing them manually is a time taking procedure. Below is the far that i can get to. Not sure how to use the arguments. Thanks for your help in advance.
wsadmin>$AdminTask help modifyAuthDataEntry
WASX8006I: Detailed help for command: modifyAuthDataEntry
Description: Modify an authentication data entry
Target object: None
Arguments:
securityDomainName - Name used to uniquely identify the security domain.
*alias - The alias of the auth data.
user - The username of the auth data.
password - The password of the auth data.
description - The description of the auth data.
Steps:
None
wsadmin>
Modify authData with:
AdminTask.modifyAuthDataEntry('[-alias myAlias -user myUser -password myPassword -description "my alias description" ]')
In general, to learn the wsadmin command for a given Admin Console operation which you know how to perform, you can use the command assistance function to capture the equivalent last wsadmin scripting command.
In Gforge, when a new user tries to log in; the user is automatically registered by fetching data from LDAP. It works fine for other users but one particular user is not able to log in and gets the error LDAP Authentication failed: Invalid Credentials . I don't understand what could be the issue? Could you please help?
This is the search function I am using.
ldap_bind($ldap, $dn, $pw)
$dn = ldap_get_dn($ldap, $entry);
$entry = ldap_first_entry($ldap,$res);
$res=ldap_search($ldap, $sys_ldap_base,$sys_ldap_id_attribute . '=' . $id,
array());
If it works for some users but not for one specific user, then it's something to do with the LDAP configuration, or with the characters in that user's ID or pwd.
Is the failing user in a different org/OU? Do they have accent characters in their username or password? These things can cause compatibility issues between GForge and the LDAP server.
Does this user have a much longer user name than other users? There is a GForge config setting called "usernameregex" that governs the complexity and length of allowed user names. Even though LDAP logins result in automatic account creation, the validation of the user's unix name might fail due to the regex in place. The error noted above could certainly be the catch-all message when this happens.
The default setting is "^[a-z0-9_.-]{3,15}$". You can change the upper length limit by changing the 15 to something else. The unix_name field in the GForge database is TEXT, so it can be extremely long (1GB?).
In GForge 6.3.x and earlier, you can find that setting in /etc/gforge/gforge.conf. Change the value and then update the system using:
cd /opt/gforge/bin && php create_config_cache.php
In GForge 6.4 and later, you can use the gf-config utility to set the value. It will take effect right away:
/opt/gforge/bin/gf-config set "usernameregex" "new regex value"
I want to reset password of any user in Sun one LDAP( or for that matter any other LDAP ) using extended operation. For the same, I have done following:
I have written two classes as follows:
PasswordExtendedRequest which implements ExtendedRequest AND
PasswordExtendedResponse which implements ExtendedResponse
I am using OID "1.3.6.1.4.1.4203.1.11.1" inside PasswordExtendedRequest
Following is code for extended operation
ExtendedRequest er = new PasswordExtendedRequest(<userName>,<password>);
ExtendedResponse extRes = (ExtendedResponse)ctx.extendedOperation(er);
But I am getting following error after execution and getResponseControls() is also returning NULL.
javax.naming.CommunicationException: [LDAP: error code 2 - unsupported extended operation]; remaining name ''
From the error it looks like that LDAP I am using, is not supporting this extended operation. What should I do with LDAP to support this reset password extended operation?
Let me know I am doing anything wrong or missing anything.
It appears that the Sun one LDAP server implementation you are using does not support the "1.3.6.1.4.1.4203.1.11.1" extension. To implement this extension would require the LDAP server administrator to implement it. (if the Sun One LDAP server CAN even support it)
Extensions are extensions beyond LDAP and may or may not be available on any given LDAP server.
You should be able to identify the support for the extension by querying the rootDSE and checking if the OID is present within the supportedExtension attribute.
-jim
I can login on my IMAP server using my username, but can't using username#company.com (related: Dovecot Authentication failed if trying login with #domain) . Same thing happens for SMTP with exim4.
How can I setup dovecot (IMAP) and exim4 (SMTP) to allow username#company.com as the login?
EDIT: I'm using driver = passwd for the userdb, and driver = pam for the passdb.
I had the same question, and similar reasons. This may not be the best wa but I used a test account, lets call it 'user' for the sake of illustration and, copied the user's line in /etc/passwd (I'm on a Ubuntu cloud server), and changed the name on the copied line-- just adding the fqdn so the user UID has two names: 'user#mydomain.com' and the original, just 'user'. I setup the account first on Thunderbird with just 'user' to login to dovecot and exim, tested send/recieve ok. Then changed the login on Thunderbird for both servers to 'user#mydomain.com'. I had to re-enter the password, but it appears to have worked spectacularly well. It tested send/recieve ok, and otherwise appears the same as before. Now, I'm short on time so I set the password separately for both accounts, but I'm not sure that part is necessary. I'll have to check later, but I think pam looks up passwords matched to the PID (if I'm wrong about that, please someone tell me!). Anyway, more testing later. I'll let you know if there are deleterious side-effects. Aside: it may be possible to simply add the full email address as an alias in /etc/alias but I haven't tested that, and I just thought of it. Anyone try that one, leave a comment! Thanks! Ciao...
You have to create users in complete form of user#domain.tld.
Setup login autocompletion by #hostname if domain part is omitted, before dovecot-auth invocation.
As far as there is lot of dovecot/exim howtos, there is no ready-to-use recipe for your case.
You can change your SQL query to use only the first part before the # sign by using the substring_index() function. Conveniently, this string search query will return the whole string if there is no # sign. This means that if the customer enters "user#domain.com", it will use the correct value (just the "local_part"), and if the customer enters just "user", it will return the whole string.
Example:
mysql> select substring_index('user#example.net','#',1);
+-------------------------------------------+
| substring_index('user#example.net','#',1) |
+-------------------------------------------+
| user |
+-------------------------------------------+
1 row in set (0.00 sec)
mysql> select substring_index('user','#',1);
+-------------------------------+
| substring_index('user','#',1) |
+-------------------------------+
| user |
+-------------------------------+
1 row in set (0.00 sec)
Using Apache mod_auth_basic and mod_authn_dbd you can authenticate a user by looking up that user's password in the database. I see that working if the password is held in clear, but what if we use a random string as a salt (also stored in the database) then store the hash of the concatenation?
mod_authn_dbd requires you to specify a query to select that password not to decide if the user is authenticated of not. So you cannot use that query to concatenate the user provided password with the salt then compare with the stored hash.
AuthDBDUserRealmQuery "SELECT password FROM authn WHERE user = %s AND realm = %s"
Is there a way to make this work?
Looking at the Password Formats for Basic Auth it seemed that I could make this work if the hash is done using the apr_md5_encode function.
Found another question that relates to this and links to a Java implementation. I used that implementation with a small change to calculate the database hash inside my website normal user-creation flow. After this i could use mod_authn_dbd with this query:
AuthDBDUserRealmQuery "SELECT CONCAT('$apr1$',password_salt,'$',password_hash) FROM users WHERE user = %s AND realm = %s"