Describe the bug
When using --client authentication and --all-subscriptions options for an Azure run, ScoutSuite only uses one subscription.
$ python scout.py azure --cli --all-subscriptions
...
scout[85592] INFO Running against 1 subscription(s)
When using --user-account-browser authentication and --all-subscriptions, ScoutSuite properly picks up all of my subscriptions.
$ python scout.py azure --user-account-browser --all-subscriptions --tenant foo
...
scout[85592] INFO Running against 123 subscription(s)
To Reproduce
See above.
Additional context
az account list shows all of my subscriptions.
Thanks @aus, will look into it.
@aus, in https://github.com/nccgroup/ScoutSuite/issues/698 you mentioned:
In the past, I've been able to skirt around this by using --cli authentication which does refresh (out of band, I guess). Unfortunately, that's not an option here because it's not picking up all my subscriptions. See #738.
Do you mean that this is a new issue? I'm not sure we changed anything relating to CLI auth recently, hence why I'm asking.
This issue (only 1 subscription being used) was an existing issue before PR #734. I don't they are related. I just meant that I experienced this problem in my first runs of scout.py azure and my workaround was to use --user-account-browser which picks up all my subscriptions.
Unfortunately, --user-account-browser will timeout of after an hour, so it wasn't a viable workaround when testing PR #734. I've created a separate issue for the timeout issue to reduce confusion.
This has been fixed in develop. Thanks for pointing it out @aus, there was an issue with the parameter evaluation order.
Confirmed this fixes the issue.
Most helpful comment
This issue (only 1 subscription being used) was an existing issue before PR #734. I don't they are related. I just meant that I experienced this problem in my first runs of
scout.py azureand my workaround was to use--user-account-browserwhich picks up all my subscriptions.Unfortunately,
--user-account-browserwill timeout of after an hour, so it wasn't a viable workaround when testing PR #734. I've created a separate issue for the timeout issue to reduce confusion.