@Aliaksandr.Samuseu, Whispeak is one of our new partners. Could give them some pointers on this integration?

Hi. Just one suggestion, before we'll dive into the main issue - could you please create a separate ticket for Cache Refresh? I'll pick it up right away. It just makes much more difficult to sort out one issue from another, when ticket covers several of them.

One question, about this part: >Files that I'm sharing are just from the Gluu steps. Installation is done via docker using pygluu-compose, I was able to do all changes except in "gluu-ldap.properties" were "binaryAttributes=objectGUID,objectguid" is being overwritten with "binaryAttributes=objectGUID" when I'm restarting the containers You're talking about regular standalone Gluu Server, right? Not a cluster, neither a Docker or K8S based setup? It's just you mentioning "containers" in plural confuses me a bit (I'm thinking of how I can quickly reproduce your issue).

Hi, Than thank you all for your fast answers. Installation is performed via pygluu-compose so on docket with multiple containers: oxtrust, oxauth and shibboleth for the main Gluu services. I have followed this link instructions https://gluu.org/docs/gluu-server/4.2/installation-guide/install-docker/. I have included svc files with the customizations made for oxtrust and oxshibbolrth in the shared folder. Sure, as it with the same integration I was including cache refresh issues but I'll open a new ticket for that. Not as much as a priority that part for now. regards

Hi, I have created this other ticked for cache-refresh issues and removed info from this one to have the issue more clear: https://support.gluu.org/single-sign-on/9606/cache-refrest-not-importing-users/ We have continued to review and try with different configs but we did not arrive to have the NameIdPolicy working. Do you had the opportunity to take a look to our configs? Do you know what might be not working in our scenario? Thanks in advance

Hi, Vreixo. Sorry for the delayed answer. > Do you had the opportunity to take a look to our configs? Do you know what might be not working in our scenario? Yes, I checked them. I'm trying to reproduce the issue locally as of now. The difficulty is that I don't have access to O365 at hand right now, so need to improvise. As it seems to be a "wrong nameid" kind of error thrown right away, I think I'll be able to, with some request replaying magic. But if you have some time, that would also help to have a HAR file of your failing flow at hand. You can use steps listed [here](https://www.inflectra.com/support/knowledgebase/kb254.aspx) - please use Firefox for that task, Chrome's HARs are flawed. Also don't forget to set "Persist log" and "Disable cache" checkboxes in the console to save everything, not just the recently loaded page. I took over your other ticket, as well.

Hi Aliaksandr, Our tests are performed with a office365 development tenant so I could give you the address and the credentials of a test user without any issues, so you can actually test our setup (our test server is publicly available) or also create you a test user in Gluu as it's all a testing environment separated from our production infrastructures and data. I would just rather send them via email and not post them here publicly. Either way I'm going to take the HAR files from Firefox and add them here.

Here it's the HAR file from Firefox. If you want to actually test it you can go to https://login.microsoftonline.com and use this temporal test user without any license nor permissions associated and no permissions over Gluu either, other than access the profile: fromldapwindows@whispeak.fr 8fNAeNgPtE9w6s6H

Excellent, thanks! I'll give it a try.

I'm attaching the HAR here with the calls https://www.dropbox.com/s/eyr4lxchqp5ti90/365-gluu.har?dl=0

Hi, have you been able to reproduce our issues? If you need further details please don't hesitate as we would like to have the integration as soon as possible thanks in advance,

Hi. Sorry for the delayed answer. Yes, I was able to confirm that some inconsistencies on how to configure nameid for this integration exist in our docs. I'm currently trying to figure out the best way to achieve it in the recent Gluu Server package.

Hi, Do you have some advancements regarding the investigation of our integration issues? We have a pending client because of this integration so it would be great if we can unlock the situation and we don't find the issue with the configuration. Thank you very much,

Hi. Yes, terribly sorry about the delay.. Need to have a few words with dev team member responsible for Docker/K8s version of Gluu. Please bear with me for a bit longer..

Btw, when I try to use the test setup you mentioned [above](https://support.gluu.org/single-sign-on/9594/office-365-invalidnameidpolicy-error/#at69357) again, you Gluu Server now responds as if it doesn't have SAML TR created for this SP (O365). Did you remove it, perhaps?

Hi, Thanks for reviewing our ticket. We have made some configuration changes and restarted our server and three trust relationships that we had passed to deactivated, it should be a bug in the version that we use. Now we have reactivated it and it should work. Is not a current requirement to go with Docker we we're just installing this way as we had issues with kubernetes version which is our desired deployment solution, if we will have a working solution sooner we can go with other installation method although we will need to redo some work so not ideal either.

Hi, Did you find any issues with our configuration? As I was stating in my previous message we have reactivated the SAML configs and the scenario is exactly the same that we discussed. I'm also seeing that SSO post is taking very very long to be answered from Gluu even getting a "stale request" error.

Hi. As of now, I'm able to configure properly functioning nameid for O365 in standalone Gluu Server. After creating custom attributes as instructed by the docs, what involved modifications to LDAP schema, I was able to add nameid by simply going to "SAML > Configure Custom NameId" and adding a mapping there like "Source Attribute: objectguid", "NameId Type: urn:oasis:names:tc:SAML:2.0:nameid-format:persistent". The just "IDPEmail" and "objectguid" attributes need to be released for this TR, and this should be it. The problem is how to push the LDAP schema changes and populate "obejctguid" in the first place (requires Cache Refresh).

I have created custom attributes also as instructed and they're properly working, I can add values in the interface to the users in these fields. > The problem is how to push the LDAP schema changes and populate "obejctguid" in the first place (requires Cache Refresh). In order to do a quick test I wanted to just add manually the objectuid for a specific user, so it should work without Cache Refresh. Am I right? > As of now, I'm able to configure properly functioning nameid for O365 in standalone Gluu Server. After creating custom attributes as instructed by the docs, what involved modifications to LDAP schema, I was able to add nameid by simply going to "SAML > Configure Custom NameId" and adding a mapping there like "Source Attribute: objectguid", "NameId Type: urn:oasis:names:tc:SAML:2.0:nameid-format:persistent". The just "IDPEmail" and "objectguid" attributes need to be released for this TR, and this should be it. If these are the only changes that you're making I understand that the changes in "saml-nameid" and "attribute-resolver" files which are described here https://gluu.org/docs/gluu-server/4.2/integration/saas/office/#immutableid-nameid-configuration is not necessary to do them. Another difference in between your statement and the docs is that you're configuring as nameid "objectguid" instead of "ImmutableID". So I have added attributes for test user directly, made both changes and removed this change in docs which I assume that is for cache refresh too https://gluu.org/docs/gluu-server/4.2/integration/saas/office/#add-mapping-in-ox-ldapproperties-file. With this new configuration error is exactly the same, I'm attaching the details for the user, the configs, logs and a new HAR. https://www.dropbox.com/s/nynylzbhb3wfo5d/Capture%20d%E2%80%99%C3%A9cran%20de%202021-05-26%2009-09-26.png?dl=0 https://www.dropbox.com/s/ezr47u6diyk6o0e/Capture%20d%E2%80%99%C3%A9cran%20de%202021-05-26%2009-09-36.png?dl=0 https://www.dropbox.com/s/uxduojx2hz9sijd/Capture%20d%E2%80%99%C3%A9cran%20de%202021-05-26%2009-10-02.png?dl=0 https://www.dropbox.com/s/26gs7t6y85eakxt/Capture%20d%E2%80%99%C3%A9cran%20de%202021-05-26%2009-10-18.png?dl=0 https://www.dropbox.com/s/21g4llk95evmbtp/Capture%20d%E2%80%99%C3%A9cran%20de%202021-05-26%2009-10-29.png?dl=0 https://www.dropbox.com/s/allsbs0mmj0j167/Capture%20d%E2%80%99%C3%A9cran%20de%202021-05-26%2009-10-57.png?dl=0 https://www.dropbox.com/s/8qbcs7ptxm86fv6/Capture%20d%E2%80%99%C3%A9cran%20de%202021-05-26%2009-11-11.png?dl=0 https://www.dropbox.com/s/e9exv5wh97m57rd/gluu-365-20210526.har?dl=0

Hi. I've done some double-checking, to be sure, and it seems to work for me, in standalone setup. I'll list all the steps I used below, just for the record, before moving to the next phase (making it wokring in Docker). The doc itself a bit overcomplicated and outdated, it seems. 1. The attributes still need to be added, for that schema needs to be modified, as docs instruct; ext attributes are needed: "IDPEmail" and "objectguid". "ImmutableID" isn't really required; for "objectguid", you still also need to modify ` /etc/gluu/conf/gluu-ldap.properties` as mentioned in the doc (unless the mapping for binary attribute "objectGUID" is already there OOTB in your setup) 2. Cache Refresh needs to be configured to populate these two new attributes; it needs to import the two attributes mentioned above, in addition to the set of basice attributes ("uid", "mail", "phone" etc); I think with some remapping it's possible to not create a separate "IDPEmail" attribute that just stores the same value as "mail" as well, but that will require more templates customization, so using a separate attribute is simpler, unless it makes your database significantly larger; when using "IDPEmail" as a separate attribute, you need to add mapping for it to CR's settings, using "mail" attribute as source 3. Creating SAML TR for O365 should be straightforward, make sure you release "IDPEmail" and "objectguid" attributes there 4. To make nameid for O365 work, we need to modify just one file, `/opt/shibboleth-idp/conf/saml-nameid.xml`; that can be done either manually in the file itself (but these changes won't persist for long; useful for quick testing still), or by modifying oxTrust's templates files. The change on itself is simple, just one fragment is needs to be added there: ``` <bean parent="shibboleth.SAML2AttributeSourcedGenerator" p:format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" p:attributeSourceIds="#{ {'objectguid'} }"> <property name="activationCondition"> <bean parent="shibboleth.Conditions.RelyingPartyId" c:candidates="#{{'urn:federation:MicrosoftOnline'}}" /> </property> </bean> ``` For reference, I'm also attaching the template file that does the same, but with persisting the change (needs to be placed under `/opt/gluu/jetty/identity/conf/shibboleth3/idp/` for that). With these changes, it should start to return the expected nameid to Office. Hope that helps. Also, if you have some issues with configuring Cache Refresh, but need to do a quick testing, you can just add "IDPEmail" and "objectguid" attributes to your test user manually, that would do I'll provide steps for configuring this all in Docker setup very soon, again, terribly sorry for the long delay.

Hi. Just a quick status update: I'm making progress with moving all the changes to Docker setup, still need to resolve this issue with Cache Refresh, which is required to work to import users with objectguid from AD properly. Some pieces are still missing there.

Hi, I'm happy to hear that and would be great if we could have soon a solution. Thanks for your investigations

Hi. We have a working solution for Docker, I'm currently preparing paper for you guys to reproduce all steps in your setup. Please bear with us a bit longer, we are almost there.

Hi Aliaksandr, We have configured an standard installation with the Ubuntu packages and we do have still the same issues that before "InvalidNameIdPolicy". Following your steps we have added the 3 custom attributes, created the TR releasing both 3 and finally added your excerpt in the /opt/shibboleth-idp/conf/saml-nameid.xml. We have also tested with the template file but the result is the same. Can we check someway which is the current NameId policy which is been detected by shibboleth? At the end of this message I'm attaching the logs from shibboleth. 2021-06-16 14:57:36,938 - 195.90.117.170 - INFO [org.gluu.idp.externalauth.ShibOxAuthAuthServlet:148] - Processing authorization response 2021-06-16 14:57:37,136 - 195.90.117.170 - INFO [org.gluu.oxauth.client.OpenIdClient:412] - Using default claims to attributes mapping 2021-06-16 14:57:37,138 - 195.90.117.170 - INFO [org.gluu.idp.externalauth.AuthenticatedNameTranslator:60] - Created an IdP subject instance with principals containing attributes for fromldapwindows@whispeak.fr 2021-06-16 14:57:37,162 - 195.90.117.170 - INFO [net.shibboleth.idp.authn.impl.ValidateExternalAuthentication:176] - Profile Action ValidateExternalAuthentication: External authentication succeeded for Subject 2021-06-16 14:57:37,232 - 195.90.117.170 - ERROR [net.shibboleth.idp.profile.impl.ResolveAttributes:276] - Profile Action ResolveAttributes: Error resolving attributes: Invalid Attribute resolver configuration 2021-06-16 14:57:37,259 - 195.90.117.170 - WARN [net.shibboleth.idp.saml.nameid.impl.AttributeSourcedSAML2NameIDGenerator:148] - Unable to locate AttributeContext 2021-06-16 14:57:37,260 - 195.90.117.170 - WARN [org.opensaml.saml.saml2.profile.impl.AddNameIDToSubjects:334] - Profile Action AddNameIDToSubjects: Request specified use of an unsupportable identifier format: urn:oasis:names:tc:SAML:2.0:nameid-format:persistent 2021-06-16 14:57:37,264 - 195.90.117.170 - WARN [org.opensaml.profile.action.impl.LogEvent:101] - A non-proceed event occurred while processing the request: InvalidNameIDPolicy 2021-06-16 14:57:37,298 - 195.90.117.170 - WARN [org.opensaml.saml.common.binding.SAMLBindingSupport:95] - Relay state exceeds 80 bytes: estsredirect=2&estsrequest=rQIIAY2SO2zTYACE46R1HyqlQgxISKgSDAgU5_cjJq1UiTR2WrexE-dZe4kcP-Lfsf279t86zY7EY-ncCTF2ZAF1YmHpVDEWkBATQkJCTIw0YmHkG0433HDS3eIcT_EUoMCDHE3R6_fAX_j8VPPAcei8aU_dP8Q3FlfePKHrn1ovpOfkZ_YLvnx2Stx1MY6S9ULBsAIYUgE0Y5QgB1MmCgq-EVowHL4liAuC-EYQJ9lZJ85Xm6fZhGcfFbki4Nk1wAKGZ5kiJW9VXV3oHGk9Gde3qiOlAoAyGdK13s5ICTQst2VaFiRaaZfZeltxda87kicjRvNUrHnNkdYCQGvrsNaTGFnoYF2QUlloerLgQ8Xr0JfZ6_XyAXaZqaAYTuxf2QUHxUE_Qgk-yX0g6pEdSlYFhaFtYmoas0MMTQNDFDZiFNkxhnaygeMeo9Uczi8djri0ietAhD3JD3b3GEEV-8a4JLMBsMV6Q8yrlQM_sde6cml73zxqGRzT3JwIqqfwZTqsVaKEp1WUdobR4dA0Oh5wx3wjBaYIGqxiNbaOWvFADasRmOQDvwYTR9Ecn2X6PvCFcZmXhnDPtprigFO63dR1eEf3fLitAMsec5ARS69z5NUQAQrPc8tX_UNorUYxcqBvf83ddmIU-JYRpTC0UJo8Tl2YRLYxopz4Yob4PrM0T66QtzKrmfs3wfLvGeLV7NUFDl96nz5SdzbP3i8RP_YXMuezhcnudiwpCAzUTVioNDi92wsGB67c0nbUysPBgAWQNeWJqGtgo7hOH5PEMUmek_OS0FfENlf8SRJP5zJnC__zpXfXMn8A0 2021-06-16 14:57:37,310 - 195.90.117.170 - INFO [Shibboleth-Audit.SSO:282] - 195.90.117.170|2021-06-16T14:57:22.409506Z|2021-06-16T14:57:37.310637Z|fromldapwindows@whispeak.fr|urn:federation:MicrosoftOnline|||||||false|false||urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST||Requester|urn:oasis:names:tc:SAML:2.0:status:InvalidNameIDPolicy|089ea07d9cc0376bffc6466678e8e1112e6e8ec25c27fcd0825f9915a8af4300|Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.77 Safari/537.36

I have tried different configs for InvalidNameIdPolicy and now I'm having this error when being redirected to microsoft after login but nameidpolicy seems to be ok: `AADSTS51004: The user account 77DC22AXU43LDBZZB73L54XGTAKMHQW7 does not exist in the 997f472c-f725-46fa-97a3-ef7c160f84e5 directory. To sign into this application, the account must be added to the directory.` Regarding Gluu idp logs I see ``` 2021-06-17 18:16:19,593 - 195.90.117.170 - INFO [org.gluu.idp.externalauth.ShibOxAuthAuthServlet:148] - Processing authorization response 2021-06-17 18:16:19,855 - 195.90.117.170 - INFO [org.gluu.oxauth.client.OpenIdClient:412] - Using default claims to attributes mapping 2021-06-17 18:16:19,856 - 195.90.117.170 - INFO [org.gluu.idp.externalauth.AuthenticatedNameTranslator:60] - Created an IdP subject instance with principals containing attributes for fromldapwindows@whispeak.fr 2021-06-17 18:16:19,877 - 195.90.117.170 - INFO [net.shibboleth.idp.authn.impl.ValidateExternalAuthentication:176] - Profile Action ValidateExternalAuthentication: External authentication succeeded for Subject 2021-06-17 18:16:20,188 - 195.90.117.170 - WARN [org.opensaml.saml.common.binding.SAMLBindingSupport:95] - Relay state exceeds 80 bytes: estsredirect=2&estsrequest=rQIIAY2SO2zTYACE46R104pHhRiQWCqBBEKK8_sRN61UiTR2UtPYSZxX7SVybf_J73ftv3WaHYnHQCeGjoxlYwF1Yu5UMVYgEBNiQp0YacTCyDecbrjhpLulBZ7iKUCBRzmaotfvg7_whZkWAIR0wbRn7h_iW0vL75_Szc-dl9IL8gv7DV88PyHujTGOkvVi0bB8FFA-MuMwCSGmzNAvekZgoWD0gSDOCeIHQRxn52FcqKkn2YRnV0tcCfDsGmABw7NMiZLrtbEu9A61gYyb9ZqrVAFQpiO6MXjiKr6G5a5My4JEK90K2-wqY93pu_LUZTSnjTVHdbUOAFpXR42BxMhCD-uClMqC6siChxSnR19kbzYr-3jMzCSM0dS-zC7CMPaHUZjg49wnohnZgWRVwyCwTUzNYnaAkWlgFAatOIzsGCM72cDxgNEakPPKBy6XqrgJRDSQPH97hxHa4tCYlGXWB7bYbImFdnXfS-y1vlze2jMPOwbHqJtToe0ofIUOGtUo4el2mPZG0cHINHoOGE_4VgpMEbRYxWrVDzvxbjuoRWBa8L0GSqCiQY9lhh7whEmFl0Zox7ZUcZdT-v10DHmoOx7aUoBlTzjEiOV3OfJqCD8MznI3rvoHyFqJ4hAiz_6euwvj0PcsI0pRYIVp8jgdoySyDZeC8fkc8XPuWp5cJu9kVjIPb4P87znizfzVBWoP_MLbS1x_1f66dpp_nTmbL-q8KnV2Ng-2W5t7wKlvlX29X-JUuQj3HCW2FQ1jAbr7aTQdbayu00ckcUSSZ2ReEoaK2OVKv0ji2ULmdPF_vvTxeuYP0 2021-06-17 18:16:20,198 - 195.90.117.170 - INFO [Shibboleth-Audit.SSO:282] - 195.90.117.170|2021-06-17T18:15:45.474008Z|2021-06-17T18:16:20.197815Z|fromldapwindows@whispeak.fr|urn:federation:MicrosoftOnline|_7a3542cf9deba8dc55d40992ce1c58b2|password|2021-06-17T18:16:19.878542Z|ImmutableID,IDPEmail,objectguid|77DC22AXU43LDBZZB73L54XGTAKMHQW7|persistent|false|false||urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST||Success||ad52c9f5232f931ece508491ed99627731cc7d57d16e179012a81ba181052887|Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.77 Safari/537.36 ``` Finally user real data is: ``` email: fromldapwindows@whispeak.fr immutableid: ELCM9YR150OX/UsXXSeqKg== objectid: 44dca103-359b-4abb-bba5-633257317852 ``` In gluu I have tested in field objectguid to put objectid, immutableid and base64 transformation of objectid and nothing works. Although this user identifier is changing "77DC22AXU43LDBZZB73L54XGTAKMHQW7". Users are properly directory synced from AD in premises so I don't see where it might be the issue. Thanks in advance for help with this new findings

Hi. ``` objectid: 44dca103-359b-4abb-bba5-633257317852 ``` <- is this an actual attribute on some user entry in your Gluu Server? That looks like plain text representation of objectguid from AD, so if you send it as nameid to O365 it won't work, as it expects binary value "as it is", according to data I've found in different integration guides so far. I have a working Docker installation that sends the correct value. I'm trying to compose some guide that will help you to reconfigure your setup the same way as of now.

Also, `immutableid: ELCM9YR150OX/UsXXSeqKg==` - what I assume is binary form of objectguid - doesn't seem to match the plaintext `44dca103-359b-4abb-bba5-633257317852` as far as I can tell. That means CR didn't import it properly.

Please try to follow next steps (while removing all extra configuration you have added so far while experimenting with it): 1. Start with adding the attributes we'll need; mostly you'll be following the guide from before - [this one](https://gluu.org/docs/gluu-server/4.2/integration/saas/office/) - with next changes: - we'll only need two of these attributes: `objectguid` and `IDPEmail` - to properly persist your changes to LDAP schema in Docker, you need to modify `77-customAttributes.ldif` schema file you can find under `volumes/opendj/config/schema/` in the directory where you deployed your Dockerized Gluu instance under - after you've modified the schema, run `# docker restart ldap` to make it load the new configuration, then proceed to registering these 2 attributes in web UI, as explained in the docs - regarding the section "Add mapping in 'ox-ldap.properties' file" - the file's name is actually `gluu-ldap.properties`, but good news you don't need to change it in this case, as it already contains `binaryAttributes=objectGUID` line OOTB, which should be enough; you can double-check it's there by running this: `# docker exec -ti oxtrust cat /etc/gluu/conf/gluu-ldap.properties | grep binaryAttributes` 2. Now when you have your attributes added, you need to configure CR properly. Let me share screenshots of configuration I use locally, hopefully it will give you enough clues (see "CR_configuration.jpg" in attachment). After you've done configuring it, run next command that will flush its working dir, what will ensure next time CR runs it will update all user entries: `# docker exec -ti oxtrust sh -c "rm -rf /var/gluu/identity/cr-snapshots/*"` 3. Do not try to configure nameid from web UI, it won't work for O365, it turns out, as it requires non-standard nameid type to send the objectguid; if you've added any nameids on "SAML > "Configure Custom NameId" page for O365 - please remove/disable them now. I'm attaching a template for `saml-nameid.xml.vm` file to this post, you'll need to copy it to the machine where your Dockerized Gluu runs, and follow next steps to deploy it: - create directory for your IDP config templates: `# mkdir -p volumes/oxtrust/idp_templates/` - copy your template there: `# cp saml-nameid.xml.vm volumes/oxtrust/idp_templates/` - edit `svc.oxtrust.yml` file; under "volumes:" section you need to add one more line, formatted exactly like the rest of the lines in this section; here is it: `- ./volumes/oxtrust/idp_templates:/opt/gluu/jetty/identity/conf/shibboleth3/idp` (please remember indentation is important in yml files!) - redeploy your whole Dockerized Gluu Server by running `# ./pygluu-compose.pyz down`, then `# ./pygluu-compose.pyz up` - as of now, you should see that O365 nameid defined in the template appearing in file `saml-nameid.xml` generated from the template inside oxTrust's container; you can double-check with this: `# docker exec -ti oxtrust cat /opt/shibboleth-idp/conf/saml-nameid.xml` (you'll see comment like "Microsoft requires a custom Persistent ID Generator..." there, together with nameid definition) 4. Now we need to employ Jackrabbit to allow oxTrust to properly deploy SAML configuration in Dockerized Gluu Server (unless you've already done this): - Open `settings.py` file and make sure you have next lines there: - `SVC_JACKRABBIT = True` - `DOCUMENT_STORE_TYPE = "JCA"` - `JACKRABBIT_USER = "admin"` - Open `jackrabbit_admin_password` file and make sure it contains a single "admin" string there (no quotes) - Redeploy your whole Dockerized Gluu Server by running `# ./pygluu-compose.pyz down`, then `# ./pygluu-compose.pyz up` - After it's started fully, log in to web UI, move to "Configuration" > "JSON Configuration" > "Store Provider Configuration" and: - change "Document store Type" to "JCA" - type "admin" into "User Id" field - type "admin" into "Password" field - click "Save configuration", then "Save store configuration" buttons; you shoud see pop-up message notifying you it's successfully changed, otherwise something is wrong, please double-check your actions - redeploy your whole Dockerized Gluu Server again by running `# ./pygluu-compose.pyz down`, then `# ./pygluu-compose.pyz up` 5. Create SAML TR using metadata I attached ("0365_metadata.xml"), as it's described in the O365 integration doc, with only exception that you need to release just two attributes: `objectguid` and `IDPEmail` 6. Redeploy both oxTrust and IDP containers to make them utilize new configuration faster: - `# docker restart oxtrust` - wait a minute - `# docker restart oxshibboleth` As of now, it should be ready to send proper formatted objectGUID to O365. Please try to run your flow, and share SAML response it produces now with us

Hi Aliaksandr, Thank you for your response. We have configured the services with the steps that you said in the docker installation (and in the standard as well making some adaptations) and cache refresh does work correctly but authentication still doesn't. Regarding this change is not possible to log users with passwords from windows active directory. Is it necessary to add the password manually for each user in Gluu?

>cache refresh does work correctly Let's make sure it does, I would say. 1. Set "loggingLevel" property to TRACE on "Configuration" > "JSON Configuration" > "oxTrust" page 2. Run this command: `# docker exec -ti oxtrust tail -F /opt/gluu/jetty/identity/logs/oxtrust_cache_refresh.log` 3. Wait untill the next CR batch and share the output with us >but authentication still doesn't. Could you share a SAML response that goes back to O365 now? >Regarding this change is not possible to log users with passwords from windows active directory. Is it necessary to add the password manually for each user in Gluu? To use your AD backend for authentication, you will need additionaly configure Gluu to do so on "Manage Authentication". But for now let's refrain from this, to not add additional completexity. You are right - you can look up some user imported from AD on "Users" > "Manage People" page and just assign a password to them. Then you'll be able to use it to test your O365 flow, that should do for now, we'll configure proper AD authenticaton later.

Hi Aliaksandr, Our configuration is now working just following the described steps in a new installation, thank you very much for the updated steps. Regarding the authentication point, I would like to know how to configure to be authenticated in remote LDAP as in the configuration section https://gluu-scw-docker.pre.whispeak.io/identity/authentication/manageCustomAuthentication.htm I'm seeing data for my opendj installation so I'm affraid that it will change authentication for all users, also outside from the SAML integration. Concerning cr-rotate is not always working and after restart of the containers it's not updating anymore the IP of oxtrust, so I need to do it myself seeing result of docker inspect. Lastly we would like to combine our custom interception script with Passport social integrations, is it possible to combine two person authentication scripts? Is there a way of executing this script before authentication as a mandatory step?

Hi, Luis. I've answered your CR-related questions in the other ticket. >Lastly we would like to combine our custom interception script with Passport social integrations, is it possible to combine two person authentication scripts? Is there a way of executing this script before authentication as a mandatory step? I've asked around to be sure nothing has changed - an it turns out merging the scripts you need manually into one script is still the only way to achieve this. We've faced such tasks before, and helped our customers to develop such scripts, so it's doable, as Gluu's custom auth scripts API have enough potential to implement multi-step authentication. Though normally we won't assist with such tasks within the scope of Community Support, due to additional strain it places on our dev team members who often are needed to participate in such projects. >Regarding the authentication point, I would like to know how to configure to be authenticated in remote LDAP as in the configuration section https://gluu-scw-docker.pre.whispeak.io/identity/authentication/manageCustomAuthentication.htm I'm seeing data for my opendj installation so I'm affraid that it will change authentication for all users, also outside from the SAML integration. So you want to be able to authenticate both with Active Directory user accounts AND using locally created user accounts as well, correct? That's doable, at least with a custom script we supply (though I also think you can achieve this with just proper configuration in web UI). Let me do a few quick test and guide you through the process.

Hi Aliaksandr, You're correct I want to be able to log users with AD credentials for the configured cache refresh scenario and also with local data for other cases. I'm seeing now an issue by the way which is how could we do multiple cache refresh implementations with multiple authentications. I have seen that it's possible to have multiple cache refresh servers if they share schema, but for relay the authentication can we use multiple servers too? As we will have one cache refresh server for each of our customers.

Sorry, could you elaborate on this part? >I'm seeing now an issue by the way which is how could we do multiple cache refresh implementations with multiple authentications An example of what you have in mind would be useful. >I have seen that it's possible to have multiple cache refresh servers if they share schema Still not clear to me what do you mean, tbh. You can import users from several different LDAP backends - that's true. But you'll only have on CR server per each Gluu Server deployment; all user entries imported from all source LDAP backends will be joined together and stored under the same branch in Gluu's LDAP tree. >but for relay the authentication can we use multiple servers too? If you import your users from several different LDAP backends, you can add all of them on "Manage authentication" page and use for authenticaiton, correct. >As we will have one cache refresh server for each of our customers Again, it seems we are on different pages here :) May be you could provide a link to a docs page, a blog entry or quote somebody on Gluu team who you talked to about this possibility?

Ok, so our use case is that we won't to have multiple of our customers for our SaaS offering to be logged using SAML integrations. In order to have this we need Cache Refresh and we would like to fallback on the password being tested with their Active Directory if voice login from the interception script is failing. We don't want to store the password of our customers internally. Each customer will be a different company so they will have independent Active Directories. As we are not going to store any personal data in Gluu will be acceptable to have in the same table users from the different customers. As we are a B2B company when I'm talking here about customers those are companies with a specific API endpoint with an independent application configured for them and an API key. When I'm referring to users those are the end users of the system so the customer employes/clients. I hope this makes it more clear for our use case. More information in our webpage about the login use case: https://whispeak.io/en/login-voice-biometrics-authentication/

Hi, we have further investigate this and found out that we should do a fork of the basic authentication script in order to have multiple ADs as target and not needing to have the same schema as internal OpenDJ. Either way this las part was out of the scope of the ticket and we don't have now the inalidnameidpolicy errors after applying Alieksandr suggestions, so we'll close the ticket. Thanks for the guidance, Regards