Please suggest some suitable Python libraries for me
February 27, 2022 10:34 AM Subscribe
Due to aspects of my question, simply searching the web for answers is returning lots of results for something similar but not quite what I'm doing. Posting here because I'm not in the mood to deal with stackoverflow/reddit snark today
I want my script to log in as the user, but search results are all about protecting my Python app which isn't the goal...
I support a team at an IT MSP. Each team member has a bunch of (mainly) AzureAD accounts. It is up to each customer if they want to allow login using our company accounts, or if they create us each individual accounts on their own domain. We cannot dictate to them what to do.
The result is that our team members are constantly dealing with expired passwords somewhere and often at the most inconvenient times. I'm hoping to create a script that will run against all customers per user, and return info about which accounts are in need of attention i.e. a login failed report
The problem is that my web searches all return results instructing how to implement SAML/OAUTH on my script , instead of how to log in the script itself as the user.
I only need to test the login against AAD itself, not log in to any specific application using SAML.
The team does use a password manager that has an API so there shouldn't be a problem looking up each account's credentials in the script.
I support a team at an IT MSP. Each team member has a bunch of (mainly) AzureAD accounts. It is up to each customer if they want to allow login using our company accounts, or if they create us each individual accounts on their own domain. We cannot dictate to them what to do.
The result is that our team members are constantly dealing with expired passwords somewhere and often at the most inconvenient times. I'm hoping to create a script that will run against all customers per user, and return info about which accounts are in need of attention i.e. a login failed report
The problem is that my web searches all return results instructing how to implement SAML/OAUTH on my script , instead of how to log in the script itself as the user.
I only need to test the login against AAD itself, not log in to any specific application using SAML.
The team does use a password manager that has an API so there shouldn't be a problem looking up each account's credentials in the script.
Response by poster: Thanks Silby, I forgot to mention that everyone would have their own version of the script to run whenever they need to. It would still be unique and private credentials, the script is simply to save the individual user from manual work testing dozens of separate logins.
Also the password manager API is authenticated and authorized, one cannot simply access another user's private vault.
posted by McNulty at 11:32 AM on February 27, 2022
Also the password manager API is authenticated and authorized, one cannot simply access another user's private vault.
posted by McNulty at 11:32 AM on February 27, 2022
I don't think you get silby's point...
If any company I worked for were to get or require my passwords to accounts which I was responsible for, I would immediately resign in protest and inform the customer of the insecure nature of their own accounts provided by my former employer. There are some pretty severe legal ramification to allowing someone else to have your dev passwords.
posted by schade at 12:42 PM on February 27, 2022
If any company I worked for were to get or require my passwords to accounts which I was responsible for, I would immediately resign in protest and inform the customer of the insecure nature of their own accounts provided by my former employer. There are some pretty severe legal ramification to allowing someone else to have your dev passwords.
posted by schade at 12:42 PM on February 27, 2022
Response by poster: Sorry to thread sit but it is critical that I clarify that nobody has anyone else's passwords in this (or any other) situation I'm presenting. Each user will run the script themselves, on their own workstation, and enter their own credentials to access the relevant parts of their own private credential vaults.
It is a personal,single-user, run on demand, utility script to save labour and not a corporate application.
Please go back and imagine that I wrote "I have lots of accounts and I want this script for myself" instead of the team aspect. Then imagine that my team thought the idea was so handy that they asked me for a copy.
I really don't think that I can be any clearer on this point but I'll try to clarify more if still required.
posted by McNulty at 12:56 PM on February 27, 2022
It is a personal,single-user, run on demand, utility script to save labour and not a corporate application.
Please go back and imagine that I wrote "I have lots of accounts and I want this script for myself" instead of the team aspect. Then imagine that my team thought the idea was so handy that they asked me for a copy.
I really don't think that I can be any clearer on this point but I'll try to clarify more if still required.
posted by McNulty at 12:56 PM on February 27, 2022
perplexed that anyone other than me had the ability to retrieve the plain text for my personal account in client domains
I would never let the rep responsible for a client that way be the only person who knows the password. It's not your personal account, it's an account the client created for your MSP to do your MSP related things. Your personal account with client is a different thing. All client user/pass combinations are available to all reps. Sorry, can't help you now, silby is in hospital in a coma, wanna create us a new account, oh... you forgot your credentials and can't, well you're shit up the creek without a paddle then because we don't know what user/pass silby used to MSP your shit. Not a good business plan. Don't do that.
I don't know what login to AAD is like, we didn't do cloud like things. Mostly SSH Unixy like things. If it is that sort of 'ssh user@client' sort of thing you want to find the module that does Expect (old TCL Expect terminal driving solution that's been ported to every sort of other language.)
I don't know Python, nor AAD, so no help there.
My scores of scripts accessing user/pass were written in Perl and backed by a Kerberos protected keystore. I wrote my own modules for such things because 'not being able to find the exact thing I need already written'. I could give some design tips there, but again, no knowledge of AAD or Python.
What is 'login' to your mostly AAD (and other things?)? Some sort of HTTPS API call? SSH?
I'd write something and toss it in a cron job that sends mail on problems that would show up in the team mailbox at 4am if there were any. Kudos for trying to fix this issue, sounds like a PITA.
posted by zengargoyle at 12:57 PM on February 27, 2022
I would never let the rep responsible for a client that way be the only person who knows the password. It's not your personal account, it's an account the client created for your MSP to do your MSP related things. Your personal account with client is a different thing. All client user/pass combinations are available to all reps. Sorry, can't help you now, silby is in hospital in a coma, wanna create us a new account, oh... you forgot your credentials and can't, well you're shit up the creek without a paddle then because we don't know what user/pass silby used to MSP your shit. Not a good business plan. Don't do that.
I don't know what login to AAD is like, we didn't do cloud like things. Mostly SSH Unixy like things. If it is that sort of 'ssh user@client' sort of thing you want to find the module that does Expect (old TCL Expect terminal driving solution that's been ported to every sort of other language.)
I don't know Python, nor AAD, so no help there.
My scores of scripts accessing user/pass were written in Perl and backed by a Kerberos protected keystore. I wrote my own modules for such things because 'not being able to find the exact thing I need already written'. I could give some design tips there, but again, no knowledge of AAD or Python.
What is 'login' to your mostly AAD (and other things?)? Some sort of HTTPS API call? SSH?
I'd write something and toss it in a cron job that sends mail on problems that would show up in the team mailbox at 4am if there were any. Kudos for trying to fix this issue, sounds like a PITA.
posted by zengargoyle at 12:57 PM on February 27, 2022
I am missing something here. What is the "end goal" for you? Or for your client?
Do you want to automate warning for your "account managers" like "account X's password has expired"? Shouldn't it be the account holder who's getting this? Like 4 weeks ahead of expiration date?
Obviously the client can choose to do AzureAD SSO, or individual login or whatever they want. But it seems they do not have a "lost password" automated procedure, such as some sort of multi-factor authentication through, say, something like Microsoft Authenticator and an email address or a phone number.
It sounds like you need to convince your clients to adopt some sort of lost-password / expired password automated service, rather trying to, than to call up the MSP every time there's a password expired situation.
Maybe a per-call fee would discourage them from that, rather than you trying to make it EASIER?
posted by kschang at 1:49 PM on February 27, 2022
Do you want to automate warning for your "account managers" like "account X's password has expired"? Shouldn't it be the account holder who's getting this? Like 4 weeks ahead of expiration date?
Obviously the client can choose to do AzureAD SSO, or individual login or whatever they want. But it seems they do not have a "lost password" automated procedure, such as some sort of multi-factor authentication through, say, something like Microsoft Authenticator and an email address or a phone number.
It sounds like you need to convince your clients to adopt some sort of lost-password / expired password automated service, rather trying to, than to call up the MSP every time there's a password expired situation.
Maybe a per-call fee would discourage them from that, rather than you trying to make it EASIER?
posted by kschang at 1:49 PM on February 27, 2022
Best answer: Why is this Python and not PowerShell? I'd be surprised if native verbs like Connect-AD should simplify this.
Python has pyad and adal, and should use the latter to get tokens from Azure AD relevant to the user at hand. You may instead not need these and can instead use classic patterns like registering a PEM cert chain in your Azure AD and using it to secure your python request.
posted by k3ninho at 2:11 PM on February 27, 2022 [1 favorite]
Python has pyad and adal, and should use the latter to get tokens from Azure AD relevant to the user at hand. You may instead not need these and can instead use classic patterns like registering a PEM cert chain in your Azure AD and using it to secure your python request.
posted by k3ninho at 2:11 PM on February 27, 2022 [1 favorite]
I may not have read accurately but perhaps look into the management API for ActiveDirectory to query the expiration information directly.
posted by sammyo at 6:31 PM on February 27, 2022 [1 favorite]
posted by sammyo at 6:31 PM on February 27, 2022 [1 favorite]
Please go back and imagine that I wrote "I have lots of accounts and I want this script for myself" instead of the team aspect. Then imagine that my team thought the idea was so handy that they asked me for a copy.
Abuse your credential store to hold a 'my accounts' sort of key where the data is a serialized list of your accounts along with last password change and method of testing for still working.
Then you write a script that takes your password to the credential store and retrieves 'my accounts' and then de-serializes them and loops through them using the appropriate set of checks. Does that account have a 60 day password change thing? Was your last password change 53 days ago? Add that the list of return things. Can you 'login'? Do nothing. Does 'login' fail? Add that to the list of return things. Does 'login' work and is there a query to ask when password expires? Check that, less that 7 days? Add that to the return value. The outer loop collects all of those things because you formatted the return values to be descriptive. If it gets nothing back then there's nothing to worry about AFAYK. Otherwise print out the collected return values. Run that every morning while you fix some coffee. If nothing happens, nothing to worry about. If there's a warning about expiration or just not connecting... you fix that.
Then you talk to your boss about getting such a thing in a location that teammates can use because you don't want them running it from your directory. Then you get permissions. Then you get a nasty-not-nasty email from the ghost in the machine becase they're getting feature request for your script because everybody assumes they wrote it. Then you get promoted and take over their old code before they moved on along. Then you become them and go "hell no, that's not your personal account, all reps have the ability to serve all clients. Not your password! Our password.". Then you're no longer a rep and you're automating that 4am message to the team "Accounts that need some attention". You get a duplicate if one of those accounts is yours.
Most of this is bespoke software engineering and can/will be "no there's not a module that does that". You have to smoosh together several modules that each to a bit of something to create the thing that works for your situation. All IKEA furniture like. And mostly it won't work anywhere else unless you're really crafty or over-engineer the thing to make it generic. Then whoops you have a module to maintain for others. And employer may consider it their intellectual property. It sounds pretty easy.
posted by zengargoyle at 11:12 PM on February 27, 2022
Abuse your credential store to hold a 'my accounts' sort of key where the data is a serialized list of your accounts along with last password change and method of testing for still working.
Then you write a script that takes your password to the credential store and retrieves 'my accounts' and then de-serializes them and loops through them using the appropriate set of checks. Does that account have a 60 day password change thing? Was your last password change 53 days ago? Add that the list of return things. Can you 'login'? Do nothing. Does 'login' fail? Add that to the list of return things. Does 'login' work and is there a query to ask when password expires? Check that, less that 7 days? Add that to the return value. The outer loop collects all of those things because you formatted the return values to be descriptive. If it gets nothing back then there's nothing to worry about AFAYK. Otherwise print out the collected return values. Run that every morning while you fix some coffee. If nothing happens, nothing to worry about. If there's a warning about expiration or just not connecting... you fix that.
Then you talk to your boss about getting such a thing in a location that teammates can use because you don't want them running it from your directory. Then you get permissions. Then you get a nasty-not-nasty email from the ghost in the machine becase they're getting feature request for your script because everybody assumes they wrote it. Then you get promoted and take over their old code before they moved on along. Then you become them and go "hell no, that's not your personal account, all reps have the ability to serve all clients. Not your password! Our password.". Then you're no longer a rep and you're automating that 4am message to the team "Accounts that need some attention". You get a duplicate if one of those accounts is yours.
Most of this is bespoke software engineering and can/will be "no there's not a module that does that". You have to smoosh together several modules that each to a bit of something to create the thing that works for your situation. All IKEA furniture like. And mostly it won't work anywhere else unless you're really crafty or over-engineer the thing to make it generic. Then whoops you have a module to maintain for others. And employer may consider it their intellectual property. It sounds pretty easy.
posted by zengargoyle at 11:12 PM on February 27, 2022
« Older What's the deal with charging Apple Watches in... | How can a worrywart and someone with no fear at... Newer »
This thread is closed to new comments.
posted by silby at 10:49 AM on February 27, 2022 [1 favorite]