Implementing Password Policy - System Tables

markborges

Hi everyone,

When talking about Password Policies (minimun length, expiration date/regular changes), everybody knows that Navision Native Dabase is not a master. :roll:

The problem in our company is that no SQL Server is allowed and we all MUST use the Native database.

So, I was thinking in a way of programatically changing the password policies through modifications in system tables, such as User table (Table 2000000002).

What I was thinking:

- Create a "Last Modified at" and "Last Modified by" field in this table
- On OnModify() of the table I would put some code to save the Last Modification Date and User ID.

Based on that I could have monthly/weekly reports telling me the last date of modification for all user logins, and then I take some action upon the results (asking users to change their password regularly, or something like that).

The question is:

- How comfortable do you people feel about changing System tables?

I did some testing in a test database we have, and it seemed Harmless to the database. It did not act weirdly nor caused any visual impact (warning messages, error messages, and so on) to me.


Has anybody ever tried this kind of things? Does anybody have any comments on that?

Hope to hear from you and thanks in advance,

Luc_VanDyck

I have modified the User-table once, to check the length of the entered password. For a particular client, passwords < 8 characters were not allowed.

I didn't experience any problems with changing this table.

bbrown

Why don't you just use Windows Authentication? Then everything is controlled by Directory Services from which you can establish password policy.

markborges

I thought of using Windows Authentication, but this would disable us from having 2 different users logged at the same machine...

This happens a lot in our industry... We may have 2 different users logged at the same time at the same computer doing tasks alternately...

So... no Windows Authentication...

bbrown

markborges wrote:

I thought of using Windows Authentication, but this would disable us from having 2 different users logged at the same machine...

This happens a lot in our industry... We may have 2 different users logged at the same time at the same computer doing tasks alternately...

So... no Windows Authentication...

I'd be interested in hearing more about this requirement. On the surface, it doesn't sound very efficient.

Have you considered Terminal Services? You could then use Windows Authentication and 2 (or more) users could open independent RDP sessions on the same computer.

markborges

Hi bbrown, actually it's not a requirement.

It's done for a more practical approach. The usual way, the 1st user would open Navision, post something, then close. Then the 2nd user would open Navision, post something, then close. And so on...

Your idea of using multiple RDS's in the same machine sounded good, and I could really think of a better password policy together with our AD Adminstrator, and then use Windows Authentication. Thanks! =D>

But, regarding the changes on system tables, I'm still open to any comments... :-k

Regards,

David_Singleton

markborges wrote:

I thought of using Windows Authentication, but this would disable us from having 2 different users logged at the same machine...

This happens a lot in our industry... We may have 2 different users logged at the same time at the same computer doing tasks alternately...

So... no Windows Authentication...

So why the comment:

markborges wrote:

The problem in our company is that no SQL Server is allowed and we all MUST use the Native database.

that is confusing? :-k

Anyway, I have often modified the login table with no problems. Just be careful what you do, and make sure not to create a scenario where you can make it impossible to login to the database. Also keep in mind the thing that you WILL forget at least once, and that is that the code will be called before CU1, so you need to close NAV each time to test your own work. The first time I did work like this it took me some time to work out why my code was not being triggered. And once its in place, really really never touch that code on the live system, one silly mistake, and you could lock out the whole database.

markborges

David Singleton wrote:

markborges wrote:

I thought of using Windows Authentication, but this would disable us from having 2 different users logged at the same machine...

This happens a lot in our industry... We may have 2 different users logged at the same time at the same computer doing tasks alternately...

So... no Windows Authentication...

So why the comment:

markborges wrote:

The problem in our company is that no SQL Server is allowed and we all MUST use the Native database.

that is confusing? :-k

Hi David...

Why confusing?

The SQL Server comment was posted first, so people could know that I'm not able to use any of SQL Server password facilities (I don't even know if there any in SQL Server :-k)...