AWS AD ConnectorとSamba4のADを接続

-

AD ConnectorとSamba-ADを連携する試み

AWSにはAD Connectorという、ローカルのActiveDirectoryの認証情報を使用するための中継サービスがある。

Linux大好きな私、とある用途でActive DirectoryをSamba4のADで構築しており、このSamba4のADとAWSのAD Connectorを接続してみようとしてみたところ、エラーが発生して繋がらないという事象が発生し、この2〜3ヶ月ほど時々トライアンドエラーをしていたのだが、ついに繋がったのでやったことのログを残しておく。

Samba4のADとAD Connectorをつなぐのがニッチらしいので、誰かの一助となれば幸いである。

前提条件はバッチリでもDNSの接続でエラーになる

Samba-ADはUbuntu18.04で構築したもの。こちらの方法で構築。

 

AWSと自宅環境は、S2S VPNで接続している状態なので、ローカル側との通信は問題なく可能。

AD Connectorの管理ガイドに書いている前提条件はバッチリできてて、DirectoryServicePortTest.exeの実行結果もOKにもかかわらず、AD ConnectorからローカルのADに接続しようとすると、以下のようなエラーが出て接続に失敗してしまう。
======================
Connectivity issues detected: DNS unavailable (TCP port 53) for IP:
======================

ルートテーブル的にも問題ないし、セキュリティグループも問題ないし、何が原因なのだろう…と２〜３ヶ月程悩んでいた。

tcpdumpで見ても、AWS側からの通信は来てて、コネクションもできてるのに…。

Samba4のADとAD Connectorをつなぐのはどうやらニッチっぽいので、世界のみんなに聞いてみても英語の情報もないのでお手上げ状態…。

で、なんとなくAWSのセグメント側から名前解決できてへんのではないかと思って、EC2インスタンスからnslookupをしてみたところ解決の糸口が見えた。

DNSにAWS側から接続できるかの切り分け

AWS側からローカルのDNSサーバに名前解決できるかどうかは、AD Connectorを起動しようとしているセグメントにEC2インスタンスを立てて、nslookupでローカルのDNSサーバを指定して名前解決をしてみると、AWS側から名前解決ができるかの切り分けができる。

下記のようにREFUSEDになると名前解決ができてない。
====================

[ec2-user@ip-<EC2インスタンスのIP> ~]$ nslookup
<ローカルにあるサーバののホスト名> <ローカルのDNSサーバのIP>
Server: <ローカルのDNSサーバのIP>
Address: <ローカルのDNSサーバのIP>#53

** server can't find <ローカルにあるサーバののホスト名>: REFUSED
====================

こちらのブログを見てbindのnamed.confの設定が、デフォルトでは特定のセグメントからの
リクエストしか受け付けないようになっている事がわかったので、AWS側のセグメントを追加してやることに。
Ubuntu18.04 LTSの場合は、/etc/bind/named.conf.optionsにセグメントの設定がある。
とりあえずクローズドな環境なのでVPCのセグメント全体を許可。
acl localnet {
    <ローカルセグメント1>/24;
    <ローカルセグメント2>/24;
    <AWSのVPCセグメント>/16;
    127.0.0.1;
};

上記設定を終えた後でAD Connectorから接続を施行すると…繋がった！
Samba-ADとAD Connectorが接続できた！

余談

ただし、１つ留意点がある。
最近、AWSとのS2S VPN接続を「vyatta+PPPoE」から「RTX810+V6プラス」に変えたので、もしかしたらそっちで上手く行った可能性もある。
本来は両方の環境で再現性があるかどうかを試してみるべきだが、めんどくさいのでそこまではしない。(・∀・)
DNS名が引けないのが問題だったので、おそらく上記の方法で解決出来るだろうと思う。


みんなでAWSの勉強しようぜ！

コメント

コメントを投稿

このブログの人気の投稿

JP1の定義をドキュメント化するjp1ajs2.jobdocが超便利

-
素晴らしいツール こちらの作者さん が作成されているJP1の定義からドキュメントのhtmlを生成するツールが超便利な件。 jp1ajs2.jobdoc https://github.com/mizukyf/jp1ajs2.jobdoc/ 必要とした経緯 JP1の標準で作成した定義を Excelに落とせるツール はあるのだが、なぜかJP1 Viewが入っている端末にExcelが入っていなかった。 （ちなみに、JP1用語だと定義を抜き出すのが「インポート」、定義を登録するのが「エクスポート」らしく大変ややこしい。） 見ようと思えば 定義ファイルの中身の記述が公開されている ので人力でも解析可能ではあるが、そんなのクソ面倒なので、誰か偉い人が作ってくれてるだろうと他力本願したところ、jp1ajs2.jobdocに出会った。 おすすめポイント 定義情報をjp1ajs2.jobdocに食わせると、html形式で解析対象配下のジョブ定義のパラメータをテーブル形式で表示してくれたり、マップもsvg形式で出力してくれる。 ブラウザがあれば定義情報とマップの両方を参照できるのが素晴らしい。 コード値に対応した日本語の説明文も出力してくれるので、わかりやすい。 また、これでドキュメント化しておけば、定義を確認するのにJP1 View開いて確認する必要がないので、JP1 Viewを見れない人に情報共有をしたり、自席で定義をサクッと確認したりするのにちょうどいいと思う。
続きを読む

アーティストとしてのolivia(lufkin)再評価

-
イメージ
オリビア再評価 Oliviaという人をご存じだろうか。 オリビアニュートンジョン…ではなく、日本でD&Dというユニットでアイドルとしてデビューしたオリビアさん(本名olivia lufkin、通称リビたん)である。 年齢がばれるが、筆者はこの人と同世代で、化粧品KATEのCMをリアルタイムで見ていた。 この美人のネーチャンがOliviaである。 リビたんは非常によい曲を作っているのだが、あんまり一般に受ける路線じゃなかった事もあり、何度かチャンスはあったもののブレイクに至らなかった不遇のアーティストである。洋楽ロックを嗜好する向きには結構受けると思うのだが、マーケティングおよび元アイドルのイメージもあり、その層の手にも中々届かなかったに違いない。 と言う訳で、リビたんがアーティスト活動を辞めて6年は経った今、リビたんを再評価したい。 といっても、そんなにリビたん自体に詳しくはないので、好きな曲を並べていくだけにはなるが。 リビたんと僕の出会い リアルタイム当時はビジュアル系にどっぷりハマっていて「ケッ、アイドルなんて！」という割と硬派なスタンスを採っており、当時全盛だったモーニング娘。の類には一切手を付けてなかったのだが、何かオリビアはいいなと思ってファーストシングル「Dear Angel」を購入していた。 ただ、スタンスがビジュアルどっぷりで丁度BUCK-TICKさんに片足を突っ込み始めたところだったので、あんまり一生懸命聞いていなかった。 その後、洋楽にハマり、Linkin Parkとかのニューメタル、Queen、Buggles、Slayer、Slipknotなんかにのめり込み、すっかり洋楽かぶれになった後、ジャズやらなんやらいろいろ聞きあさってみる時期に入り、社会人２年目くらいに「そういえばオリビアっていたなぁ」とふと思い出し、「Dear Angel」を聴き直してみた訳だが…。 これが非常に良かった。 日本語詞の方ではなくオリビアが作詞した方の英語詞版の方にグッと来たのである。 日本語詞が典型的な恋愛ソングなのに対して、英語詞の方は孤独感と自分の可能性に対する挑戦を歌っている一種のプロテストソングになっている。(←英語力は低いので個人的な解釈です。) で、改めて英語詞版のオリビアの初期シングルを聴いてみる...
続きを読む

curlでADのドメインユーザーでプロキシを超える

-
curlでADのドメインユーザーで認証してプロキシを超えたい こちらのサイト でslackにsnmp trapを送信する方法が書かれていたのに触発されてシステムのエラーを通知するのに、MicrosoftのTeamsのWebhookにjsonで飛ばしてみようと思ったらcurlでつながらない。 ADユーザーでプロキシ認証しないと外に出られない、Linux好きにとっては反吐の出る環境のため、それが原因で外に出れなかった。 ネット上にcurlで認証通す場合こうしたらいいよ～みたいなのがいっぱい転がっているが、なんかいまいちなので自分のやったことを備忘録として乗っけとく。 実際のコマンド例 ほんとは出力するメッセージを加工したりする処理を入れているのだが、要素だけ掲載すると下記のようなコマンドで飛ばせる。 WEBHOOKのURL作ったりするところはggrksでよろしくお願いします。 #環境変数定義 MESSAGE=<なんかメッセージ> TEAMS_WEBHOOKURL=＜TEAMSのWEBHOOKURL＞ #コマンド実行 echo "{ \" text \" : \" ${MESSAGE} \" } " | \ curl -H 'Content-type:application/json' \ -U "<ドメイン>\<ユーザー名>:<パスワード>" \ --proxy-ntlm \ -proxy <プロキシサーバ>:<ポート> \ -insecure -d @- ${TEAMS_WEBHOOKURL} プロキシ越えの肝となるオプション ポイントは下記の3つで、特にADのドメインユーザーで認証する場合、ntlm認証のために「--proxy-ntlm」オプションが必要らしい。 -U "<ドメイン>\<ユーザー名>:<パスワード>" --proxy-ntlm -proxy <プロキシサーバ>:<ポート>
続きを読む