Arev ver 2.12, NT Server 4.0

We are trying to supply our customer the ability to create users without actually giving them access to the SYSPROG account, for obvious reasons. I know you can't just write a record to the SYSTEM file because of the check sum field. SEC() will encrypt the password so I can build a record. Is there a way to supply the record to the secureuser TCL cmd, or SEC() or some other blackbox method to make if valid? MAKEUSER will work from TCL but SECUREUSER does not.

This may be a question for Revelation directly, I know security is a hotbutton topic. However, any help would be greatly appreicated.

Brian,

Maybe I am completely missing the boat, but all you should need is a record in SYSENV. When we set up new interfaces (users) to our system, we download a new SYSENV record, do a SETALIAS to the SYSPROG account and copy the record in.

If you set up a template record, you could change just the fields needed and write it in as a new user entry.

Matt Sorrell

msorrell@movgal.com

There is an article in Revmedia on how to do this. You need to call SEC appropriately not only to encrypt the password, but also to encrypt the record as a whole.

Fine and dandy if you are in the SYSPROG application/account to create the SYSENV user record in the first place.

However, Brian is trying to allow the client to create new user records without accessing SYSPROG and having Brian to do it. Using your scheme means that Brian would have to create the user record in a SYSPROG account off-site, which negates him trying to avoid doing the work for the client. Then send it to the client who would need the password for SYSPROG in order to do the SETALIAS, which negates the requirment of not allow the user/client access to SYSPROG.

Warren,

Actually what I was saying was put a template record in the SYSENV table. Write a utility that allows them to specify information such as user name and password. In the utility, read the template from the SYSENV table, change the fields to the information provided by the user, and then write the updated SYSENV record back with the appropriate key.

This can all be done through code, and if you're worried about them possibily seeing the SYSPROG password in the command stack, save off the command stack at the start of the program and then overwrite the current command stack with the one you saved.

Matt Sorrell

msorrell@movgal.com

The record still needs to be encrypted. Also, you would need to be sure that appropriate security measures have been placed on the screen. HR-1 does this actually. The main account is HRIS, and you can use SECUREUSER from the HRIS account. One of the things you can set is whether the user has access to SECUREUSER.

From the ever popular Revmedia, we bring you this little gem originally published in Volume 4, Issue 5.

A subroutine with four parameters which permits the developer to manipulate

users from within any account on the system. Parameters are Action,

UserName, UserRecord, Flag.

Action The code for the action to be taken. Values identified thus far are

       0&nbsp &nbsp Creates a new user. Needs user name in UserName, account to

          create user for in Record and returns a result flag in Flag.

          Flag can have the following values

             0 &nbsp &nbsp User created successfully

             2 &nbsp &nbsp Record exists but is not a user record

             7 &nbsp &nbsp Unable to create user (user already exists, account does

                not exist, not a valid account etc.)

       1 &nbsp &nbsp  Modifies an existing user record. Needs user name in UserName,

          new record (or partial record) in Record and returns result flag

          in Flag. Flag can have the following values

             0 &nbsp &nbsp User modified successfully

             2 &nbsp &nbsp Record exists but is not a user record

             3 &nbsp &nbsp Record does not exist

       2 &nbsp &nbsp Read a user record. Needs User name in UserName and returns user

          record in Record and result flag in Flag. Flag can have the

          following values

             0 &nbsp &nbsp Record read successfully

             2 &nbsp &nbsp Record exists but is not a user record

             3 &nbsp &nbsp Record does not exist

       3 &nbsp &nbsp Deletes a user record. Needs user name in UserName and returns

          user record in Record and result flag in Flag. Flag can have the

          following values

             0 &nbsp &nbsp Record deleted successfully

             2 &nbsp &nbsp Record exists but is not a user record

             3 &nbsp &nbsp Record does not exist

Note that codes other than the above return an error flag of 4. With Code 0

1 or 3, an interesting side effect is that if UserName contains a non-user

record, but still a record that exists on SYSCONFIGURE, then Record returns

the record even though the error flag is set. This could be used to good

effect to read records from SYSCONFIGURE from a non-Sysprog account.

(Volume 4, Issue 5, Page 11)

Yes, you'd have to manipulate @TCL.STACK, not re-writing the command stack record as that only gets updated at logoff time. However it would mean either hardcoding the SYSPROG password into the program which can be found by examining the object code or storing it hopefully encrypted in some other file, *but* it means having to remember to change these whenever the SYSPROG password is changed.

A RPITA IMHO. It is easier just to train the system administrator how to do admin Arev from SYSPROG properly in the first place. You have to trust your clients at some point. If they screw things up without a proper backup - SOL! If they change the SYSPROG password without telling you, there are ways around that which are pretty obvious as long as you have a working copy of ARev that you can get into.

Besides, if they screw it up, think of the money you can make charging them to fix it

Thanks,

Believe it or not I have a copy of the Revmedia mentioned. USER_SUB appears to be an AREV 3.0 subroutine, we are still at Rev 2.12. The REVMEDIA article implies that is may have previously been a TCL command. Any Clues? Copying the template record into SYSENV must work on 3.0 as well, beacuse 2.12 it returns invalid user.

I had previously created a collector and built a new SYSTEM record. I had ended up using the SETFILE, with all the baggage, my users do not have access to the TCL Stack so that should not be too much of an issue. If need be I can remove the entries from the stack no prob.

Using SEC() I can correctly encrypt the password FMC. However, FMC in the SYSTEM file must be the encrypted record that Victor was talking about. I can't figure the format of what is being encrypted here though. Any ideas on that.

Brian

If I recall, the checksum includes the record name and all lines of the record up to the checksum line. I forgot how the record name is appended. Fiddle around with it trying various delimiters. I have notes but they're at home:

recid:@fm:@record:@fm:@record@fm:…:@record

Check Revmedia again. I was referring to a different article that explained the workings of SEC calls. I think it applies to 2.12.

Alas, all I have are volumes 3 and 4 of REVMEDIA. From the index I have it looks like the SEC() writeups are in vol. 1.

You guys still solved my problem, while I was looking for SEC() I came across Volume 4 Issue 3 which contains Utility Disk #4. On it is a utility from Stan Spotts - Wolff Data Systems that will make users. Code and all. I can see the record layout in his code.

recid:@fm:Record:@fm:…:@fm:@record:@fM:"USER"

encrypt entire record

then set @record to "USER" and @record=encrypted value

Much Thanks,

Brian

This works in v2.12:

$INSERT INCLUDE,AREV.COMMON.MAIN

@ANS=USERPASSWORD'

CALL SEC(6)

PW=@ANS

UREC='

UREC=USERNAME

UREC=ACCOUNT

UREC=LOGONVERB

UREC=RESTRICTIONS

UREC=ENVIRONMENT

UREC=VIDEO

UREC=PW

UREC=RESTART ;* COMMAND:@VM:CODE

@ANS=UREC

CALL SEC(6)

@RECORD=USER'

@RECORD=@ANS

OPEN 'SYSTEM' TO SYSTEM THEN WRITE @RECORD ON SYSTEM,USERNAME

replace all occurances of @RECORD with UREC…

This is very similar to the code I found.

Thanks for taking the time to dig it out for me.

Brian

View this thread on the forum...