Network account detection matches local accounts with AD counterpart

[matt-cahill]

Not sure if this is intended behaviour or not but the test for a network account will match a local account that has the same username as a user in AD. This means ADPassMon will run even in the runIfLocal preference is false when this happens.

As far as I understand it I think that ADPassMon should work like this

Network and Mobile accounts => Always run
Local account with AD counterpart => Only run if runIfLocal is true
Local only account => Never run

Cheers

Matt

[pmbuko]

You are correct. That is the way it should work, but a recent change made it so the second case -- local account with AD counterpart -- would always be detected as network-based. I'm working on the fix now.

[pmbuko]

Please download the latest (pre-)release: https://github.com/macmule/ADPassMon/releases/tag/2.20.16 and let me know if it resolves your issue.

[matt-cahill]

Will do Peter, thanks!

[matt-cahill]

Using /usr/bin/id gets closer but leaves 2 bugs

Local accounts that have a matching AD account get detected as local accounts now but setting runIfLocal to true still enables local accounts that are local only.

Mobile accounts don't get detected when the are off the network. Well, more specifically the group membership data only seems to be cached for the length of the kerberos ticket and don't survive an off network reboot. Below I disconnected from our network and rebooted and then ran the test in a shell before and after reconnecting to the domain.

[slimjim:~] mcahill% id | grep '\\'
[slimjim:~] mcahill% networksetup -setairportpower en0 on
[slimjim:~] mcahill% id | grep '\\'
(ticket acquired by kerbminder at some point here)
[slimjim:~] mcahill% id | grep '\\'
uid=****(mcahill) gid=****(tech) groups=****(tech),****(WETAFX\systems),..........etc

Additionally if the kerberos ticket is manually destroyed and re-requested for some reason id no longer references the domain for each group so ****(WETAFX\systems) becomes ****(systems) and so on, which of course also causes the test to give a false negative.

Possibly there needs to be two tests, one to seperate local accounts from network and mobile accounts and if a local account is found and runIfLocal is true another nested one to see if that account has a brother in the search path.

[pmbuko]

Thanks for testing, Matt. I had a feeling I was making too many assumptions, hence the pre-release. I'll continue in this direction and add a secondary test.

-- Peter (from phone)

On Jan 28, 2016, at 8:14 PM, Matt Cahill [email protected] wrote:

Using /usr/bin/id gets closer but leaves 2 bugs

Local accounts that have a matching AD account get detected as local accounts now but setting runIfLocal to true still enables local accounts that are local only.

Mobile accounts don't get detected when the are off the network. Well, more specifically the group membership data only seems to be cached for the length of the kerberos ticket and don't survive an off network reboot. Below I disconnected from our network and rebooted and then ran the test in a shell before and after reconnecting to the domain.

[slimjim:] mcahill% id | grep ''
[slimjim:] mcahill% networksetup -setairportpower en0 on
[slimjim:] mcahill% id | grep ''
(ticket acquired by kerbminder at some point here)
[slimjim:] mcahill% id | grep ''
uid=_(mcahill) gid=__(tech) groups=__(tech),__(WETAFX\systems),..........etc
Additionally if the kerberos ticket is manually destroyed and re-requested for some reason id no longer references the domain for each group so *_*(WETAFX\systems) becomes ****(systems) and so on, which of course also causes the test to give a false negative.

Possibly there needs to be two tests, one to seperate local accounts from network and mobile accounts and if a local account is found and runIfLocal is true another nested one to see if that account has a brother in the search path.

—
Reply to this email directly or view it on GitHub.

[macmule]

Merged with master, will release soon.