I opened a virus file and someone got access to my emails. After this, I have changed the password and enabled 2FA, but the hacker is manipulating my Google Script.
I keep receiving emails, for example:
Your script, Untitled project, has recently failed to finish successfully. A summary of the failure(s) is shown below. To configure the triggers for this script, or change your settings for receiving future failure notifications, click here.
I don't understand what is happening; how can I delete all of these scripts and triggers, and ultimately remove this person's access from my account?
To completely remove all Google apps scripts access from your compromised account,
Change your Google account password
Visit apps script dashboard and remove all triggers and all scripts there.
Visit your Google account third party apps page and remove all apps with permissions there.
Make sure you're logged into the correct google account.
Related
I am brand new to using the DocuSign API. My company has issued me a DocuSign account and I believe I am set up as a developer. Going through the introductory documentation, I see it says to create or log into a dev sandbox.
I've tried the following:
Log into demo.docusign.net with my existing work account. This fails saying there is no such account, though I can log into that account on www.docusign.net.
Log into demo.docusign.net with a newly-created personal account. This fails saying there is no such account, though I can log into that account on www.docusign.net.
Select "Sign up" on demo.docusign.net. This brings me to a new-account page. I can create an account there which works with www.docusign.net, but not on demo.docusign.net.
Log in to demo.docusign.net using my Google account. That fails with the error "Social ID is not linked to a DocuSign membership."
So, what do I do? My goal is to set up a sandbox, ideally with my work account, where I can experiment and debug without affecting production data. How do I set up such a sandbox?
Or, am I on a completely wrong track? Do I not need such a sandbox to do development?
Sandbox accounts are completely separate from your production account.
Here is the sign up link: https://secure.docusign.com/signup/developer
I initially created a trial account. Discovered that was incorrect then created a developer account. Everything seemed good until I timed out and tried signing back in. The new password used to create the developer account was no longer valid. DocuSign had reverted my account login back to the original trial account. This has happened every time I created a Developer account. I am currently up to my 12th dev account creation. Verifying every time. At least all the fields are prepopulated so I don't have to type everything.
How do I prevent DocuSign account management from reverting my Developer account back to a Trial account? I contacted their support directly but they didn't know and suggested I ask here.
Make sure that you are logging on to demo.docusign.net and that you are going to the following page to set up your dev account. Create Dev Account
When you first login to your account make sure the url is demo.docusign.net. Demo accounts are on a completely separate server system than the production system.
Support should also be able to look up your account information by e-mail to see where your accounts are located and what the status of them are. If you have an enterprise account, I would make sure to have your enterprise account number when you call in. This will put you with the enterprise support group, which typically handles these issues more frequently.
How can I deactivate the
"Summary of failures for Google Apps Script: Gmail Scheduler"
message I keep getting everyday?
To revoke a script's access to your data, visit the permissions page for your Google account. Click the name of the script whose authorization you want to revoke, then click Revoke access on the right.
Yesterday I created a new Ghost Blog website from the Azure website gallery. The installation there asks for Gmail account and passwords, and like any security fanatic I gave my personal gmail account information (mistake #1).
Everything went nicely and got the blog up and running in no time.
Moment went and I got an email from Gmail saying that there has been suspicious log in to my gmail account from Taiwan. Google blocked this login and I made quick password change.
Today I repeated everything, but created new account to gmail to test things out. Same thing happened, but this time the login was from unknown location.
I scanned my computer for keyloggers and didn't find any.
Is it just Google being cautious and warning that the Ghost is trying to send mail and performing login while doing it? Or are those passwords leaking? They are in clear text format in the ghost configs?
Edit:
Screen capture of the Ghost Setup in Azure
To my knowledge this seems totally normal Azure configure step.
The password is stored in clear text in the config.js file, but that is just fine because the file is not accessible from the web.
The reason why GMail complains might be that, in order to send mail, Ghost has to log in to your account with your password. In this case, requests are not coming from your personal computer, but from the Azure server that is in a data center somewhere.
But it's probably not the best idea to ignore the warning, because somebody might have actually breached your account. I would simply use another service for Ghost (like Mailgun).
I have an issue with SharePoint search.
The situation
The server is installed with
SharePoint on a farm with 2 servers.
A new app pool is created and that app pool is using a domain account called moss_service.
moss_service is set to be in the administrator group in both server.
moss_service is also set to be the db_creator in the content database.
When I checked it initially, the search's default content access account is using another different account, I changed that to be using moss_service account.
I didn't do IIS reset because this is a production server, they dont want frequent iis reset.
Strangely, checking the services.msc under "office sharepoint server search" the account is still using an old one. (and apparently it's only running on 1 server, the other server is not running) I then change that to the following:
domain\moss_service with the password.
and then I rerun the crawl.
How do I diagnose the issue
Basically everytime I change something I restart the crawl and then check the event viewer. Multiple things come out but the following is the major ones:
The start address cannot be
crawled. The password for the content
access account cannot be decrypted
because it was stored with different
credentials. Re-type the password for
the account used to crawl this
content. (0x80042406)
Performance monitoring cannot be
initialized for the gatherer object,
because the counters are not loaded or
the shared memory object cannot be
opened. This only affects availability
of the perfmon counters. Restart the
computer.
Access is denied. Check that the
Default Content Access Account has
access to this content, or add a crawl
rule to crawl this content.
(0x80041205)
Crawl Logs Result
The crawl log is showing this:
The password for the content access account cannot be decrypted because it was stored with different credentials. Re-type the password for the account used to crawl this content.
I tried changing it again at service.mstsc and the rerun the full crawl again but then it doesn't work. I have tried entering it using the following way:
moss_service#domain.local
and
domain\moss_service
My Questions are:
How do I fix this?
Is this the right way to setup the
search?
Does the search account has to be
using a different domain account?
Seemed like one fix complicates the
other, how do I set this right?
Is it worth it to upgrade to sp2?
Google this you will get answer " Access is denied. Check that the Default Content Access Account has access to this content, or add a crawl rule to crawl this content. "
Alex, I think you need to completely reconfigure the search services. Keep in mind that the search crawler should be an account with least privileges (not your application service account!). Also, the indexer only runs on one server and whether the search crawler runs on one or more machines is another configuration issue. Also, some settings changes (like changing the crawled File Types) even require the search engine to be restarted.
The start address cannot be crawled. The password for the content
access account cannot be decrypted because it was stored with
different credentials. Re-type the password for the account used to
crawl this content.
For this error,
Open the Sharepoint administration
Click on "Application Management"
Click on "Manage service applications"
Click on "Search Service Application"
Click on the current value for "Default content access account" and re-enter the user's password, or update to another admin user.