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 <[email protected]> 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/[email protected]
>> >
>> >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 -- [email protected]
>> >To unsubscribe send an email to [email protected]
>> >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/[email protected]
>> >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
