Samba-ad-dc スキーマ拡張

ユーザーに設定された情報を使って、とあるサービスにアクセスできる・できないを判断しようと考えた。
ユーザーにはたくさんの属性があるから、どこかに空きがあるんじゃないかと思ったからなのだが、仮に空いていたとしてもそれを使って良いのかどうかはよく分からない。

では、属性を追加してみよう。大変そうだけれど。

ユーザーに属性を追加

他にも方法はあるのだと思うけれども、過去の経験によればKopanoがユーザーに属性を追加していたから、それを参考にながらやってみることにした。

大まかな考え方はこちら。

OIDを取得。属性やクラスには一意のIDを振る必要がある。
属性(attributeSchema)を作り、補助クラス(classSchema & カテゴリ3)でまとめる。
クラス”user”で、作成した補助クラスを取り込む。

一度スキーマを拡張すると、無効にはできても削除はできないそうだ。
慎重に計画し、ADのバックアップを取り、スキーマを拡張してテストする、という工程になる。

OIDの取得

OIDは一意なものを用意する必要があり、取得方法は色々あるそうだ。

今回はMicrosoftが用意してくれたスクリプトを使って取得することにした。
Microsoft Build / Microsoftからのオブジェクト識別子の取得

65行目の出力先を有効なディレクトリに書き換える。

oidgen.vbs

outFile="C:\Users\Administrator\Desktop\oidInfo.txt"

このスクリプトを実行するとoidInfo.txtが生成され、そこに取得したOIDが書き出されている。
14要素の強烈に長いものだったが、一意のOIDを無償で提供してくれているのだから当然のことだろう。

oidInfo.txt

Your root OID is: 
1.2.840.113556.1.8000.2554.54552.28343.60074.18066.44903.10734029.10241330

<説明は省略>

説明部分をDeepL先生に翻訳してもらって、少し手直し。

この接頭辞は、スキーマの属性やクラスの名前に使用されます。
たとえば、接頭辞が “Microsoft” の場合は、スキーマ要素に “microsoft-Employee-ShoeSize” のような名前を付ける必要があります。
接頭辞の詳細については、『server Application Specification』（http://www.microsoft.com/windowsserver2003/partners/isvs/appspec.mspx）の「スキーマ命名規則」を参照してください。

OIDに.Xを付加することで、新しいスキーマ・クラスや属性のための後続のOIDを作成することができます。
一般的なスキーマ拡張スキームは、一般的に以下のような構造を使用されます：
もし、割り当てられた OID が 1.2.840.113556.1.8000.2554.999999

であれば、クラスは以下のようになります： 1.2.840.113556.1.8000.2554.999999.1
最初のクラスのOIDは次のようになります: 1.2.840.113556.1.8000.2554.999999.1.1
2番目のクラスのOID：1.2.840.113556.1.8000.2554.999999.1.2 など…

この例を使用すると、属性は以下のようになります： 1.2.840.113556.1.8000.2554.999999.2
最初の属性のOIDは次のようになります： 1.2.840.113556.1.8000.2554.999999.2.1
2番目の属性のOID：1.2.840.113556.1.8000.2554.999999.2.2 など…

説明の中にURLがいくつか書かれているのだけれど、だいぶ古いものらしく存在しないページもあった。
今にあわせて情報を探した方が良さそうだ。

ADのバックアップ

スキーマ拡張でシステムを壊してしまったら大変なので、バックアップを取っておく。

Samba ad dcは過去やったことに基づいて整理。
その他、AWSとWindows Serverについて調べてみたのでメモしている。

Samba

バックアップについては、過去に2通り試している。
リンクは過去記事で、ちょっと特殊ではある…

自作ツールでバックアップを取っておいて、いざとなったら元に戻す。
ドメインコントローラーが1つならこれでもいいかもしれない。
それなりに頑張ってはいるけれども、ツールの信頼性はあくまで個人レベル。
標準の方法でバックアップを取っておいて、いざとなったらリストア用のドメインコントロラーを作って元に戻す。
壊れてしまったサーバーを、リストア用のドメインに参加させて復旧する。
複数のドメインコントローラーを運営しているならこれ一択、手間は掛かるけれども確実に元に戻せるはず。

今回はホームラボでこの操作を試そうとしているので、前者を選択した。

その他

AWSのディレクトリサービスでは、スキーマ拡張のやり方を一通り教えてくれていて、そこで元に戻すことについて言及されていた。
【AWS Security Blog】スキーマを拡張してMicrosoft ADディレクトリにアプリケーションのサポートを追加する方法

Windows Serverについてもやり方を一通り教えてくれている。
仮想サーバーのスナップショットでもできることはできるんだけれど、お勧めはしないということのようだった。
ドメインコントローラーのバックアップとリストアについて

属性追加の準備

属性とクラスを計画し、ldifというファイルを作る。

クラス： hogeclass
属性： hogestring(文字列型)、hogevalue(数値型)

こちらでスキーマ拡張について説明してくれていて、テンプレートも作ってくれている。
Samba Wiki / Samba AD schema extensions

lDAPDisplayNameは絶対に変えてはいけない、とされている。
Microsoftのサイトでも変更できないと書かれているから、やっちゃいけないことのようだ。

属性

テンプレートを見ながらこんなのを作ってみた。

attrs.ldlif

dn: CN=hogestring,CN=Schema,CN=Configuration,DC=hogeserver,DC=hogeddns,DC=jp
objectClass: attributeSchema
attributeID: 1.2.840.113556.1.8000.2554.54552.28343.60074.18066.44903.10734029.10241330.2.1
lDAPDisplayName: hogestring
description: String type
attributeSyntax: 2.5.5.5
isSingleValued: TRUE

dn: CN=hogevalue,CN=Schema,CN=Configuration,DC=hogeserver,DC=hogeddns,DC=jp
objectClass: attributeSchema
attributeID: 1.2.840.113556.1.8000.2554.54552.28343.60074.18066.44903.10734029.10241330.2.2
lDAPDisplayName: hogevalue
description: Numeric type
attributeSyntax: 2.5.5.16
isSingleValued: TRUE

attributeSyntaxで型が指定できるようだった。
Microsoft Build / Active Directory スキーマ – 構文

使いそうなものだけメモしてみる。

Syntax ID	Name	説明
2.5.5.8	Boolean	TRUEまたはFALSE
2.5.5.9	Integer	符号付き32ビット整数
2.5.5.16	LargeInteger	符号付き64ビット整数
2.5.5.5	String(Printable)	印刷可能な文字セット、大文字小文字が区別される
2.5.5.12	String(Unicode)	ユニコード文字、大文字と小文字を区別しない
2.5.5.11	String(Generalized-Time)	一般化時刻(YYYYMMDDHHMMSS.0Z) 20240511065612.0Z 20240511155612.0+0900

クラス

テンプレートを見ながらこんなのを作ってみた。

classes.ldif

dn: CN=hogeclass,CN=Schema,CN=Configuration,DC=hogeserver,DC=hogeddns,DC=jp
objectClass: classSchema
governsID: 1.2.840.113556.1.8000.2554.54552.28343.60074.18066.44903.10734029.10241330.1.1
lDAPDisplayName: hogeclass
subClassOf: top
objectClassCategory: 3
description: My class
mayContain: hogestring
mayContain: hogevalue

クラスには3つの分類があった。
Microsoft Build / Active Directory Domain Services – 構造クラス、抽象クラス、および補助クラス

objectClassCategory	分類
1	構造クラス
2	抽象クラス
3	補助クラス

Kopanoの例を見ると、補助クラスというのを作って属性を入れておき、それをUserクラスに入れておくことで、Userクラスに属性を追加しているらしい。
マネする。

クラス”user”で補助クラスを取り込む

過去記事や、AWSの解説などから、これでいけそうというものを作ってみた。

modify.ldif

dn: CN=User,CN=Schema,CN=Configuration,DC=hogeserver,DC=hogeddns,DC=jp
changetype: modify
add: auxiliaryClass
auxiliaryClass: hogeclass

属性を追加するためのファイルが完成した。

属性追加

いよいよ属性追加。

ホームラボで運営しているSamba ad dcに入って、属性、補助クラスを追加。
最後にユーザーに補助クラスを追加。

$ sudo docker exec -it samba bash --login

# ldbadd -H /var/lib/samba/private/sam.ldb attrs.ldif --option="dsdb:schema update allowed"=true
Added 2 records successfully

# ldbadd -H /var/lib/samba/private/sam.ldb classes.ldif --option="dsdb:schema update allowed"=true
Added 1 records successfully

# ldbmodify -H /var/lib/samba/private/sam.ldb modify.ldif --option="dsdb:schema update allowed"=true
Modified 1 records successfully

AWSではWeb UIがあるみたい。
Winodwsはコマンドがありそうだが、調べていない。

テスト

追加した属性に値がセットできるか試してみる。

# samba-tool user edit hoge

エディタが開くので、属性値を追加して保存。

hogestring: test string テスト文字列
hogevalue: 123

以下が表示されれば成功。

Modified User 'hoge' successfully

日本語コードも保存できていた。

また、hogevalueに文字を入れてみたところ、エラーで更新ができなかった。
属性の型もちゃんと反映されているようだった。

ERROR(ldb): Failed to modify user 'hoge':  - objectclass_attrs: attribute 'hogevalue' on entry 'CN=User Hoge,CN=Users,DC=hogeserver,DC=hogeddns,DC=jp' contains at least one invalid value!

Active Directory ユーザーとコンピューターでも、拡張機能を有効にして、各ユーザーのプロパティから属性エディタを開けば、値を参照することができた。

メモ

LDB

LDBはSambaのデーターベースエンジンで、LDAPに似ているが準拠しているわけではない、とされている。

スキーマの情報は/var/lib/samba/private/sam.ldbにあった。
過去にKopanoが追加したスキーマを探してみる。

# ldbsearch -H /var/lib/samba/private/sam.ldb -b CN=Schema,CN=Configuration,DC=hogeserver,DC=hogeddns,DC=jp "(&(cn=Kopano*)(objectClass=attributeSchema))"
# ldbsearch -H /var/lib/samba/private/sam.ldb -b CN=Schema,CN=Configuration,DC=hogeserver,DC=hogeddns,DC=jp "(&(cn=Kopano*)(objectClass=classSchema))"

表示させる属性を絞ることができる。

# ldbsearch -H /var/lib/samba/private/sam.ldb -b CN=Schema,CN=Configuration,DC=hogeserver,DC=hogeddns,DC=jp "(&(cn=Kopano*)(objectClass=classSchema))" dn cn objectClass

LDAPを通じてアクセスすることもできる。

# ldbsearch -H ldap://localhost -b CN=Schema,CN=Configuration,DC=hogeserver,DC=hogeddns,DC=jp "(&(cn=Kopano*)(objectClass=classSchema))" -U rohhie

ただ、ホームラボではLDAPSを指定したら上手くいかなかった。
構築した環境、もう一段の改善が必要…

LDAP

LDAPでアクセスすることも試してみた。
LDBとほとんど一緒。

LDAPSは暗号化されているので、シンプルバインドが可能。

# ldapsearch -H ldaps://localhost -b CN=Schema,CN=Configuration,DC=hogeserver,DC=hogeddns,DC=jp -D rohhie@hogeserver.hogeddns.jp -W "(&(cn=Kopano*)(objectClass=classSchema))" dn cn objectClass

ホームラボではstrong authを求めているため、LDAPではSASL認証が必要。

ここではGSSAPIを使うことにして、インストールしていなかったライブラリがあったので追加。
チケットを取りだしてコマンドを実行する。

# apt install libsasl2-modules-gssapi-heimdal
# kinit rohhie
# ldapsearch -H ldap://localhost -b CN=Schema,CN=Configuration,DC=hogeserver,DC=hogeddns,DC=jp -Y GSSAPI "(&(cn=Kopano*)(objectClass=classSchema))" dn cn objectClass

LDAPSの環境をちゃんと整えている場合は、LDAPSの方が楽な感じ。

Active Directory スキーマ

どんな構造になっているのかを知るためには、グラフィカルに色々見えると楽。

Active Directory スキーマというスナップインを使えるようにするため、コマンドプロンプトを「管理者」で開き、schmmgmt.dllというOLEコントロールを登録する。

>regsvr32 schmmgmt.dll

メッセージボックスで、

RegSvr32

schmmgmt.dll の DllRegisterServer は成功しました。

が表示されれば準備OK。

続いて、コマンドラインから mmc を起動する。

>mmc

ファイル → スナップインの追加と削除でダイアログを開き、Active Directory スキーマを追加してOKを押す。
これでスキーマを操作できるようになる。

ファイル → 名前を付けて保存で適当な名前を付けてデスクトップにでも保存しておけば、拡張子mmcのファイルが作られる。
ダブルクリックすればActive Directory スキーマがすぐに使える。

さいごに

スキーマ拡張は失敗するとシステムが壊れてしまうので、Samba ad dcのデフォルトでは、スキーマが変更できないようになっている。
今回は、それを一時的に外すパラメーターを使って拡張した。

この属性を管理者以外に見えないようにするとか、編集できないようにする、といったこともきっとできるのだろう。
でも、ちょっと探した感じでは全く方法の想像がつかなかったので、今後の課題としておく。