ClearFoundation

How do I create user accounts in ClearOS without a password?

The reason behind this:
I have 8 laptops setup running Vista, each has a password protected admin account and 2 student accounts without passwords. I want to create user accounts in ClearOS also without passwords where the user name matches the WIndows account names, so that I can map from Windows to the ClearOS home folder for the account, to make a very easy storage shares for the students.

The laptops have deepfreeze installed, so any changed student files get nuked upon reboot, and share on ClearOS would allow them a safe place to store in process class files.

Currently the back server is running SME server with passwords, I want to switch to ClearOS as the SME community seems to be self-destructing and I like where ClearOS is going. But when trying to create user accounts they will not create without passwords. How can I work around this?

Thanks
Shawn

----------------

Never mind, I found a work around that meets my needs for now. Though I really hope this is something the developers can address in the next release. The Administrator really should have the ability to control the password requirements.

OK, I see that in 5.2 there is a password policy engine, that's great, now I can control the password policy myself. Woo Hoo!.

Downloading now and installing this afternoon to test on Virtual box, maybe live into production next week.

Ah well, it was wishful thinking. The password policies in 5.2 are very limited and actually give you no real control over passwords themselves after all with the exception of length, but even then you don't have real control as 5 characters is the minimum allowed. So much for those of us who use ClearOS being able to choose our own policies. What a disappointment.

Just to fill in some background on the topic, I posted the following in a response to Shawn H's blog comment.

You should consider the password policy engine version 1.0. Many in the open source world use the "release early, release often" approach to software development. This basically means: release a basic version of the software early and then fine tune based on the input provided by users/admins/partners. Why do software development teams do this? The process of creating detailed user requirements and then building the "end product" doesn't work with many software products (including ClearOS). That doesn't mean we didn't go through the process of gathering requirements. It means that we gather the requirements, write a technical specification -www.clearfoundation.com/docs/developer/f..._policy_engine/start - and then shape a "safe" early version. By "safe" I mean that we won't back ourselves into a corner (for example, we pulled the "lock account after X failed attempts" feature just to be safe).

Your comment proves that the "release early, release often" model bears fruit! From talking to partners, to listening to subject matter experts, to trolling the forums, to learning about various regulatory requirements (HIPAA!)... not one mentioned the ability to have passwordless accounts. I'll continue the technical discussion on your forum post (this one)

To make a log story short, consider "passwordless accounts" a new requirement for the policy engine.

My gut tells me that this will be a no-no in the regulatory world. That doesn't mean it won't be able to be implemented, it just means that it may only be available via an advanced setting or command line option.

Oh... this is also relevant.

You should know that per-account password policies will be added in a future release. Before we can implement this level of detail, we need to improve the user/group plugin infrastructure in ClearOS. What do I mean by this? Any new "user aware" application may have its own set of user preferences.

- Drive letter for Samba shares
- Roaming profiles for primary domain users
- Static IP address for PPTP VPN users
- Extension number for VoIP/PBX accounts
- etc.

The password policy engine will fall into this same framework. The framework will exist in ClearOS 6.0. After that, it will be a matter of implementing the necessary bits for per-account password policies.

Wow, what an amazing response, thank you so much Peter.

I am very happy to hear that this is on the radar, you point regarding Version 1.0 and release early, release often are well taken. My apologies for sounding like such a grump in my post, it was not a good day for me.

So far I am very impressed with the stability of 5.2 and especially with the speed, the web interface is much perkier than before and much more responsive. I haven't had as much time as I want to play with it, but will be beating on it shortly.

As soon as the next Alpha or Beta is ready I would love to test it out and see what it can do.

ClearOS rocks and so does the group behind it.

Ciao
Shawn

Peter Baldwin wrote:
Just to fill in some background on the topic, I posted the following in a response to Shawn H's blog comment.

You should consider the password policy engine version 1.0. Many in the open source world use the "release early, release often" approach to software development. This basically means: release a basic version of the software early and then fine tune based on the input provided by users/admins/partners. Why do software development teams do this? The process of creating detailed user requirements and then building the "end product" doesn't work with many software products (including ClearOS). That doesn't mean we didn't go through the process of gathering requirements. It means that we gather the requirements, write a technical specification -www.clearfoundation.com/docs/developer/f..._policy_engine/start - and then shape a "safe" early version. By "safe" I mean that we won't back ourselves into a corner (for example, we pulled the "lock account after X failed attempts" feature just to be safe).

Your comment proves that the "release early, release often" model bears fruit! From talking to partners, to listening to subject matter experts, to trolling the forums, to learning about various regulatory requirements (HIPAA!)... not one mentioned the ability to have passwordless accounts. I'll continue the technical discussion on your forum post (this one)

To make a log story short, consider "passwordless accounts" a new requirement for the policy engine.

My gut tells me that this will be a no-no in the regulatory world. That doesn't mean it won't be able to be implemented, it just means that it may only be available via an advanced setting or command line option.

No worries Shawn... there was a similar reaction within the development team too. We didn't get far enough with the password policy engine in 5.2. In retrospect, I should have pushed it further during the beta.