Azure AD Connect: Unable to update this object in Azure Active Directory, exceeds allowed length

%3CLINGO-SUB%20id%3D%22lingo-sub-207466%22%20slang%3D%22en-US%22%3EAzure%20AD%20Connect%3A%20Unable%20to%20update%20this%20object%20in%20Azure%20Active%20Directory%2C%20exceeds%20allowed%20length%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-207466%22%20slang%3D%22en-US%22%3E%3CP%3EI%20am%20running%20a%20Server%202016%20as%20DC%2FAD%3C%2FP%3E%3CP%3EI%20have%20my%20Office%20365%3CSPAN%3E%26nbsp%3BEnterprise%20E1%20licenses%20assigned%20to%20my%20corporate%20users%2C%20which%20includes%20Exchange%20Online%20(E1)%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3CSPAN%3EMy%20corporate%20users%20are%20being%20synched%20from%20my%20local%20AD%20to%20Azure%20AD%20using%20the%20latest%20version%20of%20Azure%20AD%20Connect.%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3CSPAN%3EI%20want%20my%20users%20to%20be%20able%20to%20use%20the%20AAD%20based%20addressbook%20from%20OWA%20Online%20and%20from%20Outlook%202016%2C%20to%20obtain%20the%20public%20UserCertificate%20information%20in%20order%20to%20allow%20for%20secure%20email%20encryption%20ie%20S%2FMIME.%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3CSPAN%3EMy%20AD%20user%20accounts%20all%20have%20the%20attribute%20UserCertificate%20properly%20populated%20with%20a%20single%20certificate.%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%3CSPAN%3EOther%20Attributes%20such%20as%20UserSMIMECertificate%20and%20AltSecurityIdentities%20are%20NOT%20populated%20as%20this%20isnt%20a%20requirement%20according%20to%20online%20Microsoft%20literature.%26nbsp%3B%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3CSPAN%3EMy%20Office%20365%20has%20been%20populated%20with%20the%20proper%20SST%20file%20to%20trust%20any%20used%20issuing%20CA%20parties%20and%20their%20Root%20certificate%2C%20and%20when%20receiving%20a%20signed%20email%20from%20a%20trusted%20issuing%20CA%20these%20signatures%20are%20trusted%20in%20both%20Outlook%202016%20and%20OWA%20Online.%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3CSPAN%3EMy%20users%20all%20have%20the%20Microsoft%20ActiveX%20SMIME%20Control%20component%20for%20Internet%20Explorer%20installed%20though%20this%20is%20not%20a%20requirement%20for%20the%20problem%20I'm%20running%20into.%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3CEM%3E%3CSTRONG%3ESo%20the%20problem%3A%3C%2FSTRONG%3E%3C%2FEM%3E%3C%2FP%3E%3CP%3E%3CSTRONG%3EWhen%20my%20AD%20syncs%20to%20AAD%20using%20Azure%20AD%20Connect%2C%20I%20receive%20the%20following%20error%3A%3C%2FSTRONG%3E%3C%2FP%3E%3CP%3E%3CSTRONG%3EUnable%20to%20update%20this%20object%20in%20Azure%20Active%20Directory%2C%20because%20the%20attribute%20%5Bextension_405d00f7eed04a019ec1f0820568899c_userCertificate%5D%2C%20in%20the%20local%20Directory%20exceeds%20the%20maximum%20allowed%20length.%20If%20you%20want%20to%20update%2C%20reduce%20the%20length%20in%20the%20local%20directory%20services%2C%20and%20then%20try%20again.%3C%2FSTRONG%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EReading%20into%20this%20issue%2C%20the%20error%20is%20normally%20caused%20because%20UserCertificate%20contains%20more%20than%2015%20certificate%20entries%2C%20or%20another%20field%20might%20contain%20more%20than%2015%20entries.%20However%20since%20I%20only%20have%201%20certificate%20in%20my%20AD%20and%20other%20attributes%20are%20empty%2C%20this%20isnt%20the%20cause.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI%20called%20Microsoft%20Support%20and%20they%20told%20me%3A%20the%20solution%20is%20easy%3A%20do%20not%20sync%20your%20UserCertificate%20attributes%20%2C%20which%20obviously%20negates%20the%20entire%20reason%20why%20I%20want%20it%20synced.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI've%20setup%20a%20virgin%20environment%20with%20a%20new%20AD%20and%20another%20AAD%20account%2C%20again%20with%20a%20single%20certificate%20in%20the%20attribute%20Certificate%2C%20and%20again%20the%20same%20error%20occurs.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ESo%20my%20question%3A%20How%20can%20this%20issue%20be%20resolved%20without%20having%20to%20populate%20UserSMIMECertificate%20(as%20its%20a%20proprietary%20Outlook%20format%20and%20not%20properly%20supported%20from%20standard%20AD%20tools%20such%20as%20Active%20directory%20Users%20and%20Computers)%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EGuides%20I%20followed%3A%3C%2FP%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Fblogs.technet.microsoft.com%2Fexchange%2F2014%2F12%2F15%2Fhow-to-configure-smime-in-office-365%2F%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Fblogs.technet.microsoft.com%2Fexchange%2F2014%2F12%2F15%2Fhow-to-configure-smime-in-office-365%2F%3C%2FA%3E%3C%2FP%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechnet.microsoft.com%2Fen-us%2Flibrary%2Faa996408(v%3Dexchg.65).aspx%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Ftechnet.microsoft.com%2Fen-us%2Flibrary%2Faa996408(v%3Dexchg.65).aspx%3C%2FA%3E%20(yes%20old%20from%202006%20but%20still%20seems%20valid%20to%20explain%20the%20difference%20between%20the%202%20attributes)%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3E%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-207466%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3EExchange%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EOffice%20365%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3ESecurity%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E%3CLINGO-SUB%20id%3D%22lingo-sub-386734%22%20slang%3D%22en-US%22%3ERe%3A%20Azure%20AD%20Connect%3A%20Unable%20to%20update%20this%20object%20in%20Azure%20Active%20Directory%2C%20exceeds%20allowed%20length%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-386734%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F159247%22%20target%3D%22_blank%22%3E%40Admin%20M%20vdS%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%3CP%3EHi%20have%20you%20ever%20mitigated%20this%20issue%3F%20I%20see%20the%20identical%20issue%20with%20just%20one%20cert%20in%20two%20tenants.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EKind%20Regards%3C%2FP%3E%3CP%3EAnthony%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-213349%22%20slang%3D%22en-US%22%3ERe%3A%20Azure%20AD%20Connect%3A%20Unable%20to%20update%20this%20object%20in%20Azure%20Active%20Directory%2C%20exceeds%20allowed%20length%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-213349%22%20slang%3D%22en-US%22%3E%3CP%3EHi%20Michael%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EMany%20thanks.%20We've%20done%20these%20steps%20and%20it%20didnt%20result%20in%20any%20solution%20regretfully%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EMicrosoft%20also%20got%20back%20to%20me%20on%20my%20ticket%20ref%20this%20mentioned%20issue%2C%20and%20they%20wrote%3A%3C%2FP%3E%3CP%3EHi%20Michael%2C%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThis%20is%20in%20reference%20to%20your%20service%20request%20number%201XXXXXX8.%20We%20reproduced%20the%20issue%20in%20our%20test%20environment%20and%20were%20getting%20a%20similar%20error.%20We%20have%20engaged%20our%20backend%20team%20to%20check%20if%20this%20behavior%20can%20be%20changed%20or%20is%20there%20a%20work%20around%20for%20this%20specific%20issue.%20I%20will%20keep%20you%20posted%20on%20the%20status%20of%20the%20same.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThank%20you%20for%20your%20support%20and%20patience.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ERegards%2C%3CBR%20%2F%3EAbhilav%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-212697%22%20slang%3D%22en-US%22%3ERe%3A%20Azure%20AD%20Connect%3A%20Unable%20to%20update%20this%20object%20in%20Azure%20Active%20Directory%2C%20exceeds%20allowed%20length%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-212697%22%20slang%3D%22en-US%22%3E%3CP%3EHello%2C%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EPlease%20go%20to%20the%20Azure%20AD%20Connect%20Site%3A%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Factive-directory%2Fconnect%2Factive-directory-aadconnectsync-largeobjecterror-usercertificate%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Factive-directory%2Fconnect%2Factive-directory-aadconnectsync-largeobjecterror-usercertificate%3C%2FA%3E%3C%2FP%3E%0A%3CP%3EAzure%20AD%20Connect%20sync%3A%20Handling%20LargeObject%20errors%20caused%20by%20userCertificate%20attribute%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EPlease%20confirm%2C%20that%20all%20described%20steps%20are%20done%20and%20when%20it%E2%80%99s%20possible%2C%20write%20some%20results%20back%20to%20us.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EThanks%20and%20%E2%80%9CGood%20Luck%E2%80%9D%3C%2FP%3E%0A%3CP%3EFeel%20free%20to%20contact%20me%20if%20you%20any%20questions.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3ERegards%3C%2FP%3E%0A%3CP%3EMichael%3C%2FP%3E%3C%2FLINGO-BODY%3E
Highlighted
New Contributor

I am running a Server 2016 as DC/AD

I have my Office 365 Enterprise E1 licenses assigned to my corporate users, which includes Exchange Online (E1)

 

My corporate users are being synched from my local AD to Azure AD using the latest version of Azure AD Connect.

 

I want my users to be able to use the AAD based addressbook from OWA Online and from Outlook 2016, to obtain the public UserCertificate information in order to allow for secure email encryption ie S/MIME.

 

My AD user accounts all have the attribute UserCertificate properly populated with a single certificate.

Other Attributes such as UserSMIMECertificate and AltSecurityIdentities are NOT populated as this isnt a requirement according to online Microsoft literature. 

 

My Office 365 has been populated with the proper SST file to trust any used issuing CA parties and their Root certificate, and when receiving a signed email from a trusted issuing CA these signatures are trusted in both Outlook 2016 and OWA Online.

 

My users all have the Microsoft ActiveX SMIME Control component for Internet Explorer installed though this is not a requirement for the problem I'm running into.

 

So the problem:

When my AD syncs to AAD using Azure AD Connect, I receive the following error:

Unable to update this object in Azure Active Directory, because the attribute [extension_405d00f7eed04a019ec1f0820568899c_userCertificate], in the local Directory exceeds the maximum allowed length. If you want to update, reduce the length in the local directory services, and then try again.

 

Reading into this issue, the error is normally caused because UserCertificate contains more than 15 certificate entries, or another field might contain more than 15 entries. However since I only have 1 certificate in my AD and other attributes are empty, this isnt the cause.

 

I called Microsoft Support and they told me: the solution is easy: do not sync your UserCertificate attributes , which obviously negates the entire reason why I want it synced.

 

I've setup a virgin environment with a new AD and another AAD account, again with a single certificate in the attribute Certificate, and again the same error occurs.

 

So my question: How can this issue be resolved without having to populate UserSMIMECertificate (as its a proprietary Outlook format and not properly supported from standard AD tools such as Active directory Users and Computers)

 

Guides I followed:

https://blogs.technet.microsoft.com/exchange/2014/12/15/how-to-configure-smime-in-office-365/

https://technet.microsoft.com/en-us/library/aa996408(v=exchg.65).aspx (yes old from 2006 but still seems valid to explain the difference between the 2 attributes)

 

 

3 Replies
Highlighted

Hello,

 

Please go to the Azure AD Connect Site:

 

https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnectsync-larg...

Azure AD Connect sync: Handling LargeObject errors caused by userCertificate attribute

 

Please confirm, that all described steps are done and when it’s possible, write some results back to us.

 

Thanks and “Good Luck”

Feel free to contact me if you any questions.

 

Regards

Michael

Highlighted

Hi Michael

 

Many thanks. We've done these steps and it didnt result in any solution regretfully

 

Microsoft also got back to me on my ticket ref this mentioned issue, and they wrote:

Hi Michael,

 

This is in reference to your service request number 1XXXXXX8. We reproduced the issue in our test environment and were getting a similar error. We have engaged our backend team to check if this behavior can be changed or is there a work around for this specific issue. I will keep you posted on the status of the same.

 

Thank you for your support and patience.

 

Regards,
Abhilav 

Highlighted

@Admin M vdS 

Hi have you ever mitigated this issue? I see the identical issue with just one cert in two tenants.

 

Kind Regards

Anthony