none
MacPCからVPN経由でActive Directoryへのバインドができない。 RRS feed

  • 質問

  • お世話になります。

    タイトルの件ですが、弊社ではWindowsPC、MacPCにかかわらずドメイン参加をさせてADアカウントでPCにログインするようにしていますが、現在コロナウイルスの影響で社員がほぼ在宅勤務となっている為、AWS Client VPNを使用して社内ネットワークにアクセスできるようにしています。

    以前にMacPCをVPN経由でパスワード変更ができない事象があり、原因がADへのバインドに異常をきたしている可能性が高かった為、VPN経由で再度バインドを行おうとしたところ「要求された操作を認証サーバで完了できませんでした」と表示されバインドできませんでした。

    WindowsPCはVPN経由でドメイン参加ができることを確認しており、再バインドを行おうとしているMacPCでVPN接続した際にADサーバへpingが通ることも確認しています。

    今後、物理サーバを廃止し現在のADサーバもクラウド化していく予定であり、今回の事象が解決できないとMacPCのみドメイン参加できない状況となってしまう為、どなたかご教授いただけませんでしょうか。

    なお、現在社内オンプレADサーバ2台、AWS 仮想ADサーバ1台で構成しており、VPNで使用するDNSは仮想ADサーバと社内オンプレADサーバの1台を設定しています。

    宜しくお願い致します。

    2020年11月2日 2:53

回答

  • チャブーンです。

    返信が遅れましたが、これですが、おそらくnetlogonデータのキャッシュファイルが古いままで、修正ができていないためかと思います。全台のドメインコントローラーで1台ずつnetlogonサービス停止→以下のファイルを削除→サービス再起動、で対応できるか確認されるとよいでしょう。

    • netlogon.dns
    • netlogon.dnb

    後元々の件ですが、Mac側のkrb5.conf設定ファイルの確認がいるかもしれませんね。Mac側のトラブルとしてAppleのコミュニティに質問した方が、よい結果が得られる可能性がありますね。


    フォーラムは有償サポートとは異なる「コミュニティ」です。フォーラムでご質問頂くにあたっての注意点 をご一読のうえ、お楽しみください。

    • 回答としてマーク 神楽 2020年12月3日 8:04
    2020年12月3日 6:47
    モデレータ

すべての返信

  • MacPCのコンソールを確認し下記内容のエラーが出ていることを確認しました。

    opendirectoryd connection:0x7f95dbd18d70,ldap msgid:2,error:SASL_BIND_IN_PROGRESS

    opendirectoryd connection:0x7f95dbd18d70,mech:GSSAPI,error:SASL_BIND_IN_PROGRESS

    どなたかご教授いただけませんでしょうか。

    宜しくお願い致します。

    2020年11月2日 5:52
  • チャブーンです。

    この件ですが、まずドメインコントローラーの「名前」のpingが通っても意味がありません。SRVレコードとしてLDAPサービス等にアクセスできる必要があります。したの資料の「Method 3」をMacクライアント上で試してください。

    https://docs.microsoft.com/en-us/troubleshoot/windows-server/networking/verify-srv-dns-records-have-been-created?WT.mc_id=EM-MVP-8322

    コレで問題がなければ、ドメインへの再参加をもう一度行うと、解消する可能性が高いです。VPNでできない場合、LANにつなぎこんで実施してください。


    フォーラムは有償サポートとは異なる「コミュニティ」です。フォーラムでご質問頂くにあたっての注意点 をご一読のうえ、お楽しみください。

    2020年11月2日 7:48
    モデレータ
  • チャブーンさん

    ご返信ありがとうございます。

    上記URLのnslookupを利用するのはドメイン参加していなくても正常値を返してくるのでしょうか。「set type=all」がMacのnslookupではわからなかったため、「_ldap._tcp.dc._msdcs.Domain_Name」を行ったところDNSで設定しているサーバのIPアドレスのみ表示され、「server can't find _ldap._tcp.dc._msdcs.Domain_Name:no answer」と表示されてしまいました。

    自分がMacにあまり詳しくないのでネットなどでコマンドを探しましたが見つかりませんでした。ドメイン参加しているWindowsPCではご教授いただいたURLの通りの結果が表示されています。


    2020年11月2日 8:38
  • チャブーンです。

    この件ですが、Macのnslookupでは、対話型でログオンしたあと、「set type=any」とすれば、同じ効果となるはずです。試してみてください。ドメインに参加させる必要もありません。


    フォーラムは有償サポートとは異なる「コミュニティ」です。フォーラムでご質問頂くにあたっての注意点 をご一読のうえ、お楽しみください。


    2020年11月4日 4:27
    モデレータ
  • チャブーンさん

    ご返信ありがとうございます。

    ご連絡遅くなりましたが回答いただいた「set type=any」を実行し、_ldap._tcp.dc._msdcs.aaaaa.localを実行して下記のような結果となりました。(ホスト名・ドメイン名は伏せています。)

    > set type=any
    > _ldap._tcp.dc._msdcs.aaaaa.local
    Server: 192.168.241.5
    Address: 192.168.241.5#53
    _ldap._tcp.dc._msdcs.borders.local service = 0 100 389 BBBBB-AD01.aaaaa.local.
    _ldap._tcp.dc._msdcs.borders.local service = 0 100 389 ccccc-ad01.aaaaa.local.
    _ldap._tcp.dc._msdcs.borders.local service = 0 100 389 ddddd-ad02.aaaaa.local.
    _ldap._tcp.dc._msdcs.borders.local service = 0 100 389 bbbbb-ad01.aaaaa.local.
    _ldap._tcp.dc._msdcs.borders.local service = 0 100 389 CCCCC-AD01.aaaaa.local.
    >

    実際にADサーバとして稼働しているのは3台となりますがなぜか5台として結果が出てきております。また、社内でゲスト回線にてVPN接続を行って別のMacでバインドを行ったところ何回か「要求された操作を認証サーバで完了できませんでした」と表示されたのですが、その後正常にバインドでき事象が再発されなくなりました。

    ただ、在宅勤務の方で再バインドを行ったところバインドができない状態となっています。DNS内で社内検証で使用したMacPCのレコードを削除したり、追加を行ったりした際に再度「要求された操作を認証サーバで完了できませんでした」と表示されましたが、再度正常にバインドできるようになってしまい原因特定が難しい状況となります。

    また、DNSレコードを追加する際、VPNで払い出しを行っているIPアドレスに対して関連付けポインタレコードを作成できないとエラーになってしまったため、逆引き参照ゾーンにVPNで使用するIPアドレスのゾーンを作成しました。

    お手数ですが引き続きご教授の程宜しくお願いします。

    2020年11月6日 8:28
  • チャブーンです。

    直接の原因ですが、おそらく

    実際にADサーバとして稼働しているのは3台となりますがなぜか5台として結果が出てきております。

    だと思います。不要な2台のドメインコントローラーについて、以下を参考に手動で情報を取り除いてください。

    https://docs.microsoft.com/ja-jp/windows-server/identity/ad-ds/deploy/ad-ds-metadata-cleanup?WT.mc_id=EM-MVP-8322

    ドメインコントローラーにつながったりつながらなかったりするのは、SRVレコードが「ラウンドロビン」形式で循環することがあるためです。


    フォーラムは有償サポートとは異なる「コミュニティ」です。フォーラムでご質問頂くにあたっての注意点 をご一読のうえ、お楽しみください。


    2020年11月10日 5:12
    モデレータ
  • チャブーンさん

    ご返信ありがとうございます。

    ご教授いただきましたサイトをざっと確認させていただき、マスターとして使用しているサーバ(コマンド実施結果で記載しているBBBBB-AD01)でActive Directoryユーザーとコンピューターとサイトとサービスを確認したところ3つドメインコントローラとして登録されていることを確認しました。

    CCCCC-AD01・DDDDD-AD02・BBBBB-AD01

    登録されているホスト名はすべて大文字で登録されておりその中にBBBBB-AD01自身が登録されていて、ドメインコントローラの変更で状態を確認したところBBBBB-AD01自身は利用不可となっていました。ご教授いただきましたサイトではActive Directoryユーザーとコンピューターとサイトとサービスから不要なドメインコントローラを削除する手順となっていますが、削除を行った場合は稼働しているADサーバとのレプリケーションなどがされなくなることはないのでしょうか。

    前回の回答で記載を忘れていましたが、実際に稼働している3台の内2台が大文字ホスト名と小文字ホスト名でコマンドの結果として表示されています。(BBBBB-AD01.aaaaa.local.とbbbbb-ad01.aaaaa.local.・ccccc-ad01.aaaaa.local.とCCCCC-AD01.aaaaa.local.)

    その為、削除した場合にレプリケーションがされなくってしまうのは非常によろしくない状態となってしまいます。

    2020年11月10日 8:06
  • チャブーンです。

    この件ですが、FQDNを見ましたが、同じサーバー名で大文字と小文字で登録されているのですね。普通は起こりえないことですが、Windows Server 2016以降だと、状況によって発生する問題です。したの更新プログラムを適用し、まず問題を解決するといいでしょう。(問題が起こらなくなります)

    https://support.microsoft.com/ja-jp/help/4496901/windows-dns-registers-duplicate-srv-records-for-a-dc?WT.mc_id=EM-MVP-8322

    その後で確認するべきは、SRVレコードの再確認と、そのFQDNすべてに対してMac PCがアクセスできるかどうか、になります。


    フォーラムは有償サポートとは異なる「コミュニティ」です。フォーラムでご質問頂くにあたっての注意点 をご一読のうえ、お楽しみください。

    2020年11月11日 13:36
    モデレータ
  • チャブーンさん

    ご返信ありがとうございます。

    サーバOS 2016以降に発生する問題とのことですが、現在マスターとなっているADサーバは2016ですがもう1台の大文字と小文字で登録されているサーバは2008R2になります。マスターとなっているサーバに更新プログラムを適用することでこの問題は改善できるという認識でよろしいでしょうか。

    また、小文字のみで表示されているサーバddddd-ad02.aaaaa.local.ですが、このサーバのコンピュータ名も大文字で設定していますがコマンドで確認した際は大文字で表示されなかったのは問題が発生しなかったという認識でよろしいでしょうか。

    2016サーバにてご教授いただきましたURLの更新プログラムを適用しようとしましたが
    適用できませんでした。
    • 編集済み 神楽 2020年11月12日 2:45
    2020年11月12日 2:26
  • 追加情報となります。

    本件に関係してそうな下記URLを確認したので実際にDNSに登録されているSRVレコードを確認したところ2008R2サーバ1台のみが大文字と小文字で登録されており、他の2008R2サーバ・2016サーバは小文字で登録されていることを確認しました。

    https://social.technet.microsoft.com/Forums/windows/ja-JP/55b93060-f67d-45ef-b1ca-594f9bad0e7d/windows-server-2016-12398-srv?forum=Wcsupportja

    しかし、先日記載したnslookupの実行結果としては2008R2サーバ1台、2016サーバ1台が大文字と小文字で実行結果として表示され稼働しているサーバは3台ですが5台として結果に表示されています。

    2020年11月12日 3:22
  • 上記の追加情報ですが、誤りがありましたので訂正いたします。

    「_ldap._tcp.dc._msdcs.Domain_Name」を行っているので再度DNSの前方参照ゾーン>_msdcs.Domain_Name>_tcpを確認したところ稼働している3台のサーバが大文字と小文字でサーバが登録されていました。しかし、「_ldap._tcp.dc._msdcs.Domain_Name」の実行結果では1台だけが小文字で表示され他の2台は大文字と小文字で表示されています。

    実際のサーバのホスト名は大文字で登録されている状態となります。また、大文字で登録されているデータのタイムスタンプを見ると2018年や2019年のままになっており、小文字のデータは2020年で更新されています。

    大文字のSRVレコードを削除した場合問題は発生しますでしょうか。

    2020年11月17日 6:41
  • チャブーンです。

    この件ですが、ひとまず「大文字の」かぶっているFQDNのみを削除してください。DNSのFQDNは大文字小文字の認識区別はありませんので、システム上の問題はないです。

    修正プログラムが適用できないということですが、エラーコードは何が出ていますか?「Setup」イベントログに対象の記録があると思いますので、確認してください。適用の必要なし、ということなら、後続の修正プログラムが包括しているので問題なし、ということになると思われます。


    フォーラムは有償サポートとは異なる「コミュニティ」です。フォーラムでご質問頂くにあたっての注意点 をご一読のうえ、お楽しみください。

    2020年11月17日 15:25
    モデレータ
  • チャブーンさん

    ご返信ありがとうございます。大文字のホスト名を_msdcs.Domain_Nameの_tcp内から削除しnslookupで確認したところ表示数は稼働台数と一致しましたが、2008R2サーバは大文字で表示され、2016サーバは小文字で表示されています。

    大文字のレコードを削除しても更新すると小文字だったレコードが大文字に変わっています。またしばらくすると表示が4台になり、2008R2サーバが小文字で表示されました。

    更新プログラムはイベントログを確認したところ、エラー 2149842967となっていました。このエラーについて確認したところ、前提の更新プログラムがインストールされていないことで発生するようですが、Windows Update カタログで確認したところ2020/11/7にご教授いただいたKB4541329がKB4586830に置き換えられているようです。

    置き換えられたKB4586830であればすでに適用している状況となります。


    • 編集済み 神楽 2020年11月18日 5:58
    2020年11月18日 3:53
  • チャブーンです。

    この件ですが、そのエラーは「摘要の必要なし」という意味なので、他のプログラムで置き換えられた認識で問題ないです。

    タンに更新があたっているだけではだめで、ドメインコントローラーのローカルグループポリシー(gpedit.msc)で[Use lowercase DNS host names when registering domain controller SRV records]が有効になっている必要があります。ポリシーが見当たらない場合、以下のレジストリ値を設定し、netlogonを再起動してください。

    HKLM\Software\Policies\Microsoft\Netlogon\Parameters! DnsSrvRecordUseLowerCaseHostNames
    Dword:0x1


    フォーラムは有償サポートとは異なる「コミュニティ」です。フォーラムでご質問頂くにあたっての注意点 をご一読のうえ、お楽しみください。

    2020年11月19日 4:06
    モデレータ
  • チャブーンさん

    ご回答ありがとうございます。

    gpedit内に項目が見つからなかったのでregeditも確認したのですがHKLM\Software\Policies\Microsoftまで確認できたのですがnetlogon以下が見つかりませんでした。これは作成しても問題ないのでしょうか。

    念のため確認ですが、HKLMはHKEY_LOCAL_MACHINEで間違いないでしょうか。

    2020年11月19日 4:21
  • チャブーンです。

    この件、レジストリ値が内場合、手動で作るしかありません。レジストリ値の詳細については、以下英語コンテンツをあわせて確認してください。

    https://support.microsoft.com/en-us/help/4496901/windows-dns-registers-duplicate-srv-records-for-a-dc?WT.mc_id=EM-MVP-8322


    フォーラムは有償サポートとは異なる「コミュニティ」です。フォーラムでご質問頂くにあたっての注意点 をご一読のうえ、お楽しみください。

    2020年11月19日 5:52
    モデレータ
  • チャブーンさん

    ご返信ありがとうございます。

    gpedit内に該当の項目を見つけたので有効にしました。申し訳ありませんでした。

    2020年11月19日 6:14
  • ドメイン コントローラーの SRV レコードを登録するときに小文字の DNS ホスト名を使用するを有効にしてから大文字のSRVレコードを削除したのですが、2008R2サーバのレコードが更新されず_ldap._tcp.dc._msdcs.Domain_Nameを実行しても2台しか表示されなくなってしまいました。また、表示されている2008R2サーバは自動で大文字のレコードに変わってしまいます。

    再度、確認したところやはり、大文字で2008R2サーバが表示され、1台は小文字で表示されてしまいます。

    bbbbb-ad01.aaaaa.local.(2008R2)
    BBBBB-AD01.aaaaa.local.(2008R2)
    ccccc-ad01.aaaaa.local.(2016)
    DDDDD-AD02.aaaaa.local.(2008R2)
    • 編集済み 神楽 2020年11月19日 8:19
    2020年11月19日 7:09
  • 上記の件ですが、何度か大文字で表示されるホストを削除したところBBBBB-AD01.aaaaa.local.は表示されなくなりましたがDDDDD-AD02.aaaaa.local.だけは削除しても大文字で表示されてしまいます。

    また、Macからバインドを行ったところやはりバインドできず、要求された操作を認証サーバで完了できませんでしたとなってしまいます。

    追記です。社内でゲスト回線でVPN接続した状態でバインドを何回か行ったところバインドができましたが、在宅勤務している方にバインドをお願いしたところやはり要求された操作を認証サーバで完了できませんでしたとなってしまい、バインドができませんでした。

    • 編集済み 神楽 2020年11月25日 8:54
    2020年11月25日 8:23
  • チャブーンです。

    返信が遅れましたが、これですが、おそらくnetlogonデータのキャッシュファイルが古いままで、修正ができていないためかと思います。全台のドメインコントローラーで1台ずつnetlogonサービス停止→以下のファイルを削除→サービス再起動、で対応できるか確認されるとよいでしょう。

    • netlogon.dns
    • netlogon.dnb

    後元々の件ですが、Mac側のkrb5.conf設定ファイルの確認がいるかもしれませんね。Mac側のトラブルとしてAppleのコミュニティに質問した方が、よい結果が得られる可能性がありますね。


    フォーラムは有償サポートとは異なる「コミュニティ」です。フォーラムでご質問頂くにあたっての注意点 をご一読のうえ、お楽しみください。

    • 回答としてマーク 神楽 2020年12月3日 8:04
    2020年12月3日 6:47
    モデレータ
  • チャブーンさん

    ご返信ありがとうございます。

    本件ですが、いろいろ試した結果、DNSサーバをOSで直接指定することでバインドできるようになりました。本来であればVPN接続時に利用するDNSとしてAWS 仮想ADサーバ1台と社内オンプレADサーバ1台を指定して利用できるようにしているのですがVPN接続時のログを確認したところDNSがリフレッシュできなかった内容のログを確認した為、直接指定したところ正常にバインドできました。

    しかしながら、在宅勤務の方に試していただいたところバインドができず、結局出社時にVPN経由でのバインドを確認したところ正常にバインドできてしまい、原因が不明のままとなってしまいました。(在宅勤務時の回線の問題の可能性かも?)

    現状は上記の対応にて100%バインドできている為、一旦クローズとさせていただきます。

    いろいろご教授いただきましてありがとうございました。

    2020年12月3日 8:04