1
votes

Microsoft Graph - Filtrage des utilisateurs par proxy X500

Est-il possible de rechercher des utilisateurs, filtrés par une adresse proxy X500?

En utilisant la requête suivante qui filtre par une adresse SMTP, je peux renvoyer toutes mes adresses proxy:

{
  "error": {
    "code": "Request_UnsupportedQuery",
    "message": "Unsupported or invalid query filter clause specified for property 'proxyAddresses' of resource 'User'.",
    "innerError": {
      "request-id": "adcdefg",
      "date": "2019-01-01T01:01:01"
    }
  }
}


2 commentaires

Merci Mark. Appel de support ouvert avec MSFT, je fournirai une réponse officielle lorsque j'en aurai une


@MarcLaFleur Aussi, il est intéressant de noter que la deuxième requête de LisaJ ci-dessous utilise des parenthèses et semble fonctionner correctement. Je peux voir que mon organisation dans l'adresse est «exchangelabs», pas sûr à 100%, mais je suppose que cela est utilisé pour les boîtes aux lettres hébergées dans le cloud - alors peut-être que le problème est uniquement lié à celles-ci?


4 Réponses :


2
votes

Je peux utiliser des adresses X500 comme filtres sans aucune modification de l'adresse à partir d'un clone de GraphExplorer . Les requêtes suivantes renvoient toutes les deux l'enregistrement utilisateur correct

https://graph.microsoft.com/v1.0/users/?$filter=proxyAddresses/any(x:x eq 'X500:/o=Company Exchange/ou=External (FYDIBOHF25SPDLT)/cn=Recipients/cn=z804261192zc46c4az4f6032z322540z')&$select=proxyAddresses

et

https://graph.microsoft.com/v1.0/users/?$filter=proxyAddresses/any(x:x eq 'x500:/o=Company Exchange/ou=First Administrative Group/cn=Recipients/cn=UIDHere')&$select=proxyAddresses


1 commentaires

Merci - il est bon de savoir qu'il est pris en charge. Je n'arrive toujours pas à le faire fonctionner ici, et j'ai du mal à voir les différences entre votre requête et la mienne. Un pour le support MSFT alors, je suppose



2
votes

Comme Lisa - il ne s'agit pas de parenthèses. J'ai des requêtes lambda sur proxyAddresses utilisant des adresses X500 contenant des parenthèses qui fonctionnent très bien dans Graph Explorer.

Je soupçonne que le problème est en fait la taille de la chaîne de recherche. Je reprends l'erreur si la taille de la chaîne de recherche est supérieure à 120 caractères.

Je fais le suivi avec l'équipe d'ingénierie.

En attendant, Paul, comme solution de contournement (et excusez mon manque de connaissances sur X500), existe-t-il un moyen d'interroger en utilisant la chaîne X500 la plus courte?

J'espère que cela vous aidera,


4 commentaires

Merci Dan. Je manque également de connaissances sur X500, donc je ne sais pas s'il est possible de raccourcir cette chaîne. Ma solution est une intégration Outlook - je tire l'adresse X500 à l'aide de l'API Outlook côté client, donc je suis à la merci d'Outlook en ce qui concerne l'adresse qui me est donnée. Il est potentiellement possible de résoudre le X500 par ex. une adresse smtp utilisant l'API Outlook, mais cela ajoute beaucoup de complications (par exemple, fonctionne différemment en mode hors ligne), donc je préfère de loin simplement remettre ce que je suis donné à Graph


J'essaierai de répondre une fois que j'aurai reçu une réponse de l'équipe d'ingénierie, et voir si une solution est possible. Ne récupérez-vous qu'un seul X500? Si vous récupérez plusieurs retours d'Outlook, pourriez-vous choisir le plus court?


OK, merci Dan. Je ne reçois malheureusement qu'une seule adresse


Merci d'avoir regardé ça, Dan. J'ai trouvé une solution de contournement simple - voir la réponse acceptée. D'après ce que je peux comprendre, Azure AD a une limite de 133 caractères pour proxyAddresses, donc ce serait formidable si la limite du paramètre de filtre pouvait être augmentée en conséquence



1
votes

Comme l'a répondu Dan Kershaw - cela semble être une limite codée en dur de 120 caractères dans l'adresse e-mail filtrée.

Une solution simple consiste à réduire l'adresse e-mail (y compris le schéma - "x500:" ou "smtp:") à 120 caractères, et recherchez en utilisant un "commence par":

/v1.0/users/?$filter=proxyAddresses/any(x:startswith(x, 'x500:/o=ExchangeLabs/ou=Exchange Administrative Group (blahblah)/cn=Recipients/cn=trimmed'))&$select=proxyAddresses

Cela peut renvoyer plus d'une correspondance, donc c'est alors un cas de regarder dans chaque retourné utilisateur, et en regardant sa collection "proxyAddresses" pour voir laquelle correspond à l'adresse e-mail d'origine non tronquée qui fait l'objet de la recherche.


2 commentaires

C'est drôle - je revenais juste à ce fil pour suggérer exactement la même chose sur l'utilisation d'une clause beginwith. Félicitations à toi Paul, et merci pour le partage avec la communauté! Je vais toujours déposer un bug pour ce problème aussi.


Cheers @ DanKershaw-MSFT - heureux qu'il y ait un bogue ouvert car c'est le genre de problème qui pourrait facilement être manqué lors des tests, puis n'apparaître que sporadiquement dans un environnement de production



1
votes

Je peux confirmer qu'il s'agit toujours d'un problème à la date d'aujourd'hui.

J'utilise en fait les applets de commande AzureAD PowerShell, qui exploitent l'API Graph.

Je ne pouvais pas comprendre pourquoi ma requête échouait avant d'avoir trouvé ce fil de discussion, alors merci pour cela.

J'obtenais essentiellement le même message d'erreur dans PowerShell: "Clause de filtre de requête non prise en charge ou non valide spécifiée pour la propriété 'proxyAddresses' de la ressource 'Group'."

Quand j'ai pris une sous-chaîne des 120 premiers caractères et que j'ai exécuté un startsWith, cela a bien fonctionné.

C'est dommage que ce problème n'ait toujours pas été résolu.


0 commentaires