Greeting, I have setup otrs and its running. I have an inhouse authentication system used that I have integrated into otrs, but I am stumped on one last issue. I would like to use the encrypted system password for a user and use that as the password for otrs also. 1. Where is the salt defined? I see from the db that the first two characters of the username are used as the salt, but where is that configured? 2. Any suggestions on ways to accomplish this? Thank you in advance. Andrew
Hi Andrew, On Wed, Mar 12, 2003 at 02:32:43PM -0500, ahall@coxnews.com wrote:
I have setup otrs and its running. I have an inhouse authentication system used that I have integrated into otrs, but I am stumped on one last issue. I would like to use the encrypted system password for a user and use that as the password for otrs also.
1. Where is the salt defined? I see from the db that the first two characters of the username are used as the salt, but where is that configured?
2. Any suggestions on ways to accomplish this?
The perl crypt() "e. g. crypt($Pw, $User)" is used for the encrypted password in the DB. Tell me more about the used authentication system and I can show you the best way. Is there a LDAP interface? Do you sync the users into the OTRS DB?
Andrew
Martin -- Martin Edenhofer - <martin at edenhofer.de> - http://martin.edenhofer.de/ -- Old programmers never die. They just branch to a new address.
The perl crypt() "e. g. crypt($Pw, $User)" is used for the encrypted password in the DB.
I did see that in the SetPassword function. so $User is the salt?
Tell me more about the used authentication system and I can show you the best way. Is there a LDAP interface? Do you sync the users into the OTRS DB?
No I don't have LDAP. :( What I want to do is take the encrypted password from our system password (/etc/shadow) and insert that into system_users.pw, that way I can control otrs access from our central user management tool. The issue I am having is that if I take an encrypted password and put it into the db, it will not authenticate. My first impression is that the decrypt password function is using the wrong salt. From what I have gathered so far it appears that the first two characters of the username are used as the salt. So I guess what I am basicaly looking for is a way to take an encrypted password that was created with perls crypt() i.e. crypt($pw, &random_salt) and use that in otrs. Thank you in advance, Andrew
Hi Andrew, On Thu, Mar 13, 2003 at 12:58:07PM -0500, ahall coxnews.com wrote:
The perl crypt() "e. g. crypt($Pw, $User)" is used for the encrypted password in the DB.
I did see that in the SetPassword function. so $User is the salt?
Yes.
Tell me more about the used authentication system and I can show you the best way. Is there a LDAP interface? Do you sync the users into the OTRS DB?
No I don't have LDAP. :( What I want to do is take the encrypted password from our system password (/etc/shadow) and insert that into system_users.pw, that way I can control otrs access from our central user management tool.
The issue I am having is that if I take an encrypted password and put it into the db, it will not authenticate. My first impression is that the decrypt password function is using the wrong salt. From what I have gathered so far it appears that the first two characters of the username are used as the salt.
So I guess what I am basicaly looking for is a way to take an encrypted password that was created with perls crypt() i.e. crypt($pw, &random_salt) and use that in otrs.
In Kernel/System/Auth/ are the auth. modules for the agent interface. I would use the Kernel/System/Auth/DB.pm and modify the Auth() like you want. If Auth() returns 1 then the user gets access to OTRS. And I would disable to set the user password with OTRS. To do so add the following to Kernel/Config.pm and the agent can't change the passowrd: [...] $Self->{LostPassword} = 0; $Self->{PreferencesGroups}->{Password} = { Colum => 'Other Options', Label => 'Change Password', Type => 'Password', Activ => 0, }; [...]
Andrew
Martin -- Martin Edenhofer - <martin at edenhofer.de> - http://martin.edenhofer.de/ -- Old programmers never die. They just branch to a new address.
participants (2)
-
ahall＠coxnews.com -
Martin Edenhofer