[midPoint] Unexpected behavior of attribute mapping in Midpoint with tolerant false option during user recalculations
Oleksandr Nekriach
o.nekriach at dynatech.lv
Thu Jul 26 14:14:22 CEST 2018
Alexandre, in such case we have the same problem.
As I have to manage sshPublicKey as a single values attribute I have a
temporary workaround
I use a configuration that doesn't remove sshPublicKey on LDAP resource
automatically when it is removed from the user profile (mapping has
tolerant=true option).
But users, if they want, can delete sshPublicKey by removing it from user
profile and projection manually by themselves. In this case, it removes
sshPublicKey on LDAP resource successfully.
In other situations, everything works as expected. I am able to add or
replace sshPublicKey with a new one on the resource via user profile
interface in IDM.
<attribute id="135">
<c:ref>ri:sshPublicKey</c:ref>
<displayName>sshPublicKey</displayName>
<outbound>
<strength>normal</strength>
<source>
<c:path>$user/extension/sshPublicKey</c:path>
</source>
</outbound>
</attribute>
(tolerant=true by default)
Best regards, Oleksandr
On 26 July 2018 at 14:26, Alexandre Zia <alexandre.zia at ifood.com.br> wrote:
> Hi Oleksandr
>
> I think it is the same problem.
> I was using index=false, have just enabled index=true in hope to make it
> work, didn't realize the error on database was due to enabling indexing.
> Now I've just disabled it again.
>
> I have the same behavior as you mentioned if I set the outbount mapping
> strength to "normal" then one time it adds the attribute, other time it
> removes the attribute exactly as tou reported.
> If I set the outbound mapping strength to "strong" it doesn't delete the
> attribute anymore when doing a reconciliation, but when the user is editing
> its own sshPublicKeys midpoint is not syncronizing user object with shadow
> properly, one of its sshPublicKeys are missing, if user has only one
> sshPublicKey shadow has none
>
> Regards
> Alexandre
>
>
>
> On Thu, Jul 26, 2018 at 4:06 AM, Oleksandr Nekriach <
> o.nekriach at dynatech.lv> wrote:
>
>> Hi Alexandre,
>> I have a little bit different situation. I have not a problem with
>> provisioning sshPublicKey from a user profile to LDAP resource but I have a
>> problem with recalculation of users that have such attribute on the user
>> profile and the tolerant=false option in mapping in LDAP resource (more
>> details see above).
>> Your case is different in Midpoint schema you use type="xsd:string" for
>> sshPublicKey and you have a problem with field length in DB as you wrote.
>> But I use type="xsd:base64Binary" in midpoint schema and have another
>> problem only with recalculation users. When mapping has the
>> tolerant=false option in LDAP resource. The first user recalculation
>> event adds attribute value from user profile into LDAP resource the second
>> one removes this attribute on the resource from the user account. And
>> this happens periodically.
>>
>> Best regards, Oleksandr
>>
>>
>> On 26 July 2018 at 05:46, Alexandre Zia <alexandre.zia at ifood.com.br>
>> wrote:
>>
>>> Think I may have found something
>>>
>>> Got this error in logs:
>>> Caused by: java.sql.BatchUpdateException: Batch entry 0 insert into
>>> m_object_ext_string (dynamicDef, eType, valueType, eName, owner_oid,
>>> ownerType, stringValue) values ('0', 'http://www.w3.org/2001/XMLSch
>>> ema#string', 0, 'http://midpoint.evolveum.com/
>>> xml/ns/story/orgsync/ext#sshPublicKey', 'e50bac40-2b0f-4566-ba8d-76c65876ed1d',
>>> 0, 'ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA+fAh6coYQqrA5ohhqkizbPkFquRKalRv
>>> 0MzTpK620b2oVV0y5jPNgW1hh2tsIoDbXK/ZXc05EtCqV88S7PlJrmRvSPAV
>>> 5wtZ2ZSQ6H42YvgG4MmGgGF98fm8odDtKfjS1uz/aoNXHbvK9378tCy0crzo
>>> TyenSwYgavDLCjM+IG3/cFFIyDEr0OenQIq6EUXTPxoVIgPlXyb+krah/gpu
>>> rZHcyc2YKzOtDgpsOZ0/yDX68ICJMxm9UDhFxH6KL4tz/A2vNOyfbsXbnIV3
>>> bWM9A8ZsuEUR5LSCCQopFP02C6Ad3YcRVSRR33EOOwfdwQaGdRCzlzm3oGxzr07CmjqElw==')
>>> was aborted: ERROR: value too long for type character varying(255) Call
>>> getNextException to see other errors in the batch.
>>>
>>> using postgresql as database.
>>>
>>> table: m_object_ext_string - that stores extended string attribute has
>>> only 255 chars and sshPublicKeys are bigger my key have 380 chars
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Wed, Jul 25, 2018 at 3:45 PM, Alexandre Zia <
>>> alexandre.zia at ifood.com.br> wrote:
>>>
>>>> I'm facing the exact same issue, and was about to ask for help as well.
>>>> However my setup is a bit different, sshPublicKey is multivalued in
>>>> ldap, so I'm using it as multivalued in Midpoint as well
>>>>
>>>> Differences of my setup:
>>>> - Attribute sshPublicKey in my Ldap is multivalued
>>>> - Attribute sshPublicKey in my Midpoint is multivalued
>>>> - Created authorization for users to log into GUI and edit their own
>>>> sshPublicKeys
>>>>
>>>> Issues:
>>>>
>>>> - when users edit their own profile and add/delete sshPublicKeys
>>>> sometimes they are not propagated to Ldap, sometimes they are but
>>>> incomplete,
>>>>
>>>> - enabling Clockwork Debug in Midpoint, it shows that sshPublicKey is
>>>> being included in Shadow ObjectDelta but shows no action (ADD, DELETE):
>>>>
>>>> ObjectDelta(ShadowType:b679ca00-4b00-47ba-819b-c18253624bc3,MODIFY:
>>>> PropertyDelta(attributes / {.../resource/instance-3}sshPublicKey), ...
>>>> REMOVED TEXT ....): SUCCESS
>>>>
>>>> - sometimes Clockwork Debug shows actions, ADD or DELETE, but it never
>>>> reflects the user object in Midpoint, e.g. User objet has 4 sshPublicKeys,
>>>> Shadow has 3, or even User object has 1 sshPublicKey and shadow has 0
>>>>
>>>>
>>>>
>>>>
>>>> My setup:
>>>>
>>>> -----------------------------
>>>> - OpenLdap schema: (in openldap service)
>>>>
>>>> attributetype ( 1.3.6.1.4.1.24552.500.1.1.1.13 NAME 'sshPublicKey'
>>>> DESC 'MANDATORY: OpenSSH Public key'
>>>> EQUALITY octetStringMatch
>>>> SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
>>>>
>>>>
>>>> -----------------------------
>>>> - IDM extended attibute: I've created sshPublicKey as "string" in
>>>> userType
>>>> (so it would be easy for users to type it in their profiles):
>>>>
>>>> <!-- sshPublicKey -->
>>>> <xsd:element name="sshPublicKey" type="xsd:string" minOccurs="0"
>>>> maxOccurs="unbounded" >
>>>> <xsd:annotation>
>>>> <xsd:appinfo>
>>>> <a:indexed>false</a:indexed>
>>>> <a:displayName>SSH Public Key</a:displayName>
>>>> </xsd:appinfo>
>>>> </xsd:annotation>
>>>> </xsd:element>
>>>>
>>>> -----------------------------
>>>> - attribute in ldap connector schema:
>>>>
>>>> <xsd:element maxOccurs="unbounded" minOccurs="0" name="sshPublicKey"
>>>> type="xsd:base64Binary">
>>>> <xsd:annotation>
>>>> <xsd:appinfo>
>>>> <a:displayOrder>150</a:displayOrder>
>>>> <ra:nativeAttributeName>sshPublicKey</ra:nativeAttributeName>
>>>> <ra:frameworkAttributeName>sshPublicKey</ra:frameworkAttribu
>>>> teName>
>>>> </xsd:appinfo>
>>>> </xsd:annotation>
>>>> </xsd:element>
>>>>
>>>> -----------------------------
>>>> - attribute mapping in ldap connector:
>>>>
>>>> <attribute>
>>>> <c:ref>ri:sshPublicKey</c:ref>
>>>> <displayName>SSH Public Key</displayName>
>>>> <tolerant>false</tolerant>
>>>> <exclusiveStrong>false</exclusiveStrong>
>>>> <outbound>
>>>> <authoritative>false</authoritative>
>>>> <exclusive>false</exclusive>
>>>> <strength>strong</strength>
>>>> <source>
>>>> <c:path>$user/extension/sshPublicKey</c:path>
>>>> </source>
>>>> <expression>
>>>> <script xsi:type="c:ScriptExpressionEvaluatorType">
>>>> <trace>false</trace>
>>>> <relativityMode>absolute</relativityMode>
>>>> <includeNullInputs>true</includeNullInputs>
>>>> <code>
>>>> def ret = []
>>>> for (publicKey in sshPublicKey)
>>>> {
>>>> ret.add(publicKey.getBytes() )
>>>> }
>>>> return ret
>>>> </code>
>>>> </script>
>>>> </expression>
>>>> </outbound>
>>>> <inbound>
>>>> <authoritative>false</authoritative>
>>>> <exclusive>false</exclusive>
>>>> <strength>weak</strength>
>>>> <source>
>>>> <c:path>$account/attributes/sshPublicKey</c:path>
>>>> </source>
>>>> <expression>
>>>> <script xsi:type="c:ScriptExpressionEvaluatorType">
>>>> <trace>false</trace>
>>>> <relativityMode>absolute</relativityMode>
>>>> <includeNullInputs>true</includeNullInputs>
>>>> <code>
>>>> def ret = []
>>>> for (publicKey in sshPublicKey)
>>>> {
>>>> ret.add(new String(publicKey, "UTF-8"))
>>>> }
>>>> return ret
>>>> </code>
>>>> </script>
>>>> </expression>
>>>> <target>
>>>> <c:path>$user/extension/sshPublicKey</c:path>
>>>> </target>
>>>> </inbound>
>>>> </attribute>
>>>>
>>>>
>>>> -----------------------------
>>>> - Added authorization in "End User" role, for users to manage their own
>>>> sshPublicKey attribute
>>>>
>>>> <authorization>
>>>> <name>edit-own-ssh-public-key</name>
>>>> <description>
>>>> Authorize users add and delete ssh public keys from the GUI.
>>>> </description>
>>>> <action>http://midpoint.evolveum.com/xml/ns/public/security/
>>>> authorization-model-3#modify</action>
>>>> <action>http://midpoint.evolveum.com/xml/ns/public/security/
>>>> authorization-model-3#add</action>
>>>> <action>http://midpoint.evolveum.com/xml/ns/public/security/
>>>> authorization-model-3#read</action>
>>>> <action>http://midpoint.evolveum.com/xml/ns/public/security/
>>>> authorization-model-3#delete</action>
>>>> <object>
>>>> <special>self</special>
>>>> </object>
>>>> <object>
>>>> <type>ShadowType</type>
>>>> <owner>
>>>> <special>self</special>
>>>> </owner>
>>>> </object>
>>>> <c:item>extension/sshPublicKey</c:item>
>>>> <c:item>attributes/sshPublicKey</c:item>
>>>> </authorization>
>>>>
>>>> -----------------------------
>>>>
>>>>
>>>>
>>>>
>>>> Regards
>>>> Alexandre Zia
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Wed, Jul 25, 2018 at 8:25 AM, Oleksandr Nekriach <
>>>> o.nekriach at dynatech.lv> wrote:
>>>>
>>>>> Hi Gustav,
>>>>> Thank you for the quick reply but you advise doesn't help me.
>>>>> Behaviour is the same.
>>>>>
>>>>> My config after
>>>>> <attribute id="141">
>>>>> <c:ref>ri:sshPublicKey</c:ref>
>>>>> <displayName>sshPublicKey</displayName>
>>>>> <limitations>
>>>>> <minOccurs>0</minOccurs>
>>>>> <maxOccurs>1</maxOccurs>
>>>>> <access>
>>>>> <read>true</read>
>>>>> <add>true</add>
>>>>> <modify>true</modify>
>>>>> </access>
>>>>> </limitations>
>>>>> <tolerant>false</tolerant>
>>>>> <fetchStrategy>explicit</fetchStrategy>
>>>>> <outbound>
>>>>> <strength>strong</strength>
>>>>> <source>
>>>>> <c:path>$user/extension/sshPublicKey</c:path>
>>>>> </source>
>>>>> </outbound>
>>>>> </attribute>
>>>>>
>>>>>
>>>>> On 25 July 2018 at 12:43, Pálos Gustáv <gustav.palos at evolveum.com>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> try to put limitation to use it as single value:
>>>>>> <attribute id="141">
>>>>>> <c:ref>ri:sshPublicKey</c:ref>
>>>>>> <limitations>
>>>>>> <minOccurs>0</minOccurs>
>>>>>> <maxOccurs>1</maxOccurs>
>>>>>> <access>
>>>>>> <read>true</read>
>>>>>> <add>true</add>
>>>>>> <modify>true</modify>
>>>>>> </access>
>>>>>> </limitations>
>>>>>> ....
>>>>>>
>>>>>> best regards,
>>>>>>
>>>>>> Gustav
>>>>>>
>>>>>> st 25. 7. 2018 o 10:48 Oleksandr Nekriach <o.nekriach at dynatech.lv>
>>>>>> napísal(a):
>>>>>>
>>>>>>> Hi to all,
>>>>>>> I have faced with a problem of unexpected behavior of Midpoint
>>>>>>> IDM(3.7) during user recalculations.
>>>>>>> I have extended IDM and LDAP with sshPublicKey attribute
>>>>>>> (xsd:base64Binary in IDM and Octet String in LDAP) and created of mapping
>>>>>>> attribute in LDAP resource as is.
>>>>>>> I have to remove the attribute value on LDAP when it removes in IDM.
>>>>>>> For this task, I have added tolerant=false option in the attribute mapping
>>>>>>> in LDAP resource.
>>>>>>> It works in a wrong way. When I have a non-empty sshPublicKey in IDM
>>>>>>> it is provisioned in LDAP correctly. It is Ok. But when run user
>>>>>>> recalculation it removes sshPublicKey attribute value in LDAP. When I run
>>>>>>> recalculation the second time it re-provisions sshPublicKey attribute value
>>>>>>> in LDAP again.
>>>>>>> And it can be Infinite. Every time when recalculation runs it
>>>>>>> removes and restores attribute value periodically.
>>>>>>> Please help me to understand what I did in the wrong way in
>>>>>>> configuration or confirm that is a bug in Midpoint.
>>>>>>>
>>>>>>> See below configuration details
>>>>>>>
>>>>>>> Attribute in LDAP schema
>>>>>>>
>>>>>>> olcAttributeTypes: {17}( 1.3.6.1.4.1.45689.1.1.1.2.18 NAME
>>>>>>> 'sshPublicKey' DESC 'SSH Public key' EQUALITY octetStringMatch SYNTAX
>>>>>>> 1.3.6.1.4.1.1466.115.121.1.40 SINGLE-VALUE )
>>>>>>>
>>>>>>> Attribute in LDAP connector schema
>>>>>>>
>>>>>>> <xsd:element minOccurs="0" name="sshPublicKey"
>>>>>>> type="xsd:base64Binary">
>>>>>>> <xsd:annotation>
>>>>>>> <xsd:appinfo>
>>>>>>> <a:displayOrder>290</a:displayOrder>
>>>>>>> <ra:nativeAttributeName>sshPub
>>>>>>> licKey</ra:nativeAttributeName>
>>>>>>> <ra:frameworkAttributeName>ssh
>>>>>>> PublicKey</ra:frameworkAttributeName>
>>>>>>> </xsd:appinfo>
>>>>>>> </xsd:annotation>
>>>>>>> </xsd:element>
>>>>>>>
>>>>>>> Attribute in IDM schema
>>>>>>>
>>>>>>> <xsd:element name="sshPublicKey"
>>>>>>> type="xsd:base64Binary" minOccurs="0" maxOccurs="1">
>>>>>>> <xsd:annotation>
>>>>>>> <xsd:appinfo>
>>>>>>> <a:displayName>sshPublicKey</a:displayName>
>>>>>>> <a:indexed>false</a:indexed>
>>>>>>> </xsd:appinfo>
>>>>>>> </xsd:annotation>
>>>>>>> </xsd:element>
>>>>>>>
>>>>>>> Attribute mapping in LDAP connector
>>>>>>>
>>>>>>> <attribute id="141">
>>>>>>> <c:ref>ri:sshPublicKey</c:ref>
>>>>>>> <displayName>sshPublicKey</displayName>
>>>>>>> <tolerant>false</tolerant>
>>>>>>> <fetchStrategy>explicit</fetchStrategy>
>>>>>>> <outbound>
>>>>>>> <strength>strong</strength>
>>>>>>> <source>
>>>>>>> <c:path>$user/extension/sshPublicKey</c:path>
>>>>>>> </source>
>>>>>>> </outbound>
>>>>>>> </attribute>
>>>>>>>
>>>>>>> --
>>>>>>> Best regards,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Oleksandr Nekriach | Identity and access management engineer
>>>>>>>
>>>>>>> Dynatech, Mednieku str. 4a, Riga, LV-1010, Latvia
>>>>>>> <https://maps.google.com/?q=Mednieku+str.+4a,+Riga,+LV-1010,+Latvia&entry=gmail&source=g>
>>>>>>>
>>>>>>> +37125314685 <+371%2025%20314%20685>
>>>>>>> ,
>>>>>>> o.nekriach at dynatech.lv
>>>>>>> |
>>>>>>> www.dynatech.lv
>>>>>>>
>>>>>>>
>>>>>>> Stay connected:
>>>>>>> <https://www.facebook.com/DynatechLatvia/?ref=br_rs>
>>>>>>> <https://www.linkedin.com/company-beta/17893047/>
>>>>>>>
>>>>>>>
>>>>>>> Confidentiality Notice: This message contains confidential
>>>>>>> information and is intended only for the named recipient(s). If you are not
>>>>>>> the addressee you may not copy, distribute or perform any other activities
>>>>>>> with this information. If you have received this transmission in error,
>>>>>>> please notify us by e-mail immediately. E-mail transmission cannot be
>>>>>>> guaranteed to be secure or error-free as information could be intercepted,
>>>>>>> corrupted, lost, destroyed, arrive late or incomplete, or contain viruses.
>>>>>>> _______________________________________________
>>>>>>> midPoint mailing list
>>>>>>> midPoint at lists.evolveum.com
>>>>>>> http://lists.evolveum.com/mailman/listinfo/midpoint
>>>>>>>
>>>>>>> --
>>>>>>> <http://lists.evolveum.com/mailman/listinfo/midpoint>
>>>>>>> <http://lists.evolveum.com/mailman/listinfo/midpoint>
>>>>>>> <http://lists.evolveum.com/mailman/listinfo/midpoint>
>>>>>>> Gustáv Pálos
>>>>>>> Identity Engineer
>>>>>>> <http://lists.evolveum.com/mailman/listinfo/midpoint>evolveum.com
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> midPoint mailing list
>>>>>> midPoint at lists.evolveum.com
>>>>>> http://lists.evolveum.com/mailman/listinfo/midpoint
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Best regards,
>>>>>
>>>>>
>>>>>
>>>>> Oleksandr Nekriach | Identity and access management engineer
>>>>>
>>>>> Dynatech, Mednieku str. 4a, Riga, LV-1010, Latvia
>>>>> <https://maps.google.com/?q=Mednieku+str.+4a,+Riga,+LV-1010,+Latvia&entry=gmail&source=g>
>>>>>
>>>>> +37125314685 <+371%2025%20314%20685>
>>>>> ,
>>>>> o.nekriach at dynatech.lv
>>>>> |
>>>>> www.dynatech.lv
>>>>>
>>>>>
>>>>> Stay connected:
>>>>> <https://www.facebook.com/DynatechLatvia/?ref=br_rs>
>>>>> <https://www.linkedin.com/company-beta/17893047/>
>>>>>
>>>>>
>>>>> Confidentiality Notice: This message contains confidential information
>>>>> and is intended only for the named recipient(s). If you are not the
>>>>> addressee you may not copy, distribute or perform any other activities with
>>>>> this information. If you have received this transmission in error, please
>>>>> notify us by e-mail immediately. E-mail transmission cannot be guaranteed
>>>>> to be secure or error-free as information could be intercepted, corrupted,
>>>>> lost, destroyed, arrive late or incomplete, or contain viruses.
>>>>>
>>>>> _______________________________________________
>>>>> midPoint mailing list
>>>>> midPoint at lists.evolveum.com
>>>>> http://lists.evolveum.com/mailman/listinfo/midpoint
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Alexandre Roberto Zia
>>>>
>>>> *Security*
>>>>
>>>> *TEL:* +55 (11) 3634-3360
>>>>
>>>> www.ifood.com.br
>>>>
>>>>
>>>>
>>>>
>>>> <https://itunes.apple.com/br/app/ifood-delivery-e-entrega-comida/id483017239?mt=8>
>>>> <https://play.google.com/store/apps/details?id=br.com.brainweb.ifood>
>>>> <https://www.facebook.com/iFood?fref=ts> <https://twitter.com/iFood>
>>>>
>>>
>>>
>>>
>>> --
>>>
>>> Alexandre Roberto Zia
>>>
>>> *Security*
>>>
>>> *TEL:* +55 (11) 3634-3360
>>>
>>> www.ifood.com.br
>>>
>>>
>>>
>>>
>>> <https://itunes.apple.com/br/app/ifood-delivery-e-entrega-comida/id483017239?mt=8>
>>> <https://play.google.com/store/apps/details?id=br.com.brainweb.ifood>
>>> <https://www.facebook.com/iFood?fref=ts> <https://twitter.com/iFood>
>>>
>>> _______________________________________________
>>> midPoint mailing list
>>> midPoint at lists.evolveum.com
>>> http://lists.evolveum.com/mailman/listinfo/midpoint
>>>
>>>
>>
>>
>> --
>> Best regards,
>>
>>
>>
>> Oleksandr Nekriach | Identity and access management engineer
>>
>> Dynatech, Mednieku str. 4a, Riga, LV-1010, Latvia
>> <https://maps.google.com/?q=Mednieku+str.+4a,+Riga,+LV-1010,+Latvia&entry=gmail&source=g>
>>
>> +37125314685 <+371%2025%20314%20685>
>> ,
>> o.nekriach at dynatech.lv
>> |
>> www.dynatech.lv
>>
>>
>> Stay connected:
>> <https://www.facebook.com/DynatechLatvia/?ref=br_rs>
>> <https://www.linkedin.com/company-beta/17893047/>
>>
>>
>> Confidentiality Notice: This message contains confidential information
>> and is intended only for the named recipient(s). If you are not the
>> addressee you may not copy, distribute or perform any other activities with
>> this information. If you have received this transmission in error, please
>> notify us by e-mail immediately. E-mail transmission cannot be guaranteed
>> to be secure or error-free as information could be intercepted, corrupted,
>> lost, destroyed, arrive late or incomplete, or contain viruses.
>>
>
>
>
> --
>
> Alexandre Roberto Zia
>
> *Security*
>
> *TEL:* +55 (11) 3634-3360
>
> www.ifood.com.br
>
>
>
>
> <https://itunes.apple.com/br/app/ifood-delivery-e-entrega-comida/id483017239?mt=8>
> <https://play.google.com/store/apps/details?id=br.com.brainweb.ifood>
> <https://www.facebook.com/iFood?fref=ts> <https://twitter.com/iFood>
>
--
Best regards,
Oleksandr Nekriach | Identity and access management engineer
Dynatech, Mednieku str. 4a, Riga, LV-1010, Latvia
<https://maps.google.com/?q=Mednieku+str.+4a,+Riga,+LV-1010,+Latvia&entry=gmail&source=g>
+37125314685 <+371%2025%20314%20685>
,
o.nekriach at dynatech.lv
|
www.dynatech.lv
Stay connected:
<https://www.facebook.com/DynatechLatvia/?ref=br_rs>
<https://www.linkedin.com/company-beta/17893047/>
Confidentiality Notice: This message contains confidential information and
is intended only for the named recipient(s). If you are not the addressee
you may not copy, distribute or perform any other activities with this
information. If you have received this transmission in error, please notify
us by e-mail immediately. E-mail transmission cannot be guaranteed to be
secure or error-free as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or contain viruses.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20180726/9767d1ab/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: o.nekriach at dynatech.lv1520941785292-7772
Type: image/png
Size: 786 bytes
Desc: not available
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20180726/9767d1ab/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: o.nekriach at dynatech.lv1520941785292-7770
Type: image/png
Size: 4265 bytes
Desc: not available
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20180726/9767d1ab/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: o.nekriach at dynatech.lv1520941785292-7771
Type: image/png
Size: 790 bytes
Desc: not available
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20180726/9767d1ab/attachment-0002.png>
More information about the midPoint
mailing list