I tried reproducing this and I couldn't, these are the scenarios:

1. User group "a" with external user group "foremaners". User "lobato" (who is in "foremaners" in LDAP) tries to log in and autocreate the account. Account is autocreated and user "lobato" gets put in user group "a"
2. User group "a" with external user group "foremaners". User "vito" (who is in "katellers" in LDAP, nested below "foremaners") tries to log in and autocreate the account. Account is autocreated and user doesn't get put in any user group because there is no external user group "katellers".

Is the second scenario what you're experiencing? I'm not entirely sure we should support that.

I seem to be getting a different response in scenarios 1. I have tested multiple times and see nothing in the logs suggesting it is trying to refresh the user groups. Is this possible that it works for the freeipa ldap servers, but not for AD ldap servers?

My logs look like the following:
Processing by UsersController#login as HTML
Parameters: {"utf8"=>"✓", "authenticity_token"=>"FLAD+WwH1UynfdA8zheoUqyc2I2Iru8vJP/ki6XalvQ=", "login"=>{"login"=>"lrf", "password"=>"[FILTERED]"}, "commit"=>"Login"}
Expire fragment views/tabs_and_title_records-9 (0.2ms)
Expire fragment views/tabs_and_title_records-9 (0.1ms)
User 'lrf' auto-created from LDAP-AD
Expire fragment views/tabs_and_title_records-9 (0.2ms)
Expire fragment views/tabs_and_title_records-9 (0.1ms)
Redirected to https://foreman/hosts
Completed 302 Found in 5751ms (ActiveRecord: 19.9ms)
Processing by HostsController#index as HTML
Rendered common/403.html.erb within layouts/application (1.5ms)
Rendered common/_searchbar.html.erb (30.4ms)
Rendered home/_user_dropdown.html.erb (2.3ms)
Read fragment views/tabs_and_title_records-9 (0.1ms)
Rendered home/_organization_dropdown.html.erb (4.2ms)
Rendered home/_location_dropdown.html.erb (3.1ms)
Rendered home/_org_switcher.html.erb (8.1ms)
Rendered home/_submenu.html.erb (0.9ms)
Rendered home/_submenu.html.erb (1.2ms)
Write fragment views/tabs_and_title_records-9 (3.7ms)
Rendered home/_topbar.html.erb (28.3ms)
Rendered layouts/base.html.erb (30.6ms)
Filter chain halted as :authorize rendered or redirected
Completed 403 Forbidden in 96ms (Views: 58.5ms | ActiveRecord: 16.2ms)

I am seeing the same behaviour as Leah on FreeIPA

Steps to reproduce:

Create group in FreeIPA
Add user to the new group in FreeIPA (and ensure they haven't logged in to Foreman before)
Ensure group is allowed in the HBAC rule for Foreman
Create a new user group in Foreman with the same name as the group you created in FreeIPA
Add External group and add the group you added to FreeIPA
Login as the user you added to the new group

Expected Behaviour:

The user should be logged in to Foreman and be a member of the Foreman user group you created above

Actual Behaviour:

The user is logged into Foreman but is not a member of any user group in Foreman. If you refresh the external groups for the Foreman user group you created above then the user is added into the user group.

The

Sorry, should have added the versions being used:

Foreman: 1.7.3
FreeIPA: 3.0.0 (Release: 42.el6.centos)

Both running on CentOS 6.5