Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"CredSSP InvalidParameter: wrong Realm" after enabling NLA #49173

Open
unreality opened this issue Nov 19, 2024 · 3 comments
Open

"CredSSP InvalidParameter: wrong Realm" after enabling NLA #49173

unreality opened this issue Nov 19, 2024 · 3 comments

Comments

@unreality
Copy link

unreality commented Nov 19, 2024

It looks like the NLA feature of recent Teleport versions infers the Kerberos realm from the UPN of the user connecting (i think?), but this may not be the case for example you may have SUB.FQDN.EXAMPLE.COM as the KDC realm, but the UPN of users is [email protected]

It would be useful to have some way of specifying the realm explicitly for instances where this may be the case. I could not find any way to specify this at the moment, but there may be a workaround if the rust RDP kerberos code can be forced to specify a realm?

Expected behavior:

  • Logins work correctly after enabling NLA

Current behavior:

  • Logins fail with the message 'wrong Realm'

Bug details:

  • Teleport version: v17
  • Recreation steps: Attempt to connect to a Windows machine with NLA enabled where the Kerberos realm differs from the domain name in the UPN of the login user.
  • Debug logs:
    [2024-11-19T02:53:19Z INFO ironrdp_async::connector] Begin connection procedure [2024-11-19T02:53:19Z INFO ironrdp_connector::connection] Server confirmed connection selected_protocol=SecurityProtocol(HYBRID_EX) flags=ResponseFlags(EXTENDED_CLIENT_DATA_SUPPORTED | DYNVC_GFX_PROTOCOL_SUPPORTED | RDP_NEG_RSP_RESERVED | RESTRICTED_ADMIN_MODE_SUPPORTED | REDIRECTED_AUTHENTICATION_MODE_SUPPORTED) [2024-11-19T02:53:19Z INFO tracing::span] mark_as_upgraded; [2024-11-19T02:53:19Z INFO tracing::span] connect_finalize; [2024-11-19T02:53:19Z ERROR sspi::kerberos] AS exchange error err=ApplicationTag(KrbErrorInner { pvno: ExplicitContextTag0(Integer(0x05)), msg_type: ExplicitContextTag1(Integer(0x1E)), ctime: Optional(None), cusec: Optional(None), stime: ExplicitContextTag4(GeneralizedTimeAsn1(Date { year: 2024, month: 11, day: 19, hour: 2, minute: 53, second: 19, _pd: PhantomData<picky_asn1::date::GeneralizedTimeRepr> })), susec: ExplicitContextTag5(Integer(0x0DD561)), error_code: ExplicitContextTag6(68), crealm: Optional(None), cname: Optional(None), realm: ExplicitContextTag9(GeneralStringAsn1(IA5("FQDN.EXAMPLE.COM"))), sname: ExplicitContextTag10(PrincipalName { name_type: ExplicitContextTag0(Integer(0x02)), name_string: ExplicitContextTag1(Asn1SequenceOf([GeneralStringAsn1(IA5("krbtgt")), GeneralStringAsn1(IA5("FQDN.EXAMPLE.COM"))])) }), e_text: Optional(None), e_data: Optional(None) }) [2024-11-19T02:53:19Z ERROR rdp_client] client_run failed: ConnectorError(Error { context: "CredSSP", kind: Credssp(Error { error_type: InvalidParameter, description: "wrong Realm", nstatus: None }), source: None }) 2024-11-19T02:53:19Z INFO [WINDOWS_D] Rust RDP loop finished pid:56219.1 client_ip:::1 desktop_name:WINDOWSMACHINE desktop_addr:WINDOWSMACHINE.SUB.FQDN.EXAMPLE.COM:3389 teleport_user:[email protected] desktop_addr:WINDOWSMACHINE.SUB.FQDN.EXAMPLE.COM:3389 ad:true session_id:cacf2493-fc43-49b0-9b5e-2e1b8df5b7b7 screen_size:0x0 computer_name:WINDOWSMACHINE.SUB.FQDN.EXAMPLE.COM kdc_addr:KDCHOST.SUB.FQDN.EXAMPLE.COM nla:true rdp_addr:WINDOWSMACHINE.SUB.FQDN.EXAMPLE.COM:3389 rdpclient/client.go:365 2024-11-19T02:53:19Z INFO emitting audit event event_type:windows.desktop.session.end fields:map[cluster_name:teleport-dev.ict.pathwest.com.au code:TDP01I desktop_addr:WINDOWSMACHINE.SUB.FQDN.EXAMPLE.COM:3389 desktop_labels:map[datacenter:dc1 teleport.dev/ad:true teleport.dev/origin:config-file] desktop_name:WINDOWSMACHINE ei:3 event:windows.desktop.session.end login:USERNAME participants:[[email protected]] private_key_policy:none recorded:true session_start:2024-11-19T02:53:15.068Z session_stop:2024-11-19T02:53:19.979937319Z sid:cacf2493-fc43-49b0-9b5e-2e1b8df5b7b7 time:2024-11-19T02:53:19.98Z trace.component:audit uid:7bb956fd-fc8d-4c00-b53c-5e24ce891e8c user:[email protected] user_kind:1 windows_desktop_service:b8107f7b-c108-4af8-8824-a1dd637f04b6 windows_domain:SUB.FQDN.EXAMPLE.COM windows_user:USERNAME] events/emitter.go:287 2024-11-19T02:53:19Z ERRO [WINDOWS_D] RDP connection failed pid:56219.1 client_ip:::1 desktop_name:WINDOWSMACHINE desktop_addr:WINDOWSMACHINE.SUB.FQDN.EXAMPLE.COM:3389 error:[ ERROR REPORT: Original Error: *errors.errorString RDP client exited with an error: CredSSP InvalidParameter: wrong Realm Stack Trace: github.com/gravitational/teleport/lib/srv/desktop/rdp/rdpclient/client.go:359 github.com/gravitational/teleport/lib/srv/desktop/rdp/rdpclient.(*Client).startRustRDP github.com/gravitational/teleport/lib/srv/desktop/rdp/rdpclient/client.go:208 github.com/gravitational/teleport/lib/srv/desktop/rdp/rdpclient.(*Client).Run.func2 runtime/asm_amd64.s:1700 runtime.goexit User Message: RDP client exited with an error: CredSSP InvalidParameter: wrong Realm] desktop/windows_server.go:825
@zmb3
Copy link
Collaborator

zmb3 commented Nov 19, 2024

A few questions:

  • Are your users in a different domain than the hosts you are connecting to?
  • Does it work with NLA disabled?
  • Can you share your agent config?

@unreality
Copy link
Author

  • Yes, users are in the same domain
  • Yes, it works with NLA disabled
  • Could you clarify what you mean by agent config? teleport.yaml config or the windows desktop service config?

@unreality
Copy link
Author

unreality commented Nov 20, 2024

Looking further into this, it seems the culprit may be
https://github.com/Devolutions/sspi-rs/blob/856428be06a29371308fe14e01eac88c418cbb5c/src/kerberos/client/generators.rs#L81

It looks like usually the remapping of the domains to realms is done in /etc/krb5.conf under the [domain_realm] section, but sspi-rs does not examine this, or provide a way of remapping domains to realms. I'll create an issue in sspi-rs to track this since its upstream.

I tested hardcoding get_client_principal_realm to return the correct realm and after this NLA connections began working.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants