> On server side both extdom and pwd-extop plugins call > slapi_pblock_set(pb, SLAPI_EXT_OP_RET_OID, oid); > slapi_pblock_set( pb, SLAPI_EXT_OP_RET_VALUE, ret_val);
> and no LDAP entry is returned. Quick search in sources shows otherwise. There is no setting of SLAPI_EXT_OP_RET_VALUE in pwd-extop, however: https://github.com/freeipa/freeipa/blob/3a5ce9cb2af362d97d598f2198cbc20c4c32710b/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c#L1780 new_ctrl.ldctl_oid = KEYTAB_GET_OID; new_ctrl.ldctl_value = *bvp; new_ctrl.ldctl_iscritical = 0; rc = slapi_pblock_set(pb, SLAPI_ADD_RESCONTROL, &new_ctrl); So controls are set directly. There is no other place in the entire codebase where RESCONTROL is set, only for KEYTAB_RET_OID and KEYTAB_GET_OID. Compare this with extdom-extop https://github.com/freeipa/freeipa/blob/3a5ce9cb2af362d97d598f2198cbc20c4c32710b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_extop.c#L256 ret = slapi_pblock_set(pb, SLAPI_EXT_OP_RET_OID, oid); if (ret != 0) { rc = LDAP_OPERATIONS_ERROR; err_msg = "Failed to set the OID for the response.\n"; goto done; } ret = slapi_pblock_set( pb, SLAPI_EXT_OP_RET_VALUE, ret_val); if (ret != 0) { rc = LDAP_OPERATIONS_ERROR; err_msg = "Failed to set the value for the response.\n"; goto done; } Looks like keytab control operations are implemented differently. There is no mention of any controls in RFC related to extended operations either: https://www.rfc-editor.org/rfc/rfc4511#section-4.12 Extended response is just a part of LDAP message envelope https://www.rfc-editor.org/rfc/rfc4511#section-4.1.1 and should be present before controls part. Therefore I don't think the difference between calls to 2.16.840.1.113730.3.8.10.4.1 (EXOP_EXTDOM_V1_OID) and 2.16.840.1.113730.3.8.10.5 (GET_KEYTAB_OID) using ldapexop are related to the way that utility print things. There is fundamental difference in structure. On Tue, Dec 31, 2024 at 10:33 PM Alexander Bokovoy <aboko...@redhat.com> wrote: > > On Аўт, 31 сне 2024, Yuriy Halytskyy wrote: > >> They > >cannot be represented as an LDAP object directly, so LDAP object > >returned by this request is empty. > > > >That's what I find confusing, because when I had a similar problem of > >trying to retrieve SID from Active Directory user using extdom plugin > >https://freeipa.readthedocs.io/en/ipa-4-11/designs/extdom-plugin-protocol.html, > >the result was returned in response and presumably this is also not > >the kind of object ldap understands? It should be just embedded into > >an octet string of extended response, no? > > That's the same behavior. You are mixing things up because 'ldapexop' > utility returns you an extended operation result as a pseudo-LDIF entry. > > On server side both extdom and pwd-extop plugins call > > slapi_pblock_set(pb, SLAPI_EXT_OP_RET_OID, oid); > slapi_pblock_set( pb, SLAPI_EXT_OP_RET_VALUE, ret_val); > > and no LDAP entry is returned. > > > > > // ExtendedResponse ::= [APPLICATION 24] SEQUENCE { > > // COMPONENTS OF LDAPResult, > > // responseName [10] LDAPOID OPTIONAL, > > // responseValue [11] OCTET STRING OPTIONAL } > > > >e.g. > > > > ldapexop -Y GSSAPI -H ldaps://...:636 > >2.16.840.1.113730.3.8.10.4.1::MCYKAQIKAQEwHgQQYWdyZXNlYXJjaC5jby5uegQKaGFseXRza3l5eQ== > ># extended operation response > >oid: 2.16.840.1.113730.3.8.10.4.1 > >data:: > >MDQKAQEEL1MtMS01LTIxLTIwOTQ4MTI2MTQtMTg5MTkxNjgxOS0xNTQ4ODk5MTI3LTYzNDI > > > >data contains ExtdomResponseValue. > > This is just a detail of ldapexop utility implementation and is > described in their man page: > > Additional data for the extended operation can be passed to the > server using data or base-64 encoded as b64data in the case of > oid, or using the additional parameters in the case of the > specially named extended operations > > The utility has special handling of individual known extended operations > so it is able to parse them and display the data or just return them in > the pseudo-LDIF format to ease handling of that data in command line > pipelines. > > > > > >Cheers, > >Yuriy > > > >On Tue, Dec 31, 2024 at 8:21 PM Alexander Bokovoy <aboko...@redhat.com> > >wrote: > >> > >> On Аўт, 31 сне 2024, Yuriy Halytskyy via FreeIPA-users wrote: > >> >Hi, and Happy New Year! > >> > > >> >I am trying to request service and host keytabs programmatically. The > >> >idea is to create terraform data source with Go, but I am also > >> >experimenting with python because it has good ASN1 support. There are > >> >already several terraform providers for IPA but they all use RPC only > >> >and there does not appear to be an RPC call to get a keytab. > >> > > >> >This looks like straightforward extended operation in ldap: > >> > > >> >https://github.com/freeipa/freeipa/blob/3a5ce9cb2af362d97d598f2198cbc20c4c32710b/asn1/asn1c/ipa.asn1#L6 > >> > > >> >The reply I am supposed to receive is: > >> > GKReply ::= SEQUENCE { > >> > newkvno Int32, > >> > keys SEQUENCE OF KrbKey > >> > } > >> > > >> >So I send GKCurrentKeys message, but the reply is interpreted as LDAP > >> >controls both by python and Go ldap libraries? Which doesn't make any > >> >sense to me because controls are supposedly part of ldap request, not > >> >ldap response, but I don't know much about ldap. > >> > >> Correct. You sent an LDAP request with an extended control and you'd > >> receive a response with an extended control containing the keys. They > >> cannot be represented as an LDAP object directly, so LDAP object > >> returned by this request is empty. > >> > >> See https://www.freeipa.org/page/V4/Keytab_Retrieval for details. > >> > >> > > >> >This is what I get in python after sending a request for > >> >host/ipa.example.t...@ipa.example.test > >> > > >> >Request message is: > >> >>>LDAPMessage: > >> >>> messageID=30 > >> >>> protocolOp=ProtocolOp: > >> >>> extendedReq=ExtendedRequest: > >> >>> requestName=2.16.840.1.113730.3.8.10.5 > >> >>> > >> >>> requestValue=0xa11b3019a0170415686f73742f6970612e6578616d706c652e74657374 > >> > > >> > > >> >Result message: > >> ><<{'controls': [(0, > >> ><< True, > >> ><< 16, > >> ><< [(0, False, 4, b'2.16.840.1.113730.3.8.10.5'), > >> ><< (0, > >> ><< False, > >> ><< 4, > >> ><< > >> >b'\xa2\x81\xf30\x81\xf0\x02\x01\x020\x81\xea0-\xa0+0)\xa0\x03' > >> ><< b'\x02\x01\x12\xa1"\x04 > >> >R%\xb2\xec\x13=g\xc9J\xad\x07\xbf\x14' > >> ><< > >> >b'\x83\xac\xccg\xa4w\xfcV\xd8\x90#\x1a%s\xe7\xd8\xb0G\x9c0' > >> ><< > >> >b'\x1d\xa0\x1b0\x19\xa0\x03\x02\x01\x11\xa1\x12\x04\x10\xf7k' > >> ><< b'\x90\x84-\xf0\xa9\x02\xbf\xa5H\xdb\xfe\xa0\x94y0\x1d' > >> ><< b'\xa0\x1b0\x19\xa0\x03\x02\x01\x13\xa1\x12\x04\x10MOX' > >> ><< > >> >b'\x0e\xae\xed\x95_\xba\xe7\xaa\xcd?C7\x050-\xa0+0)\xa0' > >> ><< b'\x03\x02\x01\x14\xa1"\x04 > >> >\xd5]6\xe4\xf6D\x96#i\xa6\x9fX' > >> ><< > >> >b"\x93\xd7\xf3\x03\xc9f\xb5'\x022z\x93WZ\xb2\x8c\xe5rW\x0f" > >> ><< > >> >b'0\x1d\xa0\x1b0\x19\xa0\x03\x02\x01\x19\xa1\x12\x04\x10<' > >> ><< > >> >b'|\x84\xdd"\x9cl\xed\x01\xdb\xc7\xbe\xd2\xbfg\xbe0-\xa0+0' > >> ><< b')\xa0\x03\x02\x01\x1a\xa1"\x04 > >> >\xf6.\xd9/\xae\xf8\xc3j4\x03' > >> ><< > >> >b'\n\x12?\xb4%!\x10+&]\xae\xad\xb5\x07\xf7f\xc6\x93\xb1\xcb' > >> ><< b'L\x96')])], > >> ><< 'messageID': 30, > >> ><< 'payload': [(0, False, 10, 0), (0, False, 4, b''), (0, False, 4, b'')], > >> ><< 'protocolOp': 24} > >> > > >> >The payload is just 4 bytes... > >> > > >> >That bit blob in controls is valid keytab list and I can decode it > >> >using asn1 definitions from > >> >>>> c.result['controls']['2.16.840.1.113730.3.8.10.5'].values().mapping['value'] > >> >b'\xa2\x81\xf30\x81\xf0\x02\x01\x020\x81\xea0-\xa0+0)\xa0\x03\x02\x01\x12\xa1"\x04 > >> >R%\xb2\xec\x13=g\xc9J\xad\x07\xbf\x14\x83\xac\xccg\xa4w\xfcV\xd8\x90#\x1a%s\xe7\xd8\xb0G\x9c0\x1d\xa0\x1b0\x19\xa0\x03\x02\x01\x11\xa1\x12\x04\x10\xf7k\x90\x84-\xf0\xa9\x02\xbf\xa5H\xdb\xfe\xa0\x94y0\x1d\xa0\x1b0\x19\xa0\x03\x02\x01\x13\xa1\x12\x04\x10MOX\x0e\xae\xed\x95_\xba\xe7\xaa\xcd?C7\x050-\xa0+0)\xa0\x03\x02\x01\x14\xa1"\x04 > >> >\xd5]6\xe4\xf6D\x96#i\xa6\x9fX\x93\xd7\xf3\x03\xc9f\xb5\'\x022z\x93WZ\xb2\x8c\xe5rW\x0f0\x1d\xa0\x1b0\x19\xa0\x03\x02\x01\x19\xa1\x12\x04\x10<|\x84\xdd"\x9cl\xed\x01\xdb\xc7\xbe\xd2\xbfg\xbe0-\xa0+0)\xa0\x03\x02\x01\x1a\xa1"\x04 > >> >\xf6.\xd9/\xae\xf8\xc3j4\x03\n\x12?\xb4%!\x10+&]\xae\xad\xb5\x07\xf7f\xc6\x93\xb1\xcbL\x96' > >> > > >> >Go produces similar result. This is what the response looks like: > >> >LDAP Response: (Universal, Constructed, Sequence and Sequence of) > >> >Len=297 "<nil>" > >> > Message ID: (Universal, Primitive, Integer) Len=1 "2" > >> > Extended Response: (Application, Constructed, 0x18) Len=7 "<nil>" > >> > (Universal, Primitive, Enumerated) Len=1 "0" > >> > (Universal, Primitive, Octet String) Len=0 "" > >> > (Universal, Primitive, Octet String) Len=0 "" > >> > (Context, Constructed, 0x00) Len=281 "<nil>" > >> > (Universal, Constructed, Sequence and Sequence of) Len=277 "<nil>" > >> > (Universal, Primitive, Octet String) Len=26 > >> > "2.16.840.1.113730.3.8.10.5" > >> > (Universal, Primitive, Octet String) Len=246 > >> >"\xa2\x81\xf30\x81\xf0\x02\x01\x020\x81\xea0-\xa0+0)\xa0\x03\x02\x01\x12\xa1\"\x04 > >> >R%\xb2\xec\x13=g\xc9J\xad\a\xbf\x14\x83\xac\xccg\xa4w\xfcVؐ#\x1a%s\xe7ذG\x9c0\x1d\xa0\x1b0\x19\xa0\x03\x02\x01\x11\xa1\x12\x04\x10\xf7k\x90\x84-\xf0\xa9\x02\xbf\xa5H\xdb\xfe\xa0\x94y0\x1d\xa0\x1b0\x19\xa0\x03\x02\x01\x13\xa1\x12\x04\x10MOX\x0e\xae\xed\x95_\xba\xe7\xaa\xcd?C7\x050-\xa0+0)\xa0\x03\x02\x01\x14\xa1\"\x04 > >> >\xd5]6\xe4\xf6D\x96#i\xa6\x9fX\x93\xd7\xf3\x03\xc9f\xb5'\x022z\x93WZ\xb2\x8c\xe5rW\x0f0\x1d\xa0\x1b0\x19\xa0\x03\x02\x01\x19\xa1\x12\x04\x10<|\x84\xdd\"\x9cl\xed\x01\xdbǾҿg\xbe0-\xa0+0)\xa0\x03\x02\x01\x1a\xa1\"\x04 > >> >\xf6.\xd9/\xae\xf8\xc3j4\x03\n\x12?\xb4%!\x10+&]\xae\xad\xb5\a\xf7fƓ\xb1\xcbL\x96" > >> > > >> >Again, the extended response is just 4 bytes of nothing, and the > >> >actual result is provided after that and Go is confused (and so am I). > >> > > >> >[root@ipa /]# ipa --version > >> >VERSION: 4.11.0, API_VERSION: 2.253 > >> > > >> >Is there a bug here, or does this work as intended? > >> > > >> >Cheers, > >> >Yuriy > >> >-- > >> >_______________________________________________ > >> >FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org > >> >To unsubscribe send an email to freeipa-users-le...@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/freeipa-users@lists.fedorahosted.org > >> >Do not reply to spam, report it: > >> >https://pagure.io/fedora-infrastructure/new_issue > >> > >> > >> > >> -- > >> / Alexander Bokovoy > >> Sr. Principal Software Engineer > >> Security / Identity Management Engineering > >> Red Hat Limited, Finland > >> > > > > > > -- > / Alexander Bokovoy > Sr. Principal Software Engineer > Security / Identity Management Engineering > Red Hat Limited, Finland > -- _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@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/freeipa-users@lists.fedorahosted.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
