[Azure] ポイント対サイト接続時のエラー798を回避する

AzureでクライアントVPNを提供するポイント対サイト接続（※2014年3月現在プレビュー版）ですが、MSDNの手順通りに進めても、私の環境ではクライアントからの接続時にエラー798が出て失敗してしまいました。海外のフォーラムでも同じ問題が報告されています。
色々と試行錯誤した結果、問題の回避策を見つけました。上記フォーラムにも投稿していますが、改めて日本語で手順を説明したいと思います。前提として、ルート証明書とクライアント証明書の作成、ルート証明書のアップロード、AzureからダウンロードしたVPNパッケージのインストール等は、MSDNの手順に沿って実施済みとします。

1. 「ファイル名を指定して実行」から「ncpa.cpl」を実行する。「詳細」ビューに切り替えて、「電話番号またはホスト アドレス」列を参照し、「azuregateway」で始まる接続先を控えておく。
2. 「ネットワークと共有センター」からVPN接続をセットアップする。「インターネット アドレス」には、控えておいた「azuregateway」で始まる接続先を指定する。
3. セットアップしたVPN接続のプロパティを開く。
4. 「セキュリティ」タブの「認証」欄で、「拡張認証プロトコル（EAP）を使う」⇒「Microsoft: スマート カードまたはその他の証明書」を選択する。
5. 更にプロパティを開き、「接続のための認証方法」で「このコンピューターの証明書を使う」を選択して「OK」ボタンを押す。
6. 「ネットワーク」タブで「インターネット プロトコル バージョン 4」のプロパティを開く。更に詳細設定を開き、「リモート ネットワークでデフォルト ゲートウェイを使う」のチェックを外す。
7. 「OK」ボタンで全てのダイアログを閉じる。
8. VPN接続を開始する。初回には接続先を確認するダイアログが出るが、そのまま進める。クライアント証明書の選択ダイアログが出たら、事前に作成・導入した証明書を選択する。

上記手順でのVPN接続ですが、単にエラーを回避するだけでなく、VPN接続時のDNS指定やDNSへのレコード登録等、さまざまなプロパティを設定できるメリットもあります。私はその点を重宝して、ポイント対サイト接続では専ら上記手順で作成したVPN接続を使用しています。

[SQL Server] ミラーリングされたDBについて、プライマリDBのみトランザクションログバックアップ（切り捨て）を行うT-SQL文

Lync ServerのバックエンドDBをミラーリングした場合、トランザクションログの肥大化による障害を回避するため、定期的なトランザクションログバックアップが必要となります（参考KB）。プライマリとミラーのスイッチを考慮すると、ミラーを構成するSQL Serverの両インスタンスでバックアップを実行するのが確実ですが、その場合ミラーDBに対するバックアップは失敗し、ログにエラーが出力されます。

エラーそのものは製品仕様に基づくため問題ではないものの、他のエラーが埋もれてしまう懸念と気分の問題から、ミラーリングされたDBのステータス（プライマリかミラーか）を取得し、プライマリの場合のみトランザクションログバックアップを実行するT-SQL文を作成しました。これをSQL Server Agentで毎時実行することで、ラボ環境にて余計なエラー出力なくトランザクションログを切り捨てることができています。ラボ環境では切り捨てだけできればよかったのでバックアップ先をnullデバイスにしていますが、バックアップデータが必要な場合でも簡単に変更して再利用可能です。

-- T-SQL文開始 --
declare @database_name sysname
declare principal_databases cursor
    local static read_only forward_only
    for select name
    from sys.databases d, sys.database_mirroring m
    where d.database_id = m.database_id
    and m.mirroring_role_desc like 'PRINCIPAL'
    order by name
open principal_databases
fetch next from principal_databases into @database_name
while @@fetch_status = 0 begin
    backup log @database_name to disk = N'NUL'
    fetch next from principal_databases into @database_name
end
close principal_databases
deallocate principal_databases
-- T-SQL文終了 --

[Lync] ラボ環境でPBXを利用するには

AsteriskNOWとX-Liteを使うことで、Lync Server 2010 / 2013のラボ環境で、PBXを利用した機能検証・テストを手軽に行うことができるようになります。導入・設定までの詳細な手順は、以下の記事が参考になります。

Series: Exchange 2013 and Lync 2013 Integration with AsteriskNOW PBX Pt. 1
Series: Exchange 2013 and Lync 2013 Integration with AsteriskNOW PBX Pt. 2
Series: Exchange 2013 and Lync 2013 Integration with AsteriskNOW PBX Pt. 3

以下、記事に沿ってHyper-V上のラボ環境に導入・設定してみて気づいた注意点です。

• 記事ではメモリ1GBとありますが、512MBでも設定後の状態で約半分空きがあるので、軽めの利用であればそれで十分そうです。
  
  
• ベースがCentOSであるため、Hyper-Vの統合サービスを簡単に導入できます。それにより、レガシーでないネットワークアダプターも利用できるようになります。
  
  
• インストール時には、ネットワークアダプターがないとインストールが中断されてしまうため、最低1つのレガシーネットワークアダプターが必要です。Hyper-Vの統合サービスを導入してレガシーでないネットワークアダプターを追加した後は、レガシーネットワークアダプターは削除しても問題ありません。
  
  
• レガシーネットワークアダプターはインストール時にeth0として認識され、削除された後もeth0が他のネットワークアダプターに割り当てられることはありません。私はそれが気になったので、以下のファイルでMACアドレスが指定されている個所を編集し、eth0の割り当てを変えました。
  /etc/udev/rules.d/70-persistent-net.rules
/etc/sysconfig/network-scripts/ifcfg-eth0


• 私の場合、記事通りの設定ではSIPがTCPでListenしませんでした。記事のコメント欄でも報告されていますが、/etc/asterisk/sip_custom.confにtcpenabled=yesを追加してサービスを再起動したところ、TCPでListenされるようになりました。

[Active Directory] Active Directoryドメイン名のベストプラクティス

ちょっと調べる必要があったので、Webで調べた結果と自分の経験を踏まえて表にまとめてみました。ユーザビリティについてはNetBIOS名やUPNの設定次第でユーザーになじみ易い形にできるので、サブドメイン名を使用するのが一番のように思えます。

What's in an Active Directory DNS Name?
Active Directory .local domain design and Office 365.
DNS 名前空間の計画

<Active Directoryドメイン名の比較表>

前提：パブリックなDNSドメイン名がexample.comの場合		パブリックな ドメイン名と 同じドメイン名	サブドメイン名 （MS推奨）	パブリックな 別TLDの ドメイン名	プライベートなTLDの ドメイン名
具体的なADドメイン名		example.com	corp.example.com	example.net	example.local
ユーザ ビリティ	ユーザーにとって覚えやすくなじみ易いドメイン名か →○：YES、×：NO	○	×	×	×
管理性	インターネット用と社内用とでDNSを分け、相互に転送や委任を設定して管理負荷を軽減できるか →○：YES、×：NO	×	○	○	○
名前空間 衝突の 潜在的 リスク	他社と名前空間が重複し、M&A等でADの連携/統合が必要になった場合に障害となる可能性はないか →○：ほぼなし、×：あり	○	○	○/×	×
ドメイン名 確認が できない ことによるリスク	証明書発行等ドメイン名確認が必要な申請が却下されるリスクはないか →○：ほぼなし、×：あり	○	○	○/×	×
備考				○/×の箇所は、ドメイン名を所有していれば○、所有していなければ×

[Active Directory] オブジェクトに対する権限を特定のセキュリティグループに付与するには

Active DirectoryではOUを分割して、そのOUの管理をセキュリティグループに委任するのが一般的です。これに対し、あるOU直下にフラットに格納されているオブジェクトに対して、サブOUに分割することなく、特定のセキュリティグループに権限を付与できないかを調べました。

結果、Windows Server 2008以降で追加されたOWNER RIGHTSというセキュリティプリンシパルで実現できそうなことがわかりました。

AD DS: Owner Rights

やり方は下記の通りです。私の場合、あるセキュリティグループのメンバーに、一部ユーザーアカウントのパスワードリセット権限を付与することが上手くいきました。

1. 権限を付与したいセキュリティグループを、オブジェクトのOwnerとして指定
2. オブジェクトまたは格納先OUのセキュリティ設定で、OWNER RIGHTSを追加し、付与したい権限を指定

OUに権限を委任する場合と異なり、誰が権限を持っているか分かりづらくなるのが欠点ですが、上手く使えばOUの階層を浅く保ちつつ権限を分割することができそうです。

[Office 365] ドメイン名に企業の商標等が含まれていると、StartSSLの無償証明書発行が却下されます

先日の記事で紹介したStartSSLに無償の証明書の発行を申請したところ、却下されてしまいました。却下の理由は下記の通りで、ドメイン名に「office365」が含まれていたことが原因です。ドメイン名は商標等を含まないものにしておいた方が無難ですね。

simply high profile brands and names should be generally avoided, but are not possible in the Class 1 (free) level at all. We can not issue the requested certificate containing office365 (a brand name of Microsoft).

[Office 365] AD FS用証明書を無償or安価で使用する

Office 365のAD FS（Proxy）では、インターネットから利用する場合や、社内からでもOWA以外でExchange Onlineを利用する場合には、Microsoft Federation Gateway（MFG）が信頼しているルートCAが発行した証明書が必要となります。証明書が必要な理由については、下記リンク先が参考になります。

AD FS Proxyの役割 « 日々徒然 

AD FS（AD FS Proxy）で利用するSSL証明書 « 日々徒然

その証明書ですが、無償のものでは以下が使えるようです。StartComの方はMFGが信頼しているCA一覧には載っていないのですが、海外の記事で使えたという報告を見つけました。（2012/7/1追記）FreeSSLも一覧にはありませんが、私個人の検証環境で使えることを確認しました。

Comodo（90日間）

StartCom（1年間）

FreeSSL（30日間）

一方、無償のものはどうしても有効期限があるので、期限がなくできるだけ安価なものを探したところ、Comodo Positive SSLにたどり着きました。Namecheap.comで9ドル/1年で購入可能な上、MFGが信頼しているCA一覧に載っているため、安心して使えそうです。購入の流れは下記リンク先が参考になります。

720円で SSL を導入する方法 | TipsZone

私は当面無償のもので評価しつつ、有効期限が切れたら有償のものにトライしてみたいと思います。