Describe the bug
Some user and group properties are shown as byte arrays instead of strings when a Microsoft .NET app query an authentik LDAP outpost.
Eg:

To Reproduce
Steps to reproduce the behavior:

1. Setup LDAP outpost as described within the documentation: https://version-2023-4.goauthentik.io/docs/providers/ldap/generic_setup
2. As sample, from a Windows machine create a PowerShell test script in order to search object (User / Group) su as the following.

Add-Type -AssemblyName System.DirectoryServices.Protocols

$username = 'cn=YourAccount,ou=users,dc=ldap,dc=goauthentik,dc=io'
$pwd = 'YourPassword'
$ldapPath = "LDAP://YourServerAddress/dc=ldap,dc=goauthentik,dc=io"

$rootDn = [System.DirectoryServices.DirectoryEntry]::new($ldapPath, $username, $pwd, [System.DirectoryServices.AuthenticationTypes]"None")

$searcher = [System.DirectoryServices.DirectorySearcher]::new($rootDn)
$searcher.SearchScope = "Subtree"
$searcher.PropertiesToLoad.Clear()
$searcher.Filter = "(&(ObjectClass=user)"

$res = $searcher.FindOne()
$res.Properties

Expected behavior
User and group attributes must be recognized with the proper attribute type defined within LDAP RFCs in order to be used properly within Windows .NET applications.

Screenshots
If applicable, add screenshots to help explain your problem.

Logs
Output of docker-compose logs or kubectl logs respectively
Kubernetes Logs of the LDAP outpost:
{"bindDN":"cn=YourAccount,ou=users,dc=ldap,dc=goauthentik,dc=io","client":"172.19.15.70","event":"User has access","level":"info","requestId":"01fffbb9-4ecd-40d9-b5ab-8a7d11e517f4","timestamp":"2023-04-19T09:19:47Z"} {"bindDN":"cn=YourAccount,ou=users,dc=ldap,dc=goauthentik,dc=io","client":"172.19.15.70","event":"Allowed access to search","group":"ldap-searchers","level":"info","requestId":"01fffbb9-4ecd-40d9-b5ab-8a7d11e517f4","timestamp":"2023-04-19T09:19:48Z"} {"bindDN":"cn=YourAccount,ou=users,dc=ldap,dc=goauthentik,dc=io","client":"172.19.15.70","event":"Bind request","level":"info","requestId":"01fffbb9-4ecd-40d9-b5ab-8a7d11e517f4","timestamp":"2023-04-19T09:19:48Z","took-ms":3354} {"baseDN":"dc=ldap,dc=goauthentik,dc=io","bindDN":"cn=YourAccount,ou=users,dc=ldap,dc=goauthentik,dc=io","client":"172.19.15.70","event":"Search request","filter":"(objectClass=*)","level":"info","requestId":"043a71be-7c57-43c3-bd66-9e5da048a1b6","scope":"Base Object","timestamp":"2023-04-19T09:19:49Z","took-ms":687} {"baseDN":"dc=ldap,dc=goauthentik,dc=io","bindDN":"cn=YourAccount,ou=users,dc=ldap,dc=goauthentik,dc=io","client":"172.19.15.70","event":"Search request","filter":"(&(ObjectClass=user))","level":"info","requestId":"2c9099b0-edc3-469a-b46f-42b172e7dbdc","scope":"Whole Subtree","timestamp":"2023-04-19T09:19:49Z","took-ms":282}

Version and Deployment (please complete the following information):

• authentik version: 2023.4.0
• Deployment: helm

Additional context
With a traffic analyzer like Wireshark, searchResEntry seams OK.

Maybe the LDAP Server should be able to send it's own Schema in order to work ?
When trying to retrieve an object with it's full DN, the following error occurs:
Unknown error (0x8000500c) which means according to Microsoft : The directory datatype cannot be converted to/from a native DS datatype.
Reference: https://support.microsoft.com/en-us/topic/-0x8000500c-error-when-you-use-adsi-to-read-data-from-an-openldap-server-from-windows-8-or-windows-server-2012-c49f4427-13c8-7172-5e69-697128ecebca