From 39ce5c0a8b50a665025bc943457d68d7d37ebc10 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Arvid=20Kronosj=C3=B6?= Date: Tue, 12 Dec 2023 15:25:43 +0100 Subject: [PATCH] Fix spelling from kerbereos to kerberos --- docs/docfx/articles/authn-authz.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/docfx/articles/authn-authz.md b/docs/docfx/articles/authn-authz.md index bec6c4fc3..5de5087b2 100644 --- a/docs/docfx/articles/authn-authz.md +++ b/docs/docfx/articles/authn-authz.md @@ -86,7 +86,7 @@ These authentication types already pass their values in the request headers and These protocols are commonly used with remote identity providers. The authentication process can be configured in the proxy application and will result in an authentication cookie. That cookie will flow to the destination server as a normal request header. -### Windows, Negotiate, NTLM, Kerbereos +### Windows, Negotiate, NTLM, Kerberos These authentication types are often bound to a specific connection. They are not supported as means of authenticating a user in a destination server behind the YARP proxy (see [#166](https://github.com/microsoft/reverse-proxy/issues/166). They can be used to authenticate an incoming request to the proxy, but that identity information will have to be communicated to the destination server in another form. They can also be used to authenticate the proxy to the destination servers, but only as the proxy's own user, impersonating the client is not supported.