Roles Based Access Control (RBAC)が一般提供開始（GA）です。ちまたでは「あーるばっく」と発音するようです。
初めて登場したのが2014年9月10日なんで1年以上かかりましたね。長かったです。
前書いたRBAC概要なことを引用しておきます。
- 今まではサブスクリプションの管理を別のアカウントに任せたいと思っても、Co-Adminということで全権限を付与するしかできませんでしたが、RBACを使えば付与する権限を限定的にすることができます。またロールを定義してロールにユーザーを追加することで管理を簡単にすることができます。（今のところビルトインのロール定義を変えたりできませんが将来的には。）
- また、On-PremiseのActive DirectoryからAzure ActiveDirectoryのグループへ同期することができるようになりました。グループで管理することで煩雑な管理を簡素化することもできますね。またADPremiumの委任グループ管理機能も利用できます。
- ロールベースの管理ということで、新しく定義されたロールや同期されたグループを使って、より限定的にアクセスを許可することができます。そう、リソースグループ単位でロールにユーザーやグループを割り当てることができるようになりました。
例えば1つのサブスクリプションで本番用のリソースグループとステージング用のリソースグループがあるとき、開発チームの人たちはステージングは追加も削除もできるけど本番用のリソースグループについては参照だけ、といったようなことが可能になりました。 - RBACは継承されます。サブスクリプション→リソースグループ→リソースと権限の割り当てが継承されます。
- ロールの管理や割り当てはプレビューポータルか、PowerShell等のコマンドラインツールからのみ行えます。
ロールは以前は3つぐらいしかありませんでしたが、リソースタイプの単位で大まかにロールができてたりします。
※日本語の場合、ドキュメントだと共同作業者なところがポータル上では「共同作成者」になってますね。
またドキュメントにもある通り継承関係とスコープを持っていますので上位で指定されるとそれが下位（リソースグループやリソース）に継承されます。
特に何もしていなければOwner（所有者）にサブスクリプション管理者が割り当てられた状態だと思います。
所有者はサブスクリプション管理者が含まれており、サブスクリプション共同管理者としてサービス管理者、共同管理者（クラシックポータルでCo-Adminを設定している場合）なロールのアカウントが含まれています。
サブスクリプションが最上位にくるので結局サービス管理者、クラシックポータルで設定したCo-Adminは全部の権限を持つことになります。注意しましょう。ちなみに管理用APIも影響をもちろん受けます。（ただしRBACの影響を受けるのはリソースマネージャー（ARM）だけです。つまりCo-AdminなどではなくRBACでのみ権限を持ったユーザーはASMは使えないということです）
ちなみに所有者ロールにアカウントを追加できますが、サブスクリプション管理者ではないのと所有者ロールはRBACなのでそのユーザーはクラシックポータルにアクセスできません（=ARMではないサービス等を管理できません）
またあたりまえですがリソースの操作と、各リソース内での権限は別物です。RBACでSQL Databaseを参照できるからといってSQL DatabaseにつないでDBの中身が見えるのは別物です。（RBACはリソース管理をするための仕組みなのでサービス内の制御はできません。※今のところ。SQL DatabaseなどはDBへのアクセス制御にAzure AD使えるようになったりしてるので可能になる可能性もありますが）
各ロールでできることはドキュメントに書かれているのでそちらを参照ください。だいたいは対象のリソースの管理とロール・ロール割り当ての読み取り、関連リソースの参照、アラートルールの管理とサポートチケットの管理などが行えます。（閲覧者など特殊なのもあります）
例えば仮想マシンの共同作成者であれば関連リソースとしてストレージや仮想ネットワークの参照、参加などの権限も含まれます。まぁ細かいのはドキュメント見てください。NOT Actionということで明示的に拒否される操作もあります。
対象のディレクトリ
サブスクリプションに紐づくAzure Active Directoryが使えます。
また外部ユーザーとしてMicrosoftアカウントを招待して使うことができます。（Azure AD側で招待OKにしておかないといけない）
ディレクトリの関連付けを変更したい場合などはこちらのドキュメントを参照。
また割り当てることができるのはMicrosoftアカウントやAzure AD上のユーザーのほかにAzure ADのグループ、サービスプリンシパルも利用できます。
大規模な場合はグループなどをうまく活用しましょう。またアプリケーションから管理する場合などはサービスプリンシパルが利用できますね。
設定方法
コマンドで行う場合はこちらを参照ください。
Previewポータル上で行う場合はサブスクリプション内の「役割」ブレードから行えます。
追加でAzure AD上のユーザーやグループを選択できます（Ctrl+クリックで複数同時選択もOK）。また「招待する」かユーザー名欄にMicrosoftアカウントを入力すれば外部ユーザーを追加することもできます。
追加されているかどうかは役割ブレードのユーザー/グループ列を見ればすぐにわかりますね。
リソースへの個別権限割り当て
各リソースのユーザーぽいリンクやプロパティの「ユーザー」から行えます。
監査周り
ロールの割り当て・変更などの操作は監査ログ（Audit Log）に記録されます。ResourceProviderName が Microsoft.Authorization のイベントで記録されるのでそちらを参照ください。
PrincipalIdが割り当てようとした対象のID（AzureAD上の）、RoleDefinitionIdやScopeが対象のロール、サブスクリプションなどのスコープのIDになります。IDから名称などを引っ張ろうとするとAzure PowerShellなどを呼び出して引かないとわかりませんが監査ログに最低限の情報残ってます。
既知の問題など
App Serviceや仮想マシンなど関連するリソースが多いとややこしい状態になるので注意しましょう。
まとめ
ぜひRBAC活用して安全な運用を目指してください。
補足
通常、AzureにサインアップするにはMicrosoftアカウントが必要ですけど、今では組織アカウント（Azure ADアカウント）を使ってサインアップできます。
Microsoftアカウントを排除することでRBACも活かしやすくなりますね。（MSアカウントの長期間未使用によるサブスクリプション停止問題も気にせず企業の管理下でちゃんと使えますね）
ブチザッキ 