| ||
|
●ユーザー認証機能改善
Sambaを利用するには，従来UNIX/Linuxのアカウントの（/etc/passwdファイルなどへの）登録と，Sambaアカウントの（/etc/samba/smbpasswdファイルなどへの）登録の両方が必要であった。そのため管理コストが不要に増大してしまう。Samba 3.0ではユーザー認証機能を再設計し，UNIX/Linuxアカウントが存在しなくてもSambaを利用できるようになった。
また，対応認証方式の拡充も実現し，表1[拡大表示]に示すような複数の認証方式を柔軟に組み合わせて利用できるようになった。これにより，LDAP認証を利用する際のシステム構築の手間が削減される。というのもSamba2.2では，LDAP認証使用時はLDAP以外の認証が使えなかったからである。このため，通常認証とLDAP認証の2種類のSambaパッケージを作成する必要があった。しかしSamba3.0では，その必要がなくなる。
複数の認証方式を利用する際は，Sambaの設定ファイル「smb.conf」に図2[拡大表示]のように，認証方式の優先度に応じて左から，認証方式や認証用データベースを指定する。
なお，Samba 3.0の標準認証方式はLDAPに変更されている。そのため，Samba 2.2の標準設定と同じ動作をさせるには，
passdb backend = smbpasswd
と，明示的に認証方式を指定する必要がある。ただし，Sambaをドメイン・コントローラにし，WindowsのActive Directoryのような大規模なユーザー管理を行う際には，LDAP認証を利用した方が良い。LDAP認証についての詳細は後述する。
●ファイル名変換機構の再実装
Linux/UNIXでは，1つのファイルには1つのファイル名しか存在しない＊4。しかしWindowsでは，1つのファイルに，MS-DOS時代からの名残りである8.3形式のシフトJISコードで表現されるSFN（短いファイル名）と，Windows NTからサポートされたUnicodeで表現されるLFN（長いファイル名）の2つのファイル名が存在する。このうち，LFNはLinux/UNIXのファイル名をそのまま利用すれば良いが，SFNについてはSambaで生成してやる必要がある。
SFNを生成するSambaの機能は，名前マングリング（Name Mangling）と呼ばれている。
ところが従来のSamba2.2では，同機能の変換アルゴリズムが単純でSFNの衝突が発生しやすい問題があった。クライアントから要求された際に，SFNを動的に生成する仕様だったことで，SFNがタイミングによって変化する（永続的でない）問題もあった。
Samba3.0では，生成したSFNを内部データベースで管理することで，LFNとSFNの対応付けが崩れないように改良している。また，SFN生成方式も見直し，ファイル名の衝突が生じにくいアルゴリズムを採用した。これらの改良により，ユーザーやアプリケーションが想定しないファイルが更新されるという問題が減少する。
ただし，ファイル名処理部分のコードが大幅刷新されたため，従来，Samba日本語版で提供していた日本語ファイル名処理用の改修プログラムが利用できなくなった。ベータ2の段階でも，日本語ファイル名がうまくSFNに変換されなかったり，ファイルにアクセスできなくなるなどの問題が発生している。
●netコマンドのサポート
Windowsにおけるネットワーク管理/ユーザー管理用コマンドであるnetコマンドが，Sambaでもサポートされるようになった。Samba 3.0付属のnetコマンドを利用すると，Sambaサーバーに対してもWindowsサーバーに対しても表2のような操作が行える。
●Windows NT4.0からの移行機能
Windows NT4.0サーバーをPDCとしてWindowsドメインを構築している環境で，Samba 3.0をPDCとして稼働させるための移行コマンドも用意されている。これは「VAMPIRE（吸血鬼）機能」と呼ばれるもので，BDCとしてドメインに参加させたSambaサーバーに，PDCのユーザー情報やグループ情報を複製する機能である。情報複製後にSambaサーバーをPDCとして設定し直せば，そのまま従来のドメインを引き継げる。なお，情報の複製にはnetコマンドを次のように実行する。
$ net vampire
●NTドメインとの信頼関係
Samba 2.xでは，Windows NT4.0ドメインと信頼関係を結ぶことができなかった。このため，リソース・ドメイン（マシン・アカウント管理）とユーザー管理ドメインを分けて構築し，リソース・ドメインがユーザー管理ドメインを信頼することで運用コスト削減や拡張性を確保していたシステムを，そのままSambaドメインに移行することができなかった。しかし，Samba 3.0では，netコマンドを使ってWindows NT4.0ドメインとの信頼関係を結ぶことが可能になった。これにより，こうしたシステムからの移行や部署単位でのネットワーク管理の委譲といったことが容易に行える。
●ユーザー/グループIDの統一管理
Samba 2.2.2以降に同こんされる「winbind」というソフトウエアを利用すると，Linux/UNIXシステムのユーザー管理を，Windowsドメインのドメイン・コントローラに任せられる。これにより，ユーザー管理の統一が実現できるが，Windowsにおけるアカウント情報を判別するRID（Relative ID）と，Linux/UNIXのユーザーID/グループIDとの対応付けは各システムごとに行われていた。
そのため，同一ユーザーに対して，各Linux/UNIXシステムでばらばらなユーザーID/グループIDが割り当てられることがあった。これではアカウント管理を統一するメリットが減少してしまう。
Samba3.0では，RIDとユーザーID/グループIDのマッピングをLDAPサーバーに保存することで，すべてのマシンで，同一のRIDに同一のユーザーID/グループIDを割り振ることを保証している。
