Managing Samba-3.0.21: The pdbedit utility, part 2

The pdbedit tool in Samba-3 is the only one that can manage account security and policy settings. As I said in part one of this tip, having control of account security and policy settings

    Requires Free Membership to View

is important to businesses that must comply with the Sarbanes-Oxley Act of 2002. Now, I'll show you how to put pdbedit to work creating Linux system user and group accounts; assembling Windows group accounts, thus mapping Windows group accounts to Linux group accounts; adding Windows user accounts; and establishing network access policies and controls.

First, let's get on with the establishment of Linux system user and group accounts.

Two group accounts will be created, one for scientists, and one for managers:

root #> groupadd scientists
root #> groupadd managers

Two user accounts will be created here: one for Tom Bryant (scientists), and one for Melinda Stone (managers). Both users require a home directory. The following steps will create these accounts:

  1. root #> useradd -m -c "Tom Bryant" -G scientists -g users tbryant
  2. root #> passwd tbryant
  3. New Password: XXXXXXX
  4. Re-enter New Password: XXXXXXX
  5. root #> useradd -m -c "Melinda Stone" -G managers -g users mstone
  6. root #> passwd mstone
  7. New Password: XXXXXXX
  8. Re-enter New Password: XXXXXXX

Both accounts are specifically created to be primary members of the users group, and secondary members of the respective groups to which they also belong.

Creation of Windows group accounts

Linux group accounts must now be mapped to Windows group accounts. The following commands will map the key Windows domain groups to local Linux system accounts:

  • root #> net groupmap modify ntgroup="Domain Admins" unixgroup=managers
  • root #> net groupmap modify ntgroup="Domain Users" unixgroup=users
  • root #> net groupmap modify ntgroup="Domain Guests" unixgroup=nobody

The next commands will create Windows groups that will match the Linux group accounts:

  • root #> net groupmap create ntgroup="Scientists" unixgroup=scientists type d

Addition of Windows user accounts

The following steps create the SambaSAMAccount entries in the passdb backend that was chosen in the last article (tdbsam). The use of the pdbedit tool will demonstrate the account information that can be managed.

  1. root #> pdbedit -a tbryant
  2. new password: XXXXXXX
  3. retype new password: XXXXXXX
  4. root #> pdbedit -a mstone
  5. new password: XXXXXXX
  6. retype new password: XXXXXXX

Both accounts have now been added. This is demonstrated here:

  • root #> pdbedit -Lw
    • tbryant:6001:0E74DBD7B1C3CC88AAD3B435B51404EE:72BBEAA844F6E0E9CE546CE7E61C963F:[U ]:LCT-439530A0:
    • mstone:6002:744F505BEE319723AAD3B435B51404EE:5F7D844D278CD6898B4022AE766CCA1A:[U ]:LCT-43953197:

SambaSAMAccount information can be displayed using the pdbedit tool:

root #> pdbedit -Lv tbryant
Unix username: tbyrant
NT username:
Account Flags: [U ]
User SID: S-1-5-21-726309263-6128913605-1168186429-13000
Primary Group SID: S-1-5-21-726309263-6128913605-1168186429-1201
Full Name:
Home Directory: \\violetsblue\tbryant
HomeDir Drive: H:
Logon Script: scripts\logon.bat
Profile Path: \\violetsblue\profiles\tbryant
Account desc:
Munged dial:
Logon time: 0
Logoff time: Mon, 18 Jan 2038 20:14:07 MST
Kickoff time: Mon, 18 Jan 2038 20:14:07 MST
Password last set: Mon, 05 Dec 2005 23:37:11 MST
Password can change: Wed, 07 Dec 2005 23:37:11 MST
Password must change: Thu, 19 Jan 2006 23:37:11 MST
Last bad password : 0
Bad password count : 0

The use of the tdbsam backend account database makes it possible to override any of these settings.

Had the smbpasswd backend database been used, it would not be possible to change these settings, because this database does not store the advanced attributes of the SambaSAMAccount data structure.

It is possible to set a forced password change for just one user in the following:

root #> pdbedit --pwd-must-change-time="2006-01-31" \
--time-format="%Y-%m-%d" tbryant
Unix username: tbryant
Password last set: Mon, 05 Dec 2005 23:37:11 MST
Password can change: Wed, 07 Dec 2005 23:37:11 MST
Password must change: Tue, 31 Jan 2006 00:00:00 MST

In many cases, it is more desirable to create a global network access policy than to be required to set each account separately. The global setting must be in place before user accounts are created, otherwise the old settings will continue to be used. The per-user settings override the global settings.

In the following example, a global policy will be implemented. The policies that can be set include:

  • min password length
  • password history
  • user must logon to change password
  • maximum password age
  • minimum password age
  • lockout duration
  • reset count minutes
  • bad lockout attempt
  • disconnect time
  • refuse machine password change

In our example, we will implement stringent Sarbanes-Oxley compliance settings.

  • root #> pdbedit -P "min password length" -C 8
  • description: Minimal password length (default: 5)
  • account policy "min password length" value was: 5
  • account policy "min password length" value is now: 8

The policy was set to eight characters. Security conscious sites may want to set this to 14 characters:

  • root #> pdbedit -P "password history" -C 5
  • Length of Password History Entries (default: 0 => off)
  • account policy "password history" value was: 5
  • account policy "password history" value is now: 5

In the example above, the last five passwords will be remembered. This means that an old password can be reused only after six unique passwords have already been used. We want a minimum password age of 45 days (3888000 seconds).

  • root #> pdbedit -P "minimum password age" -C 3888000
  • description: Minimal password age, in seconds (default: 0 => allow immediate password change)
  • account policy "minimum password age" value was: -1
  • account policy "minimum password age" value is now: 3888000

A password can be changed only after 45 days:

  • root #> pdbedit -P "maximum password age" -C 3888000
  • account policy "maximum password age" description: Maximum password age, in seconds (default: -1 => never expire passwords)
  • account policy "maximum password age" value was: -1
  • account policy "maximum password age" value is now: 3888000

Passwords must be changed every 45 days. This means that an old password can be re-used only after 270 days. If the minimum password age is left at the default, a smart user can simply enter six new passwords and then reset the original password in rapid succession, thereby defeating the controls.

  • root #> pdbedit -P "bad lockout attempt" -C 3
  • description: Lockout users after bad logon attempts (default: 0 => off)
  • account policy "bad lockout attempt" value was: 0
  • account policy "bad lockout attempt" value is now: 3

The setting above ensures that the user account will be locked out after three failed logon attempts. This is an important means by which password cracking attempts may be thwarted.

Where an LDAP password back end is used, the policy settings must be exported to the LDAP directory. This can be done by executing:

root #> pdbedit -y -i tdbsam -e ldapsam

It must be noted that the full capabilities mentioned in this article were stabilized in the Samba-3.0.21 release. Where Sarbanes-Oxley compliance is required please use the most recently released stable version. At the time of writing this is 3.0.21.

The use of the Samba pdbedit tool has been shown to be a simple matter. Once you have mastered it, you'll be ready to move on to the next phase of mastering Samba management: the practical use of the net command, both for initiation configuration as well as for on-going system maintenance. That's the topic of the next episode in my Managing Samba series.

About the author: John H. Terpstra is chief technology officer at PrimaStasys Inc., and a member of SearchOpenSource.com's Editorial Advisory Board. He is author of the new books, Samba-3 by Example: Practical Excercises to Successful Deployment, 2nd edition and The Office Samba-3 HOWTO and Reference Guide, 2nd Edition.

This was first published in December 2005

There are Comments. Add yours.

TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.