Office 365 SSO with SAML triggers nidsIdentity object to be removed and re-added with every login

  • 7018539
  • 27-Jan-2017
  • 31-Jan-2017

Environment

NetIQ Access Manager 4.3
NetIQ Access Manager 4.2
Office 365

Situation

Office 365 integrated with Access Manager using SAML2 Federation protocol. When a user accesses Office365 and is redirected to authenticate against the NAM IDP server using SAML2 protocol, each user login triggers a removeIdentity call (and corresponding AC eDir update with nidsIdentityName), followed by a new add as shown in snippet of catalina log below. This has a corresponding LDAP operation into the Admin Console LDAP server and concerns arise with performance when the number of users logging in is high.

// Catalina remove operation on login before the re-add is done later

<amLogEntry> 2016-03-23T15:19:10Z DEBUG NIDS Application:
Method: NIDPPrincipal.removeIdentity
Thread: ajp-bio-127.0.0.1-9019-exec-22
Remove the identity for: Identity Id: urn:federation:MicrosoftOnline, provided: true, federated: true, Pr
incipal: cn=ncashell,o=novell </amLogEntry>

<amLogEntry> 2016-03-23T15:19:10Z DEBUG NIDS Application:
Method: NIDPPrincipal.removeIdentity
Thread: ajp-bio-127.0.0.1-9019-exec-22
Removing identity for: Identity Id: urn:federation:MicrosoftOnline from the Principal identity list at in
dex: 0: ( isTemporary: false) ( isProvisioned: false) </amLogEntry>

<amLogEntry> 2016-03-23T15:19:10Z DEBUG NIDS Application:
Method: NIDPPrincipal.removeIdentity
Thread: ajp-bio-127.0.0.1-9019-exec-22
Removing the entire Principal identity list entry because both elements are null </amLogEntry>


From the dstrace side, we can see the following operation generated by IDP server to Admin Console LDAP removing nidsIdentityName and re-adding it:

[2016/03/23  8:24:07.811] (151.155.20.70:39024)(0x0003:0x63) DoSearch on connection 0xe67c380
[2016/03/23  8:24:07.811] (151.155.20.70:39024)(0x0003:0x63) Search request:
        base: "nidsGUID=fb2ff27d68f3094c1e91fb2ff27d68f3,cn=LibertyUserProfiles0,cn=SCCnkfr77,cn=cluster,
cn=nids,ou=accessManagerContainer,o=novell"
        scope:0  dereference:3  sizelimit:0  timelimit:0  attrsonly:0
        filter: "(objectClass=*)"
        attribute: "nidsGUID"
[2016/03/23  8:24:07.812] (151.155.20.70:39024)(0x0003:0x63) nds_back_search: Search Control OID 2.16.840
.1.113730.3.4.2
[2016/03/23  8:24:07.812] (151.155.20.70:39024)(0x0003:0x63) Sending search result entry "nidsGUID=fb2ff2
7d68f3094c1e91fb2ff27d68f3,cn=LibertyUserProfiles0,cn=SCCnkfr77,cn=cluster,cn=nids,ou=accessManagerContai
ner,o=novell" to connection 0xe67c380
[2016/03/23  8:24:07.812] (151.155.20.70:39024)(0x0003:0x63) Sending operation result 0:"":"" to connecti
on 0xe67c380
[2016/03/23  8:24:08.84] (151.155.20.70:39024)(0x0004:0x4a) DoDelete on connection 0xe67c380
[2016/03/23  8:24:08.84] (151.155.20.70:39024)(0x0004:0x4a) delete: dn (nidsIdentityName=%2By%2FyfWjzCUwe
kfsv8n1o8w%3D%3D,cn=STSPwdd7ld,cn=SMIP74zhbl,cn=SCCnkfr77,cn=cluster,cn=nids,ou=accessManagerContainer,o=
novell)
[2016/03/23  8:24:08.86] (151.155.20.70:39024)(0x0004:0x4a) Sending operation result 0:"":"" to connectio
n 0xe67c380
[2016/03/23  8:24:08.91] (151.155.20.70:39024)(0x0005:0x68) DoAdd on connection 0xe67c380
[2016/03/23  8:24:08.91] (151.155.20.70:39024)(0x0005:0x68)     add: dn (nidsIdentityName=%2By%2FyfWjzCUw
ekfsv8n1o8w%3D%3D,cn=STSPwdd7ld,cn=SMIP74zhbl,cn=SCCnkfr77,cn=cluster,cn=nids,ou=accessManagerContainer,o
=novell)
[2016/03/23  8:24:08.93] (151.155.20.70:39024)(0x0005:0x68) Sending operation result 0:"":"" to connectio
n 0xe67c380
[2016/03/23  8:24:11.248] (127.0.0.1:55421)(0xd292:0x63) DoSearch on connection 0xe78c000
[2016/03/23  8:24:11.248] (127.0.0.1:55421)(0xd292:0x63) Search request:
        base: ""
        scope:0  dereference:0  sizelimit:0  timelimit:0  attrsonly:0
        filter: "(objectClass=*)"
        no attributes

There does not appear to be a way of removing this. Using Ws-federation as the Federation protocol does not show up the same behaviour.

Resolution

Apply NAM 4.2 SP3.

Cause

JNDI making unecessary calls into AC eDir because of the persistent name identifier used with Office 365.