Jamf Pro Classic APIのBasic認証をBearer認証に置き換える
Jamf ProのAPIとは?
Jamf社が提供するAppleデバイスの管理に特化したMDM、Jamf Pro。
標準機能だけでも柔軟な管理が可能ですが、Jamf ProではAPIが公開されており、これを活用することでさらに様々な要件を実装することが可能です。
例えば、Macのコンピュータ名を会社の管理番号で自動付番したり、アプリ使用ログを集計して勤怠システム上の時間と乖離がないか確認したり...。
国内外様々な企業の管理者様が、自社の要件に基づいて素晴らしい仕組みを構築されています。
そんなJamf ProのAPIですが、認証方法変更のアナウンスに伴い、一部手直しが必要になってきましたので、今回はそちらの作業を行っていきたいと思います。
※APIをご利用されていない方にはまったく関係の無い、正直かなりニッチな内容ですがご興味ある方はお付き合い頂ければ幸いです...!
【2024年5月28日 追記】
Jamf Pro Classic APIにおけるBasic認証は2024年3月に廃止され、11.5へのアップグレード時に自動的にオフに変更となっています。(設定 > ユーザアカウントとグループ > パスワードポリシー > Classic API に Basic 認証を許可)
重要なお知らせ - Jamf Pro リリースノート 11.5.0 | Jamf
本ブログでご紹介しているBearer認証、あるいはAPIロールとクライアントを使用した認証が必要となりますのでご注意ください!
はじめに
まず、今回手直しする必要があるのは「Classic API」と呼ばれるインターフェースを使用している場合になります。
※Jamf ProにはClassic APIとJamf Pro API、2種類のAPIがあります。両者の違いについては、以下のページをご参照ください。
Jamf Pro - Jamf Developer Portal | JamfClassic APIではこれまで「Basic認証」と呼ばれる認証方式をサポートしていましたが、2022年8~12月を目安に廃止が予定されており、順次「Bearer(ベアラー)認証」に置き換えていく必要があります。
※案内自体は2022年1月にリリースされたJamf Pro 10.35.0からされていましたが、いよいよ廃止時期が近づいてきたため、今回実際に試していくという次第です。
廃止および削除 - Jamf Pro リリースノート | Jamf Classic API Authentication Changes設定
それでは、「Bearer(ベアラー)認証」の設定を進めていきましょう。
ステップ1:Basic認証について(前提の確認)
まずは前提の確認です。
Basic認証では、Jamf Proユーザアカウントとグループの情報を用いて認証を行っていました。以下のような形でスクリプト内に情報を記述します。
#!/bin/bash
jssURL="https://xxxxxx.jamfcloud.com"
apiUsername="USERNAME"
apiPassword="PASSWORD"
※余談ですが、Jamf Proのポリシー機能でスクリプトを展開する場合、パラメータを活用して以下のように定義することも可能です。スクリプト内にユーザ情報を平文で記述したくない!という場合にオススメです。
#!/bin/bash
jssURL="https://xxxxxx.jamfcloud.com"
apiUsername="$4"
apiPassword="$5"
また、指定するユーザの権限はJamf Pro側でカスタマイズすることが可能です。
例えば、前段でご紹介させて頂いたアプリ使用ログを集計する場合であれば、コンピュータのインベントリ情報を読み取りできれば良いだけですので、Jamf Proのシステム設定 > Jamf Proユーザアカウントとグループ>権限タブから以下の画像のように設定します。
※APIエンドポイントごとに必要な権限については以下のページをご参照ください。
Privilege Requirementsステップ2:Bearer認証への置き換え
それでは、実際に置き換え作業を行っていきます。
まずは、以下のコマンドをターミナル等で実行してBase64でエンコードされた認証ヘッダを生成します。(今回の場合「VVNFUk5BTUU6UEFTU1dPUkQ=」という情報が返ってきます。)
Code Samplesprintf "USERNAME:PASSWORD" | iconv -t ISO-8859-1 | base64 -i -
そして、Jamf Pro APIの「/v1/auth/token」エンドポイントを使用してBearerトークンのリクエストを行います。
Create a token based on other authentication details (basic, etc.)先程のヘッダ情報を使用して、以下のような形で記述していきます。
※このスクリプトをポリシーで展開する場合は、ステップ1と同様に変数authTokenを「"$4"」にて定義しても大丈夫です。
#!/bin/bash
jssURL="https://xxxxxx.jamfcloud.com"
authHeader="VVNFUk5BTUU6UEFTU1dPUkQ="
authToken=$(curl -s -X POST "${jssURL}/api/v1/auth/token" -H "Accept: application/json" -H "Authorization: Basic ${authHeader}" | plutil -extract token raw -)
こちらのスクリプトを実行すると、変数authTokenには以下のような情報が代入されています。(一部の文字を変更しています。)
このトークンは通常30分後に失効してしまうため、今回のスクリプトでは認証ヘッダ情報を使用して都度新しいトークンを入手する形を想定しています。
※現在有効なトークンと「/v1/auth/keep-alive」エンドポイントを使用して、新しいトークンを生成することも可能ですので、場合によってはこちらを使用するほうが良いかもしれません。
Invalidate existing token and generates new tokenあとは、このトークンを使用してこれまで同様APIを実行するだけです。 例えば、コンピュータのインベントリ情報を取得する場合以下のような形で記述できます。
#!/bin/bash
serialNumber=$(system_profiler SPHardwareDataType | awk '/Serial/ {print $4}')
jssURL="https://xxxxxx.jamfcloud.com"
authHeader="VVNFUk5BTUU6UEFTU1dPUkQ="
authToken=$(curl -s -X POST "${jssURL}/api/v1/auth/token" -H "Accept: application/json" -H "Authorization: Basic ${authHeader}" | plutil -extract token raw -)
curl -s -X GET "${jssURL}/JSSResource/computers/serialnumber/${serialNumber}" -H "authorization: Bearer ${authToken}" | xmllint --format -
以上です!
活用事例(直近1週間のMac利用時間を集計)
...というわけで本題は終了してしまったのですが、これだけでは内容が少し寂しい気もするので、最後に今回のBearer認証を使用した実際の活用事例を記載させて頂きます。
基本的には、前段でご紹介させて頂いたアプリ使用ログを集計する記事と同じ内容なのですが、そこではGAS(Google Apps Script)を活用して、Googleスプレッドシートにまとめる手法が解説されていました。
ですが、お客様によってはGoogleサービスをご利用されていないケースもあるかと思います。
今回は、
①Jamf Proの拡張属性にて直近1週間のMac利用時間をインベントリ情報として収集
②その情報を条件にスマートグループでしきい値を定義
これによって、しきい値超えている(=働き過ぎ)なユーザをピックアップする形式で行こうと思います。
まず、拡張属性に定義するスクリプトは以下のとおりです。
※今回は直近1週間で収集していますが、例えば1ヶ月とする場合は変数startDate(6行目)の部分を「date -v-1m '+%Y-%m-%d'」に変更してください。
#!/bin/bash
# 基本情報
jssURL="https://xxxxxx.jamfcloud.com"
authHeader="VVNFUk5BTUU6UEFTU1dPUkQ="
startDate=$(date -v-1w '+%Y-%m-%d')
endDate=$(date '+%Y-%m-%d')
# 直近1週間のMac利用時間(分)を集計
authToken=$(curl -s -X POST "${jssURL}/api/v1/auth/token" -H "Accept: application/json" -H "Authorization: Basic ${authHeader}" | plutil -extract token raw -)
serialNumber=$(system_profiler SPHardwareDataType | awk '/Serial/ {print $4}')
foregroundList=$( curl -s -H "Accept: text/xml" -H "Authorization: Bearer ${authToken}" "${jssURL}/JSSResource/computerapplicationusage/serialnumber/ $serialNumber/${startDate}_${endDate}" | xmllint --format - | grep "foreground" | awk -F ">|<" '{ print $3 }' )
totalMinutes=$( echo "$foregroundList" | awk '{ total += $0 } END { print total }' )
echo "${totalMinutes}"
ちなみに、スクリプトの実行結果は「2496」のように数字で返ってきますので、拡張属性のデータタイプは必ず「Integer」を選択してください。
次にスマートグループでしきい値を定義します。
例えば1日の勤務時間を8時間、残業が4時間を超えている状態が継続していたら働き過ぎと仮定します。(本当はもっと早く上がるべきです...!)
というわけで、以下のように(480+240)×5=3600分をCriteriaの数値に入力します。
あとは、こちらのスマートグループに誰かが含まれる際には、Slackに通知を飛ばす、デバイスにメッセージを表示するなどのアクションを検討します。
Slackへの通知については以下の記事をご参照ください。
Jamf Proからの通知をSlackで受け取る方法を考えてみました。 | @kajinariメッセージを表示する手法は様々ありますが、以下の記事のようにjamfHelperを活用するのが良いかと思います。
Marriott Library - Apple Infrastructure | Helping jamfHelperこんな感じでメッセージが表示されます。
※決してふざけているわけではないのです。こんなメッセージは目にする機会が無いのがイチバンですね...。
まとめ
いかがでしたでしょうか?
冒頭にもお話させて頂きましたが、Jamf ProでAppleデバイスを管理するにあたり、APIの利用は必須ではありません。(むしろイレギュラーであることの方が多いです。)
ですが、運用上の課題になっていることが場合によっては解決できるかもしれません。 もしお困り事や、今回の内容で気になることがございましたら、API利用要否の判断含めサポートさせて頂ければと思いますので、ぜひお気軽にお問い合わせください!
記事は2022年6月16日現在の内容です。
この記事に付けられたタグ
おすすめ記事を見る