Environment
NetIQ Access Manager 4.2
NetIQ Advanced Authentication Framework 5.4 or 5.5
Situation
The AAF logs would indicate that the user successfully authenticated:
I cleared the NAAF logs and tried accessing NAAF thru NAM again and I actually see that my attempt was successful:
System Log
May 23 17:26:16 (UTC+0200) aucore-1000 CEF:0|AAA|Core|5.0|101|User was successfully logged on|7|ep_addr=10.112.122.6 event=Authenticators<space>Management method_name=LDAP_PASSWORD:1 template_owner=ORG\\ncashelltenant_name=TOP user_name=ORG\\ncashellp=55462
May 23 17:26:16 (UTC+0200) aucore-1000 CEF:0|AAA|Core|5.0|100|User logon started|4|ep_addr=10.112.122.6 event=Authenticators<space>Management tenant_name=TOP user_name=ORG\\ncashellp=55462
Web server log
2017-05-23 17:26:15 (UTC+0200) INFO [uwsgi-end-req] GET /account/basic 198.55.130.91 808ms
2017-05-23 17:26:16 (UTC+0200) DEBUG [aucore.au.utils.sender] Sender thread got event
2017-05-23 17:26:16 (UTC+0200) INFO [aucore.logger.client] CEF:0|AAA|Core|5.0|101|User was successfully logged on|7|ep_addr=10.112.122.6 event=Authenticators Management method_name=LDAP_PASSWORD:1 template_owner=ORG\\ncashelltenant_name=TOP user_name=ORG\\ncashell p=55462
2017-05-23 17:26:16 (UTC+0200) DEBUG [aucore.au.logon_manager] CHAIN COMPLETE LDAP Password Only
2017-05-23 17:26:16 (UTC+0200) DEBUG [aucore.views] GET /admin/api/logs?p=0&h=&l=0&i=syslog&tz=120 10.112.122.6
2017-05-23 17:26:16 (UTC+0200) INFO [aucore.logger.client] CEF:0|AAA|Core|5.0|100|User logon started|4|ep_addr=10.112.122.6 event=Authenticators Management tenant_name=TOP user_name=ORG\\ncashell p=55462
2017-05-23 17:26:16 (UTC+0200) DEBUG [aucore.au.ldap_helper] SEARCH SUBTREE ARGS:<('OU=Corporate,DC=org,DC=netiq,DC=com', '(&(objectClass=user)(|(sAMAccountName=denlau)(userPrincipalName=ncashell)))')> FILTER:<None> ATTRS:<['msDS-User-Account-Control-Computed', 'otherMobile', 'objectSID', 'primaryGroupId', 'userPrincipalName', 'accountExpires', 'userAccountControl', 'mobile', 'mail', 'logonHours', 'cn', 'objectGUID', 'sAMAccountName', 'objectClass', 'otherMailbox']>
Resolution
For the use case where you want to block portal to end users but allow enrollment, the following seems to work:
* block /admin
* allow /admin/api/*
This will give you access to /account (enrollment portal) and you will be able to enroll methods.
Note too that if you are using smartphone based authentication, a number of other public resources must be defined - here's the list we used to get it going behind the AG.
This is complete protected resource list we used for accelerating AAF enrollment page:
* /
-> some contract,
Auth-Rule: redirect / to /account/basic
* /account/basic -> some
contract, II injection
* /admin/*
-> deny all
* /admin/api/* -> public
resource (or some Contract)
* /smartphone/* -> public
resource
* /oob/*
-> public resource
* /helpdesk/* ->
Auth-Rule: deny, unless member of helpdesk group