# 2016/07/09
# 別の認証電話へのボイス通知に関するMethodTypeを追記
Azure Active Directory(Azure AD)の多要素認証(MFA)のセットアップは基本的にユーザ自身で通知手段や通知先の設定を行う必要があります。
今回は、この設定を管理者からやってしまいたいと思います。
尚、当然ですが、Azure Authenticatorなどペアリングを行う必要があるアプリケーションを通知先として管理者側で設定して利用できる状態にしてあげることはできません。
可能なのは、
・携帯電話へのボイス通知
・携帯電話へのテキスト通知
・オフィス電話へのボイス通知
の3種類だけです。
※通知手段としてアプリを強制することはできますが、ペアリングされていない状態なので、認証時にエラーが出ます。
◆従来の多要素認証設定(ユーザ自身による設定)
多要素認証が必要な場面になるとログイン時に多要素認証が要求されます。この際、事前にユーザが通知手段の設定を行っていないと、セットアップを促されます。
ユーザは自身で通知手段と通知先を設定する必要があります。
これらを管理者から事前にセットアップしておくには、
・通知手段
・通知先
の両方を管理者から設定できる必要があります。
順に見ていきましょう。
◆通知手段を設定する
おさらいですが、Azure ADの多要素認証には、・携帯電話へのボイス通知
・携帯電話へのテキスト通知
・オフィス電話へのボイス通知
・モバイルアプリへのPush通知
・モバイルアプリのOTP(One Time Password)の利用
・別の認証電話へのボイス通知
・別の認証電話へのボイス通知
の6種類の通知手段が用意されています。
この設定はユーザのStrongAuthenticationMethodsという属性に配列として定義されています。
MFAを有効にしたユーザの属性をGet-MsolUserで見ると以下のように設定が入っています。
このMethodTypeが通知の方法でIsDefaultがその名の通り、既定で使われるかどうかを示しています。
尚、このMethodType、つまり通知手段は先の5つの方法それぞれに対応して以下の通りの文字列となっています。
通知手段 | MethodTypeの値 |
---|---|
携帯電話へのボイス通知 | TwoWayVoiceMobile |
携帯電話へのテキスト通知 | OneWaySMS |
オフィス電話へのボイス通知 | TwoWayVoiceOffice |
モバイルアプリへのPush通知 | PhoneAppNotification |
モバイルアプリのOTP(One Time Password)の利用 | PhoneAppOTP |
別の認証電話へのボイス通知 | TwoWayVoiceAlternateMobile |
ということで、このStrongAuthenticationMethodsをSet-MsolUserで設定してあげれば、通知手段を強制的に設定することが出来ます。
ただ、先にも書いた通り、この属性は配列となっているので、Microsoft.Online.Administration.StrongAuthenticationMethod型のオブジェクトを作成し、プロパティを設定した上で配列化してから、実際のユーザ属性へセットする必要があります。
この辺りは以下のコードの最後の$mfおよび$mfa変数への値のセットの仕方を参考にしてください。
では、この方法でユーザに通知手段を設定したユーザでログインを試みてみます。
先ほどとは異なり、通知が行われます。
(携帯電話へのテキスト通知を設定しました)
しかし、通知先の設定をしていないため、当然ながらエラーが発生します。
ということで、次は通知先の設定を行います。
◆通知先を設定する
こちらは非常に簡単です。ユーザの属性に携帯電話の番号や会社の電話の番号を設定すればよいだけです。
クラウドユーザならSet-MsolUserコマンドレットもしくはAzure ADの管理ポータルでユーザの属性を設定します。
Set-MsolUserコマンドレットの場合:
会社の電話 : PhoneNumber
携帯電話 : MobilePhone
Azure AD管理ポータルの場合:
会社の電話 : 勤務先タブの中の会社電話
携帯電話 : 携帯電話
尚、PowerShellから設定する際、国コードおよび電話番号が必要ですが、国コードと国内番号の間は半角スペース、国内番号の最初の0はつけたままにしておく必要があります。
(また、内線番号を使っている場合は国内番号と内線番号の間に"x"を入れておくとデリミタとなります)
こんな感じです。
尚、ローカルActive Directoryから同期しているユーザの場合、管理ポータル等で電話番号が変更できないので、ローカルActive Directory側で属性を設定してあげる必要があります。
会社電話はここです。
携帯電話場はここです。
これで同期を行うと、Azure AD管理ポータル上に値が入ります。
さて、ここまで設定したらログインを試行し通知が正しく行われるはずです。
実際にログインすると、、、、
正しく通知されました。
また、この後、ユーザ自身で通知手段を変更することもできるのですが、その際の通知先として先に設定した属性が正しく認識されます。
なかなかユーザ自身での多要素認証設定を徹底するのはリテラシー的にも厳しい場合もあると思うので、管理者側で一気に設定を行うことも検討しても良いかも知れませんね。
0 件のコメント:
コメントを投稿