I am in the process of switching the LDAP backend that we use to authenticate access to Gerrit.
When a user logs in via LDAP, a local account is created within Gerrit. We are running version 2.15 of Gerrit, and therefore our local user accounts have migrated from the SQL DB into NoteDB.
The changes in our infrastructure, mean that once the LDAP backend has been switched, user logins will appear to Gerrit as new users and therefore a new local account will be generated. As a result we will need perform a number of administrative tasks to the existing local accounts before and after migration.
The REST API exposes some of the functionality that we need, however two key elements appear to be missing:
There appears to be no way to retrieve a list of all local accounts through the API (such that I could then iterate through to perform the administrative tasks I need to complete). The /accounts/ endpoint insists on a query filter being specified, which does not appear to include a way to simply specify 'all' or '*'. Instead I am having to try and think of a search filter that will reliably return all accounts - I haven't succeeded yet.
There appears to be no way to delete an account. Once the migration is complete, I need to remove the old accounts, but nothing is documented for the API or any other method to remove old accounts.
Has anybody found a solution to either of these tasks that they could share?
I came to the conclusion that the answers to my questions were:
('/a/' in the below examples is accessing the administrative endpoint and so basic Auth is required and the user having appropriate permissions)
Retrieving all accounts
There is no way to do this in a single query, however combining the results of:
GET /a/accounts?q=is:active&n=<number larger than the number of users>
GET /a/accounts?q=is:inactive&n=<number larger than the number of users>
will give effectively the same thing.
Deleting an account
Seems that this simply is not supported. The only option appears to be to set an account inactive:
DELETE /a/accounts/<account_id>/active
Related
I am trying to collect all active TIs via the Beta Graph API by following this. But it doesn't return anything. Here is what I use in Postman:
https://graph.microsoft.com/beta/security/tiIndicators
Response (200):
{
"#odata.context": "https://graph.microsoft.com/beta/$metadata#security/tiIndicators",
"value": []
}
A bit of context for the environment I work in.
The tenant has multiple Sentinel workspaces & resource groups.
The application I use has the correct permissions:
ThreatIndicators.Read.All
ThreatIndicators.ReadWrite.OwnedBy
ThreatSubmission.Read.All
ThreatSubmission.ReadWrite.All
It is my current belief that this might be due to the limitations of the Beta API. My reasoning is that accourding to this documentation you need the ThreatIndicators.ReadWrite.OwnedBy permission to access the API. This would suggest that currently you can only view TI's that the resource itself created.
If more info is needed just ask.
According to the documentation, ThreatIndicators.ReadWrite.OwnedBy permission allow you to manage threat indicators your app creates or owns.
If you want to read all the threat indicators for your organization then your app needs ThreatIndicators.Read.All permission.
Although this is not a solution to the question it is a workaround. By using the Log Analytics API you can get the TI via a KQL.
ThreatIntelligenceIndicator
| where ExpirationDateTime > now() and
NetworkIP matches regex #"^(?:(?:25[0-5]|(?:2[0-4]|1\d|[1-9]|)\d)\.?\b){4}$" and
ConfidenceScore > 25
| summarize by NetworkIP
This is probably better as you can also use a watchlist to exclude specific IP addresses with one request.
One thing I struggled with this was Authorization. You must give your Application permission to use the api.loganalytics.io API, and the application needs the Log Analytics Reader role in the Log Analytic workspace you want to use.
I have inherited a Swift iOS project with that includes Firebase, and I need to troubleshoot a first login with account creation issue, so I expect it will involve repeatedly removing a single account.
Is it possible to access the databases web frontend of the database from the information included in the GoogleService-Info.plist file that was included in the project? Or might I need some information from the previous developer.
The DATABASE_URL ends in firebaseio.com.
Putting the url from DATABASE_URL into a web browser will expand the URL to something like console.firebase.google/com/u/<number>/project/<root> where:
<number> will be 0, 1, 2, etc. But probably 0.
<root> will be
the project name, which is also the first part of the DATABASE_URL
string in GoogleService-Info.plist
You might find that the URL returns a page that states "There was an error while processing the request. Try Again". This is because you're logged in on a different Google account that cannot access that DB. Logging in with the right account should get you the page you want. (This will also change <number> to a new value which is the one you'll always want to use when accessing this DB)
After that you can navigate to authentication/users to see your created accounts, and you can sort by creation date to easily access the accounts you want to delete.
I've been trying to return the employeeId of a user through the Microsoft Graph API but so far haven't had much luck.
I'm assuming this is probably because it doesn't exist in the metadata for the user in the Graph API so makes sense.
However, the property is populated in Azure AD. If I use the AZ command prompt to query the user I can see the property. Likewise, if I query the old Active Directory Graph API endpoint I can even see it there.
For example, querying
https://graph.windows.net/{tennant}/users/{upn}?api-version=1.6 directly I receive the employeeId as part of the response (using the ActiveDirectoryClient however seems to ignore this property and doesn't store it anywhere).
Is there any reason for this? Wouldn't it make sense to have it returned as an additional property? I've also looked into extensions, but as it's not an extension isn't returned there.
Any help would be appreciated. I can get the information I need by querying the old endpoint directly, but this seems like a complete backwards step and involves multiple queries to get the information I need - including having to use multiple end points (one of which I assume will be deprecated and removed soon).
EmployeeId is currently a beta feature and is only available in the beta endpoint of the Graph API.
So if you want to access the beta endpoint you just have to change the version to beta in your url. For example:
https://graph.microsoft.com/beta/me/
https://graph.microsoft.com/beta/users/{id|upn}/
https://graph.windows.net/{tennant}/users/{id|upn}?api-version=beta
For more information about the user-object in the beta endpoint see: https://developer.microsoft.com/en-us/graph/docs/api-reference/beta/resources/user
I am currently working on a solution that is accessing OneDrive in Office 365 using Microsoft Graph. I am using the adal4j library to handle authentication and have configured the app in portal.azure.com.
My question relates the call to get the children for a specified drive. I am using a query similar to the one shown below, as I want to get folders and files at the root level of a specified users drive:
https://graph.microsoft.com/v1.0/users/*user id*/drives/*drive id*/root/children
When I login to the Graph Explorer and execute the query, I get a json result showing the root folder contents for the drive and user specified. All works as expected.
When I call it from my java application, the JSON node value is empty ([]).
Initially my thought was, because the Graph Explorer uses a different app id in the portal it was possibly something to do with access rights. However, I successfully read user profiles in our O365 tenant, the drive id's for each user, and if I execute the following:
https://graph.microsoft.com/v1.0/users/*user id*/drives/*drive id*/root/search(q='')
It provides me a complete list of all of the folders, sub folders etc within the appropriate user's drive.
Therefore, making me think this is a bug with the Graph query I am attempting to use rather than an authorization issue, but, that wouldn't explain why it works in the Graph Explorer.
The same java method is used for all calls, and the url is passed in as a parameter.
Just to follow up, the azure portal app permissions has the capability of adding permissions for the graph api. This was, indeed the problem. It would appear that the search was ignoring the permission and successfully reading the data whereas the /children call was honouring the security model. This caused a lot of confusion, but is now resolved.
Thanks Marc for your help.
I have a project with an single API key in Mandrill. It has three sub-accounts: production, staging, development. I have created a rule that rejects all requests that don't match a small list of domains and I want to apply that rule to both the staging and development sub accounts. The idea is to not accidentally spam clients while we are testing.
I don't see how I can apply the rule to different sub accounts. Is it possible? If not, and I need to create different APIs for each environment, can someone explain when to use sub-account vs when to create different API keys.
As a bonus, when an email matches a rule, is it possible to reroute it to a specified address instead of rejecting it?
I would use separate sub accounts for tracking different systems in a multi-tenant environment (eg you are acting as a service provider for multiple customers or departments via the same Mandrill account).
In your case, I would definitely use separate API keys for each each environment. The main feature you would potentially want to take advantage of is to be able to set one of those keys (eg staging) as a "test key" such that the emails don't ever get sent, they just get tracked in Mandrill so you can verify that they are working.
The last thing you want to have happen is that emails from your non-production environments actually get sent to real users.
The way I typically do things is to have my development system use a non-test key, but only have dummy users whose email addresses all come back to me so I can test things. Then in my staging system, I use a test key with real users (a copy of the production user database) so that any emails that get sent are captured by Mandrill for verification that they are working, but don't ever get forwarded on to the actual user.
I'm assuming that your rejection rule based on a list of domains is intended to achieve the same result that using a test key does - in which case, go with the test keys and forget the rules.
You can't apply a rule to a specific sub account - only to a specific API key.
And no, you can't reroute an email to a different address based on the outcome of a rule - the best you could so is to wire a webhook to somehow notify your system that the rule was triggered so that your system can re-send the email - but that requires custom development work.
Again, if this is actually just an attempt to avoid sending emails to real users when testing, this is what test keys are for.