I'm one of the maintainers of sssd in Gentoo. I have separate openldap, kerberos and DNS servers. I would like the use sss_ssh_knownhostsproxy but I cannot find a schema for the the attributes sssd wants.
Here's what is displays when looking it up: (2024-03-27 20:20:10): [be[EXAMPLE.COM]] [sdap_get_generic_ext_step] (0x0400): [RID#8] calling ldap_search_ext with [(&(objectClass=ipHost)(fqdn=ldap.example.com))][dc=example,dc=com]. (2024-03-27 20:20:10): [be[EXAMPLE.COM]] [sdap_get_generic_ext_step] (0x1000): [RID#8] Requesting attrs: [objectClass] (2024-03-27 20:20:10): [be[EXAMPLE.COM]] [sdap_get_generic_ext_step] (0x1000): [RID#8] Requesting attrs: [cn] (2024-03-27 20:20:10): [be[EXAMPLE.COM]] [sdap_get_generic_ext_step] (0x1000): [RID#8] Requesting attrs: [fqdn] (2024-03-27 20:20:10): [be[EXAMPLE.COM]] [sdap_get_generic_ext_step] (0x1000): [RID#8] Requesting attrs: [serverHostname] (2024-03-27 20:20:10): [be[EXAMPLE.COM]] [sdap_get_generic_ext_step] (0x1000): [RID#8] Requesting attrs: [sshPublicKey]
sshPublicKey is part of openssh-lpk, but I cannot find "fqdn" or "serverHostname" anywhere.
In the end, I was able to work around this by adding the following line to /etc/sssd.conf:
ldap_host_fqdn = cn
I have some YubiKeys on order and intend to test and document using passkey support (and as one of the maintainers of sssd in Gentoo, add passkey support to it). However, there is no schema with the "passkey" attribute, nor is there another attribute I can map to (like I can with ssh).
Is there a schema available for the "missing" attributes? If not, could one be created?
Am Sun, Jul 14, 2024 at 11:27:36PM -0000 schrieb Christopher Byrne:
In the end, I was able to work around this by adding the following line to /etc/sssd.conf:
ldap_host_fqdn = cn
I have some YubiKeys on order and intend to test and document using passkey support (and as one of the maintainers of sssd in Gentoo, add passkey support to it). However, there is no schema with the "passkey" attribute, nor is there another attribute I can map to (like I can with ssh).
Is there a schema available for the "missing" attributes? If not, could one be created?
Hi,
please have a look at https://docs.yubico.com/hardware/oid/oid-ldap-arc.html#ldap-attributes, the 'yubicoPublicKeys' attribute seems suitable.
A more generic one, i.e. without a company name, can be found at https://github.com/osstech-jp/fido2-ldap-demo/blob/master/ldap/fido2.schema.
HTH
bye, Sumit
-- _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
By the way, please note that *sss_ssh_knownhostsproxy* is deprecated since 2.10-beta1 and will be replaced by the already-present tool *sss_ssh_knownhosts*, but they sources of information are configured in the same way, so everything you did for *sss_ssh_knownhostsproxy* is also used by *sss_ssh_knownhosts*.
https://sssd.io/release-notes/sssd-2.10.0-beta1.html
On Mon, Jul 15, 2024 at 1:28 AM Christopher Byrne salah.coronya@gmail.com wrote:
In the end, I was able to work around this by adding the following line to /etc/sssd.conf:
ldap_host_fqdn = cn
I have some YubiKeys on order and intend to test and document using passkey support (and as one of the maintainers of sssd in Gentoo, add passkey support to it). However, there is no schema with the "passkey" attribute, nor is there another attribute I can map to (like I can with ssh).
Is there a schema available for the "missing" attributes? If not, could one be created? -- _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Yeah, I know its deprecated, and since I doubt we have any users (yet) of it in Gentoo I dropped support for the old tool, and will only document the new one.
Basically, for passkey support, I need a schema that looks like this:
attributeTypes: ( passkey-oid NAME 'passkey' DESC 'Passkey mapping' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) objectclasses: ( passkeyUser-oid NAME 'passkeyUser' DESC 'Passkey user' AUXILIARY MAY passkey )
The "passKey user" objectClass can be added as an auxiliary class to the appropriate DN, which has the "passkey" member in the format SSSD expects. ("passkey":CredentialID,PEM)
Short of borrowing the IDP schema for passkeys, I don't see a good way of doing this. I don;t think either the FIDO2 or Yubico one will work for what SSSD is expecting.
On Аўт, 16 ліп 2024, Christopher Byrne wrote:
Yeah, I know its deprecated, and since I doubt we have any users (yet) of it in Gentoo I dropped support for the old tool, and will only document the new one.
Basically, for passkey support, I need a schema that looks like this:
attributeTypes: ( passkey-oid NAME 'passkey' DESC 'Passkey mapping' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) objectclasses: ( passkeyUser-oid NAME 'passkeyUser' DESC 'Passkey user' AUXILIARY MAY passkey )
The "passKey user" objectClass can be added as an auxiliary class to the appropriate DN, which has the "passkey" member in the format SSSD expects. ("passkey":CredentialID,PEM)
Short of borrowing the IDP schema for passkeys, I don't see a good way of doing this. I don;t think either the FIDO2 or Yubico one will work for what SSSD is expecting.
I think you can take FreeIPA schema which is essentially the same, just that we have these OIDs already registered in Red Hat's subtree.
attributeTypes: ( 2.16.840.1.113730.3.8.23.27 NAME 'ipapasskey' DESC 'Passkey mapping' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'IPA v4.10' ) objectclasses: ( 2.16.840.1.113730.3.8.24.9 NAME 'ipaPasskeyUser' DESC 'IPA passkey user' AUXILIARY MAY ipapasskey X-ORIGIN 'IPA v4.10')
What specific IdP software are you talking about?
I am planning to add support for retrieving the mapping to Keycloak eventually. The content is compatible with what a typical WebAuthn RP is expecting, just needs some data massaging. For FreeIPA we also plan to use python-fido2 for WebAuthn RP, which is developed by Yubico, I already verified it will be possible to consume the data from the same mappings there.
On 7/16/24 12:30, Alexander Bokovoy wrote:
On Аўт, 16 ліп 2024, Christopher Byrne wrote:
Yeah, I know its deprecated, and since I doubt we have any users (yet) of it in Gentoo I dropped support for the old tool, and will only document the new one.
Basically, for passkey support, I need a schema that looks like this:
attributeTypes: ( passkey-oid NAME 'passkey' DESC 'Passkey mapping' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) objectclasses: ( passkeyUser-oid NAME 'passkeyUser' DESC 'Passkey user' AUXILIARY MAY passkey )
The "passKey user" objectClass can be added as an auxiliary class to the appropriate DN, which has the "passkey" member in the format SSSD expects. ("passkey":CredentialID,PEM)
Short of borrowing the IDP schema for passkeys, I don't see a good way of doing this. I don;t think either the FIDO2 or Yubico one will work for what SSSD is expecting.
I think you can take FreeIPA schema which is essentially the same, just that we have these OIDs already registered in Red Hat's subtree.
attributeTypes: ( 2.16.840.1.113730.3.8.23.27 NAME 'ipapasskey' DESC 'Passkey mapping' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'IPA v4.10' ) objectclasses: ( 2.16.840.1.113730.3.8.24.9 NAME 'ipaPasskeyUser' DESC 'IPA passkey user' AUXILIARY MAY ipapasskey X-ORIGIN 'IPA v4.10')
What specific IdP software are you talking about?
I am planning to add support for retrieving the mapping to Keycloak eventually. The content is compatible with what a typical WebAuthn RP is expecting, just needs some data massaging. For FreeIPA we also plan to use python-fido2 for WebAuthn RP, which is developed by Yubico, I already verified it will be possible to consume the data from the same mappings there.
I meant IPA, not IDP. I'll go ahead and use that piece of the FreeIPA schema instead and point SSSD to the correct attribute.
On 7/16/24 12:38, Christopher Byrne wrote:
On 7/16/24 12:30, Alexander Bokovoy wrote:
On Аўт, 16 ліп 2024, Christopher Byrne wrote:
Yeah, I know its deprecated, and since I doubt we have any users (yet) of it in Gentoo I dropped support for the old tool, and will only document the new one.
Basically, for passkey support, I need a schema that looks like this:
attributeTypes: ( passkey-oid NAME 'passkey' DESC 'Passkey mapping' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) objectclasses: ( passkeyUser-oid NAME 'passkeyUser' DESC 'Passkey user' AUXILIARY MAY passkey )
The "passKey user" objectClass can be added as an auxiliary class to the appropriate DN, which has the "passkey" member in the format SSSD expects. ("passkey":CredentialID,PEM)
Short of borrowing the IDP schema for passkeys, I don't see a good way of doing this. I don;t think either the FIDO2 or Yubico one will work for what SSSD is expecting.
I think you can take FreeIPA schema which is essentially the same, just that we have these OIDs already registered in Red Hat's subtree.
attributeTypes: ( 2.16.840.1.113730.3.8.23.27 NAME 'ipapasskey' DESC 'Passkey mapping' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'IPA v4.10' ) objectclasses: ( 2.16.840.1.113730.3.8.24.9 NAME 'ipaPasskeyUser' DESC 'IPA passkey user' AUXILIARY MAY ipapasskey X-ORIGIN 'IPA v4.10')
What specific IdP software are you talking about?
I am planning to add support for retrieving the mapping to Keycloak eventually. The content is compatible with what a typical WebAuthn RP is expecting, just needs some data massaging. For FreeIPA we also plan to use python-fido2 for WebAuthn RP, which is developed by Yubico, I already verified it will be possible to consume the data from the same mappings there.
I meant IPA, not IDP. I'll go ahead and use that piece of the FreeIPA schema instead and point SSSD to the correct attribute.
Well, pointing SSSD to the correct attribute isn't so easy. Adding
ldap_user_passkey = ipapasskey
Doesn't seem to have any effect, and furthermore, config-check spits out this:
[rule/allowed_domain_options]: Attribute 'ldap_user_passkey' is not allowed in section 'domain/EXAMPLE.COM'. Check for typos.
Is this intentional? If it is, do I just rename/add a new name to the IPA schema piece so it matches what sssd expects?
On 7/18/24 22:08, Christopher Byrne wrote:
On 7/16/24 12:38, Christopher Byrne wrote:
On 7/16/24 12:30, Alexander Bokovoy wrote:
On Аўт, 16 ліп 2024, Christopher Byrne wrote:
Yeah, I know its deprecated, and since I doubt we have any users (yet) of it in Gentoo I dropped support for the old tool, and will only document the new one.
Basically, for passkey support, I need a schema that looks like this:
attributeTypes: ( passkey-oid NAME 'passkey' DESC 'Passkey mapping' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) objectclasses: ( passkeyUser-oid NAME 'passkeyUser' DESC 'Passkey user' AUXILIARY MAY passkey )
The "passKey user" objectClass can be added as an auxiliary class to the appropriate DN, which has the "passkey" member in the format SSSD expects. ("passkey":CredentialID,PEM)
Short of borrowing the IDP schema for passkeys, I don't see a good way of doing this. I don;t think either the FIDO2 or Yubico one will work for what SSSD is expecting.
I think you can take FreeIPA schema which is essentially the same, just that we have these OIDs already registered in Red Hat's subtree.
attributeTypes: ( 2.16.840.1.113730.3.8.23.27 NAME 'ipapasskey' DESC 'Passkey mapping' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'IPA v4.10' ) objectclasses: ( 2.16.840.1.113730.3.8.24.9 NAME 'ipaPasskeyUser' DESC 'IPA passkey user' AUXILIARY MAY ipapasskey X-ORIGIN 'IPA v4.10')
What specific IdP software are you talking about?
I am planning to add support for retrieving the mapping to Keycloak eventually. The content is compatible with what a typical WebAuthn RP is expecting, just needs some data massaging. For FreeIPA we also plan to use python-fido2 for WebAuthn RP, which is developed by Yubico, I already verified it will be possible to consume the data from the same mappings there.
I meant IPA, not IDP. I'll go ahead and use that piece of the FreeIPA schema instead and point SSSD to the correct attribute.
Well, pointing SSSD to the correct attribute isn't so easy. Adding
ldap_user_passkey = ipapasskey
Doesn't seem to have any effect, and furthermore, config-check spits out this:
[rule/allowed_domain_options]: Attribute 'ldap_user_passkey' is not allowed in section 'domain/EXAMPLE.COM'. Check for typos.
Is this intentional? If it is, do I just rename/add a new name to the IPA schema piece so it matches what sssd expects?
Never mind. Despite the error, it works as intended - I was looking at the wrong logs entries on the LDAP server. With a little more configuration, I have successfully gotten SSSD to asks for a passkey and use the entry on the LDAP server!
Am Thu, Jul 18, 2024 at 10:08:53PM -0500 schrieb Christopher Byrne:
On 7/16/24 12:38, Christopher Byrne wrote:
On 7/16/24 12:30, Alexander Bokovoy wrote:
On Аўт, 16 ліп 2024, Christopher Byrne wrote:
Yeah, I know its deprecated, and since I doubt we have any users (yet) of it in Gentoo I dropped support for the old tool, and will only document the new one.
Basically, for passkey support, I need a schema that looks like this:
attributeTypes: ( passkey-oid NAME 'passkey' DESC 'Passkey mapping' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) objectclasses: ( passkeyUser-oid NAME 'passkeyUser' DESC 'Passkey user' AUXILIARY MAY passkey )
The "passKey user" objectClass can be added as an auxiliary class to the appropriate DN, which has the "passkey" member in the format SSSD expects. ("passkey":CredentialID,PEM)
Short of borrowing the IDP schema for passkeys, I don't see a good way of doing this. I don;t think either the FIDO2 or Yubico one will work for what SSSD is expecting.
I think you can take FreeIPA schema which is essentially the same, just that we have these OIDs already registered in Red Hat's subtree.
attributeTypes: ( 2.16.840.1.113730.3.8.23.27 NAME 'ipapasskey' DESC 'Passkey mapping' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'IPA v4.10' ) objectclasses: ( 2.16.840.1.113730.3.8.24.9 NAME 'ipaPasskeyUser' DESC 'IPA passkey user' AUXILIARY MAY ipapasskey X-ORIGIN 'IPA v4.10')
What specific IdP software are you talking about?
I am planning to add support for retrieving the mapping to Keycloak eventually. The content is compatible with what a typical WebAuthn RP is expecting, just needs some data massaging. For FreeIPA we also plan to use python-fido2 for WebAuthn RP, which is developed by Yubico, I already verified it will be possible to consume the data from the same mappings there.
I meant IPA, not IDP. I'll go ahead and use that piece of the FreeIPA schema instead and point SSSD to the correct attribute.
Well, pointing SSSD to the correct attribute isn't so easy. Adding
ldap_user_passkey = ipapasskey
Doesn't seem to have any effect, and furthermore, config-check spits out this:
[rule/allowed_domain_options]: Attribute 'ldap_user_passkey' is not allowed in section 'domain/EXAMPLE.COM'. Check for typos.
Is this intentional? If it is, do I just rename/add a new name to the IPA schema piece so it matches what sssd expects?
Hi,
no this is not intentional, 'ldap_user_passkey' is missing in the 'ldap_user_*' attribute list in src/config/cfg_rules.ini. Would you like to open a pull request at https://github.com/SSSD/sssd/pulls and add it?
bye, Sumit
-- _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
sssd-users@lists.fedorahosted.org