Open Source Document Management System | OpenKM

Comments: In many companies the name \'admin\' cannot be used as an LDAP account name so hard coding the \'admin\' name to the functional ability to display the Administrator Tab will never fly in many companies. I am not sure why this is needed as I\'ve never seen any other systems do this before but it may kill this as a potential solution for us at the company I currently work for.

Question: Is there a way to have both a local (default) security schema setup where the admin account is stored locally without requiring a LDAP version and have the rest of the users authenticate through LDAP?

If we wanted to change the source so that the hardcoded \'admin\' account matched our internal naming requirements how hard of an undertaking would that be. In other words is this just referenced in some very specific areas that you could point us to or is it located in hundreds of places in the code. I know that you recently changed it from system to admin so the requirement has been there before.

If not, are there any plans to change the handling for the \'admin\'account to something that is not hardcoded?

Actually \"admin\" is hardcoded. We will change this to \"okmAdmin\" in future OpenKM releases. I hope this issue to be solved with this (last?) administrator username change.

Actually, the okmadmin account would not work with our polices either as our polices state that the work admin cannot be used as any part of the account even if it has a prefix or suffix. I would like to offer a suggestion that might resolve this headache for you and all your potential customers.

Why not use an \'Alias\' during install that would allow me to assign a different name that fit our polices and allow you to keep your internal structure anyway you wanted it in terms of naming conventions.

I have seen this used in other systems and it works very well where the issue is the same thing. Since the \'Alias\' would be given at installation time there would be no concern over security as well.

I really believe that unless you come up with a strategy close to this idea you will continue to run into organizations that could rule your product out of consideration as an application strictly because of this limitation around the account name required for administration of the product.

This change can be made easy right now. Perhaps in a future release... The quickest fix is change source code and recompile.

I have a developer that has changed your source and recompiled not for an \'Alias\' but to change the \'Admin\' name to our required conventions. Our current problem is understanding how to assign the \'AdminRol\' to the person who is the administrator when connected by LDAP using Active Directory.

When connected to LDAP (Active Directory in this case, do the roles have to come from LDAP as well or can you chain authentication so that JBOSS uses LDAP to authenticate the user id and the local hypersonic database where default user information is stored to provide the roles?

If so, how would we structure that in the configuration file or what class do we need to look at in order to just force the role until you get the potential change in place for the next version for using an \'alias\'?

Well, the best configuration is to get OpenKM users and roles from LDAP, not only users. You have to create and AdminRol in LDAP and assign to your admin user.