最新 追記

だめだめ日記

ツッコミの内容は検索サイトからの検索やサイトのレーティングに影響します。そのため問題があるキーワードを含むと思われるツッコミについては、当方の判断で削除することがあります。予めご了承ください。 なお、コメントspamと判断されたツッコミは自動的に消去されます。ご容赦ください。
2002|12|
2003|01|02|03|04|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|05|06|09|10|11|12|
2013|01|02|02|03|08|09|
2014|01|
2015|09|10|11|
2016|01|04|

執筆、翻訳などに関わった書籍類


【改訂新版】Samba [実践]入門

Linux教科書
LPICレベル3 300試験

マスタリング Nginx

実践 パケット解析 第2版

改訂版 Sambaのすべて

アンドキュメンテッド
Microsoftネットワーク

その他の書籍は だめだめ日記のおみせ@本店でどうぞ。



2015年10月01日 [長年日記]

[Windows][Samba]AzureのファイルサーバにSambaから接続

このあたりをみたら、いままでプレビュー版だったAzureのFile Storage機能がGAされたとあったので、とりあえず試してみました。

Windowsからももちろんつなげたんですが、一応smbclientからつないでみました。こんな感じ

azureuser@ubuntu1404-03:~$ smbclient -m SMB3 //ストレージアカウント.file.core.windows.net/share1 -U ストレージアカウント%キー
Domain=[X] OS=[] Server=[]
smb: \> dir
  .                                   D        0  Wed Sep 30 16:47:04 2015
  ..                                  D        0  Wed Sep 30 16:47:04 2015
  test.txt                            A       12  Wed Sep 30 16:47:20 2015

                83886080 blocks of size 65536. 83886079 blocks available

ドメイン名は上記のとおり「X」で、OS名、サーバ名は空欄でした。ここは伏せ字にしたわけではありません。

ちなみに、アクセス許可はサポートされてないようで、Windows側から参照すると「セキュリティ」タブが表示されず、無理やりCACLSでアクセス許可をみようとしても、

X:\>cacls test.txt
Cacls コマンドは、NTFS ファイル システムを使用しているディスク ドライブのみで実行できます。

といった感じでした。

追記(10/06)

このあたりを読むと、Azureのストレージへのアクセス制御は、SASモデルを使ってくださいとかあるんですが、これがFile Storage機能とどう絡むのかがよくわからない……

なんか面倒そう。

追記(10/23)

このあたりを読むと、SASはREST APIでのみサポートとあります。

ということで、現状SMB接続では実質アクセス制御はできない、と。


2015年10月06日 [長年日記]

[Samba]Samba 4.3.0で7つのFSMOを操作する

Samba 4.3.0 リリースノートに、Samba 4.3.0ではWindowsでは直接参照できないDNSに関するFSMOを操作できるとあったので、試してみました。

まずはFSMOの表示

root@jessie64-1:~# samba-tool fsmo show
SchemaMasterRole owner: CN=NTDS Settings,CN=WIN2K3R2ENT-1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=addom1,DC=ad,DC=local
InfrastructureMasterRole owner: CN=NTDS Settings,CN=WIN2K3R2ENT-1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=addom1,DC=ad,DC=local
RidAllocationMasterRole owner: CN=NTDS Settings,CN=WIN2K3R2ENT-1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=addom1,DC=ad,DC=local
PdcEmulationMasterRole owner: CN=NTDS Settings,CN=WIN2K3R2ENT-1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=addom1,DC=ad,DC=local
DomainNamingMasterRole owner: CN=NTDS Settings,CN=WIN2K3R2ENT-1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=addom1,DC=ad,DC=local
DomainDnsZonesMasterRole owner: CN=NTDS Settings,CN=WIN2K3R2ENT-1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=addom1,DC=ad,DC=local
ForestDnsZonesMasterRole owner: CN=NTDS Settings,CN=WIN2K3R2ENT-1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=addom1,DC=ad,DC=local

DomainDnsZonesMasterRoleForestDnsZonesMasterRoleというFSMOが確認できます。

次は転送

root@jessie64-1:~# samba-tool fsmo transfer --role=all
FSMO transfer of 'rid' role successful
FSMO transfer of 'pdc' role successful
FSMO transfer of 'naming' role successful
FSMO transfer of 'infrastructure' role successful
FSMO transfer of 'schema' role successful
ERROR: Failed to delete role 'domaindns': LDAP error 50    LDAP_INSUFFICIENT_ACCESS_RIGHTS -  <00002098: SecErr: DSID-03151D80, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0> <>

うーん。


2015年10月17日 [長年日記]

[Windows]Azure Active Directory Domain Servicesを触ってみた

このあたりこのあたりをみると、Azure Active Directory Domain Services(略称AADDS)のプレビュー版が使えるようになったということなので、とりあえず触ってみました。

日本リージョンでは未サポートなので、とりあえずサポートされている東アジアで仮想ネットワークを作成の上、既存のAADの「構成」を選択すると、次の画面のように「ドメイン サービス」が表示されているので、「はい」を選択して構成してみます。

AADDSの構成画面

手順に従って、AAD DC Administratorsグループ(必ずこの名前である必要がある)の作成とメンバの追加、メンバのパスワードリセットを行ったうえで、Windowsクライアントを参加させ、RSATで眺めてみました。ちなみにDCのコンピュータ名は初期設定のままのランダムな名称となっています。

AADDSをADUCから参照

こんな感じで、AADで作成されたユーザがAADDC UsersというOU内に格納され、新規にドメインに参加したコンピュータはAADDC ComputersというOUに格納されます。 RSATが英語版なのはOSの日本語化が面倒だっただけで、他意はありません

このAAD DC Administratorsグループに所属するユーザは、ADの管理権があることになっていますが、ADのもつ権限の委任(Delegation)機能により、一部の機能が委任されているだけなので、実際はかなり制限がありました。

できること

  • PCのドメイン参加(コンピュータアカウントの新規作成)
  • 既存のGPOの編集

できないこと

  • ユーザやグループの作成、削除(ユーザやグループの作成、削除はAAD側で行う必要がある)
  • OUやGPOの新規作成
  • 信頼関係の操作
  • Active Directory サイトとサービスからの操作

たとえば、ADUCでドメインのアイコンを右クリックしても、通常なら出てくるはずの「新規作成(New)」メニューが表示されません。ちなみに機能レベルはドメイン、フォレストともにWindows Server 2012 R2でした。

ADUCでドメインのアイコンを右クリック

グループポリシーは、以下の図のように4つが参照できるのですが、実際はDefault Domain PolicyとDefault Domain Controllers Policyは編集できないので、使えるのはAADDCからはじまる名前の2つだけです。

グループポリシーの表示

そんなこんなで機能制限が多いAADDSではありますが、それでもコンピュータの参加とGPOの適用という基本的な機能が実現できるのは大きいと思います。


2015年10月18日 [長年日記]

[Samba][Windows]AADDSにSambaサーバを参加

プレビュー版がリリースされたAADDSに、とりあえずSambaを参加させてみました。 適当に設定を行ってドメイン参加……

root@ubuntu1404-04:/etc/samba# net ads join -U admin01
Enter admin01's password:
Using short domain name -- AZUREx
Joined 'UBUNTU1404-04' to dns domain 'AZUREx.monyo.com'

あっけなく参加できました。 こんな感じで、ユーザ一覧も取得できます。

root@ubuntu1404-04:/etc/samba# wbinfo  -t
checking the trust secret for domain AZUREx via RPC calls succeeded
root@ubuntu1404-04:/etc/samba# wbinfo  -u
AZUREx\guest
AZUREx\krbtgt
AZUREx\dcaasadmin
AZUREx\monyo
AZUREx\user02
AZUREx\user01
AZUREx\admin01

ちなみにsmbclientコマンドで接続してみると、こんな感じ

root@ubuntu1404-04:~# smbclient //10.0.0.4/sysvol -Uadmin01
Enter admin01's password:
Domain=[AZUREx] OS=[Windows Server 2012 R2 Datacenter 9600] Server=[Windows Server  2012 R2 Datacenter 6.3]
smb: \> dir
 .                                   D        0  Sat Oct 17 07:39:05 2015
 ..                                  D        0  Sat Oct 17 07:39:05 2015
 azurex.monyo.com                    D        0  Sat Oct 17 07:39:05 2015

               40957 blocks of size 1048576. 40232 blocks available

Windows Server 2012 R2で構築されてますねということで。


2015年10月24日 [長年日記]

[Samba]Samba 4.3系列でサポートされた外部信頼関係

Samba 4.3.0 リリースノートの翻訳にも言及がありますが、Samba4のSamba 4.3系列からはドメイン間およびフォレスト間の外部信頼関係がサポートされています。

せっかくですので、Samba 4.3.1で検証してみました。

DNS関係の設定

信頼関係を締結する上では、互いのADのDNSゾーンを参照できる必要があります。一番手っ取り早いのは互いに相手のドメインのセカンダリになることなのですが、Samba内蔵DNSはセカンダリゾーンをサポートしていないため、BIND9_DLZで構築してみました。

まずは、Sambaサーバ上でBIND9をConfigure BIND as backend for Samba ADを参考に設定を行い、BIND9_DLZが正しく動作している状態にします。

ついで、互いをセカンダリゾーンとする設定を行います。

WindowsのDNSサーバをBIND9のセカンダリとして設定する際ですが、試した限りBIND9側はデフォルトでゾーン転送を許可しているようで、Windowsサーバ側でBIND9のセカンダリの設定を行っただけで、普通にゾーン転送が行われました。今回は念のため、ドメイン名ゾーンと_msdcs.ドメイン名ゾーンの両方のセカンダリとして構成しました。

BINDをWindowsのDNSサーバのセカンダリとして構成する際は、このあたりなどを参考にして別サーバへのゾーン転送を許可します。

信頼関係の設定

まずはWindows側で双方向の外部信頼の設定を通常通り行います。

ついで、いよいよSamba側で信頼関係の設定となります。

root@jessie64-1:/usr/local/samba/etc# samba-tool domain trust create ADDOM1.AD.LOCAL --type=external --direction=both --create-location=local --no-aes-keys -U Administrator -W ADDOM1
New Incoming Trust Password:    ←入力方向の信頼関係のパスワードを入力
Retype Incoming Trust Password: ←入力方向の信頼関係のパスワードを入力
New Outgoing Trust Password:    ←出力方向の信頼関係のパスワードを入力
Retype Outgoing Trust Password: ←出力方向の信頼関係のパスワードを入力
LocalDomain Netbios[ADDOM2] DNS[addom2.ad.local] SID[S-1-5-21-938814754-xxxxxxxxx-xxxxxxxxxx]
RemoteDC Netbios[WIN2K3R2ENT-1] DNS[win2k3r2ent-1.ADDOM1.AD.LOCAL] ServerType[PDC,GC,LDAP,DS,KDC,TIMESERV,CLOSEST,WRITABLE,GOOD_TIMESERV]
Password for [ADDOM1\Administrator]:
RemoteDomain Netbios[ADDOM1] DNS[ADDOM1.AD.LOCAL] SID[S-1-5-21-2707235770-xxxxxxxxx-xxxxxxxx]
Creating local TDO.
Local TDO created
Validating outgoing trust...
OK: LocalValidation: DC[\\win2k3r2ent-1.ADDOM1.AD.LOCAL] CONNECTION[WERR_OK] TRUST[WERR_OK] VERIFY_STATUS_RETURNED
Success.

--typeとしては、external(外部信頼)かforest(フォレスト間信頼)を指定します。

--directionについては、現状双方向しかサポートしていないとありましたので、bothを指定しました。

--create-locationでは、bothを指定するとWindowsサーバ側の信頼関係の設定も行えるようでしたが、今回はWindows側で事前に設定済ですので、localを指定しました。

最後に、今回は脱Windows Server 2003ということで、Windows Server 2003 R2で検証したため、--no-aes-keysを設定しています。

動作確認(Windows)

まずはWindows側で確認してみました。最初に「ドメインと信頼関係」で「信頼関係の検証を行い、入出力双方とも検証に成功することを確認しました。

ついで、次のように、オブジェクトピッカーで、Sambaで構築したドメインのユーザ(たとえばdns-jessie64-1とか)が参照できることを確認しました。

ユーザ・グループ選択画面

実際に、ファイルのアクセス許可に設定することもできました。

アクセス許可の設定

ログオン画面でも信頼するドメイン名(ADDOM2)が表示されています。

ログオン画面

Sambaで構築したドメインのユーザとして、認証に成功していることを確認。

ちなみに認証に失敗すると、以下のエラーではなく、「ログオンできません」というエラーになります。

ログオン画面

動作確認(Samba)

つぎはSamba側での動作確認です。まずはsamba-toolで確認して、

root@jessie64-1:/usr/local/samba/etc# samba-tool domain trust validate addom1.ad.local -U ADDOM1\\Administrator
LocalDomain Netbios[ADDOM2] DNS[addom2.ad.local] SID[S-1-5-21-938814754-xxxxxxxxx-xxxxxxxxxx]
LocalTDO Netbios[ADDOM1] DNS[ADDOM1.AD.LOCAL] SID[S-1-5-21-2707235770-xxxxxxxxx-xxxxxxxx]
OK: LocalValidation: DC[\\win2k3r2ent-1.ADDOM1.AD.LOCAL] CONNECTION[WERR_OK] TRUST[WERR_OK] VERIFY_STATUS_RETURNED
OK: LocalRediscover: DC[\\win2k3r2ent-1.ADDOM1.AD.LOCAL] CONNECTION[WERR_OK]
RemoteDC Netbios[WIN2K3R2ENT-1] DNS[win2k3r2ent-1.ADDOM1.AD.LOCAL] ServerType[PDC,GC,LDAP,DS,KDC,TIMESERV,CLOSEST,WRITABLE,GOOD_TIMESERV]
Password for [ADDOM1\Administrator]:
OK: RemoteValidation: DC[\\jessie64-1.addom2.ad.local] CONNECTION[WERR_OK] TRUST[WERR_OK] VERIFY_STATUS_RETURNED
OK: RemoteRediscover: DC[\\jessie64-1.addom2.ad.local] CONNECTION[WERR_OK]
root@jessie64-1:/usr/local/samba/etc# samba-tool domain trust  show addom1.ad.local
LocalDomain Netbios[ADDOM2] DNS[addom2.ad.local] SID[S-1-5-21-938814754-xxxxxxxxxx-xxxxxxxxxx]
TrusteDomain:

NetbiosName:    ADDOM1
DnsName:        ADDOM1.AD.LOCAL
SID:            S-1-5-21-2707235770-xxxxxxxxx-xxxxxxxx
Type:           0x2 (UPLEVEL)
Direction:      0x3 (BOTH)
Attributes:     0x4 (QUARANTINED_DOMAIN)
PosixOffset:    0x00000000 (0)
kerb_EncTypes:  0x4 (RC4_HMAC_MD5)

ついで、Sambaで構築したADドメインに参加しているWindows 7マシンから、Windowsで構築したADドメインのユーザでログオンしてみました。


字が小さくて見づらいですが、「システム」ではaddom2.ad.localドメイン(Sambaで構築)に所属しているにも関わらず、左上にあるアクセス許可の設定画面では、aduser01@addom1.ad.localというユーザにアクセス許可が設定されていることが確認できます。

ただし、オブジェクトピッカーで、Windowsで構築したADドメインのユーザなどが参照できるか確認したのですが、参照はできず、アクセス許可の設定もできませんでした。

信頼関係の削除

こんな感じ

root@jessie64-1:/usr/local/samba/etc# samba-tool domain trust delete addom1.ad.local -UADDOM1\\Administrator
LocalDomain Netbios[ADDOM2] DNS[addom2.ad.local] SID[S-1-5-21-938814754-xxxxxxxxx-xxxxxxxxxxx]
RemoteDC Netbios[WIN2K3R2ENT-1] DNS[win2k3r2ent-1.ADDOM1.AD.LOCAL] ServerType[PDC,GC,LDAP,DS,KDC,TIMESERV,CLOSEST,WRITABLE,GOOD_TIMESERV]
Password for [ADDOM1\Administrator]:
RemoteDomain Netbios[ADDOM1] DNS[ADDOM1.AD.LOCAL] SID[S-1-5-21-2707235770-xxxxxxxxx-xxxxxxxx]
RemoteTDO deleted.

Samba側からWindows側も含めた信頼関係を作成

あらためて、--direction=bothとして、Samba側からWindows側の信頼関係の設定も含めて作成してみました。

また、よくみるとSIDフィルタは未サポートでしたので、--quarantined=no を指定してみました。

root@jessie64-1:/usr/local/samba/etc# samba-tool domain trust create ADDOM1.AD.LOCAL --type=external --direction=both --create-location=both --no-aes-keys --quarantined=no -U ADDOM1\\Administrator
LocalDomain Netbios[ADDOM2] DNS[addom2.ad.local] SID[S-1-5-21-938814754-xxxxxxxxx-xxxxxxxxxx]
RemoteDC Netbios[WIN2K3R2ENT-1] DNS[win2k3r2ent-1.ADDOM1.AD.LOCAL] ServerType[PDC,GC,LDAP,DS,KDC,TIMESERV,CLOSEST,WRITABLE,GOOD_TIMESERV]
Password for [ADDOM1\Administrator]:
RemoteDomain Netbios[ADDOM1] DNS[ADDOM1.AD.LOCAL] SID[S-1-5-21-2707235770-xxxxxxxxx-xxxxxxxx]
Creating remote TDO.
Remote TDO created.
Creating local TDO.
Local TDO created
Validating outgoing trust...
OK: LocalValidation: DC[\\win2k3r2ent-1.ADDOM1.AD.LOCAL] CONNECTION[WERR_OK] TRUST[WERR_OK] VERIFY_STATUS_RETURNED
Validating incoming trust...
OK: RemoteValidation: DC[\\jessie64-1.addom2.ad.local]  CONNECTION[WERR_OK] TRUST[WERR_OK] VERIFY_STATUS_RETURNED
Success.
root@jessie64-1:/usr/local/samba/etc# samba-tool domain trust show addom1.ad.local
LocalDomain Netbios[ADDOM2] DNS[addom2.ad.local] SID[S-1-5-21-938814754-xxxxxxxxx-xxxxxxxxxx]
TrusteDomain:

NetbiosName:    ADDOM1
DnsName:        ADDOM1.AD.LOCAL
SID:            S-1-5-21-2707235770-xxxxxxxxx-xxxxxxxx
Type:           0x2 (UPLEVEL)
Direction:      0x3 (BOTH)
Attributes:     0x0 ()
PosixOffset:    0x00000000 (0)
kerb_EncTypes:  0x4 (RC4_HMAC_MD5)

こちらも問題なく機能しましたが、やはりSambaで構築したADドメインに所属するメンバについては、信頼するドメインのユーザでログオンはできるものの、アクセス許可を付与できず……。

追記(10/25)

リリースノートをよく見ると

  • 信頼するドメインのユーザやグループをドメイングループに追加することができない

とあるので、今のところ、アクセス許可の付与ができないのは仕様っぽい気がしました。


2015年10月25日 [長年日記]

[Samba]続:外部信頼関係の検証

昨日に続き、今度はWindows Server 2012 R2で構築した、機能レベルも2012R2(ドメイン、フォレストとも)のADドメインと信頼関係が締結できるかを試してみました。

以下の実行例では若干怪しいメッセージも出ていますが、信頼関係自体は締結できました。ちなみにADDOM3がSambaで構築したドメイン、ADDOM4がWindowsで構築したドメインです。

root@ubuntu1404-03: ~# samba-tool domain trust  create ADDOM3.AD.LOCAL --type=external --direction=both --create-location=both --quarantined=no -U ADDOM3\\Administrator
LocalDomain Netbios[ADDOM4] DNS[addom4.ad.local] SID[S-1-5-21-1270313711-xxxxxxxxxx-xxxxxxxxxx]
RemoteDC Netbios[WIN2K12R2DC-03] DNS[WIN2K12R2DC-03.ADDOM3.AD.LOCAL] ServerType[PDC,GC,LDAP,DS,KDC,TIMESERV,CLOSEST,WRITABLE,FULL_SECRET_DOMAIN_6,ADS_WEB_SERVICE,DS_8,__unknown_00008000__]
Password for [ADDOM3\Administrator]: ←パスワードを入力
RemoteDomain Netbios[ADDOM3] DNS[ADDOM3.AD.LOCAL] SID[S-1-5-21-302367910-xxxxxxxx-xxxxxxxxxx]
Creating remote TDO.
Remote TDO created.
Setting supported encryption types on remote TDO.
Creating local TDO.
Local TDO created
Setting supported encryption types on local TDO.
Validating outgoing trust...
ERROR: LocalValidation: DC[\\WIN2K12R2DC-04.ADDOM3.AD.LOCAL]  CONNECTION[WERR_NO_TRUST_SAM_ACCOUNT]  TRUST[WERR_NO_TRUST_SAM_ACCOUNT] VERIFY_STATUS_RETURNED
root@ubuntu1404-03: ~# samba-tool domain trust show addom3.ad.local
LocalDomain Netbios[ADDOM4] DNS[addom4.ad.local] SID[S-1-5-21-1270313711-xxxxxxxxxx-xxxxxxxxxx]
TrusteDomain:

NetbiosName:    ADDOM3
DnsName:        ADDOM3.AD.LOCAL
SID:            S-1-5-21-302367910-xxxxxxxx-xxxxxxxxxx
Type:           0x2 (UPLEVEL)
Direction:      0x3 (BOTH)
Attributes:     0x0 ()
PosixOffset:    0x00000000 (0)
kerb_EncTypes:  0x18  (AES128_CTS_HMAC_SHA1_96,AES256_CTS_HMAC_SHA1_96)

Copyright (C) 2003-2017 TAKAHASHI, Motonobu
webmaster@monyo.com