追記

だめだめ日記

ツッコミの内容は検索サイトからの検索やサイトのレーティングに影響します。そのため問題があるキーワードを含むと思われるツッコミについては、当方の判断で削除することがあります。予めご了承ください。 なお、コメント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|

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


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

マスタリング Nginx

実践 パケット解析 第2版

改訂版 Sambaのすべて

Samba [実践]入門

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

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



2016年04月10日 [長年日記]

[Windows][Linux]bash on Windows on Ubuntuを試してみた

久々ですが、こんな記事が出てたので、試してみました。

インストールとかは、ブログとかを適当にみてWindows 10 Insider Previewのビルド14316でやってみました。

とりあえず起動してみた

とりあえず起動してコマンドをいくつか打ってみたのが以下の画面イメージです。

bashのプロンプト

bashとタイプすることで、bashに切り替わります。これはPowerShell上でなくても構いません。

psコマンドでプロセスの様子を見てみました。 上記のような感じで、/sbin/init 以外は bash しか起動してません。かなり限定的な環境ですが、最低限の Linux 環境上で bash が動作している感じです。

ちなみに、ファイルシステムはかなり特殊なことをやってるようで、df コマンドは動作しませんでした。ユーザとしては root になってます。

bash を複数起動していると、上記のように、各 bash のプロセスが ps コマンドで表示されますので、なんらか同一の環境上で動作していることはわかります。

とりあえずパッケージを入れてみた

パッケージを入れてみたのが以下の画面イメージです。

パッケージのインストール

途中を省略せずに載せたのでちょっと長くなってます。

最初に apt-get update したらサーバにつなげなかったので焦りましたが、/etc/resolb.conf に適切な DNS サーバ(ここでは192.168.1.15)を追加したら問題なくアクセスできました。

pingとかifconfigとか&/dev

ネットワーク系コマンドと/dev配下

pingとかを試してみましたが、ほかでも報告がある通り、うまく動きませんでした。

ls -l /dev してみるとデバイスファイルも殆ど存在しないことが確認できました。

/proc はありますが、こちらも /proc/net のシンボリックリンク先が存在していないようです。ということで、ネットワーク系のコマンドは基本的に機能しないと思われます。

とりあえずプログラム開発とか

とりあえず gcc と gdb を入れて、コマンドラインからデバッグしてみました。

gdbの動作する様子

見ての通り、address space randomization が無効とかいう微妙なメッセージも出てますが、とりあえずは動作しました。

emacs

emacs24-nox パッケージをインストールしたところ、次の通り、とりあえず動作はしてます。なお白地になっているのは個人の好みです。

emacs

ただ、M-x gdb はうまく動きませんでしたというのと、CTRL+A doest not workとしてバグ登録しましたが、現状 Ctrl-A が動作しないので操作するのはかなり辛いです。

端末制御もまだ不具合があり、しょっちゅう Ctrl-L して画面の再描画をして、それでもいまいちうまく表示できてないといった感じです。

sshクライアントとして

Ubuntu の openssh-client パッケージが標準で入ってますので、その意味ではほかの Linux マシンなどに気軽に ssh できます。

sshしたところ

LANGをUTF-8にすれば、日本語も表示できました。

ただ、emacs のところで記載した通り、端末制御はいまいち微妙です。ちょっと vi でいじるくらいであれば大丈夫なんですが……。

日本語ファイル名

Windows側から てすと.txt というファイルを作成して、Linux 側からみたところが以下になります。

Windowsのプロンプト bashのプロンプト

参考にしたところ

本日のツッコミ(全2件) [ツッコミを入れる]

_ たけろぐ [何をしたくて積んだのかわかりませんね。それともプレビュー版だからであって、正式版ではあっと驚く完成度になるのでしょう..]

_ monyo [もともとが開発者用オプションという位置づけなこともありますが、おっしゃるように、使用イメージがあまりピンとこないです..]


2016年01月01日 [長年日記]

[Samba]FreeBSD 10以降の内蔵iconv関数とSamba

いまさらですが、2013年10月以降のFreeBSD 10以降で実装されたiconv(3)関数について確認してみました。

$ which iconv
/usr/bin/iconv
$ iconv -l | grep EUCJP-MS
EUC-JP-MS EUCJP-MS EUCJP-OPEN EUCJP-WIN EUCJPMS

ということで、従来glibcもしくはパッチを適用したGNU libiconv以外で、はじめてEUCJP-MSが実装されたiconv関数になります。

ただ、Portsを最新化して確認してみましたが、最新のsamba43パッケージでも、GNU libiconvの依存関係が有効なままで、シンボル上も

root@fbsd10-1-1: # smbd -b | grep ICONV
  HAVE_ICONV_H
  HAVE_ICONV
  HAVE_ICONV_OPEN
  HAVE_LIBICONV
  HAVE_NATIVE_ICONV

のように、GNU libiconvも認識されています。

実際には、GNU libiconv由来のiconvコマンドでは、次のようにEUCJP-MSロケールが認識されていないにもかかわらず、

root@fbsd10-1-1: # /usr/local/bin/iconv -l | grep EUCJP-MS

後述する、文字コードとしてEUCJP-MSを指定したsmb.confを使用しても問題なく動作する(つまりEUCJP-MSロケールを認識している)ので、内蔵のiconv()関数が使用されているようです。

ただ、切り分けとしては気持ち悪いので、念のため、次のようにして、GNU libiconvを使用していない状態で確認してみました。

  • libiconvを明示的にアンインストール
  • /usr/ports/net/samba43/Makefileを編集してUSES行からiconvを削除(これをしないと、依存関係チェックでlibiconvをインストールしようとするため)
  • PortsからSambaをインストール
root@fbsd10-1-1: # smbd -b | grep ICONV
  HAVE_ICONV_H
  HAVE_ICONV
  HAVE_ICONV_OPEN
  HAVE_NATIVE_ICONV

のように、LIBICONVシンボルがなくなっており、/usr/local/bin/iconvもインストールされていないことを確認のうえ、次のような/usr/local/etc/smb4.confを作成して確認してみましたが、特に問題は発生せず、日本語ファイル名がEUC-JPの符号化形式で正しく保存されていました。

[global]
  dos charset = CP932
  unix charset = EUCJP-MS

[homes]
  writeable = yes
  browseable = no

ちなみに、iconv関数が認識できない文字コードを指定すると、log.smbdに次にようなログが出力されます。

[2016/01/01 09:49:54.241896,  0]  ../lib/util/charset/convert_string.c:391(convert_string_talloc_handle)
  convert_string_talloc: Conversion not supported.

PortsからインストールしたSamba 4.3.3の場合は、最終的にsmbd自体の起動がアボートしました。

ためしに次のようなファイル名のファイルを作ってみましたが、

機種依存文字のファイル名

比較的文字化けしやすいと思われる、「てすとⅠⅰ.txt」と「てすと㈱¬」というファイル名について、Linux上に格納されているファイル名を次のようにしてダンプしてみると、

$ ls|tail -2|od -tx1
0000000    a4  c6  a4  b9  a4  c8  ad  b5  8f  f3  f3  2e  74  78  74  0a
0000020    a4  c6  a4  b9  a4  c8  ad  ea  a2  cc  2e  74  78  74  0a
  • 「Ⅰ」は「ad b5」
  • 「ⅰ」は「8f f3 f3」
  • 「㈱」は「ad ea」
  • 「¬」は「a2 cc」

に、おのおの適切に符号化されていることを確認できています。

網羅的な確認は行えていませんが、サンプリング的に確認した範囲では、結論としてFreeBSD 10以降であれば、本来的にSambaにGNU libiconv(libiconvパッケージ)は不要といえるように思います。

それにより、今まで面倒であった、FreeBSDのSambaでGNU libiconvを使用する場合にEUCJP-MSロケールなどに対応するための日本語パッチを適用するため、必ずPortsから作成する必要があるといったバッドノウハウも発展的に解消すると思われます。


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

[Samba]dos charsetパラメータの必要性について

最近すっかり影が薄くなったdos charsetパラメータですが、どの程度影が薄い(設定の影響度が低い)のかを、少しソースコードベースで探ってみました。

まぁ、実態としては、設定しないことによる影響はほとんどないと言ってもよいのかも知れません……。


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)

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月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月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月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月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年09月27日 [長年日記]

[Windows]Windows 10の更新プログラムの提供方法

Microsoft社のブログにもありますし、このあたりに細かい画面イメージがありますが、Windows 10では、更新プログラムをP2P機構を使用して、インターネット上のどっかのPCから取得する動作がデフォルトになってます。

更新プログラムの提供方法

これは良いんですが(よくないですが……)、Windows Update の配信の最適化に関する FAQにある以下の記載が気になりました。

ダウンロードのFAQ

「従量課金接続が使われていることが検出された場合」はデータの自動送信は行われない(無用のトラフィックは発生しない)とのことですが、モバイルルータでNATしている環境などで「従量課金接続の検出」に失敗する可能性が否定できないということで、怖い機能だなぁと。

この機能のせいで、気づいたら従量課金がとんでもないことになっていたという事例が絶対に出てきそうな……。

あと、レジストリで設定できるようですが、FAQをみるとWifi接続での従量課金接続検出とあるので、PCからみてWifi接続でないケースでは、そもそもレジストリの設定がちゃんと効くのかとか、いろいろ微妙な気がします。

[Windows]Azure Active Directoryに参加

とりあえず、手元のWindows 10をAzure Active Directoryに参加させてみました。

Azure Active Directory参加

ちなみにパケットキャプチャしながら見てたんですが、SSL通信をひたすらやってるだけなので、眺めていても無意味……

サインイン画面では、次のような感じでユーザ名を入力

AADユーザでのサインイン

サインイン後、「組織」が変わっていることを確認。

システムのプロパティ

さらにユーザ情報も確認。

whoami /userコマンド

こんな感じで AzureAD\ユーザ名 というユーザとして認識されている模様。この AzureAD というドメイン名?は、AADの名称とは無関係に一律付与されるようでした。

ローカルユーザではないので、net user コマンドを実行しても一覧には表示されず。ただ、いわゆる AD に参加しているわけではないので、net user /domain コマンドを実行しても、次のような感じでエラーでした。

net user /domainコマンド

[Windows]Azure Active Directoryにプロキシ経由で参加できるか

やってみました。

先ほど参加できたWindows 10の環境で、いったんAADから抜けたうえで、デフォルトゲートウェイを削除してみました。

SSLも含め、プロキシ経由でインターネットに出られることは、IEとEdgeとで確認の上、参加を試みたんですが……

エラーコード801c000cの画面

こんな感じのエラーで参加できませんでした。

Integrating your on-premises identities with Azure Active Directoryという記事を見つけて、machine.configを設定してみたんですが、状況変わらず。

エラーコード 801c000c で検索しても何も情報ないし、Wiresharkで見てた感じ、HTTPS以外の通信はないですし、通信上はまったくエラーもないので、何が原因かわからないままです。


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