I apologize, but I don't have enough information in the provided knowledge sources to give a detailed explanation on how to integrate Microsoft Active Directory SSO with self-hosted Ory. The knowledge sources primarily focus on Ory Network (the cloud offering) and don't contain specific information about integrating Microsoft Active Directory SSO with self-hosted Ory installations. However, I can provide some general information about social sign-in with Microsoft in Ory Network, which might be somewhat similar: Ory Network supports Microsoft as a social sign-in provider. The process involves configuring the integration through the Ory Console or CLI, setting up an application in the Azure portal, and configuring the necessary OAuth2 scopes and data mapping. For self-hosted Ory, the process might be similar, but would likely require additional configuration steps specific to your self-hosted environment and Microsoft Active Directory setup. Unfortunately, I don't have detailed information about this specific integration in the provided knowledge sources. If you need specific instructions for integrating Microsoft Active Directory SSO with self-hosted Ory, I recommend checking the official Ory documentation for self-hosted installations or reaching out to Ory support for more detailed guidance.

Based on the information provided in the knowledge sources, I can offer some insights on using Ory Kratos for multiple services in your company. Ory Kratos is designed to be a scalable identity management server that can support multiple services. However, the exact configuration depends on your specific requirements and use case. Here are a few key points to consider: 1. Scalability: Ory Kratos is built to scale horizontally. As mentioned in the [Scalability documentation](https://www.ory.sh/docs/self-hosted/operations/scalability), you can spin up multiple instances of Kratos with the same configuration to handle increased load without any additional work. 2. Single Instance for Multiple Services: In many cases, a single instance (or cluster) of Kratos can serve multiple services. This is because Kratos handles identity management, login, registration, and other identity-related flows, which can be shared across different services. 3. Multiple Domains: If your services are on different domains, you might need to consider the cookie domain settings. As explained in the [Multiple custom domains documentation](https://www.ory.sh/docs/kratos/bring-your-own-ui/configure-ory-to-use-your-ui#multiple-custom-domains), users will need to authenticate separately on each domain due to browser security restrictions. 4. Separation of Data: If you need to strictly separate data between different services or user groups, you might consider multiple instances. For example, the documentation mentions a case where a company wanted to separate customer and employee data: > You can deploy Ory Kratos two times, and use the same login UI pointing to two different Kratos login endpoints -

/login/customer

or

/login/employee

[Source](https://www.ory.sh/docs/kratos/debug/troubleshooting) 5. Multi-tenancy: It's worth noting that true multi-tenancy is not available for self-hosted Ory Kratos. As stated in the [Multitenancy documentation](https://www.ory.sh/docs/kratos/guides/multi-tenancy-multitenant), "It is not possible to self-host Ory Kratos as a multi-tenant service as its data model does not support this due to data, scalability, and operational complexity." Given these considerations, for most use cases, you can likely configure a single Kratos instance (or cluster) to support multiple services in your company. However, if you have strict data separation requirements or significantly different configurations needed for different services, you might need to consider multiple instances. For the most accurate advice tailored to your specific use case, I recommend reaching out to Ory support or consulting their detailed documentation, as the optimal setup can depend on various factors not covered in the provided knowledge sources.