You'll have to follow these directions for [Inbound SAML](https://gluu.org/docs/ce/3.1.3/authn-guide/inbound-saml-passport/) where ADFS is the "External IDP"

Hello, I can’t see anything about ADFS when following the link ... I found how to reshape the metadata there [https://blog.kloud.com.au/2014/10/31/adfs-metadata-conversion-for-shibboleth/](https://blog.kloud.com.au/2014/10/31/adfs-metadata-conversion-for-shibboleth/) I know I have to change saml:AuthnContextClassRef to “urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport” for this Outbound TR but I don’t know where. Gluu documentation redirect to shibboleth documention. Shibboleth documentation says to modify configuration files. Gluu support forum says to not modify files directly. For now, after just importing reshaped metadata, which are validated, I don’t know why I have a monitor EntityID exception in oxtrust.log in continuous loop. And why idp server became unavailable with error 503 ?

If you modify the configuration files, they will be written over. You have to modify the templates. As long as you modify part of the template outside of the dynamic part that gets rendered by the velocity template, you should be ok.

Is there a documentation to modify Gluu templates for ADFS ?

Gilles, Here are two docs which might be helpful to you, there are section of template customization included: - [Office365](https://gluu.org/docs/ce/3.1.3/integration/saas/office/) - [Google](https://gluu.org/docs/ce/3.1.3/integration/saas/google/)

Not specifically for ADFS, but a Gluu engineer will post subsequently on how to modify the templates. That should be in the docs, but it's not.

Hi, Gilles. Let's handle one issue at a time. So far, your IDP becoming unavailable is the most serious one: >And why idp server became unavailable with error 503 ? Have you already modified any its configuration files? Or your only change so far have been creating new TR with metadata you produced? Could you please try next steps first? 1. Log in to container 2. Restart web UI service: `# service identity restart` 3. Restart IDP service: `# service idp restart` 4. Check whether your IDP is accessible now. Try to access url like `https://YOUR.HOST.NAME/idp/shibboleth` (use your Gluu Server's hostname). If you see a page with metadata, don't follow the rest of the steps 5. If you don't see it, stop IDP: `# service idp stop` 6. Remove, or move to other place IDP's log files: `rm -f /opt/shibboleth-idp/logs/*; rm -f /opt/gluu/jetty/idp/logs/*` 7. Start the service and wait for 5 minutes: `# service idp start` 8. Gather all newly-created logs from both those directories, package them and share for us to review. Also, you could consider reinstalling it from scratch, if you think some modifications you did could cause it. It may actually take less time than fixing it.

Please also provide us the metadata you said you composed as well. By any chance, is your ADFS installation can be accessed from the outside world? We could try to reproduce your issue locally and run a test against it in such case.

It is worldwide published, but should be protected by authorized referers at Netscaler Level. Attached, metadata reshaped by : [https://blog.kloud.com.au/2014/10/31/adfs-metadata-conversion-for-shibboleth/](https://blog.kloud.com.au/2014/10/31/adfs-metadata-conversion-for-shibboleth/)

Hello, There is no metadata provide in attachment. Have you apply the steps provide by @Alex in his previous post? Note that currently we don't have a ADFS setup, so we need all information(Log/error files) form you.

Attachements via mail doesn't work...

yes, Only customers can upload files. Use google drive or something similar.

I did. There is an attchement in the same post...

As soon as I had the TR (with no configuration), I have a loop with the following exception. When I delete the TR, the exception stop logging. 2018-07-11 23:59:40,680 ERROR [ForkJoinPool.commonPool-worker-7] [org.gluu.oxtrust.ldap.service.EntityIDMonitoringService] (EntityIDMonitoringService.java:92) - Exception happened while monitoring EntityId java.lang.NullPointerException: null at org.apache.commons.collections.CollectionUtils.getCardinalityMap(CollectionUtils.java:230) ~[commons-collections-3.2.2.jar:3.2.2] at org.apache.commons.collections.CollectionUtils.disjunction(CollectionUtils.java:156) ~[commons-collections-3.2.2.jar:3.2.2] at org.gluu.oxtrust.ldap.service.EntityIDMonitoringService.process(EntityIDMonitoringService.java:128) ~[classes/:?] at org.gluu.oxtrust.ldap.service.EntityIDMonitoringService$Proxy$_$$_WeldSubclass.process(Unknown Source) ~[classes/:?] at org.gluu.oxtrust.ldap.service.EntityIDMonitoringService.processMetadataValidationTimerEvent(EntityIDMonitoringService.java:90) [classes/:?] at org.gluu.oxtrust.ldap.service.EntityIDMonitoringService$Proxy$_$$_WeldSubclass.processMetadataValidationTimerEvent$$super(Unknown Source) [classes/:?] at sun.reflect.GeneratedMethodAccessor790.invoke(Unknown Source) ~[?:?] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_162] at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_162] at org.jboss.weld.interceptor.proxy.TerminalAroundInvokeInvocationContext.proceedInternal(TerminalAroundInvokeInvocationContext.java:51) [weld-core-impl-3.0.1.Final.jar:3.0.1.Final] at org.jboss.weld.interceptor.proxy.AroundInvokeInvocationContext.proceed(AroundInvokeInvocationContext.java:78) [weld-core-impl-3.0.1.Final.jar:3.0.1.Final] at org.xdi.service.cdi.async.AsynchronousInterceptor$1.get(AsynchronousInterceptor.java:36) [oxcore-service-3.1.3.Final.jar:?] at java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1590) [?:1.8.0_162] at java.util.concurrent.CompletableFuture$AsyncSupply.exec(CompletableFuture.java:1582) [?:1.8.0_162] at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289) [?:1.8.0_162] at java.util.concurrent.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1056) [?:1.8.0_162] at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1692) [?:1.8.0_162] at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:157) [?:1.8.0_162]

With no TR, after restarting services Gluu metadata url works on each node. When I add the TR(see attachement) I have these error on One node : 2018-07-12 15:02:12,447 ERROR [qtp1744347043-14] [apache.velocity.runtime.parser.node.ASTComparisonNode] (ASTComparisonNode.java:100) - Left side ($trustParams.trustEntityIds.get($trustRelationship.inum).size()) of comparison operation has null value at attribute-filter.xml.vm[line 8, column 93] 2018-07-12 15:03:47,405 ERROR [ForkJoinPool.commonPool-worker-4] [org.gluu.oxtrust.ldap.service.Shibboleth3ConfService] (Shibboleth3ConfService.java:1002) - Failed to parse metadata file '/opt/shibboleth-idp/metadata/E776B600E0F4F497000259618C3C0006BB69643D-sp-metadata.xml' org.xml.sax.SAXParseException: Content is not allowed in prolog. at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.java:257) ~[?:1.8.0_162] at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:339) ~[?:1.8.0_162] at org.xdi.service.XmlService.getXmlDocument(XmlService.java:192) ~[oxcore-service-3.1.3.Final.jar:?] at org.gluu.oxtrust.ldap.service.Shibboleth3ConfService.isFederationMetadata(Shibboleth3ConfService.java:1000) [classes/:?] at org.gluu.oxtrust.ldap.service.Shibboleth3ConfService.isFederation(Shibboleth3ConfService.java:1519) [classes/:?] at org.gluu.oxtrust.ldap.service.MetadataValidationTimer.validateMetadata(MetadataValidationTimer.java:205) [classes/:?] at org.gluu.oxtrust.ldap.service.MetadataValidationTimer.procesMetadataValidation(MetadataValidationTimer.java:113) [classes/:?] at org.gluu.oxtrust.ldap.service.MetadataValidationTimer.processMetadataValidationTimerEvent(MetadataValidationTimer.java:103) [classes/:?] at org.gluu.oxtrust.ldap.service.MetadataValidationTimer$Proxy$_$$_WeldSubclass.processMetadataValidationTimerEvent$$super(Unknown Source) [classes/:?] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_162] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_162] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_162] at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_162] at org.jboss.weld.interceptor.proxy.TerminalAroundInvokeInvocationContext.proceedInternal(TerminalAroundInvokeInvocationContext.java:51) [weld-core-impl-3.0.1.Final.jar:3.0.1.Final] at org.jboss.weld.interceptor.proxy.AroundInvokeInvocationContext.proceed(AroundInvokeInvocationContext.java:78) [weld-core-impl-3.0.1.Final.jar:3.0.1.Final] at org.xdi.service.cdi.async.AsynchronousInterceptor$1.get(AsynchronousInterceptor.java:36) [oxcore-service-3.1.3.Final.jar:?] at java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1590) [?:1.8.0_162] at java.util.concurrent.CompletableFuture$AsyncSupply.exec(CompletableFuture.java:1582) [?:1.8.0_162] at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289) [?:1.8.0_162] at java.util.concurrent.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1056) [?:1.8.0_162] at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1692) [?:1.8.0_162] at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:157) [?:1.8.0_162] Then back to loop with the "Exception happened while monitoring EntityId" on each node.

While TR is [active](https://ANFH.storage.orange-business.com/invitations?share=8686f34d41248c8bb4bf&dl=0) And for now Gluu metadata still working

Hi Gilles, So right now, the metadata validation works well. Are you encounter another issue if so please let's help. I also noted that the TR registered don't have any attributes released. You have to release some attribute like username and email.

Except errors I sent. Then I don't know what I'm supposed to do to have ADFS TR working.

That log is coming from which file? > With no TR, after restarting services Gluu metadata url works on each node. When I add the TR(see attachement) I have these error on One node : 2018-07-12 15:02:12,447 ERROR [qtp1744347043-14] That description is confusing. Let's focus on the process itself. The first process should looks like this: 1. Get ADFS metadata 2. Create a TR in Gluu server with that metadata 3. Then restart idp service 4. Check that the metadata validation is working well. From previous post, the step and two done.

Hi, Gilles. Log excerpts you provided above show possible issues with generating IDP's configuration from templates. Have you edited any configuration files manually, so far? If so, did you back up the original files? Please try to revert all your manual changes, and restart `identity`, then `idp`.

No file modification for now.

It also seems it's complaining about some null values when processing `attribute-filter.xml.vm`. I noted that on the screenshot attached [here](https://support.gluu.org/installation/5715/adfs-40-saml-outband/#at35983) you seem to not specify any attributes to release, neither you configure specific profile settings for your SP. Let's try to do next: 1. Either create a new TR, or edit the one you have created (also please note that only one TR for the specific `entityid` must exist and be active at the same time) 2. Add a couple attributes to release to the list. `transientid` and `email` or `username` is a solid choice. 3. Set "Configure Relying Party" checkbox and configure it as depicted on the attached screenshot 4. Save your changes and restart `idp` service. Let's see whether the errors will go away.

Corrected the item 4 above, please note you need to save your changes in web UI before restarting IDP

I tried to release attibutes. On 'update', I had a pop saying it failed. I restart identity/idp on both nodes. After restart, gluu metadata are available on node1 but error 503 on node 2. So I join the fresh [logs](https://ANFH.storage.orange-business.com/invitations?share=20f77582f72a3c7c9b9a&dl=0).

After services restart, While idp is still 503 on node2, I was able to do the [4 steps](https://ANFH.storage.orange-business.com/invitations?share=7f011dffc887ef2781e8&dl=0). EntityID monitor Exception is still there. Notified in /opt/gluu/jetty/identity/logs/oxtrust.log

From your last post we can see these sentences: 1. I restart identity/idp on both nodes. After restart, gluu metadata are available on **node1** but error 503 on **node 2**. 1. With no TR, after restarting services Gluu metadata url works on **each node** With these sentences we can inferred that you are using a **Gluu cluster**. Right? Please share with doc you have follow to setup your cluster environment. Our suggestion is this: **Let's setup ADFS/Gluu using a single Gluu server. So just install a fresh gluu 3.1.3 on a VM and let's use it to proceed.**

I think cluster deployment should not be mixed in here. I'm closing this ticket. The customer should proceed with a fresh single server instance. Once it's functionally correct, move for clusters.

Anyone know what Monitor EntityID Exception is about ??

Please read the last post and check the ticket status.